[Libguestfs] fallback to virtio_blk if guest kernel lacks virtio_scsi support

[Richard W.M. Jones]

On Mon, Sep 03, 2012 at 11:06:01AM +0200, Olaf Hering wrote:
> 
> Currently virtio_scsi is forced if qemu in the host supports this
> feature. This test does however not take the capabilities of the started
> guest into account. As a result no disks will be found if the guest
> kernel is older than 3.4.

There's not a good way for us to detect this, that I know of.  For
example you can't easily query if a random kernel supports a feature
(eg: virtio-scsi might have been compiled directly into the kernel).

In Fedora we tend to have the latest of everything, so this is not an
issue.  In the long term, virtio-scsi is so much better than
virtio-blk that (eventually) I think we will demand that everyone use it.

> I forced qemu_supports_virtio_scsi to return always 0, which seem to
> work well for the kernel versions as shipped in SLES11SP2, openSuSE 12.1
> and older. Is there any functionality that would be missing if a guest
> kernel has just virtio_blk?

Now: using up to 255 disks.
In future: hotplugging, proper handling of sparseness.

> How can I force the host tools to not enable virtio_scsi? Should it be a
> runtime option, or should it be done at build time with
> --disable-virtio_scsi or something like that?

I don't know if I want to add extra complexity for this, given what I
said above about virtio-scsi being clearly a better option for the
future.  Can you maintain a small out-of-tree patch for this until
OpenSuSE updates its kernel?

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://et.redhat.com/~rjones/virt-top