[Libguestfs] [PATCH] virt-v2v: Remove iface:ide parameter (RHBZ#895898)

[Mike Latimer]

On Wednesday, September 04, 2013 07:57:25 PM Richard W.M. Jones wrote:
> I'll give you a bit of background to this (mis-)feature.  The "iface"
> optional argument was added so that you could use qemu's IDE interface
> instead of whatever the default is (virtio-scsi, falling back to
> virtio-blk).

Thanks for the background. That does help fill in some holes.

> This has no effect (only limitations) for ordinary libguestfs users,
> but for virt-v2v it allows us to run the 'mkinitrd' command in the
> guest and have it work for very old and buggy mkinitrd / guests that
> got confused by virtio.  I think it was for RHEL 4 ...

Will the new guestconv still support older (i.e. RHEL 4) environments?

> What it does do is cause endless problems, mainly because people want
> to use virt-v2v with more disks than IDE allows (just 2, once you take
> into account the transfer disk and the libguestfs appliance).

What about performance differences between IDE and virtio-scsi? I originally 
encountered this problem because the initramfs in the SUSE guestfs 
implementation did not include ata_piix. This resulted in the IDE devices not 
being visible at all (obviously). Removing the iface parameter allowed the 
virtio-scsi interface to be used, and everything "just worked".

The iface parameter makes more sense now, but there is still a concern over 
the requirement of an IDE driver, and any potential performance differences 
between that driver and virtio-scsi. In addition, there is still the concern 
about what mode the guestfs backend is in. The whole issue could be avoided by 
just dropping the parameter, and essentially forcing virtio-scsi. On the other 
hand, I don't have any benchmarks to show a problem, so maybe it's not a valid 
concern.

> So I wouldn't worry about removing iface => "ide".

If my comments above don't raise any concerns from your side, that resolution 
is fine, and I'll ensure an IDE driver is available in our guestfs environment. 
Any performance differences are likely minimal anyway (although I might test a 
bit to be sure).

Thanks again for the additional info.

-Mike