On Thu, Aug 14, 2008 at 10:48:20AM +0200, Stefan de Konink wrote:
Output from dumpxml:
<domain type='xen' id='-1'> <name>unittest_200808081319_00010</name> <uuid>380ac319-6b7c-a471-305c-e467c1672c73</uuid> <bootloader/> <os> <type>linux</type> <kernel>/usr/lib/xen/boot/linux-2.6.20-xen-r6</kernel> <cmdline> root=/dev/xvda ro</cmdline> </os> <memory>131072</memory> <vcpu>1</vcpu> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <disk type='file' device='disk'> <driver name='tap' type='aio'/> <source file='/mnt/images/unittest_200808081319_1'/> <target dev='xvda' bus='xen'/> </disk> <interface type='bridge'> <source bridge='xenbr0'/> <target dev='vif-1.0'/> <mac address='00:16:3E:00:00:1E'/> <ip address='85.17.131.40'/> <script path='vif-bridge'/> </interface> <console type='pty'> <target port='0'/> </console> </devices> </domain>
Can you provide the corresponding output of 'xm list --long unittest_200808081319_00010' The handling of bootloaders has changed in XenD sooooo many times I wouldn't be surprised if we have a bug in this area with certain Xen versions.
*bootloader was never specified*
Now if I create that file again look at the changes:
<domain type='xen' id='-1'> <name>unittest_200808081319_00010</name> <uuid>380ac319-6b7c-a471-305c-e467c1672c73</uuid> <bootloader/> <os> <type>linux</type> </os> <memory>131072</memory> <vcpu>1</vcpu> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <disk type='file' device='disk'> <driver name='tap' type='aio'/> <source file='/mnt/images/unittest_200808081319_00010_1'/> <target dev='xvda' bus='xen'/> </disk> <interface type='bridge'> <source bridge='xenbr0'/> <target dev='vif-1.0'/> <mac address='00:16:3E:00:00:1E'/> <ip address='85.17.131.40'/> <script path='vif-bridge'/> </interface> <console type='pty'> <target port='0'/> </console> </devices> </domain>
Looks interesting he :)
This is clearly broken - can you provide the 'xm list --long' output at this time too, so we can see where the kernel/initrd went. Also the '/var/log/xen/xend.log' file wil show us what config was passed to Xen at VM creation time.
Now the only way to get the <os /> childnodes back is to remove the bootloader node. I think we can see this as a bug :)
Absoutely - please file a BZ with all this xm list info & the XML files at http://bugzilla.redhat.com Under the 'Virtualization Tools' product, and 'libvirt' componet. Then we can see about fixing it & adding another test case to ensure it doesn't break again Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|