Hi, I'm looking for a mechanism to do a sequence of API calls as atomic operation. Is there any way for libvirt's API client to acquire an exclusive VM lock to prevent other client from changing VM state through libvirt?

On 14.12.2015 18:10, Peter Krempa wrote: >On Mon, Dec 14, 2015 at 17:18:22 +0300, Dmitry Andreev wrote: >>Hi, >> >>I'm looking for a mechanism to do a sequence of API calls as atomic >>operation. Is there any way for libvirt's API client to acquire an >>exclusive VM lock to prevent other client from changing VM state >>through libvirt? > >No there isn't anything. Libvirt is locking only on internal events that >need protection. > >Doing transaction locking should be relatively easy to implement on >application layer though. Sure we can implement a lock manager on the API client side, but it can't lock VM for other clients. And that’s the problem for us. Are maintainers interested in VM lock manager on the server side? Can I move in this direction or you have something against it?

> >Peter > -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On 15.12.2015 11:47, Martin Kletzander wrote: >On Mon, Dec 14, 2015 at 06:50:56PM +0300, Dmitry Andreev wrote: >>On 14.12.2015 18:10, Peter Krempa wrote: >>>On Mon, Dec 14, 2015 at 17:18:22 +0300, Dmitry Andreev wrote: >>>>Hi, >>>> >>>>I'm looking for a mechanism to do a sequence of API calls as atomic >>>>operation. Is there any way for libvirt's API client to acquire an >>>>exclusive VM lock to prevent other client from changing VM state >>>>through libvirt? >>> >>>No there isn't anything. Libvirt is locking only on internal events that >>>need protection. >>> >>>Doing transaction locking should be relatively easy to implement on >>>application layer though. >> >>Sure we can implement a lock manager on the API client side, but it >>can't lock VM for other clients. And that’s the problem for us. >> >>Are maintainers interested in VM lock manager on the server side? >>Can I move in this direction or you have something against it? >> > >Well, I think that if you want to lock it in the layer above, you should >lock it in the layer above. And you can disable other clients, restrict >them, etc. Would you mind describing the use-case more thoroughly? >Maybe we have a solution for that already. > We allow users to manage VMs with virt-manager but when we updates VM configuration using API we want the read-change-write operation to be atomic. In few other cases we don't want to allow user run or stop vm while we doing post creation or guest configuration job.

>>> >>>Peter >>> >> >>-- >>libvir-list mailing list >>libvir-list(a)redhat.com >>https://www.redhat.com/mailman/listinfo/libvir-list