On 01/19/2012 10:48 PM, Eric Blake 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;
Indeed, and using CAP_SYS_RAWIO might let guests brick your disks by
doing firmware updates.
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'.
I don't even see the need to add an attribute to the <disk> element. I
think it's wrong, because you cannot set CAP_SYS_RAWIO for only one
disk. It's a per process decision.
I think Taku's current approach is the right one.
Paolo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list