On Thu, 19 Jan 2012 14:48:41 -0700 Eric Blake <eblake@xxxxxxxxxx> wrote: > On 01/19/2012 02:10 PM, Daniel P. Berrange wrote: > > On Thu, Jan 19, 2012 at 01:32:08PM -0700, Eric Blake wrote: > >> On 01/18/2012 12:38 AM, Taku Izumi wrote: > >>>> I am now wondering if we should do this in a different way. ie if > >>>> there is some XML configuration parameter for the <disk> that > >>>> indicates the need for rawio, then libvirt could automatically > >>>> ensures that we add CAP_SYS_RAWIO when starting QEMU. > >>> > >>> I see. > >>> You say if a guest has the following XML configuration, > >>> "CAP_SYS_RAWIO" capability is automatically added to it, right? > >>> > >>> <disk type='block' device='lun'> > >> > >> Yes, that actually seems reasonable, especially since device='lun' is > >> brand new, and so far, is really the only reason that we'd need > >> CAP_SYS_RAWIO. > > > > Does device='lun' really require CAP_SYS_RAWIO ? I hadn't seen that > > mentioned before now > > My understanding (and hopefully Paolo corrects me if I'm wrong) is that > some, but not all, SG_IO ioctl usage patterns require CAP_SYS_RAWIO; > using device='lun' is what allows any SG_IO ioctl to pass through in the > first place, but then there is further validation based on the > capabilities. So maybe this calls for an additional xml attribute, only > needed for device='lun', that controls whether the cap is also desired > when accessing the pass-through block device: > > <disk type='block' device='lun' rawio='enabled'> > > rather than always blindly granting CAP_SYS_RAWIO merely because of the > presence of device='lun'. OK. I'll try to implement like this way. -- Taku Izumi <izumi.taku@xxxxxxxxxxxxxx> -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list