cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
Subject Re: Adding VirtIO SCSI to KVM hypervisors
Date Wed, 25 Jan 2017 07:47:14 GMT

> Op 25 januari 2017 om 4:44 schreef Simon Weller <sweller@ena.com>:
> 
> 
> Maybe this is a good opportunity to discuss modernizing the OS selections so that drivers
(and other features) could be selectable per OS.
> 

That seems like a good idea. If you select Ubuntu 16.04 or CentOS 7.3 then for example it
will give you a VirtIO SCSI disk on KVM, anything previous to that will get VirtIO-blk.

Wido

> 
> Thoughts?
> 
> 
> ________________________________
> From: Syed Ahmed <sahmed@cloudops.com>
> Sent: Tuesday, January 24, 2017 10:46 AM
> To: dev@cloudstack.apache.org
> Cc: Simon Weller
> Subject: Re: Adding VirtIO SCSI to KVM hypervisors
> 
> To maintain backward compatibility we would have to add a config option here unfortunately.
I do like the idea however. We can make the default VirtIO ISCSI and keep the VirtIO-blk as
an alternative for existing installations.
> 
> On Mon, Jan 23, 2017 at 8:05 AM, Wido den Hollander <wido@widodh.nl<mailto:wido@widodh.nl>>
wrote:
> 
> > Op 21 januari 2017 om 23:50 schreef Wido den Hollander <wido@widodh.nl<mailto:wido@widodh.nl>>:
> >
> >
> >
> >
> > > Op 21 jan. 2017 om 22:59 heeft Syed Ahmed <sahmed@cloudops.com<mailto:sahmed@cloudops.com>>
het volgende geschreven:
> > >
> > > Exposing this via an API would be tricky but it can definitely be added as
> > > a cluster-wide or a global setting in my opinion. By enabling that, all the
> > > instances would be using VirtIO SCSI. Is there a reason you'd want some
> > > instances to use VirtIIO and others to use VirtIO SCSI?
> > >
> >
> > Even a global setting would be a bit of work and hacky as well.
> >
> > I do not see any reason to keep VirtIO, it os just that devices will be named sdX
instead of vdX in the guest.
> 
> To add, the Qemu wiki [0] says:
> 
> "A virtio storage interface for efficient I/O that overcomes virtio-blk limitations and
supports advanced SCSI hardware."
> 
> At OpenStack [1] they also say:
> 
> "It has been designed to replace virtio-blk, increase it's performance and improve scalability."
> 
> So it seems that VirtIO is there to be removed. I'd say switch to VirtIO SCSI at version
5.X? :)
> 
> Wido
> 
> [0]: http://wiki.qemu.org/Features/VirtioSCSI
> [1]: https://wiki.openstack.org/wiki/LibvirtVirtioScsi
> 
> >
> > That might break existing Instances when not using labels or UUIDs in the Instance
when mounting.
> >
> > Wido
> >
> > >
> > >> On Sat, Jan 21, 2017 at 4:22 PM, Simon Weller <sweller@ena.com<mailto:sweller@ena.com>>
wrote:
> > >>
> > >> For the record, we've been looking into this as well.
> > >> Has anyone tried it with Windows VMs before? The standard virtio driver
> > >> doesn't support spanned disks and that's something we'd really like to
> > >> enable for our customers.
> > >>
> > >>
> > >>
> > >> Simon Weller/615-312-6068<tel:615-312-6068> <(615)%20312-6068>
> > >>
> > >>
> > >> -----Original Message-----
> > >> *From:* Wido den Hollander [wido@widodh.nl<mailto:wido@widodh.nl>]
> > >> *Received:* Saturday, 21 Jan 2017, 2:56PM
> > >> *To:* Syed Ahmed [sahmed@cloudops.com<mailto:sahmed@cloudops.com>];
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> [
> > >> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>]
> > >> *Subject:* Re: Adding VirtIO SCSI to KVM hypervisors
> > >>
> > >>
> > >>> Op 21 januari 2017 om 16:15 schreef Syed Ahmed <sahmed@cloudops.com<mailto:sahmed@cloudops.com>>:
> > >>>
> > >>>
> > >>> Wido,
> > >>>
> > >>> Were you thinking of adding this as a global setting? I can see why
it
> > >> will
> > >>> be useful. I'm happy to review any ideas you might have around this.
> > >>>
> > >>
> > >> Well, not really. We don't have any structure for this in place right now
> > >> to define what type of driver/disk we present to a guest.
> > >>
> > >> See my answer below.
> > >>
> > >>> Thanks,
> > >>> -Syed
> > >>> On Sat, Jan 21, 2017 at 04:46 Laszlo Hornyak <laszlo.hornyak@gmail.com<mailto:laszlo.hornyak@gmail.com>>
> > >>> wrote:
> > >>>
> > >>>> Hi Wido,
> > >>>>
> > >>>> If I understand correctly from the documentation and your examples,
> > >> virtio
> > >>>> provides virtio interface to the guest while virtio-scsi provides
scsi
> > >>>> interface, therefore an IaaS service should not replace it without
user
> > >>>> request / approval. It would be probably better to let the user
set
> > >> what
> > >>>> kind of IO interface the VM needs.
> > >>>>
> > >>
> > >> You'd say, but we already do those. Some Operating Systems get a IDE disk,
> > >> others a SCSI disk and when Linux guest support it according to our
> > >> database we use VirtIO.
> > >>
> > >> CloudStack has no way of telling how to present a volume to a guest. I
> > >> think it would be a bit to much to just make that configurable. That would
> > >> mean extra database entries, API calls. A bit overkill imho in this case.
> > >>
> > >> VirtIO SCSI is supported by all Linux distributions for a very long time.
> > >>
> > >> Wido
> > >>
> > >>>> Best regards,
> > >>>> Laszlo
> > >>>>
> > >>>> On Fri, Jan 20, 2017 at 10:21 PM, Wido den Hollander <wido@widodh.nl<mailto:wido@widodh.nl>>
> > >>>> wrote:
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> VirtIO SCSI [0] has been supported a while now by Linux and
all
> > >> kernels,
> > >>>>> but inside CloudStack we are not using it. There is a issue
for this
> > >> [1].
> > >>>>>
> > >>>>> It would bring more (theoretical) performance to VMs, but one
of the
> > >>>>> motivators (for me) is that we can support TRIM/DISCARD [2].
> > >>>>>
> > >>>>> This would allow for RBD images on Ceph to shrink, but it can
also
> > >> give
> > >>>>> back free space on QCOW2 images if quests run fstrim. Something
all
> > >>>> modern
> > >>>>> distributions all do weekly in a CRON.
> > >>>>>
> > >>>>> Now, it is simple to swap VirtIO for VirtIO SCSI. This would
however
> > >> mean
> > >>>>> that disks inside VMs are then called /dev/sdX instead of /dev/vdX.
> > >>>>>
> > >>>>> For GRUB and such this is no problems. This usually work on
UUIDs
> > >> and/or
> > >>>>> labels, but for static mounts on /dev/vdb1 for example things
break.
> > >>>>>
> > >>>>> We currently don't have any configuration method on how we
want to
> > >>>> present
> > >>>>> a disk to a guest, so when attaching a volume we can't say
that we
> > >> want
> > >>>> to
> > >>>>> use a different driver. If we think that a Operating System
supports
> > >>>> VirtIO
> > >>>>> we use that driver in KVM.
> > >>>>>
> > >>>>> Any suggestion on how to add VirtIO SCSI support?
> > >>>>>
> > >>>>> Wido
> > >>>>>
> > >>>>>
> > >>>>> [0]: http://wiki.qemu.org/Features/VirtioSCSI
> > >>>>> [1]: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> > >>>>> [2]: https://issues.apache.org/jira/browse/CLOUDSTACK-8104
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>>
> > >>>> EOF
> > >>>>
> > >>
>

Mime
View raw message