4:06 a.m.
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.
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?
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?
Olaf
5:01 a.m.
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
7:58 a.m.
On Mon, Sep 03, Richard W.M. Jones wrote:
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?
I agree that this guest capability can not be queried easily. Perhaps
running file on the vmlinuz and query the version, assume 3.4 and later
is good enough. That would not cover backported features.
I will carry a small patch which forces qemu_supports_virtio_scsi to
always return 0.
Olaf
4494
days inactive
4494
days old
2 comments
2 participants
participants (2)
-
Olaf Hering -
Richard W.M. Jones