[Libvir] dumpxml define not idempotent due to <bootlader/> tag

Hi, when using "virsh dumpxml <domain> > xmlfile" on a running paravirt xen domain that has no bootloader entry whatsoever I get: ... <bootloader/> <os> <type>linux</type> <kernel>/boot/vmlinuz-vm</kernel> <initrd>/boot/initrd.img-vm</initrd> <cmdline>root=/dev/sda1 ro </cmdline> </os> ... reimporting this via "virsh define xmlfile" and then dumping again gives something like: ... <bootloader/> <os> <type>linux</type> </os> ... since a bootloader tag is found the kernel and initrd entries are being dropped. My hack is to ignore empty bootloader statements for the moment: diff --git a/src/xend_internal.c b/src/xend_internal.c index fd38a61..5428cd7 100644 --- a/src/xend_internal.c +++ b/src/xend_internal.c @@ -1438,9 +1438,6 @@ xend_parse_sexp_desc(virConnectPtr conn, struct sexpr *root, if (tmp != NULL) { bootloader = 1; virBufferVSprintf(&buf, " <bootloader>%s</bootloader>\n", tmp); - } else if (sexpr_has(root, "domain/bootloader")) { - bootloader = 1; - virBufferVSprintf(&buf, " <bootloader/>\n"); } tmp = sexpr_node(root, "domain/bootloader_args"); if (tmp != NULL && bootloader) { Would that be the right place to fix this? Cheers, -- Guido

On Thu, Feb 07, 2008 at 12:38:07PM +0100, Guido Guenther wrote:
Hi, when using "virsh dumpxml <domain> > xmlfile" on a running paravirt xen domain that has no bootloader entry whatsoever I get:
... <bootloader/> <os> <type>linux</type> <kernel>/boot/vmlinuz-vm</kernel> <initrd>/boot/initrd.img-vm</initrd> <cmdline>root=/dev/sda1 ro </cmdline> </os> ...
reimporting this via "virsh define xmlfile" and then dumping again gives something like: ... <bootloader/> <os> <type>linux</type> </os> ... since a bootloader tag is found the kernel and initrd entries are being dropped. My hack is to ignore empty bootloader statements for the moment:
Nope, that's no good - empty bootloader indicates use of the defautl XenD bootloader. What we need is to not drop the kernel/initrd when doing XML to SEXPR back into XenD. We currently create an SXPR with either a (bootloader) or a (kernel) block - we should unconditionally do both & not try to second guess it. IIRC, John mentioned this is already needed for Solaris too. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

Daniel P. Berrange wrote:
On Thu, Feb 07, 2008 at 12:38:07PM +0100, Guido Guenther wrote:
... since a bootloader tag is found the kernel and initrd entries are being dropped. My hack is to ignore empty bootloader statements for the moment:
I've seen this issue as well.
Nope, that's no good - empty bootloader indicates use of the defautl XenD bootloader. What we need is to not drop the kernel/initrd when doing XML to SEXPR back into XenD. We currently create an SXPR with either a (bootloader) or a (kernel) block - we should unconditionally do both & not try to second guess it. IIRC, John mentioned this is already needed for Solaris too.
Ah. So to make sure I understand correctly, the planned resolution is to leave the empty bootloader tag and then ensure that it's handled properly during the domain start? -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
participants (3)
-
Daniel P. Berrange
-
Guido Guenther
-
Kaitlin Rupert