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

On Tue, Sep 03, 2013 at 11:30:07PM -0600, Mike Latimer
wrote:
> On Tuesday, September 03, 2013 06:09:26 PM Mike Latimer wrote:
> > However, as mentioned in the bug, this parameter is likely no longer
> > required. Unless there is a use-case where this setting is required,
it
> > seems like a good idea to remove it completely (which should work in
> > either libvirt or direct mode), rather than recommend the workaround.
> 
> As much as I hate to reply to myself... I just did some additional testing
and
> realized that if 'iface:ide' is removed, the disks could be
inaccessible in
> environments that don't have virtio_scsi (in the guestfs environment).
In
> other words, with just ata_piix, the 'iface:ide' might be required.
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).

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 ...

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

So I wouldn't worry about removing iface => "ide".
> Do we know if there are any environments which are commonly missing
> the virtio stack?
Even ARM has it these days.  libguestfs doesn't work without it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

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

On Wed, Sep 04, 2013 at 01:36:19PM -0600, Mike Latimer
wrote:
> 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.
We're not able to drop the parameter, since that would break backwards
compatibility.  However my understanding is that guestconv won't use
"iface" at all and will use another method to convert the problematic
guest, perhaps patching the mkinitrd or dropping in a replacement.
You'll need to ask Matt Booth about that.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW