6:04 p.m.
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
1:39 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Thanks & Regards
--Ajish
2:42 a.m.
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
3:55 a.m.
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
3:48 a.m.
New subject: Bug with <bootloader /> (Re: [libvirt] Reusing dumpxml output)
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
4:17 a.m.
New subject: Bug with <bootloader /> (Re: [libvirt] Reusing dumpxml output)
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 :|
4:20 a.m.
New subject: Bug with <bootloader /> (Re: [libvirt] Reusing dumpxml output)
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
4:47 a.m.
New subject: Bug with <bootloader /> (Re: [libvirt] Reusing dumpxml output)
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
4:13 a.m.
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 :|
7:34 a.m.
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
4:13 a.m.
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 :|
4:12 a.m.
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 :|
4:15 a.m.
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
2:31 p.m.
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
5:01 p.m.
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 :|
5945
days inactive
5946
days old
14 comments
5 participants
participants (5)
-
ajishrao -
Andrew Cathrow -
Daniel P. Berrange -
John Levon -
Stefan de Konink