Bug 472437

Summary: Xen driver does not properly escape special chars in sexpr generation
Product: Red Hat Enterprise Linux 5 Reporter: Gurhan Ozen <gozen>
Component: libvirtAssignee: Cole Robinson <crobinso>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 5.4CC: berrange, clalance, crobinso, dallan, gozen, jburke, jdenemar, kirbyzhou, llim, minovotn, syeghiay, vbian, virt-maint, xen-maint
Target Milestone: beta   
Target Release: 5.6   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: libvirt-0.8.2-13.el5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-13 22:51:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 514500    

Comment 4 Cole Robinson 2010-03-16 13:50:19 UTC
I think you should be able to trigger this bug by changing an /etc/xen file from something like

disk="/some/path/to/disk.img'

to

disk="/some/path/to/&amp;disk.img'

then trying to start the VM. If that manages to work, then this bug can probably be closed, since a fixed libvirt and virt-install will make the original xen issue impractical to reproduce.

Comment 6 Michal Novotny 2010-06-01 10:59:26 UTC
Cole,
it isn't such a problem to implement this directly into xen daemon but I don't think it's practical since this is what's being send from libvirt layer.

If you start e.g. virt-install using this syntax:

virt-install --name testing --location /some/location --nonsparse --paravirt --file /var/lib/xen/images/test_guest -s 5 --ram 512 --nographics -x \&amp\; 

It's always going through the libvirt layer so what if we change this to be a HVM guest and instead of Xen we use KVM or pure QEMU? This way we would need to change configuration in all the hypervisors and QEMU emulator as well. If we change this in the libvirt layer directly before passing to hypervisor we would be able to have it fixed for all the hypervisors used with libvirt, wouldn't we? Do you see my point?

Let's say we make a typo like (untested but it should work):

virt-install --name test --location /some/location.iso --nonsparse --hvm --file /var/lib/xen/images/&test.img -s 5 --ram 512

If we fix this in Xen daemon then if the hypervisor is Xen it will start up the domain right and installation will proceed fine. But what if the hypervisor is KVM? Or when we emulate this using pure QEMU? This way it won't be working fine. If we implement the fix in libvirt directly we don't need to worry about the HV used since no matter what the HV is the correct string (i.e. "/var/lib/xen/images/test.img") will be passed to it.

Are you sure that fixing it in Xen is a good idea if you consider what I wrote here right now?

Thanks,
Michal

Comment 7 Cole Robinson 2010-06-01 15:42:47 UTC
This isn't about an accidental typo '&' character, its about trying to use a disk image actually named /tmp/&.img, or a kernel command line actually containing an &, etc.

So, I'd recommend testing that command line you posted:

virt-install --name test --location /some/location.iso --nonsparse --hvm --file
/var/lib/xen/images/\&test.img -s 5 --ram 512

If the xen guest starts up fine, then this bug can be closed. If that command fails, then something needs to be fixed, and virtinst and libvirt were already patched to handle this (though it may have regressed).

Comment 8 Michal Novotny 2010-06-01 16:13:42 UTC
(In reply to comment #7)
> This isn't about an accidental typo '&' character, its about trying to use a
> disk image actually named /tmp/&.img, or a kernel command line actually
> containing an &, etc.

Oh, ok. So it isn't accidental, right? In fact that file cannot not exists at all since '&' character is not a valid character of file system path, can it?

For command "echo something > /var/lib/xen/images/&test.img" I'm having:
# echo something > /var/lib/xen/images/&test.img
[1] 14328
-bash: /var/lib/xen/images/: Is a directory
-bash: test.img: command not found
[1]+  Exit 1                  echo something > /var/lib/xen/images/
#

> 
> So, I'd recommend testing that command line you posted:
> 
> virt-install --name test --location /some/location.iso --nonsparse --hvm --file
> /var/lib/xen/images/\&test.img -s 5 --ram 512
> 
> If the xen guest starts up fine, then this bug can be closed. If that command
> fails, then something needs to be fixed, and virtinst and libvirt were already
> patched to handle this (though it may have regressed).    

Ok, is the patch already available in RHEL-5 libvirt/virtinst to test it with Xen?

I'm using following RPMs on RHEL-5.5 box used for testing:
kernel-xen-2.6.18-194.el5
libvirt-0.6.3-33.el5
kernel-xen-2.6.18-194.3.1.el5
python-virtinst-0.400.3-9.el5
xen-3.0.3-110.el5virttest28.g030a5fc
libvirt-0.6.3-33.el5

And the result of the command is:

# virt-install --name test --location /root/boot.iso --nonsparse --hvm --file /var/lib/xen/images/\&test.img -s 1 --ram 512
Starting install...
ERROR    POST operation failed: xend_post: error from xen daemon: (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 test'; otherwise, please
 restart your installation.
ERROR    POST operation failed: xend_post: error from xen daemon: (xend.err 'Invalid configuration unexpected EOF')
Traceback (most recent call last):
  File "/usr/sbin/virt-install", line 889, in ?
    main()
  File "/usr/sbin/virt-install", line 751, in main
    start_time, guest.start_install)
  File "/usr/sbin/virt-install", line 813, in do_install
    dom = install_func(conscb, progresscb, wait=(not wait))
  File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 541, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 633, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib64/python2.4/site-packages/libvirt.py", line 974, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: POST operation failed: xend_post: error from xen daemon: (xend.err 'Invalid configuration unexpected EOF')

Additionally the file /etc/xen/test was not created so my guess is that libvirt is passing a bad string to the xen daemon and xen daemon doesn't create the file /etc/xen/test to start up the domain.

Thanks,
Michal

Comment 9 Cole Robinson 2010-06-01 16:44:58 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > This isn't about an accidental typo '&' character, its about trying to use a
> > disk image actually named /tmp/&.img, or a kernel command line actually
> > containing an &, etc.
> 
> Oh, ok. So it isn't accidental, right? In fact that file cannot not exists at
> all since '&' character is not a valid character of file system path, can it?
> 
> For command "echo something > /var/lib/xen/images/&test.img" I'm having:
> # echo something > /var/lib/xen/images/&test.img
> [1] 14328
> -bash: /var/lib/xen/images/: Is a directory
> -bash: test.img: command not found
> [1]+  Exit 1                  echo something > /var/lib/xen/images/
> #
> 

& is a valid path character:

$ touch "foo&.img"
$ ls foo*
foo&.img

> > 
> > So, I'd recommend testing that command line you posted:
> > 
> > virt-install --name test --location /some/location.iso --nonsparse --hvm --file
> > /var/lib/xen/images/\&test.img -s 5 --ram 512
> > 
> > If the xen guest starts up fine, then this bug can be closed. If that command
> > fails, then something needs to be fixed, and virtinst and libvirt were already
> > patched to handle this (though it may have regressed).    
> 
> Ok, is the patch already available in RHEL-5 libvirt/virtinst to test it with
> Xen?
> 
> I'm using following RPMs on RHEL-5.5 box used for testing:
> kernel-xen-2.6.18-194.el5
> libvirt-0.6.3-33.el5
> kernel-xen-2.6.18-194.3.1.el5
> python-virtinst-0.400.3-9.el5
> xen-3.0.3-110.el5virttest28.g030a5fc
> libvirt-0.6.3-33.el5
> 
> And the result of the command is:
> 

Should be.

> # virt-install --name test --location /root/boot.iso --nonsparse --hvm --file
> /var/lib/xen/images/\&test.img -s 1 --ram 512
> Starting install...
> ERROR    POST operation failed: xend_post: error from xen daemon: (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 test'; otherwise, please
>  restart your installation.
> ERROR    POST operation failed: xend_post: error from xen daemon: (xend.err
> 'Invalid configuration unexpected EOF')
> Traceback (most recent call last):
>   File "/usr/sbin/virt-install", line 889, in ?
>     main()
>   File "/usr/sbin/virt-install", line 751, in main
>     start_time, guest.start_install)
>   File "/usr/sbin/virt-install", line 813, in do_install
>     dom = install_func(conscb, progresscb, wait=(not wait))
>   File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 541, in
> start_install
>     return self._do_install(consolecb, meter, removeOld, wait)
>   File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 633, in
> _do_install
>     self.domain = self.conn.createLinux(install_xml, 0)
>   File "/usr/lib64/python2.4/site-packages/libvirt.py", line 974, in
> createLinux
>     if ret is None:raise libvirtError('virDomainCreateLinux() failed',
> conn=self)
> libvirtError: POST operation failed: xend_post: error from xen daemon:
> (xend.err 'Invalid configuration unexpected EOF')
> 
> Additionally the file /etc/xen/test was not created so my guess is that libvirt
> is passing a bad string to the xen daemon and xen daemon doesn't create the
> file /etc/xen/test to start up the domain.
>

Or, libvirt is passing a valid value, and xen is choking on it. Xen doesn't create the /etc/xen/test file anyways, libvirt does in this case. 
 
Another way to test, take an existing guest and rename it's disk image to have an & in it. Edit the /etc/xen file and have it point to the new disk image path with the & in it. see if xm start $vmname  . if not, xen bug.

Comment 10 Michal Novotny 2010-06-07 09:42:55 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > This isn't about an accidental typo '&' character, its about trying to use a
> > > disk image actually named /tmp/&.img, or a kernel command line actually
> > > containing an &, etc.
> > 
> > Oh, ok. So it isn't accidental, right? In fact that file cannot not exists at
> > all since '&' character is not a valid character of file system path, can it?
> > 
> > For command "echo something > /var/lib/xen/images/&test.img" I'm having:
> > # echo something > /var/lib/xen/images/&test.img
> > [1] 14328
> > -bash: /var/lib/xen/images/: Is a directory
> > -bash: test.img: command not found
> > [1]+  Exit 1                  echo something > /var/lib/xen/images/
> > #
> > 
> 
> & is a valid path character:
> 
> $ touch "foo&.img"
> $ ls foo*
> foo&.img
> 

Oh, ok. I didn't know that because of my testing which resulted into error (I mean for the "echo something > /var/lib/xen/images/&test.img" command).

> > > 
> > > So, I'd recommend testing that command line you posted:
> > > 
> > > virt-install --name test --location /some/location.iso --nonsparse --hvm --file
> > > /var/lib/xen/images/\&test.img -s 5 --ram 512
> > > 
> > > If the xen guest starts up fine, then this bug can be closed. If that command
> > > fails, then something needs to be fixed, and virtinst and libvirt were already
> > > patched to handle this (though it may have regressed).    
> > 
> > Ok, is the patch already available in RHEL-5 libvirt/virtinst to test it with
> > Xen?
> > 
> > I'm using following RPMs on RHEL-5.5 box used for testing:
> > kernel-xen-2.6.18-194.el5
> > libvirt-0.6.3-33.el5
> > kernel-xen-2.6.18-194.3.1.el5
> > python-virtinst-0.400.3-9.el5
> > xen-3.0.3-110.el5virttest28.g030a5fc
> > libvirt-0.6.3-33.el5
> > 
> > And the result of the command is:
> > 
> 
> Should be.
> 
> > # virt-install --name test --location /root/boot.iso --nonsparse --hvm --file
> > /var/lib/xen/images/\&test.img -s 1 --ram 512
> > Starting install...
> > ERROR    POST operation failed: xend_post: error from xen daemon: (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 test'; otherwise, please
> >  restart your installation.
> > ERROR    POST operation failed: xend_post: error from xen daemon: (xend.err
> > 'Invalid configuration unexpected EOF')
> > Traceback (most recent call last):
> >   File "/usr/sbin/virt-install", line 889, in ?
> >     main()
> >   File "/usr/sbin/virt-install", line 751, in main
> >     start_time, guest.start_install)
> >   File "/usr/sbin/virt-install", line 813, in do_install
> >     dom = install_func(conscb, progresscb, wait=(not wait))
> >   File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 541, in
> > start_install
> >     return self._do_install(consolecb, meter, removeOld, wait)
> >   File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 633, in
> > _do_install
> >     self.domain = self.conn.createLinux(install_xml, 0)
> >   File "/usr/lib64/python2.4/site-packages/libvirt.py", line 974, in
> > createLinux
> >     if ret is None:raise libvirtError('virDomainCreateLinux() failed',
> > conn=self)
> > libvirtError: POST operation failed: xend_post: error from xen daemon:
> > (xend.err 'Invalid configuration unexpected EOF')
> > 
> > Additionally the file /etc/xen/test was not created so my guess is that libvirt
> > is passing a bad string to the xen daemon and xen daemon doesn't create the
> > file /etc/xen/test to start up the domain.
> >
> 
> Or, libvirt is passing a valid value, and xen is choking on it. Xen doesn't
> create the /etc/xen/test file anyways, libvirt does in this case. 

So why doesn't libvirt create the file to see what's being passed? To clarify it: it should be working for definition like "/var/lib/xen/images/&amp;rhel3-64fv.img" provided the fact that the file exists. Right?

> 
> Another way to test, take an existing guest and rename it's disk image to have
> an & in it. Edit the /etc/xen file and have it point to the new disk image path
> with the & in it. see if xm start $vmname  . if not, xen bug.    

Ok, I see what you mean. So you did confirm what I wrote above. I'll do the testing and let you know.

Michal

Comment 11 Michal Novotny 2010-06-08 08:50:25 UTC
...
> 
> Ok, I see what you mean. So you did confirm what I wrote above. I'll do the
> testing and let you know.
> 
> Michal    

Cole,
I did testing of this one and renamed /home2/test.img to /home2/t&est.img using the Midnight Commander and it started successfully. In xenstore there was:

      2048 = ""
       domain = "rhel5-32fv"
       frontend = "/local/domain/1/device/vbd/2048"
       format = "raw"
       dev = "sda"
       state = "2"
       params = "/home2/t&est.img"
       mode = "r"
       online = "1"
       frontend-id = "1"
       type = "file"
       node = "/dev/loop0"
       physical-device = "7:0"
       hotplug-status = "connected"

and the disk was accessible in the guest. The definition in xen domain configuration file was:

disk = [ "file:/var/lib/xen/images/colossus/rhel5-32fv.img,hda,w", "file:/home2/t&est.img,sda,w" ]

I used it as a second drive. I also did try to define it like "file:/home2/t&amp;est.img,sda,w" and this was not working returning an error:

# xm create rhel5-32fv
Using config file "/etc/xen/rhel5-32fv".
Error: Disk image does not exist: /home2/t&amp;est.img
#

I did try it using the latest xen RPMs. So, my suggestion is to make libvirt pass the correct (un-escaped) argument here to make such a xen domain configuration work although it *may* be possible that we can un-escape it in xen daemon itself. So what do you think, Cole?

Thanks,
Michal

Comment 12 Michal Novotny 2010-06-09 08:25:14 UTC
Well, I've been talking to Mirek (mrezanin) and we both think that fixing this in libvirt directly to pass non-escaped string to xen daemon is a better way to go.

Michal

Comment 13 Michal Novotny 2010-06-14 10:11:06 UTC
Based on conversation with Mirek we decided to move it to libvirt space.

Michal

Comment 14 Daniel Berrangé 2010-07-06 15:14:15 UTC
> # xm create rhel5-32fv
> Using config file "/etc/xen/rhel5-32fv".
> Error: Disk image does not exist: /home2/t&amp;est.img

What is the actual bug here ?  Is the bug that libvirt is not generating the /etc/xen/rhel5-32fv file correctly ? Or is it that XenD simply can't cope with '&' in disk names, even when the config file is correctly generated. 

If this is a libvirt bug, please provide 2 things:

 - A libvirt XML document for $GUESTNAME
 - A corresponding *correct* /etc/xen/$GUESTNAME file

Comment 15 Michal Novotny 2010-07-07 13:05:57 UTC
(In reply to comment #14)
> > # xm create rhel5-32fv
> > Using config file "/etc/xen/rhel5-32fv".
> > Error: Disk image does not exist: /home2/t&amp;est.img
> 
> What is the actual bug here ?  Is the bug that libvirt is not generating the
> /etc/xen/rhel5-32fv file correctly ? Or is it that XenD simply can't cope with
> '&' in disk names, even when the config file is correctly generated. 
> 
> If this is a libvirt bug, please provide 2 things:
> 
>  - A libvirt XML document for $GUESTNAME
>  - A corresponding *correct* /etc/xen/$GUESTNAME file    

Well, I don't have it Daniel but you're right about /etc/xen/rhel5-32fv not generated correctly, the problem was reproduced using the Cole's suggestion from comment #9, i.e. I did try the definition using:

disk=[ "file:/path/to/&file.img,hda,w" ]

and it passed but not using the libvirt since libvirt seems to be escaping it to &amp;file.img but this is not valid since the file name is &file.img and *not* &amp;file.img.

Michal

Comment 16 Cole Robinson 2010-07-26 15:40:00 UTC
I took another look at this. If a VM has disk pointing to /tmp/&frob.img, we correctly write out an /etc/xen config:

disk = [ "file:/tmp/&frob.img,hda,w" ]

If we then run xm create <vmname>, the generated sexpr looks like:

    (device
        (vbd (backend 0) (dev hda:disk) (uname 'file:/tmp/&frob.img') (mode w))
    )

If we drop the & from the filename, xm doesn't wrap the file: part in single quotes. I assume when libvirt generates the sexpr, we aren't adding the single quotes. So this is a libvirt bug.

Comment 17 Kirby Zhou 2010-08-07 07:17:00 UTC
I have encounter nearly the same situation.


virt-install -d --name=rhel5xenguest --vcpus=2 --ram=2048 --disk=vol=vgext/rhel5xenguest.img,size=24 --os-variant=rhel5 -l http://ftp.no.sohu.com/pub/os/Linux/RedHat/enterprise/x86_64/5ASU5/dvd/ --nographics -x 'ks=http://192.168.1.201/pub/ks/as-ins.php?v=5AS&a=x86_64&r=U5 ip=10.12.10.190 netmask=255.255.252.0 gateway=10.12.11.254 type=rd'

failed because of 'ks=http://192.168.1.201/pub/ks/as-ins.php?v=5AS&a=x86_64&r=U5'


Sat, 07 Aug 2010 15:16:22 DEBUG    Requesting libvirt URI default
Sat, 07 Aug 2010 15:16:22 DEBUG    Received libvirt URI 'xen:///'
Sat, 07 Aug 2010 15:16:22 DEBUG    Requesting virt method 'default'
Sat, 07 Aug 2010 15:16:22 DEBUG    Received virt method 'xen'
Sat, 07 Aug 2010 15:16:22 DEBUG    Hypervisor name is 'xen'
Sat, 07 Aug 2010 15:16:22 DEBUG    Parsed volume: as pool='vgext' vol='rhel5xenguest.img'
Sat, 07 Aug 2010 15:16:22 DEBUG    parse_disk: returning (None, ('vgext', 'rhel5xenguest.img'), None, 'disk', None, False, False, 24.0, True, None)
Sat, 07 Aug 2010 15:16:22 DEBUG    Overwriting 'path' with value from StorageVolume object.
Sat, 07 Aug 2010 15:16:22 DEBUG    Detected storage as type 'block'
Sat, 07 Aug 2010 15:16:22 DEBUG    Setting os type to 'linux' for variant 'rhel5'
Sat, 07 Aug 2010 15:16:22 DEBUG    DistroInstaller location is a network source.


Starting install...
Sat, 07 Aug 2010 15:16:22 DEBUG    Attempting to detect distro:
Sat, 07 Aug 2010 15:16:22 DEBUG    Fetching URI: http://ftp.no.sohu.com/pub/os/Linux/RedHat/enterprise/x86_64/5ASU5/dvd/.treeinfo
Sat, 07 Aug 2010 15:16:22 DEBUG    Saved file to /var/lib/xen/virtinst-.treeinfo.yyy46w
Retrieving file .treeinfo...                                                                                 |  442 B     00:00     
Sat, 07 Aug 2010 15:16:22 DEBUG    Fetching URI: http://ftp.no.sohu.com/pub/os/Linux/RedHat/enterprise/x86_64/5ASU5/dvd/images/xen/vmlinuz
Sat, 07 Aug 2010 15:16:22 DEBUG    Saved file to /var/lib/xen/virtinst-vmlinuz.IhwIiK
Retrieving file vmlinuz...                                                                                   | 2.0 MB     00:00     
Sat, 07 Aug 2010 15:16:22 DEBUG    Fetching URI: http://ftp.no.sohu.com/pub/os/Linux/RedHat/enterprise/x86_64/5ASU5/dvd/images/xen/initrd.img
Sat, 07 Aug 2010 15:16:22 DEBUG    Saved file to /var/lib/xen/virtinst-initrd.img.aedcpW
Retrieving file initrd.img...                                                                                | 7.7 MB     00:00     
Sat, 07 Aug 2010 15:16:22 DEBUG    Creating guest from:
<domain type='xen'>
  <name>rhel5xenguest</name>
  <currentMemory>2097152</currentMemory>
  <memory>2097152</memory>
  <uuid>9a2e7ec7-3a4c-adb8-e5cc-8a069d67ee97</uuid>
  <os>
    <type arch='x86_64'>linux</type>
    <kernel>/var/lib/xen/virtinst-vmlinuz.IhwIiK</kernel>
    <initrd>/var/lib/xen/virtinst-initrd.img.aedcpW</initrd>
    <cmdline>method=http://ftp.no.sohu.com/pub/os/Linux/RedHat/enterprise/x86_64/5ASU5/dvd/ ks=http://192.168.1.201/pub/ks/as-ins.php?v=5AS&amp;a=x86_64&amp;r=U5 ip=10.12.10.190 netmask=255.255.252.0 gateway=10.12.11.254 type=rd</cmdline>
  </os>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>destroy</on_reboot>
  <on_crash>destroy</on_crash>
  <vcpu>2</vcpu>
  <devices>
    <disk type='block' device='disk'>
      <source dev='/dev/vgext/rhel5xenguest.img'/>
      <target dev='xvda' bus='xen'/>
    </disk>
    <interface type='network'>
      <source network='default'/>
      <mac address='00:16:36:0a:9f:e1'/>
    </interface>
    <input type='mouse' bus='xen'/>
  </devices>
</domain>

Sat, 07 Aug 2010 15:16:22 DEBUG    Removing /var/lib/xen/virtinst-vmlinuz.IhwIiK
Sat, 07 Aug 2010 15:16:22 DEBUG    Removing /var/lib/xen/virtinst-initrd.img.aedcpW
Sat, 07 Aug 2010 15:16:22 ERROR    POST operation failed: xend_post: error from xen daemon: (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 rhel5xenguest'; otherwise, please
 restart your installation.
Sat, 07 Aug 2010 15:16:22 ERROR    POST operation failed: xend_post: error from xen daemon: (xend.err 'Invalid configuration unexpected EOF')
Traceback (most recent call last):
  File "/usr/sbin/virt-install", line 889, in ?
    main()
  File "/usr/sbin/virt-install", line 751, in main
    start_time, guest.start_install)
  File "/usr/sbin/virt-install", line 813, in do_install
    dom = install_func(conscb, progresscb, wait=(not wait))
  File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 541, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 633, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib64/python2.4/site-packages/libvirt.py", line 974, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: POST operation failed: xend_post: error from xen daemon: (xend.err 'Invalid configuration unexpected EOF')

Comment 18 Dave Allan 2010-11-16 22:41:01 UTC
Cole, does this bug still exist?

Comment 19 Cole Robinson 2010-11-17 16:02:07 UTC
No this isn't fixed upstream AFAICT. I'll take a stab at it.

Comment 20 Cole Robinson 2010-11-22 21:46:59 UTC
To fix this bug, all we need is this very simple commit:

http://libvirt.org/git/?p=libvirt.git;a=commit;h=c8b2a23c02b472f57256579d0f4077d85089e0ca

There are other escaping issues with characters ' " \    but if noone has complained about them yet they probably aren't worth backporting.

Comment 23 Jiri Denemark 2010-11-24 17:00:33 UTC
Fixed in libvirt-0.8.2-13.el5

Comment 25 Vivian Bian 2010-11-25 06:58:31 UTC
steps to make a reproducer
==========================
libvirt-0.8.2-12.el5
xen-3.0.3-117.el5
kernel-2.6.18-228.el5

# virt-install --noautoconsole --nographics -f /var/lib/libvirt/images/el5-i386-st3 -s 5  -l nfs:tango.camlab.fab.redhat.com:/srv/store/rhel/5/0.Server.i386 -r 400 -n el5_i386_st3 -x 'utf8 text ks=http://jedi.camlab.fab.redhat.com/eks/ba7837428988c6e9680998ef4d3df8aa/srv/store/rhel/5/0.Server.i386&foo=bar'


Starting install...
Retrieving file vmlinuz...                                                                                                            | 2.0 MB     00:09     
Retrieving file initrd.img...                                                                                                         | 4.7 MB     00:45     
ERROR    POST operation failed: xend_post: error from xen daemon: (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 el5_i386_st3'; otherwise, please
 restart your installation.
ERROR    POST operation failed: xend_post: error from xen daemon: (xend.err 'Invalid configuration unexpected EOF')
Traceback (most recent call last):
  File "/usr/sbin/virt-install", line 892, in ?
    main()
  File "/usr/sbin/virt-install", line 754, in main
    start_time, guest.start_install)
  File "/usr/sbin/virt-install", line 816, in do_install
    dom = install_func(conscb, progresscb, wait=(not wait))
  File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 541, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 633, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib/python2.4/site-packages/libvirt.py", line 1277, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: POST operation failed: xend_post: error from xen daemon: (xend.err 'Invalid configuration unexpected EOF')

*****************************************************************************

steps to verify this bug
========================
kernel-2.6.18-233.el5
xen-3.0.3-120.el5
libvirt-0.8.2-14.el5

# virt-install --noautoconsole --nographics -f /var/lib/libvirt/images/el5-i386-st3 -s 5  -l nfs:tango.camlab.fab.redhat.com:/srv/store/rhel/5/0.Server.i386 -r 400 -n el5_i386_st3 -x 'utf8 text ks=http://jedi.camlab.fab.redhat.com/eks/ba7837428988c6e9680998ef4d3df8aa/srv/store/rhel/5/0.Server.i386&foo=bar' 

Starting install...
Retrieving file vmlinuz...                                                                                                            | 2.0 MB     00:09     
Retrieving file initrd.img...                                                                                                         | 4.7 MB     01:04     
Creating storage file...                                                                                                              | 5.0 GB     00:00     
Creating domain...                                                                                                                    |    0 B     00:00     
Domain installation still in progress. You can reconnect to 
the console to complete the installation process.

# virsh console el5_i386_st3
Connected to domain el5_i386_st3
Escape character is ^]
Linux version 2.6.18-8.el5xen (brewbuilder.redhat.com) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Fri Jan 26 14:42:21 EST 2007
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 0000000019800000 (usable)
0MB HIGHMEM available.
408MB LOWMEM available.
NX (Execute Disable) protection: active
ACPI in unprivileged domain disabled
Built 1 zonelists.  Total pages: 104448
Kernel command line:  method=nfs:tango.camlab.fab.redhat.com:/srv/store/rhel/5/0.Server.i386 utf8 text ks=http://jedi.camlab.fab.redhat.com/eks/ba7837428988c6e9680998ef4d3df8aa/srv/store/rhel/5/0.Server.i386&foo=bar
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0

..........

from the above , we can see with the latest libvirt-0.8.2-14.el5, xeb druver could properly escape special chars in sexpr generation. 

so set bug status to VERIFIED .

Comment 26 Vivian Bian 2010-11-25 07:01:04 UTC
(In reply to comment #25)
this bug is verified on following platform
RHEL5.6-xen-x86_64-server
RHEL5.6-xen-x86_64-client
RHEL5.6-xen-i386-server
RHEL5.6-xen-i386-client

Comment 28 errata-xmlrpc 2011-01-13 22:51:05 UTC
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/RHEA-2011-0060.html