Bug 428209 - virt-install lacks XML escaping of extra-args
virt-install lacks XML escaping of extra-args
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt (Show other bugs)
5.1
All Linux
low Severity low
: rc
: ---
Assigned To: Daniel Veillard
Virtualization Bugs
:
Depends On: 324701
Blocks: 449772
  Show dependency treegraph
 
Reported: 2008-01-09 17:43 EST by Cole Robinson
Modified: 2009-12-14 16:23 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 16:22:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 1 Cole Robinson 2008-01-09 17:54:36 EST
Without the patched virtinst, this can be reproduced simply by attempting a
normal paravirt virt-install with the params -x \&amp\;

This produces the error shown above:

libvirtError: virDomainCreateLinux() failed POST operation failed:
(xend.err 'Invalid configuration unexpected EOF')
Comment 3 RHEL Product and Program Management 2008-06-02 16:25:12 EDT
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.
Comment 4 Daniel Veillard 2008-06-20 10:34:42 EDT
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 \&amp\;
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 \&amp\;
[...]

  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;amp;
method=http://192.168.0.12/RHEL5/</cmdline>\n  </os>\n  <on_powero"...
(gdb) 

  So the '&amp;' passed from the command line results in the XML
to an '&amp;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 '&amp;
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
Comment 6 Gurhan Ozen 2008-11-17 22:14:30 EST
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 \&amp\; 


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
Comment 8 Cole Robinson 2008-11-18 09:40:56 EST
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.
Comment 11 Cole Robinson 2008-11-18 13:53:21 EST
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.
Comment 12 Bill Burns 2008-11-19 14:44:41 EST
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.
Comment 13 Gurhan Ozen 2008-11-20 15:26:53 EST
Ok bug #472437 created for xend for 5.4 .
Comment 15 errata-xmlrpc 2009-01-20 16:22:10 EST
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

Note You need to log in before you can comment on or make changes to this bug.