<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 25, 2016 at 4:34 PM, Michal Privoznik <span dir="ltr"><<a href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 25.11.2016 14:38, Roman Mohr wrote:<br>
> Hi,<br>
><br>
> I recently started to use the libvirt domain events. With them I increase<br>
> the responsiveness of my VM state wachers.<br>
> In general it works pretty well. I just listen to the events and do a<br>
> periodic resync to cope with missed events.<br>
><br>
> While watching the events I ran into a few interesting situations I wanted<br>
> to share. The points 1-3 describe some minor issues or irregularities.<br>
> Point 4 is about the fact that domain and state updates are not versioned<br>
> which makes it very hard to stay in sync with libvirt when using events.<br>
><br>
> My libvirt version is 1.2.18.4.<br>
<br>
</span>This might be the root cause. I'm unable to see some of the scenarios<br>
you're seeing. Have you tried the latest release (or even git HEAD) to<br>
check whether all the scenarios you are describing still stand?<br></blockquote><div><br></div><div>Definitely better with latest HEAD but still it does not look completely right. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
><br>
> 1) Event order seems to be weird on startup:<br>
><br>
> When listening for VM lifecycle events I get this order:<br>
><br>
> {"event_type": "Started", "timestamp": "2016-11-25T11:59:53.209326Z",<br>
> "reason": "Booted", "domain_name": "generic", "domain_id":<br>
> "8ff7047b-fb46-44ff-a4c6-<wbr>7c20c73ab86e"}<br>
> {"event_type": "Defined", "timestamp": "2016-11-25T11:59:53.435530Z",<br>
> "reason": "Added", "domain_name": "generic", "domain_id":<br>
> "8ff7047b-fb46-44ff-a4c6-<wbr>7c20c73ab86e"}<br>
><br>
> It is strange that a VM already boots before it is defined. Is this the<br>
> intended order?<br>
<br>
</span>I don't see this order so probable this is fixed upstream.<br></blockquote><div><br></div><div>On latest master a normal creation emits these events:</div><div><div><br></div><div>event 'lifecycle' for domain testvm: Resumed Unpaused</div><div>event 'lifecycle' for domain testvm: Started Booted</div></div><div><br></div><div>The Resumed event looks wrong. Further I get no more Defined/Undefined events. Maybe they were removed?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
><br>
> 2) Defining a VM with VIR_DOMAIN_START_PAUSED gives me this event order<br>
<br>
</span>I don't think you can define a domain with that flag. What's the actual<br>
action?<br></blockquote><div><br></div><div>That is the flag for the api, when using virsh using `--paused` does that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
><br>
> {"event_type": "Defined", "timestamp": "2016-11-25T12:02:44.037817Z",<br>
> "reason": "Added", "domain_name": "core_node", "domain_id":<br>
> "b9906489-6d5b-40f8-a742-<wbr>ca71b2b84277"}<br>
> {"event_type": "Resumed", "timestamp": "2016-11-25T12:02:44.813104Z",<br>
> "reason": "Unpaused", "domain_name": "core_node", "domain_id":<br>
> "b9906489-6d5b-40f8-a742-<wbr>ca71b2b84277"}<br>
> {"event_type": "Started", "timestamp": "2016-11-25T12:02:44.813733Z",<br>
> "reason": "Booted", "domain_name": "core_node", "domain_id":<br>
> "b9906489-6d5b-40f8-a742-<wbr>ca71b2b84277"}<br>
<br>
<br>
</span>Interesting, so here is "defined" event delivered before the "started"<br>
event. Also - where is "suspended" event?<br></blockquote><div><br></div><div><br></div><div>With latest master the situation looks better. Now I see </div><div><div><br></div><div>event 'lifecycle' for domain testvm: Started Booted</div><div>event 'lifecycle' for domain testvm: Suspended Paused</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
><br>
> This boot-order makes it hard to track active domains by listening to<br>
> life-cycle events. One could theoretically still always fetch the VM state<br>
> in the event callback and check the state, but if the state is not<br>
> immediately transferred with the event itself, it can already be outdated,<br>
> so this might be racy (intransparent for the libvirt bindings user), and as<br>
> described in (3) currently not even possible. In general the real existing<br>
> events seem to differ quite significantly from the described life-cycle in<br>
> [1].<br>
<br>
</span>Again, in the upstream I see something different:<br>
event 'lifecycle' for domain $domain: Started Booted<br>
event 'lifecycle' for domain $domain: Suspended Paused<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>On master I see that too when I start the VM with `virsh create --paused`.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
><br>
> 3) "Defined" event is triggered before the domain is completely defined<br>
><br>
> {"event_type": "Defined", "timestamp": "2016-11-25T12:02:44.037817Z",<br>
> "reason": "Added", "domain_name": "core_node", "domain_id":<br>
> "b9906489-6d5b-40f8-a742-<wbr>ca71b2b84277"}<br>
> {"event_type": "Resumed", "timestamp": "2016-11-25T12:02:44.813104Z",<br>
> "reason": "Unpaused", "domain_name": "core_node", "domain_id":<br>
> "b9906489-6d5b-40f8-a742-<wbr>ca71b2b84277"}<br>
> {"event_type": "Started", "timestamp": "2016-11-25T12:02:44.813733Z",<br>
> "reason": "Booted", "domain_name": "core_node", "domain_id":<br>
> "b9906489-6d5b-40f8-a742-<wbr>ca71b2b84277"}<br>
><br>
> When I try to process the first event and do a xmldump I get:<br>
><br>
>    Event: [Code-42] [Domain-10] Domain not found: no domain with matching<br>
> uuid 'b9906489-6d5b-40f8-a742-<wbr>ca71b2b84277' (core_node)<br>
><br>
> So it seems like I get the event before the domain is completely ready.<br>
<br>
</span>You know that you shouldn't be calling libvirt APIs from event callbacks? </blockquote><div> </div><div>No, good to know. Anyway, just tried to work around the above problems.</div><div><br></div><div><br></div><div>So if the Defined/Undefined events were removed deliberately, then only the problem with the 'Resumed' event on a normal VM start remains. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
><br>
> 4) There libvirt domain description is not versioned<br>
><br>
> I would expect that every time I update a domainxml (update from third<br>
> party entity), or an event is generated (update from libvirt), that the<br>
> resource version of a Domain is increased and that I get this resource<br>
> version when I do a xmldump or when I get an event. Without this there is<br>
> afaik no way to stay in sync with libvirt, even if you do regular polling<br>
> of all domains. The main issue here is that I can never know if events in<br>
> the queue arrived before my latest domain resync or after it.<br>
><br>
> Also not that this is not about delivery guarantees of events. It is just<br>
> about having a consistent view of a VM and the individual event. If I have<br>
> resource versions, I can decide if an event is still interesting for me or<br>
> not, which is exactly what I need to solve the syncing problem above.<br>
> When I do a complete relisting of all domains to syn, I know which version<br>
> I got and I can then see on every event if it is newer or older.<br>
><br>
> If along side with the event, the domain xml, the VM state, and the<br>
> resource version would be sent to a client, it would be even better. Then,<br>
> whenever there is a new event for a VM in the queue, I can be sure that<br>
> this domainxml I see is the one which triggered the event. This xml is then<br>
> a complete representation for this revision number.<br>
<br>
</span>I recall some people asking for this. Basically, they were worried about<br>
somebody from outside could manipulate their XMLs without them knowing.<br>
Frankly I don't recall what was our answer to that.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Having a version number in live XML makes sense. However, it makes less<br>
sense for config XML - there would be no way how to start with version<br>
#0 once I've edited the file.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-HOEnZb"><font color="#888888"><br>
Michal<br>
</font></span></blockquote></div><br></div></div>