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