Bug 616480

Actually, virtinst is where the cache=none default is being set. The solution isn't necc. straightforward though, since virtinst doesn't know for sure whether --cdrom /dev/foo is a host cdrom or just a plain host block device. The safest thing to do is probably just not set an explicit cache value for any -cdrom device, I assume CDROM performance isn't the highest priority. Sound good to QEMU folks?

Whether we want libvirt (or I'd argue it should be qemu) to reject cache=none for cdrom devices is probably less urgent and could wait till 6.1

In my case it wasn't actually virt-install but virt-manager I used to verify
the case. Even after a guest is installed, it allows you to go in and connect
the CDROM drive and then change the caching of it to 'none' which will not
work.

It's not quite clear to me in how many places this needs to be fixed, I thought
it was libvirt allowing it for CDROMs. However from what you are saying it
sounds like it is both a problem with virt-install and virt-manager setting
'none' as default, which is a serious blocker, plus virt-manager allowing
one to change it to 'none' after install as well.

QEMU upstream will reject cache=none with an error, so libvirt/virt-install/
virt-manager needs to know not to specify it for those devices.

Not setting cache default for CDROM devices in virt-install and virt-manager
seems a reasonable fix for 6.0.

Created attachment 433262 [details]
Don't set an explicit default cache value for guest CDROM devices

Blocker justification: Installing a guest using the host's CDROM device is a fairly common usage scenario, and without this patch it is completely broken (install errors in the bios) via virt-install and virt-manager in a non-obvious way. The patch is very small and IMO very low risk.

Cole, just to be sure, does your patch fix both virt-manager and virt-install,
or is a separate patch needed for virt-manager?

This patch fixes the install from host CDROM case for both virt-install and virt-manager.

virt-manager still offers cache=none if adding a guest CDROM device post-install, but I don't think that is as important to fix for 6.0.

Fix built in python-virtinst-0.500.3-6.el6

Verified this bug with python-virtinst-0.500.3-6.el6.noarch and PASSED.

On old version - python-virtinst-0.500.3-5.el6.noarch:
...
    <disk type='block' device='cdrom'>
      <driver name='qemu' type='raw' cache='none'/>
      <source dev='/dev/cdrom'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>
...

On new version - python-virtinst-0.500.3-6.el6.noarch:
...
    <disk type='block' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/cdrom'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>
...

After update python-virtinst-0.500.3-6.el6, virt-manager install guest from CDROM device successfully, too.

*** Bug 619951 has been marked as a duplicate of this bug. ***

*** Bug 619214 has been marked as a duplicate of this bug. ***

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

verified this bug with:
Linux localhost.localdomain 2.6.32-130.el6.x86_64 #1 SMP Tue Apr 5 19:58:31 EDT
2011 x86_64 x86_64 x86_64 GNU/Linux

python-virtinst-0.500.5-3.el6.noarch
libvirt-0.8.7-17.el6.x86_64

passed.