Open Stack

So what I've figured out is the following seems to work with xen4.

$ diff  nova-2011.3/nova/virt/libvirt.xml.template  libvirt.xml.template
21c21
<             <root>/dev/xvda</root>
---
>             <root>/dev/sda</root>
46a47,49
>     #if $type == 'xen'
>       <bootloader>/usr/lib/xen-4.0/bin/pygrub</bootloader>
>     #end if
62c65,69
<             <target dev='${disk_prefix}a' bus='${disk_bus}'/>
---
>             #if $type == 'xen'
>                <target dev='${disk_prefix}a1' bus='${disk_bus}'/>
>             #else
>                <target dev='${disk_prefix}a' bus='${disk_bus}'/>
>             #end if
74c81,85
<             <target dev='${disk_prefix}a' bus='${disk_bus}'/>
---
>             #if $type == 'xen'
>                <target dev='${disk_prefix}a1' bus='${disk_bus}'/>
>             #else
>                <target dev='${disk_prefix}a' bus='${disk_bus}'/>
>             #end if

This seems to get the VM to start in xen4. Now another issue is coming up that should be easier. Seeing the console output I am now stuck at the following.

Begin: Running /scripts/local-premount ... done.
[    0.460986] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.
[    1.348832] EXT4-fs (sda1): re-mounted. Opts: (null)
cloud-init start-local running: Fri, 19 Aug 2011 21:34:59 +0000. up 4.01 seconds
no instance data found in start-local
init: cloud-init-local main process (186) terminated with status 1

What would be causing that? If anyone knows.



On 8/19/11 10:52 AM, "Joshua Harlow" <harlowja at yahoo-inc.com> wrote:

For my nova/virt/libvirt.xml.template on my compute node.

The following is being done.

  #if $type == 'xen'
        #set $disk_prefix = 'sd'
        #set $disk_bus = 'scsi'
            <type>linux</type>
            <root>/dev/xvda</root>

Should that be /dev/sda for the /root node here?

On 8/19/11 10:24 AM, "Joshua Harlow" <harlowja at yahoo-inc.com> wrote:

Ya, that is what I was thinking also.

I haven't customized anything though. This is just the normal euca-run-instances + basic openstack diablo-3.

$ euca-run-instances  ami-0000001f  -k mykey -t m1.tiny

Where ami is:

IMAGE    ami-0000001f    ubb/maverick-server-uec-amd64.img.manifest.xml        available    private        x86_64    machine    aki-0000001e
IMAGE    aki-0000001e    ubb/maverick-server-uec-amd64-vmlinuz-virtual.manifest.xml        available    private        x86_64    kernel

The original libvirt from openstack is the following (the previous one was from virsh dumpxml):

Maybe there is a bug in the libvirt + xen usage in openstack, since it seems like that file should not be having a "sda" hard drive being used?

The annoying thing is with this crash is that it seems that xen is burning cpu cycles when it does crash, thus making the machine harder to use.

<domain type='xen'>
    <name>instance-0000002c</name>
    <memory>524288</memory>
    <os>
            <type>linux</type>
            <root>/dev/xvda</root>
            <kernel>/home/ctoteam/nova/nova/..//instances/instance-0000002c/kernel</kernel>
                <cmdline>ro</cmdline>
    </os>
    <features>
        <acpi/>
    </features>
    <vcpu>1</vcpu>
    <devices>
        <disk type='file'>
            <driver type='qcow2'/>
            <source file='/home/ctoteam/nova/nova/..//instances/instance-0000002c/disk'/>
            <target dev='sda' bus='scsi'/>
        </disk>

        <interface type='bridge'>
            <source bridge='pan0'/>
            <mac address='02:16:3e:5f:5f:1b'/>
            <!--   <model type='virtio'/>  CANT RUN virtio network right now -->
            <filterref filter="nova-instance-instance-0000002c-02163e5f5f1b">
                <parameter name="IP" value="10.0.0.2" />
                <parameter name="DHCPSERVER" value="192.168.1.1" />
            </filterref>
        </interface>

        <!-- The order is significant here.  File must be defined first -->
        <serial type="file">
            <source path='/home/ctoteam/nova/nova/..//instances/instance-0000002c/console.log'/>
            <target port='1'/>
        </serial>

        <console type='pty' tty='/dev/pts/2'>
            <source path='/dev/pts/2'/>
            <target port='0'/>
        </console>

        <serial type='pty'>
            <source path='/dev/pts/2'/>
            <target port='0'/>
        </serial>

        <graphics type='vnc' port='-1' autoport='yes' keymap='en-us' listen='0.0.0.0'/>
    </devices>
</domain>


On 8/18/11 10:31 PM, "Isaku Yamahata" <yamahata at valinux.co.jp> wrote:

It looks you specified "root=/dev/xvda", but the disk that is
instantiated is /dev/sda.
But I didn't see why it happened. Did you customized the template
for libvirt, libvirt.xml.template?


On Thu, Aug 18, 2011 at 05:54:45PM -0700, Joshua Harlow wrote:
> Hi all,
>
> On xen + openstack diaboli-3 when running an instance with the generic ubuntu
> UEC images  from http://wiki.openstack.org/RunningNova#Registering_the_image  I
> am seeing the following:
>
> [    0.210681] VFS: Cannot open root device "xvda" or unknown-block(0,0)
> [    0.210691] Please append a correct "root=" boot option; here are the
> available partitions:
> [    0.210708] ca00            8192 sda driver: vbd
> [    0.210720] Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
>
> This is on debian 6 (x86-64), is this a location that exists for others?
>
> Here is the xml that was used to create this instance. It looks pretty
> standard. Any xen users out there encountered this?
>
> <domain type='xen' id='18'>
>   <name>instance-0000002b</name>
>   <uuid>a1655436-d1c6-3e2c-bf57-a9c487f21e27</uuid>
>   <memory>524288</memory>
>   <currentMemory>524288</currentMemory>
>   <vcpu>1</vcpu>
>   <bootloader></bootloader>
>   <os>
>     <type>linux</type>
>     <kernel>/home/ctoteam/nova/nova/..//instances/instance-0000002b/kernel</
> kernel>
>     <cmdline>root=/dev/xvda ro</cmdline>
>   </os>
>   <clock offset='utc'/>
>   <on_poweroff>destroy</on_poweroff>
>   <on_reboot>restart</on_reboot>
>   <on_crash>destroy</on_crash>
>   <devices>
>     <emulator>/usr/lib/xen-4.0/bin/qemu-dm</emulator>
>     <disk type='file' device='disk'>
>       <driver name='file'/>
>       <source file='/home/ctoteam/nova/nova/..//instances/instance-0000002b/
> disk'/>
>       <target dev='sda' bus='scsi'/>
>     </disk>
>     <interface type='bridge'>
>       <mac address='02:16:3e:65:67:59'/>
>       <source bridge='pan0'/>
>       <script path='/etc/xen/scripts/vif-bridge'/>
>       <target dev='vif18.0'/>
>     </interface>
>     <console type='pty' tty='/dev/pts/2'>
>       <source path='/dev/pts/2'/>
>       <target type='xen' port='0'/>
>     </console>
>     <input type='mouse' bus='xen'/>
>     <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0' keymap=
> 'en-us'/>
>   </devices>
> </domain>
>
>
>
>

> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


--
yamahata



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110819/d1b96737/attachment.html>