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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list