[libvirt] Reusing dumpxml output
I would like to reuse configurations that have been edited using the libvirt api. For example by attaching interfaces. Now the output that dumpxml generates, is very 'specific' to an active configuration. I am not able to use a stored configuration from an active domain to redefine it after it has been undefined. Is there a trick to do so? Or should one really strip all 'live' attributes first? Stefan
You need to take care of only two parameters ID and VNC port, other things will remain. If you want to put different path for disk you can do that as well. API is already available to define by you own xml. Even if you don't modify the id/vnc it doesn't matter, everything is taken care by libvirt. On Thu, 2008-08-14 at 01:04 +0200, Stefan de Konink wrote:
I would like to reuse configurations that have been edited using the libvirt api. For example by attaching interfaces.
Now the output that dumpxml generates, is very 'specific' to an active configuration. I am not able to use a stored configuration from an active domain to redefine it after it has been undefined. Is there a trick to do so? Or should one really strip all 'live' attributes first?
Stefan
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Thanks & Regards --Ajish
On Thu, 14 Aug 2008, ajishrao wrote:
You need to take care of only two parameters ID and VNC port, other things will remain. If you want to put different path for disk you can do that as well. API is already available to define by you own xml. Even if you don't modify the id/vnc it doesn't matter, everything is taken care by libvirt.
Technically the VIF also changes, and what I see if I completely reuse the config, it automatically gets a <bootloader /> (I think it changes to hvm) Stefan
On Thu, 2008-08-14 at 09:42 +0200, Stefan de Konink wrote:
On Thu, 14 Aug 2008, ajishrao wrote:
You need to take care of only two parameters ID and VNC port, other things will remain. If you want to put different path for disk you can do that as well. API is already available to define by you own xml. Even if you don't modify the id/vnc it doesn't matter, everything is taken care by libvirt.
Technically the VIF also changes, and what I see if I completely reuse the config, it automatically gets a <bootloader /> (I think it changes to hvm)
You are right thats why it uses script in VIF to manage it. Yes you can use complete config. I really didn't understand your concern about <bootloader/> can you elaborate little more
Stefan
Thanks & Regards --Ajish
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> *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 :) 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 :) Stefan
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 :|
On Thu, 14 Aug 2008, Daniel P. Berrange wrote:
Then we can see about fixing it & adding another test case to ensure it doesn't break again
I'm going to upgrade to the latest git to be sure, I'll report back soon. Stefan
On Thu, 14 Aug 2008, Stefan de Konink wrote:
On Thu, 14 Aug 2008, Daniel P. Berrange wrote:
Then we can see about fixing it & adding another test case to ensure it doesn't break again
I'm going to upgrade to the latest git to be sure, I'll report back soon.
New version fixes the issue. I still have another issue with respect to a segmentation fault on exit (libvirtd), but i'm not able to reproduce it consistently. (I think it is with respect to an umount) Stefan
On Thu, Aug 14, 2008 at 09:42:09AM +0200, Stefan de Konink wrote:
On Thu, 14 Aug 2008, ajishrao wrote:
You need to take care of only two parameters ID and VNC port, other things will remain. If you want to put different path for disk you can do that as well. API is already available to define by you own xml. Even if you don't modify the id/vnc it doesn't matter, everything is taken care by libvirt.
Technically the VIF also changes, and what I see if I completely reuse the config, it automatically gets a <bootloader /> (I think it changes to hvm)
The <target dev='vifXXX'> element is ignored when creating a VM if it contains an auto-allocated VIF name. 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 :|
On Thu, Aug 14, 2008 at 09:42:09AM +0200, Stefan de Konink wrote:
You need to take care of only two parameters ID and VNC port, other things will remain. If you want to put different path for disk you can do that as well. API is already available to define by you own xml. Even if you don't modify the id/vnc it doesn't matter, everything is taken care by libvirt.
Technically the VIF also changes, and what I see if I completely reuse the config, it automatically gets a <bootloader /> (I think it changes to hvm)
The reporting of a serial console for Xen is also very flaky in dumpxml regards john
On Thu, Aug 14, 2008 at 12:09:24PM +0530, ajishrao wrote:
You need to take care of only two parameters ID and VNC port, other things will remain. If you want to put different path for disk you can do that as well. API is already available to define by you own xml. Even if you don't modify the id/vnc it doesn't matter, everything is taken care by libvirt.
That is no longer neccessary - we ignore the 'id' attribute when creating a domain, and the VNC port syntax has been extended so we can explicitly track whether the VNC port is auto-allocated or not Any further problems in this area are bugs. 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 :|
On Thu, Aug 14, 2008 at 01:04:56AM +0200, Stefan de Konink wrote:
I would like to reuse configurations that have been edited using the libvirt api. For example by attaching interfaces.
Now the output that dumpxml generates, is very 'specific' to an active configuration. I am not able to use a stored configuration from an active domain to redefine it after it has been undefined. Is there a trick to do so? Or should one really strip all 'live' attributes first?
The XML is supposed to be idempotent - the XML you get from 'dumpxml' should be able to be fed back into 'create' resulting in exactly the same VM config. Previously there were a few places where you had to tweak the XML, eg to remove the auto-allocated VNC port, or remove the VIF target device name. In current CVS those issues are all fixed, so you should not have to change anything in the XML. So any further problems in this area are definitely bugs. There is also the option to request the 'inactive' XML dump for a running domain which removes any auto-allocated params. This is just a convenience though, and not required for re-creating the VM later. 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 :|
On Thu, 14 Aug 2008, Daniel P. Berrange wrote:
On Thu, Aug 14, 2008 at 01:04:56AM +0200, Stefan de Konink wrote:
I would like to reuse configurations that have been edited using the libvirt api. For example by attaching interfaces.
Now the output that dumpxml generates, is very 'specific' to an active configuration. I am not able to use a stored configuration from an active domain to redefine it after it has been undefined. Is there a trick to do so? Or should one really strip all 'live' attributes first?
The XML is supposed to be idempotent - the XML you get from 'dumpxml' should be able to be fed back into 'create' resulting in exactly the same VM config.
Previously there were a few places where you had to tweak the XML, eg to remove the auto-allocated VNC port, or remove the VIF target device name. In current CVS those issues are all fixed, so you should not have to change anything in the XML. So any further problems in this area are definitely bugs.
There is also the option to request the 'inactive' XML dump for a running domain which removes any auto-allocated params. This is just a convenience though, and not required for re-creating the VM later.
Do you see the <bootloader /> bug? Or am I using a buggy git version? I'll try the inactive parameter, that should be better in general. Stefan
On Thu, 2008-08-14 at 10:12 +0100, Daniel P. Berrange wrote:
There is also the option to request the 'inactive' XML dump for a running domain which removes any auto-allocated params. This is just a convenience though, and not required for re-creating the VM later.
What version is this in I don't see this in the F9 virsh (libvir 0.4.4) or is it just not documented.
Daniel
On Thu, Aug 14, 2008 at 03:31:04PM -0400, Andrew Cathrow wrote:
On Thu, 2008-08-14 at 10:12 +0100, Daniel P. Berrange wrote:
There is also the option to request the 'inactive' XML dump for a running domain which removes any auto-allocated params. This is just a convenience though, and not required for re-creating the VM later.
What version is this in I don't see this in the F9 virsh (libvir 0.4.4) or is it just not documented.
It is not exposed in virsh yet - only in the C api. It will only be useful as of 0.4.5 (yet to be released) because all current versions ignore the 'inactive' flag. 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 :|
participants (5)
-
ajishrao -
Andrew Cathrow -
Daniel P. Berrange -
John Levon -
Stefan de Konink