On Fri, Mar 10, 2017 at 07:04:38PM -0800, ashish mittal wrote: > On Wed, Mar 8, 2017 at 10:11 AM, Daniel P. Berrange <berra...@redhat.com> > wrote: > > On Wed, Mar 08, 2017 at 09:59:32AM -0800, ashish mittal wrote: > >> On Wed, Mar 8, 2017 at 5:04 AM, Ketan Nilangekar > >> <ketan.nilange...@veritas.com> wrote: > >> > > >> > > >> >> On Mar 8, 2017, at 1:13 AM, Daniel P. Berrange <berra...@redhat.com> > >> >> wrote: > >> >> > >> >>> On Tue, Mar 07, 2017 at 05:27:55PM -0800, ashish mittal wrote: > >> >>> Thanks! There is one more input I need some help with! > >> >>> > >> >>> VxHS network library opens a fixed number of connection channels to a > >> >>> given host, and all the vdisks (that connect to the same host) share > >> >>> these connection channels. > >> >>> > >> >>> Therefore, we need to open secure channels to a specific target host > >> >>> only once for the first vdisk that connects to that host. All the > >> >>> other vdisks that connect to the same target host will share the same > >> >>> set of secure communication channels. > >> >>> > >> >>> I hope the above scheme is acceptable? > >> >> > >> >> I don't think I'm in favour of such an approach, as it forces a single > >> >> QEMU process to use the same privileges for all disks it uses. > >> >> > >> >> Consider an example where a QEMU process has two disks, one shared > >> >> readonly disk and one exclusive writable disk, both on the same host. > >> >> > >> > > >> > This is not a use case for VxHS as a solution. We do not support sharing > >> > of vdisks across QEMU instances. > >> > > >> > Vxhs library was thus not designed to open different connections for > >> > individual vdisks within a QEMU instance. > >> > > >> > Implementing this will involve rewrite of significant parts of libvxhs > >> > client and server. Is this a new requirement for acceptance into QEMU? > >> > > >> > > >> >> It is reasonable as an administrator to want to use different > >> >> credentials > >> >> for each of these. ie, they might have a set of well known credentials > >> >> to > >> >> authenticate to get access to the read-only disk, but have a different > >> >> set > >> >> of strictly limited access credentials to get access to the writable > >> >> disk > >> >> > >> >> Trying to re-use the same connection for multiple cause prevents QEMU > >> >> from > >> >> authenticating with different credentials per disk, so I don't think > >> >> that > >> >> is a good approach - each disk should have totally independant state. > >> >> > >> > >> libvxhs does not make any claim to fit all the general purpose > >> use-cases. It was purpose-built to be the communication channel for > >> our block device service. As such, we do not need/support all the > >> general use-cases. For the same reason we changed the name of the > >> library from linqnio to libvxhs (v8 changelog, #2). > > > > I raise these kind of points because they are relevant to apps like > > OpenStack, against which you've proposed VHXS support. OpenStack > > intends to allow a single volume to be shared by multiple guests, > > so declare that out of scope you're crippling certain use cases > > within openstack. Of course you're free to make such a decision, > > but it makes VHXS a less compelling technology to use IMHO. > > > > Fair point! Sharing of the same disk across multiple guests would > require significant work from our side, and we would like to evaluate > that after OpenStack starts supporting the feature. Would adding this > support now, be a prerequisite for merging vxhs code to qemu?
No, it isn't a requirement - just a (strong-ish) suggestion. We just need to ensure that the CLI syntax allows us to support it in the future without backwards incompatible changes to the CLI. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
