This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 905439 - A newly attached CDROM device is given target=hdb, which takes precedence over pre-existing HDC
A newly attached CDROM device is given target=hdb, which takes precedence ove...
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-01-29 08:01 EST by Simone Caronni
Modified: 2013-10-15 02:33 EDT (History)
4 users (show)

See Also:
Fixed In Version: virt-manager-0.10.0-4.git79196cdf.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-10-15 02:33:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
Description Simone Caronni 2013-01-29 08:01:45 EST
Description of problem:

When trying to add a second cdrom with an iso image to a guest, the second image replaces the first.


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):


How reproducible:


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.
Comment 1 Simone Caronni 2013-02-15 05:50:45 EST
Comment 2 Cole Robinson 2013-03-05 16:28:32 EST
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
Comment 3 Daniel Berrange 2013-03-06 04:18:25 EST
> 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.
Comment 4 Simone Caronni 2013-03-06 05:44:53 EST
Thanks, if you need to test any virt-manager patch/build to solve this please let me know.
Comment 5 Simone Caronni 2013-05-21 06:49:00 EDT

I've seen in koji snapshot builds for 0.10.0 [1]; any chance to see this fixed before final release?


Comment 6 Cole Robinson 2013-06-12 18:31:01 EDT
(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]

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.
Comment 7 Simone Caronni 2013-06-13 11:41:29 EDT
Ok, thanks.
Comment 8 Cole Robinson 2013-10-03 08:49:59 EDT
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
Comment 9 Fedora Update System 2013-10-06 15:58:43 EDT
virt-manager-0.10.0-4.git79196cdf.fc20 has been submitted as an update for Fedora 20.
Comment 10 Fedora Update System 2013-10-07 11:46:58 EDT
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:
then log in and leave karma (feedback).
Comment 11 Fedora Update System 2013-10-15 02:33:53 EDT
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.

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