On Thu, Mar 16, 2017 at 03:50:51PM +0100, Peter Krempa wrote:
On Thu, Mar 16, 2017 at 14:42:30 +0000, Daniel Berrange wrote:
> On Thu, Mar 16, 2017 at 01:46:38PM +0100, Peter Krempa wrote:
> > On Mon, Feb 27, 2017 at 16:41:28 +0100, Francesco Romani wrote:
[...]
> > In general I don't have a problem with this and if it would make the
> > life of mgmt tools easier I don't see a reason why not.
> >
> > There's one problem though. For setter (or getter) APIs for the metadata
> > you need a way how to uniquely identify a device on which you want to
> > operate. There's no such way currently in use in libvirt so you need to
> > come up with something to do it.
>
> Once you have a reliable identifier for a device, it is not compelling
> to store metadata against each device as you can reliably identify the
> device from data in the existing metadata block. I don't find the
> atomicity argument very compelling, because even if hidden behind a
> single libvirt API, it is still fundamentally multiple operations in
> libvirt which are just as likely to fail as if the app did multiple
You get the atomicity for free if you store the metadata in the device
object and parse it along with the device definition.
We parse the XML at first (which would include the metadata). If the
device attach fails during hotplug we will free the device definition
(including the metadata).
The same applies for unplug. Once unplug finishes we will free the
device data structure and thus the metadata with it.
The scenario where device attach fails is not the problem - you can
get the same level of reliabilty to that by simply updating the
global metadata before & after hotplug in the same way. What is
difficult is when libvirt fails to persist the XML config on disk
or when libvirt crashes part way through the operation, and other
akward failure scenarios unrelated to QEMU itself.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://entangle-photo.org -o-
http://search.cpan.org/~danberr/ :|