Bug 620878

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Some notes for QE, please test the following scenarios:

- Default virt-manager guest creation using default storage. Should work as usual
- guest creation using qcow2. a qcow2 disk should be provisioned on the storage page of the 'new vm' wizard. at the end of the install, select 'Customize before install', go to the disk details section, and set format from 'raw' to 'qcow2'. finish the install, ensure everything works.
- 'import' guest creation using the newly provisioned qcow2 image with an OS installed in it. don't change any other settings. ensure that the guest fails to start up, because libvirt is using 'raw' by default. we want to fix this case out of the box in the future, but it's not easy, and too invasive to do for rhel6. let's just verify that it is indeed broken

- hotplug an existing raw disk image to a guest, do not alter any format parameters in the 'add hardware' wizard. this should succeed as usual.
- hotplug an existing qcow2 disk to the guest, do not alter any format parameters. the guest should not be able to read any of the content on the disk image, since it is trying to access it like a raw image. this is known broken.
- hotplug an existing qcow2 to the guest, specify that the format is qcow2. make sure everything works as expected.

Okay, I'm not really sure what I was doing here to reproduce the broken behavior described in the first comment. The recent libvirt changes actually don't change format probing in the storage driver, so virt-manager isn't largely affected for the time being. qcow2 hotplug and via the 'new vm' wizard should work out of the box. Sorry for the noise.

The proposed work is still relevant for virt-manager and better qcow2 support from a security stand point, but we can safely punt it to 6.1.

Available upstream now:

http://hg.fedorahosted.org/hg/virt-manager/rev/e221a5d12a43

Fixed in virt-manager-0.8.6-1.el6

I find 2 scenarios can not work well.

------Scenario 1--------
- guest creation using qcow2. At the end of the install, select 'Customize
before install', go to the disk details section,click Advanced options and set format as 'qcow2'. but an error display in the installation process.
Error:
Unable to complete install: 'internal error Process exited while reading console log output: char device redirected to /dev/pts/5
qemu: could not open disk image /var/lib/libvirt/images/xx.img: Inappropriate ioctl for device

# tail -f .virt-manager/virt-manager.log
...
 <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/libvirt/images/xx.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>
...
[Wed, 19 Jan 2011 01:53:43 virt-manager 706] DEBUG (error:66) dialog message: Unable to complete install: 'internal error Process exited while reading console log output: char device redirected to /dev/pts/5
qemu: could not open disk image /var/lib/libvirt/images/xx.img: Inappropriate ioctl for device
' : Unable to complete install: 'internal error Process exited while reading console log output: char device redirected to /dev/pts/5
qemu: could not open disk image /var/lib/libvirt/images/xx.img: Inappropriate ioctl for device
'
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1622, in do_install
    guest.start_install(False, meter=meter)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 1193, in start_install
    start_xml, final_xml, is_initial)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 1252, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1346, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error Process exited while reading console log output: char device redirected to /dev/pts/5
qemu: could not open disk image /var/lib/libvirt/images/xx.img: Inappropriate ioctl for device

And I check the disk img type
# qemu-img info /var/lib/libvirt/images/xx.img
image: /var/lib/libvirt/images/xx.img
file format: raw
virtual size: 5.0G (5368709120 bytes)
disk size: 0

So this disk file format is not same and the installation display an error.

-------Scenario 2-------
- hotplug an existing qcow2 disk to the guest, select storage format as raw, the hotplug still succeed.But i think it should fail since the storage format is not correct. Please confirm. Thanks

Also I dump guest xml as following:
....
   <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/qcow2.img'/>
      <target dev='vdb' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>
...

# qemu-img info /var/lib/libvirt/images/qcow2.img 
image: /var/lib/libvirt/images/qcow2.img
file format: qcow2
virtual size: 10M (10485760 bytes)
disk size: 140K
cluster_size: 65536

=========
The following are correct.
- hotplug an existing raw disk image to a guest, select storage format as raw in the 'add hardware' wizard. It succeed as usual.
- hotplug an existing qcow2 disk image to a guest,select storage format as qcow2 in the 'add hardware' wizard. It succeed.
- Default virt-manager guest creation using default storage. Work as usual
- 'import' guest creation using the newly provisioned qcow2 image with an OS
installed in it. don't change any other settings. The guest can start successfully. Check the disk format found it is qcow2. 

But 'Import qcow2 img' behavior is not the same as comment #3. Please help to confirm. Thanks




Version-Release number of selected component (if applicable):

# uname -a
Linux dhcp-65-85.nay.redhat.com 2.6.32-99.el6.x86_64 #1 SMP Fri Jan 14 10:46:00
EST 2011 x86_64 x86_64 x86_64 GNU/Linux

virt-manager-0.8.6-1.el6
kernel-2.6.32-99.el6.x86_64
qemu-kvm-0.12.1.2-2.129.el6.x86_64
libvirt-0.8.7-1.el6.x86_64

(In reply to comment #8)
> I find 2 scenarios can not work well.
> 
> ------Scenario 1--------
> - guest creation using qcow2. At the end of the install, select 'Customize
> before install', go to the disk details section,click Advanced options and set
> format as 'qcow2'. but an error display in the installation process.
> Error:
> Unable to complete install: 'internal error Process exited while reading
> console log output: char device redirected to /dev/pts/5
> qemu: could not open disk image /var/lib/libvirt/images/xx.img: Inappropriate
> ioctl for device
> 
> # tail -f .virt-manager/virt-manager.log
> ...
>  <devices>
>     <emulator>/usr/libexec/qemu-kvm</emulator>
>     <disk type='file' device='disk'>
>       <driver name='qemu' type='qcow2' cache='none'/>
>       <source file='/var/lib/libvirt/images/xx.img'/>
>       <target dev='vda' bus='virtio'/>
>     </disk>
> ...
> [Wed, 19 Jan 2011 01:53:43 virt-manager 706] DEBUG (error:66) dialog message:
> Unable to complete install: 'internal error Process exited while reading
> console log output: char device redirected to /dev/pts/5
> qemu: could not open disk image /var/lib/libvirt/images/xx.img: Inappropriate
> ioctl for device
> ' : Unable to complete install: 'internal error Process exited while reading
> console log output: char device redirected to /dev/pts/5
> qemu: could not open disk image /var/lib/libvirt/images/xx.img: Inappropriate
> ioctl for device
> '
> Traceback (most recent call last):
>   File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in
> cb_wrapper
>     callback(asyncjob, *args, **kwargs)
>   File "/usr/share/virt-manager/virtManager/create.py", line 1622, in
> do_install
>     guest.start_install(False, meter=meter)
>   File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 1193, in
> start_install
>     start_xml, final_xml, is_initial)
>   File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 1252, in
> _create_guest
>     dom = self.conn.createLinux(start_xml or final_xml, 0)
>   File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1346, in
> createLinux
>     if ret is None:raise libvirtError('virDomainCreateLinux() failed',
> conn=self)
> libvirtError: internal error Process exited while reading console log output:
> char device redirected to /dev/pts/5
> qemu: could not open disk image /var/lib/libvirt/images/xx.img: Inappropriate
> ioctl for device
> 
> And I check the disk img type
> # qemu-img info /var/lib/libvirt/images/xx.img
> image: /var/lib/libvirt/images/xx.img
> file format: raw
> virtual size: 5.0G (5368709120 bytes)
> disk size: 0
> 
> So this disk file format is not same and the installation display an error.
> 

Changing the driver format for an existing disk will not actually reformat the underlying storage. The UI does not make this very clear, but the underlying concept is kind of confusing anyways.

In this case, you are telling qemu to treat a raw disk image as qcow2. The error message, while unclear, is probably the result of qemu not finding the expected qcow2 metadata. You might want to file a separate bug against qemu for a better error message in this case, with a simple qemu-kvm command line reproducer.

> -------Scenario 2-------
> - hotplug an existing qcow2 disk to the guest, select storage format as raw,
> the hotplug still succeed.But i think it should fail since the storage format
> is not correct. Please confirm. Thanks
> 
> Also I dump guest xml as following:
> ....
>    <disk type='file' device='disk'>
>       <driver name='qemu' type='raw'/>
>       <source file='/var/lib/libvirt/images/qcow2.img'/>
>       <target dev='vdb' bus='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x07'
> function='0x0'/>
>     </disk>
> ...
> 
> # qemu-img info /var/lib/libvirt/images/qcow2.img 
> image: /var/lib/libvirt/images/qcow2.img
> file format: qcow2
> virtual size: 10M (10485760 bytes)
> disk size: 140K
> cluster_size: 65536
> 
> =========
> The following are correct.
> - hotplug an existing raw disk image to a guest, select storage format as raw
> in the 'add hardware' wizard. It succeed as usual.
> - hotplug an existing qcow2 disk image to a guest,select storage format as
> qcow2 in the 'add hardware' wizard. It succeed.
> - Default virt-manager guest creation using default storage. Work as usual
> - 'import' guest creation using the newly provisioned qcow2 image with an OS
> installed in it. don't change any other settings. The guest can start
> successfully. Check the disk format found it is qcow2. 
> 
> But 'Import qcow2 img' behavior is not the same as comment #3. Please help to
> confirm. Thanks
> 

In this case, qemu can read the qcow2 image as a raw file no problem, it will just present scrambled output to the guest, since the qcow2 metadata will be interfering with the actual image data.

In this case there really isn't any way we can error without relying on image format autodetection, which has security implications (and is a large portion of the motivation for this whole format wrangling).

So both cases are actually working as expected, despite the UI not making this clear.

> Changing the driver format for an existing disk will not actually reformat the
> underlying storage. The UI does not make this very clear, but the underlying
> concept is kind of confusing anyways.
> 
> In this case, you are telling qemu to treat a raw disk image as qcow2. The
> error message, while unclear, is probably the result of qemu not finding the
> expected qcow2 metadata. You might want to file a separate bug against qemu for
> a better error message in this case, with a simple qemu-kvm command line
> reproducer.

First of all, this disk image is not pre-existing, but created by guest installation wizard. 
So I think the root cause is that virt-manager create a *raw* image file, not qcow2, then qemu throw an error.

Here I give some analysis:
When user specify *qcow2* format for disk image file, virt-manager should do these 2 things:
step 1: virt-manager should create a disk *qcow2* image if this image file is not existing.  
step 2: virt-manager should use qcow2 driver to read this disk image file.

So it looks like virt-manager created image file with incorrect format(raw) in step 1, not user specified format. I thinks this is a libvirt issue.  Right?


Another question, according to your comment 3:
> - 'import' guest creation using the newly provisioned qcow2 image with an OS
> installed in it. don't change any other settings. ensure that the guest fails
> to start up, because libvirt is using 'raw' by default. we want to fix this
> case out of the box in the future, but it's not easy, and too invasive to do
> for rhel6. let's just verify that it is indeed broken

I follow your suggestion. The guest can start successfully. Check libvirt xml, found that libvirt is using "qcow2" driver. So it looks like it works fine on RHEL6.

(In reply to comment #10)
> > Changing the driver format for an existing disk will not actually reformat the
> > underlying storage. The UI does not make this very clear, but the underlying
> > concept is kind of confusing anyways.
> > 
> > In this case, you are telling qemu to treat a raw disk image as qcow2. The
> > error message, while unclear, is probably the result of qemu not finding the
> > expected qcow2 metadata. You might want to file a separate bug against qemu for
> > a better error message in this case, with a simple qemu-kvm command line
> > reproducer.
> 
> First of all, this disk image is not pre-existing, but created by guest
> installation wizard. 
> So I think the root cause is that virt-manager create a *raw* image file, not
> qcow2, then qemu throw an error.
> 
> Here I give some analysis:
> When user specify *qcow2* format for disk image file, virt-manager should do
> these 2 things:
> step 1: virt-manager should create a disk *qcow2* image if this image file is
> not existing.  
> step 2: virt-manager should use qcow2 driver to read this disk image file.
> 
> So it looks like virt-manager created image file with incorrect format(raw) in
> step 1, not user specified format. I thinks this is a libvirt issue.  Right?
> 
> 

I guess this is more a virt-manager UI issue. Choosing 'Customize before install' and changing the format type in the disk details section is not expected to change the format when creating the new disk image

Maybe we should desensitize the format combobox if the user isn't selecting preexisting storage. I think that's for another bug report though, since it sounds like this is doing what it's supposed to, it's just a bit confusing for new storage.

According to the comment #8,comment #9, comment #11. Verified this bug as Passed.


Below I summarize all the scenarios test results for this bug:
- Default virt-manager guest creation using default storage. Work as
usual
- 'import' guest creation using the newly provisioned qcow2 image with an OS
installed in it. don't change any other settings. The guest can be installed
successfully. Check the disk image format found it is qcow2. 
- guest creation using qcow2. The disk is not pre-existing.At the end of the installation wizard, select 'Customize before install', go to the disk details section,click Advanced options and set format as 'qcow2'.Then begin installation. But an error display.
Error:
Unable to complete install: 'internal error Process exited while reading
console log output: char device redirected to /dev/pts/5
qemu: could not open disk image /var/lib/libvirt/images/xx.img: Inappropriate
ioctl for device
I have reported a new bug 677255 to track this issue.

- hotplug an existing raw disk image to a guest, do not alter any format
parameters in the 'add hardware' wizard. this succeed as usual.
- hotplug an existing qcow2 to the guest, specify that the format is qcow2.
It succeed.
- hotplug an existing qcow2 disk to the guest, select storage format as raw,
the hotplug still succeed.

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-2011-0637.html