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