[Libguestfs] fallback to virtio_blk if guest kernel lacks virtio_scsi support
Richard W.M. Jones
rjones at redhat.com
Mon Sep 3 10:01:02 UTC 2012
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
More information about the Libguestfs
mailing list