[libvirt] [PATCH 00/15 v5] Unprivileged SG_IO support

[Osier Yang]

On 2012年12月07日 08:59, Eric Blake wrote:
> On 12/05/2012 02:25 AM, Osier Yang wrote:
>> Hi,
>>
>> As a result of RFC [1], this implements the unprivleged SG_IO
>> support.

<...>
>>Testing is not that enough, but I'd like see the
>> reviewing earlier, and meanwhile I'm not going to give up
>> the further testing.
</...>

This should have been removed, as I did much testing after v2.

>
> I didn't see where [1] links to.

It's 
https://www.redhat.com/archives/libvir-list/2012-November/msg00988.html, 
it was missed when posting new set. :-)

>
>>
>> Patches 1/10 ~ 4/10 are to introduce the internal list for shared
>> disks.
>>
>> Osier Yang (15):
>>    qemu: Introduce a list to maintain the shared disks between domains
>>    qemu: Init/Free the list with the driver's lifecyle
>>    qemu: Add/remove the shared disk entry during domain's lifecyle
>>    qemu: Add/Remove the entry of sharedDisks when live
>>      attaching/detaching
>
> Are you properly handling backing files as potential shared disks?

Not yet. Thanks for reminding this. But could the base disk be a
scsi block device? AFAIK, it could be only raw and qcow2 currently.

> I
> think we really need to reach the point where we can specify the entire
> backing chain as part of domain XML, and where we fill in the backing
> chain if the user didn't provide it up front.

Yeah, regardless of this patch set, I think it's nice for not have to
determine the backing chain every time, and isn't the backing chain lost 
after restarting or reloading libvirtd?

Though the backing chain could be changed outside of libvirt, any
external changing is not support by libvirt. So that will be fine.

Should we also determine the backing chains for attached domain process?
I.E, the API qemuDomainAttach. These are not related to this topic,
but good to raise up.

   After all, it is entirely
> reasonable to allow for:
>
> base<- A.img
>       <- B.img
>
> where A.img is used by domain A, B.img is used by domain B, but where
> we'd like to have SG_IO support for both domain's read-only use of base.
>   I don't know if this will impact what needs to happen in your series.

Let's ignore whether the base disk could be block device or not
here, and with assuming that the backing chain is already exposed
to domain XML, that means we have to add "cdbfilter" and
"old_cdbfilter" to struct _virStorageFileMetadata, and allows it
only for the root base once the backing are exposed to domain XML.

And then just like what this set does for general disks, it has to
have various checking/setting/restoring when domain starting,
destroying, disk attaching, detaching. block-pull/block-commit
should not be affected, as they doesn't change the root base.

Regards,
Osier