Description of problem: When trying to add a second cdrom with an iso image to a guest, the second image replaces the first. Example: cdrom1: win-7-ultimate-sp1-64.iso cdrom2: virtio-win-0.1-52.iso When I try to add the second cdrom device pointing to virtio-win-0.1-52.iso in the virt-manager gui, the iso in the first cdrom gets replaced and the second cdrom does not have any iso connected. Version-Release number of selected component (if applicable): virt-manager-0.9.4-4.fc18.noarch How reproducible: Always. Steps to Reproduce: 1. Create a VM (Windows 7 in my case) 2. Edit the VM and attach a second cdrom device pointing to the virtio-win driver iso (to be used during installation) 3. Look at the first cdrom device, it is now connected to the virtio-win iso and the second device does not have any iso connected to it. Actual results: The second cdrom has no iso attached, the first one is replaced. Expected results: Each cdrom device should have its own iso file attached. Additional info: To solve this, I have to edit the libvirt xml guest definition by hand. Then the GUI shows the correct isos connected to the devices. Also happened in Fedora 17 just before the upgrade.
ping?
Yeah that is not good. The first CDROM device is being given the 'hdc', when you add a new CDROM, it sees 'hdc' is taken and find the first available hd* which is likely hda or hdb. When we define the XML, libvirt sorts the disks by that target value, and the new CDROM is inserted above the existing CDROM. There's a few things here: 1) Need to check if the hdc was ever required for CDROM devices with libvirt and take it into account 2) We should probably only ever append new devices, even if there's a free target name that comes first. 3) UI could use a way to reorder devices. Doing #2 would be easy and fix the issue but I'd only want to do it with a decent amount of testing. You should be able to work around this in the UI too in a round about way: - New VM - Point to windows ISO - Customize before install - Add new cdrom, but leave path empty, apply - Change that new CDROM to point to the install media - Change the original CDROM to point to virtio-win iso - start install
> 1) Need to check if the hdc was ever required for CDROM devices with libvirt > and take it into account Libvirt didn't care, but QEMU versions which predate the introduction of '-drive' can only use "hdc". I can't remember what version -drive was introduced in, but it was a very long time ago, probably around QEMU 0.9.something.
Thanks, if you need to test any virt-manager patch/build to solve this please let me know.
Hello, I've seen in koji snapshot builds for 0.10.0 [1]; any chance to see this fixed before final release? Thanks, --Simone [1] http://koji.fedoraproject.org/koji/packageinfo?packageID=198
(In reply to Simone Caronni from comment #5) > Hello, > > I've seen in koji snapshot builds for 0.10.0 [1]; any chance to see this > fixed before final release? > > Thanks, > --Simone > > [1] http://koji.fedoraproject.org/koji/packageinfo?packageID=198 I'm doing a release this week in time for the Fedora 19 final freeze, however I don't think I'll get to this fix. There's historical baggage here and I'm a bit worried about potential regressions if doing this on a short time frame. I've stuck it on my calendar to revisit this in a couple weeks when we aren't as pressed for time. Sorry for the delay.
Ok, thanks.
Okay, upstream now 1) doesn't force hdc for cdroms, and 2) tries to append a disk to the device list first rather than take the first free slot, which is about the best we can do here. either way your particular usecase should be fixed. Too risky to backport to f18/f19 though, so moving to f20
virt-manager-0.10.0-4.git79196cdf.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/virt-manager-0.10.0-4.git79196cdf.fc20
Package virt-manager-0.10.0-4.git79196cdf.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing virt-manager-0.10.0-4.git79196cdf.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18473/virt-manager-0.10.0-4.git79196cdf.fc20 then log in and leave karma (feedback).
virt-manager-0.10.0-4.git79196cdf.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.