<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 25, 2016 at 8:23 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"><div class="m_7198805992790565218gmail-HOEnZb"><div class="m_7198805992790565218gmail-h5">On 25.11.2016 18:33, Roman Mohr wrote:<br>
> On Fri, Nov 25, 2016 at 6:04 PM, Michal Privoznik <<a href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a>><br>
> wrote:<br>
><br>
>> On 25.11.2016 17:54, Roman Mohr wrote:<br>
>>> On Fri, Nov 25, 2016 at 4:34 PM, Michal Privoznik <<a href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a>><br>
>>> wrote:<br>
>>><br>
>>>> 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<br>
>> 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<br>
>>>> 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<br>
>> versioned<br>
>>>>> which makes it very hard to stay in sync with libvirt when using<br>
>> events.<br>
>>>>><br>
>>>>> My libvirt version is 1.2.18.4.<br>
>>>><br>
>>>> 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>
>>>><br>
>>><br>
>>> Definitely better with latest HEAD but still it does not look completely<br>
>>> right.<br>
>>><br>
>>>><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-7c20c<wbr>73ab86e"}<br>
>>>>> {"event_type": "Defined", "timestamp": "2016-11-25T11:59:53.435530Z",<br>
>>>>> "reason": "Added", "domain_name": "generic", "domain_id":<br>
>>>>> "8ff7047b-fb46-44ff-a4c6-7c20c<wbr>73ab86e"}<br>
>>>>><br>
>>>>> It is strange that a VM already boots before it is defined. Is this the<br>
>>>>> intended order?<br>
>>>><br>
>>>> I don't see this order so probable this is fixed upstream.<br>
>>>><br>
>>><br>
>>> On latest master a normal creation emits these events:<br>
>>><br>
>>> event 'lifecycle' for domain testvm: Resumed Unpaused<br>
>>> event 'lifecycle' for domain testvm: Started Booted<br>
>>><br>
>>> The Resumed event looks wrong. Further I get no more Defined/Undefined<br>
>>> events. Maybe they were removed?<br>
>><br>
>> Yes, they were removed.<br>
><br>
><br>
> Nice<br>
><br>
><br>
>> The Resumed event comes from qemu actually,<br>
>> because libvirt starts qemu in paused mode so that we can do some setup<br>
>> (e.g. place vcpu threads into cgroups) and only after that we can resume<br>
>> guest CPUs and in fact let guest start. Once this is done we<br>
>> deliberately emit Started event.<br>
>><br>
><br>
> I would expect an event like this:<br>
><br>
> event 'lifecycle' for domain testvm: Suspended Bootstrapping<br>
><br>
> before the other two events. That takes the ambiguity from the Resumed<br>
> event.<br>
><br>
><br>
>>><br>
>>><br>
>>>><br>
>>>>><br>
>>>>> 2) Defining a VM with VIR_DOMAIN_START_PAUSED gives me this event order<br>
>>>><br>
>>>> I don't think you can define a domain with that flag. What's the actual<br>
>>>> action?<br>
>>>><br>
>>><br>
>>> That is the flag for the api, when using virsh using `--paused` does<br>
>> that.<br>
>><br>
>> Ah, that's for virsh create/start not virsh define. Anyway, this is no<br>
>> longer the case with upstream, is it?<br>
>><br>
>><br>
> Right<br>
><br>
><br>
>>><br>
>>><br>
>>>><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-ca71b<wbr>2b84277"}<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-ca71b<wbr>2b84277"}<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-ca71b<wbr>2b84277"}<br>
>>>><br>
>>>><br>
>>>> Interesting, so here is "defined" event delivered before the "started"<br>
>>>> event. Also - where is "suspended" event?<br>
>>>><br>
>>><br>
>>><br>
>>> With latest master the situation looks better. Now I see<br>
>>><br>
>>> event 'lifecycle' for domain testvm: Started Booted<br>
>>> event 'lifecycle' for domain testvm: Suspended Paused<br>
>><br>
>> Again, both of these are deliberately emitted by libvirt and in fact I<br>
>> think they reflect what is happening.<br>
>><br>
>><br>
> Why is in this case  not<br>
><br>
>  event 'lifecycle' for domain testvm: Resumed Unpaused<br>
><br>
> event emitted?<br>
><br>
> I would expect<br>
><br>
> event 'lifecycle' for domain testvm: Resumed Unpaused<br>
<br>
</div></div>I fail to see why this is supposed to be emitted. The QEMU is started as<br>
paused. If this even would be emitted, even if immediately followed by<br>
Paused event, it might suggest that guest CPUs have run for a little<br>
while. But that's not true.<br>
<span class="m_7198805992790565218gmail-"><br></span></blockquote><div><br></div><div>So to sum this up, to see if I get it right. </div><div><br></div><div>When I directly start a VM I get:</div><div><br></div><div><span style="color:rgb(80,0,80)"> 1) event 'lifecycle' for domain testvm: Resumed Unpaused</span></div><div><span style="color:rgb(80,0,80)"> 2) event 'lifecycle' for domain testvm: Started Booted</span></div><div><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)">When I want to start it in paused mode I get:</span></div><div><span style="color:rgb(80,0,80)"><br></span></div><div> 1) event 'lifecycle' for domain testvm: Started Booted<br> 2) event 'lifecycle' for domain testvm: Suspended Paused<span style="color:rgb(80,0,80)"><br></span></div><div><br></div><div>but no Resumed Unpaused as first event. </div><div><br></div><div>The "Resumed Unpaused" I get in the first case, is because of internal libvirt VM setup on a paused VM, right?<br></div><div>This work is not happening before the Started Booted event when I start the VM in paused mode?</div><div><br></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="m_7198805992790565218gmail-">
> event 'lifecycle' for domain testvm: Started Booted<br>
> event 'lifecycle' for domain testvm: Suspended Paused<br>
><br>
><br>
> So the situation on master is much better but because of the<br>
> Resumed/Unpaused event I still have the feeling that the most simple but<br>
> powerful usecase, watching for CREATE, UPDATE, DELETE is very hard because<br>
> you can't know if the Resumed/Unpaused is the indicator for CREATE or<br>
> UPDATE.<br>
><br>
<br>
</span>It's neither. Resumed event reflects vCPU state, not the domain XML<br>
change. Maybe we need to document that better.</blockquote><div><br></div><div>That would be great :)</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"><br>
For domain create event you need to watch for Started lifecycle event.<br></blockquote><div><br></div><div>I have two questions here:<br></div><div> 1) So the domain which triggers the resumed event does not exist before this Started even although I get notifications assigned to it?<br></div><div><div> 2) Isn't the resumed event still ambiguous then? Normally it implies that the domain already exists and was paused, but in this case it reflects internal libvirt work on a not yet created domain.</div></div><div><br></div><div>I don't think it is that much a deal, you can work around that, but it is something everyone has to keep in mind when working with these events.</div><div>But even something simple like having a special event reason, let's say 'Resumed Initialized' would fix that, although the word 'Resumed' just sounds wrong in this context.</div><div><br></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">
For domain update event you need to watch for device-* event.<br>
For domain shutdown event you need to watch for Stopped lifecycle event.<br>
<span class="m_7198805992790565218gmail-HOEnZb"><font color="#888888"><br>
Michal<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Roman</div></div>