Created attachment 1192886 [details] v2v-log Description of problem: v2v shouldn't convert any device to IDE type if the guest is installed at UEFI mode Version-Release number of selected component (if applicable): libvirt-2.0.0-5.el7.x86_64 libguestfs-1.32.7-2.el7.x86_64 virt-v2v-1.32.7-2.el7.x86_64 qemu-kvm-rhev-2.6.0-21.el7.x86_64 virtio-win-1.8.0-5.el7.noarch OVMF-20160608-3.git988715a.el7.noarch How reproducible: 100% Steps to Reproduce: 1.Convert a uefi guest which has cdrom device from vmware to libvirt # virt-v2v -ic vpx://root.145.47/data/10.73.3.19/?no_verify=1 juzhou-test-efi -on uefi-guest-cdrom -of qcow2 --password-file /tmp/passwd -v -x |& tee > uefi-guest-cdrom.log 2.Failed to power on the guest after finishing conversion with below error, details pls refer to v2v log" uefi-guest-cdrom.log" # virsh start uefi-guest-cdrom error: Failed to start domain uefi-guest-cdrom error: unsupported configuration: IDE controllers are unsupported for this QEMU binary or machine type 3.Delete all ide device and controller for uefi-guest-cdrom and then guest could be powered on successfully Actual results: As above description Expected results: Because the Q35 machine type doesn't have any integrated IDE controller, and libvirt doesn't support adding additional IDE controller(details pls refer to https://bugzilla.redhat.com/show_bug.cgi?id=1368300#c2), v2v shouldn't convert any device to IDE type if the guest is installed at UEFI mode Additional info:
This is actually not too trivial to fix, which I didn't realize before. The source guest defines: <disk type='file' device='disk'> <source file='[esx5.5-tzheng] juzhou-test-efi/juzhou-test-efi.vmdk'/> <target dev='sda' bus='scsi'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <source file='/vmimages/tools-isoimages/winPre2k.iso'/> <target dev='hdc' bus='ide'/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> So it's declaring an IDE CD-ROM. When we convert the guest to Q35, the Q35 machine type doesn't support bus=ide at all. We must use bus=sata instead. However we cannot simply add a bus=sata CD-ROM to the output, because that CD will appear as a /dev/sda device in the target, possibly conflicting with the main disk (if not using virtio, or in future if using virtio-scsi).
Moved to RHEL 7.4 because any fix for this is going to be complicated. I've not ruled out the possibility that bus='ide' is actually a libvirt or ESX artifact.
The "target dev" attribute seems to be used by exactly nothing in the qemu driver; as I understand it, it's not even possible to tell the guest OS what to name the device. The best qemu could do is change the ordering of the devices in an attempt to "trick" the guest OS into using a particular name. So, even if you could give the same target dev name to the devices in the libvirt config (libvirt complains when you try), they would not be confused/conflicting in the guest, since the guest never sees that information, and calls the devices whatever it pleases. As a matter of fact, I edited a sample q35 domain to have a disk with: <target bus='scsi' dev='sda'/> and a CD rom with <target bus='sata' dev='[several different things]'/> and although libvirt wouldn't allow me to name both of the devices "sda" with target dev, I did try setting it to "sdb", "sdc" and "hdc", and in all three cases the generated qemu commandline was identical. So I think it is a smaller problem than you think - just set target bus='sata', and target dev="sdc", or even "hdc" and be done with it. BTW, as for your suspicion that having bus set to 'ide' is a libvirt "artifact" - I looked into it and was surprised to learn that *if bus isn't explicitly set in the input XML*, the dev attribute is examined, and bus is auto-set based on the pattern of the dev name; in particular, if the target dev starts with "hd", or if it doesn't match any of the other checked prefixes (sd, vd, xvd, ubd), then the bus is set to "ide". I would have assumed exactly the *opposite* of that might be done; that would certainly be more useful. (The whole deal of target dev seems like it's just a pointless attempt to carry on something that was/is likely useful in the context of xen (and possibly lxc - I haven't looked), but means nothing for qemu.
The problem is that virt-v2v precisely does need to know how devices are named inside the guest, so we can (re)write configuration files. For Linux conversions, using bus='sata' will cause the devices to occupy the same namespace (sd*) as certain hard drives, so this really is a difficult problem, for virt-v2v. https://github.com/libguestfs/libguestfs/blob/master/v2v/types.mli#L277 > BTW, as for your suspicion that having bus set to 'ide' is a libvirt > "artifact" - I looked into it and was surprised to learn that *if bus > isn't explicitly set in the input XML*, the dev attribute is examined, > and bus is auto-set based on the pattern of the dev name; in particular, > if the target dev starts with "hd", or if it doesn't match any of the > other checked prefixes (sd, vd, xvd, ubd), then the bus is set to "ide". This might explain why the ESX driver returns bus=ide, but at the same time I can see no mention of ide inside the ESX driver.
(In reply to Richard W.M. Jones from comment #5) > The problem is that virt-v2v precisely does need to know how devices are > named inside the guest, so we can (re)write configuration files. For Linux > conversions, using bus='sata' will cause the devices to occupy the same > namespace (sd*) as certain hard drives, so this really is a difficult > problem, for virt-v2v. Okay, so it's not what's in the target dev attribute of the libvirt config that's the problem, but the difference in how the various guest OSes name the device once it shows up. Unfortunate, but your concern now makes more sense (and unfortunately I can't see a simple way for libvirt to help you avoid it :-/) One point though - since it's the guest OS that's choosing the name of the device, it won't be possible for a SATA CD drive's name to *conflict* with a SCSI harddisks name. The guest OS will prioritize one or the other bus over the other, so the devices on one type of bus will be named "sda...sda$n and those on the other bus will be sd$n+1..sd[whatever]. You'll just have to learn the ordering for each OS. > > https://github.com/libguestfs/libguestfs/blob/master/v2v/types.mli#L277 > > > BTW, as for your suspicion that having bus set to 'ide' is a libvirt > > "artifact" - I looked into it and was surprised to learn that *if bus > > isn't explicitly set in the input XML*, the dev attribute is examined, > > and bus is auto-set based on the pattern of the dev name; in particular, > > if the target dev starts with "hd", or if it doesn't match any of the > > other checked prefixes (sd, vd, xvd, ubd), then the bus is set to "ide". > > This might explain why the ESX driver returns bus=ide, but at the same > time I can see no mention of ide inside the ESX driver. Auto-setting to bus='ide' happens in the XML parser, which is common code for all hypervisor drivers. Look in domain_conf.c:virDomainDiskDefParseXML() for "def->bus = VIR_DOMAIN_DISK_BUS_IDE" and you'll see the code (this is around line 7805 in current master).
Out of development time for RHEL 7.4. Moving to RHEL 7.5.
*** Bug 1442036 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 1637857 ***