Re: [libvirt] [PATCH 01/14] virstoragefile: Introduce virStoragePRDef

On 01/26/2018 04:07 AM, John Ferlan wrote: I believe so, but I'll let Paolo answer that. The way I understand reservations is that qemu needs to issue 'privileged' SCSI commands and thus for regular SCSI (which for purpose of this argument involves iSCSI emulated by kernel) either qemu needs CAP_SYS_RAWIO or a helper process to which it'll pass the FD and which will issue the 'privileged' SCSI commands on qemu's behalf. These should work too with my patches (not tested though - I don't have any real SCSI machine). I think these don't need the feature since qemu can access the device directly. So, in case of unmanaged path, here are the assumptions that my patches are built on: 1) unmanaged helper process (UHP) is spawned by somebody else's than libvirtd (hence unmanaged) - it doesn't have to be user, it can be systemd for instance. 2) path to UHP's socket has to be labeled correctly - libvirt doesn't touch that, because it knows nothing about usage scenario, whether sys admin intended one UHP per whole host and thus configured label that way, or it is spawned by mgmt app (or systemd, or whomever) per one domain, or even disk. Therefore, we can do nothing more than shrug shoulders and require users to label the socket correctly. Or use managed helper. 3) in future, when UHP dies, libvirt will NOT spawn it again. It's unmanaged after all. It's user/sysadmin responsibility to spawn it again. Now, for the managed helper process (MHP) the assumptions are: 1) there's one MHP per domain (all SCSI disks in the domain share the same MHP). 2) the MHP runs as root, but is placed into the same CGroup, mount namespace as qemu process it serves 3) MHP is lives and dies with the domain it is associated with. The code might be complicated more than needed - it is prepared to have one MHP per disk rather than domain (should we ever need it). Therefore instead of storing one pid_t, we store them in a hash table where more can be stored. Michal