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). Having dedicated communication channels for each device, or sharing the channels between multiple devices, should both be acceptable choices. The latter, IO multiplexing, is also a widely adopted IO model. It just happens to fit our use-cases better. Binding access control to a communication channel would prevent anybody from using the latter approach. Having a separate way to allow access-control would permit the use of latter also. >>> >>> If yes, then we have a couple of options to implement this: >>> >>> (1) Accept the TLS credentials per vdisk using the previously >>> discussed --object tls-creds-x509 mechanism. In this case, if more >>> than one vdisk have the same host info, then we will use only the >>> first one's creds to set up the secure connection, and ignore the >>> others. vdisks that connect to different target hosts will use their >>> individual tls-creds-x509 to set up the secure channels. This is, of >>> course, not relevant for qemu-img/qemu-io as they can open only one >>> vdisk at a time. >>> >>> (2) Instead of having a per-vdisk --object tls-creds-x509, have a >>> single such argument on the command line for vxhs block device code to >>> consume - if that is possible! One way to achieve this could be the >>> user/password authentication we discussed earlier, which we could use >>> to pass the directory where cert/keys are kept. >>> >>> (3) Use the instance UUID, when available, to lookup the cert files >>> per instance (i.e. for qemu-kvm), and use the --object tls-creds-x509 >>> mechanism, when instance UUID is NULL (i.e. qemu-io, qemu-img etc). >>> The cert/key files are anyway protected by file permissions in either >>> case, so I guess there is no additional security provided by either >>> method. >> >> 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/ :|
