[PATCH] virt-v2v: Remove iface:ide parameter (RHBZ#895898)
The iface:ide parameter (used in the libguestfs add_drive call) does not work with a libvirt backend. The error usually seen is: 'iface' parameter is not supported by the libvirt attach-method at /usr/share/perl5/vendor_perl/Sys/VirtConvert/GuestfsHandle.pm line 96. This issue was previously mentioned in this thread: https://www.redhat.com/archives/libguestfs/2013-February/msg00057.html, and a workaround of 'export LIBGUESTFS_ATTACH_METHOD=appliance' was suggested. 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. --- lib/Sys/VirtConvert/GuestfsHandle.pm | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/lib/Sys/VirtConvert/GuestfsHandle.pm b/lib/Sys/VirtConvert/GuestfsHandle.pm index 549ba11..71f11da 100644 --- a/lib/Sys/VirtConvert/GuestfsHandle.pm +++ b/lib/Sys/VirtConvert/GuestfsHandle.pm @@ -73,21 +73,18 @@ sub new # Open a guest handle my $g; my $open = sub { - my $interface = "ide"; - $g = Sys::Guestfs->new(); foreach my $disk (@{$disks}) { my ($name, $path, $format) = @$disk; $g->add_drive_opts($path, format => $format, - iface => $interface, name => $name); } # Add the transfer iso if there is one $g->add_drive_opts($transfer, - format => 'raw', iface => $interface, readonly => 1) + format => 'raw', readonly => 1) if defined($transfer); # Enable networking in the guest -- 1.8.1.4
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. Do we know if there are any environments which are commonly missing the virtio stack? (If the answer is not much, I'd still rather drop iface:ide, and work with both backend types (through virtio_scsi). -Mike
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
participants (2)
-
Mike Latimer -
Richard W.M. Jones