Without the patched virtinst, this can be reproduced simply by attempting a normal paravirt virt-install with the params -x \&\; This produces the error shown above: libvirtError: virDomainCreateLinux() failed POST operation failed: (xend.err 'Invalid configuration unexpected EOF')
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
I wonder if the remains at the libvirt level are just a duplicate of #428879 Basically on a RHEL-5.2 with libvirt updated to libvirt-0.3.3-9 with the fix I see the following: [root@test ~]# gdb /usr/bin/python [...] (gdb) b virDomainCreateLinux Function "virDomainCreateLinux" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (virDomainCreateLinux) pending. (gdb) r /usr/bin/virt-install -n test428209 -f /data/test428209.img -s 4 -p -r 512 --noautoconsole --nographics -l http://192.168.0.12/RHEL5/ -x \&\; Starting program: /usr/bin/python /usr/bin/virt-install -n test428209 -f /data/test428209.img -s 4 -p -r 512 --noautoconsole --nographics -l http://192.168.0.12/RHEL5/ -x \&\; [...] so here I add the extra argument as suggested in comment #1 Breakpoint 2, virDomainCreateLinux (conn=0x1ffed860, xmlDesc=0x2001eb14 "<domain type='xen'>\n <name>test428209</name>\n <currentMemory>524288</currentMemory>\n <memory>524288</memory>\n <uuid>2f1f61b4-6558-efc5-6af7-2648e2e64a4a</uuid>\n <os>\n <type>linux</type>\n <k"..., flags=0) at libvirt.c:861 861 { (gdb) So here we are in libvirt and we can look at the XML generated (gdb) p xmlDesc + 200 $4 = 0x2001ebdc "ernel>/var/lib/xen/virtinst-vmlinuz.l1Yduj</kernel>\n <initrd>/var/lib/xen/virtinst-initrd.img.LQSXRR</initrd>\n <cmdline>&amp; method=http://192.168.0.12/RHEL5/</cmdline>\n </os>\n <on_powero"... (gdb) So the '&' passed from the command line results in the XML to an '&amp;' which is the correctly escaped value passed as the argument. let's see what happens down when passing the output to Xen: (gdb) b xenDaemonDomainCreateLinux Breakpoint 3 at 0x2b89d05c6520: file xend_internal.c, line 1010. (gdb) c Continuing. Breakpoint 3, xenDaemonDomainCreateLinux (xend=0x1ffed860, sexpr=0x2001ee70 "(vm (name 'test428209')(memory 512)(maxmem 512)(vcpus 1)(uuid '2f1f61b4-6558-efc5-6af7-2648e2e64a4a')(on_poweroff 'destroy')(on_reboot 'destroy')(on_crash 'destroy')(image (linux (kernel '/var/lib/xen"...) at xend_internal.c:1010 1010 { (gdb) p sexpr + 150 $6 = 0x2001ef06 "rash 'destroy')(image (linux (kernel '/var/lib/xen/virtinst-vmlinuz.l1Yduj')(ramdisk '/var/lib/xen/virtinst-initrd.img.LQSXRR')(args '& method=http://192.168.0.12/RHEL5/')))(device (tap (dev 'xvda"... (gdb) to me the argument are then passed correctly via the Sexpr to xend. On the receiving side i see the following in the xend logs: [2008-06-20 14:54:07 xend 5841] ERROR (SrvBase:88) Request create failed. Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/xen/web/SrvBase.py", line 85, in perform return op_method(op, req) File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDomainDir.py", line 75, in op_create raise XendError(errmsg) XendError: Invalid configuration unexpected EOF I dont know why xend reacts that way, but from a libvirt viewpoint it looks fine now with the patch for 428879 libvirt-0.3.3-9.el5 has been built in dist-5E-qu-candidate and I think this fixes the libvirt part, but I'm not 100% sure Daniel
This still fails for me with the following: # rpm -qa | egrep "xen|libvirt" xen-libs-3.0.3-73.el5 kernel-xen-2.6.18-121.el5 libvirt-python-0.3.3-14.el5 libvirt-0.3.3-14.el5 xen-3.0.3-73.el5 # virt-install --name testing --location nfs:bigpapi.bos.redhat.com:/vol/engineering/redhat/rel-eng/RHEL5.3-Server-20081029.0/5/x86_64/os --nonsparse --paravirt --file /var/lib/xen/images/test_guest -s 5 --ram 512 --nographics -x \&\; Starting install... Creating storage file... | 5.0 GB 01:36 virDomainCreateLinux() failed POST operation failed: (xend.err 'Invalid configuration unexpected EOF') Domain installation may not have been successful. If it was, you can restart your domain by running 'virsh start testing'; otherwise, please restart your installation. Mon, 17 Nov 2008 22:06:09 ERROR virDomainCreateLinux() failed POST operation failed: (xend.err 'Invalid configuration unexpected EOF') Traceback (most recent call last): File "/usr/sbin/virt-install", line 560, in ? main() File "/usr/sbin/virt-install", line 492, in main dom = guest.start_install(conscb, progresscb, wait=(not wait)) File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 822, in start_install return self._do_install(consolecb, meter, wait) File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 843, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib64/python2.4/site-packages/libvirt.py", line 573, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: virDomainCreateLinux() failed POST operation failed: (xend.err 'Invalid configuration unexpected EOF') In line with what DV said, xend.log says: Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/xen/web/SrvBase.py", line 85, in perform return op_method(op, req) File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDomainDir.py", line 75, in op_create raise XendError(errmsg) XendError: Invalid configuration unexpected EOF
Please see comment #5: this is the expected result. We fixed the bug on our end (virt-install/libvirt) but unfortunately xen is choking on that output somehow (most likely a xen bug). From the virt-install space we are really doing everything we can. Unfortunately if xen doesn't accept this it's kind of useless, but that's all this bug covered.
If that fits the process, it's fine by me. Since the end-user experience doesn't change, it doesn't call for a release note/errata doc, so dup + close sounds fine.
Agreement that this is fixed in 5.3 and another bug for Xend is needed for 5.4. Moved back to on_qa, cleared blocker.
Ok bug #472437 created for xend for 5.4 .
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0142.html