[libvirt] Libvirt domain event usage and consistency
rmohr at redhat.com
Wed Dec 7 08:29:08 UTC 2016
On Wed, Dec 7, 2016 at 8:38 AM, Fabian Deutsch <fdeutsch at redhat.com> wrote:
> On Wed, Dec 7, 2016 at 8:26 AM, Michal Privoznik <mprivozn at redhat.com>
> > On 06.12.2016 14:12, Roman Mohr wrote:
> >> On Fri, Nov 25, 2016 at 4:34 PM, Michal Privoznik <mprivozn at redhat.com>
> >> wrote:
> >>> On 25.11.2016 14:38, Roman Mohr wrote:
> >> [...]
> >>>> 4) There libvirt domain description is not versioned
> >>>> I would expect that every time I update a domainxml (update from third
> >>>> party entity), or an event is generated (update from libvirt), that
> >>>> resource version of a Domain is increased and that I get this resource
> >>>> version when I do a xmldump or when I get an event. Without this
> there is
> >>>> afaik no way to stay in sync with libvirt, even if you do regular
> >>>> of all domains. The main issue here is that I can never know if
> events in
> >>>> the queue arrived before my latest domain resync or after it.
> >>>> Also not that this is not about delivery guarantees of events. It is
> >>>> about having a consistent view of a VM and the individual event. If I
> >>> have
> >>>> resource versions, I can decide if an event is still interesting for
> >>> or
> >>>> not, which is exactly what I need to solve the syncing problem above.
> >>>> When I do a complete relisting of all domains to syn, I know which
> >>> version
> >>>> I got and I can then see on every event if it is newer or older.
> >>>> If along side with the event, the domain xml, the VM state, and the
> >>>> resource version would be sent to a client, it would be even better.
> >>> Then,
> >>>> whenever there is a new event for a VM in the queue, I can be sure
> >>>> this domainxml I see is the one which triggered the event. This xml is
> >>> then
> >>>> a complete representation for this revision number.
> >>> I recall some people asking for this. Basically, they were worried
> >>> somebody from outside could manipulate their XMLs without them knowing.
> >>> Frankly I don't recall what was our answer to that.
> >> Having a version number in live XML makes sense. However, it makes less
> >>> sense for config XML - there would be no way how to start with version
> >>> #0 once I've edited the file.
> >> I think it would be very beneficial to have it on the config file too.
> >> Think about the resource version as opaque data which can be used by
> >> libvirt to see if the domain xml update contains the same resource
> >> which libvirt sees.
> > If we do this then it's just a matter of time that users start demanding
> > "How do I return to revision #1337?". And we don't want to go there.
> Well - We could argue that currently it is just not possible to
> connect libvirtd events and a specific dom revision. This implies that
> users also could not do it themselves.
> With the change however, libvirtd will not provide the full history,
> but if it's needed then now users are able to add such functionality
> alongside of libvirtd. It would ismpliy enable this usecase.
If the dom and events are connected, creating your own history is just a
matter of storing the dom in a map or a key-value store with the revision
as a key. Really no need to have that in libvirt. In my eyes the benefit
here really is that you get consistency which enables all the consistent
caching and update usecases.
> >> So if you want to be sure that you are updating the domain xml from the
> >> latest state, you pass in the resource version of your cached domain xml
> >> view. If the version is still the same inside of libvirt, libvirt
> >> the domain xml and increases the resource version. If it has changed in
> >> meantime, it rejects the update and the client can re-fetch the latest
> >> state and try again.
> > Makes sense.
> >> For classic update mode, just don't pass in the
> >> resource version as a client and libvirt can then just update the domain
> >> xml like always. This is pretty much the same principle like described
> >> .
> > What if users start mixing XMLs with and without revision IDs?
> > Also, I'm a bit worried about revision ID wrap, but hopefully ULL is big
> > enough.
> I guess that mixing with and without IDs in subsequent updates should
> not be an issue.
> In the case with the ID it's a sanity check to ensure that the right
> state is getting updated. Without the ID this check is omitted.
I can understand the concerns here. Maybe having a config value to enable
resource versioning might make sense.
Then we could enforce the presence of a resource version on updates. If
versioning is turned off, everything is like always.
This would problems like this completely.
> - fabian
> >> What is the rationale for this?
> >> I am mostly operating on cached views on libvirts data in combination
> >> events. If, on listing resources and on events, I get a domain xml with
> >> resource version and the Domain state, I have a full snapshot of the
> >> Domain, which I can put into a cache or queue. Then syncing with libvirt
> >> based on events and initial listing is possible. Otherwise I can never
> >> sure if my view of libvirt is out of sync.
> >> When I then process an event I can process it based on the consistent
> >> snapshot view of the Domain and update the domain xml. If something has
> >> changed in the meantime, the update of the domain xml will fail and I
> >> recheck and retry. Even better: In most cases the event does not need
> >> retries, because a newer event is already in the queue with the new
> >> view which caused the update to fail.
> > What if on event arrival you'd only note whatever actions you need to
> > perform and only after you've processed the whole queue you start
> > executing them?
The problem I see here is that there can always be another event while I am
executing an action, that makes it very hard to write well behaving code in
combination with events.
> > Michal
> Fabian Deutsch <fdeutsch at redhat.com>
> Associate Manager, RHV Hypervisor
> Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libvir-list