Re: [PATCH 2/2] qemu: emit 'defined' event after reverted to snapshot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 14.12.2015 23:10, John Ferlan wrote:


On 12/09/2015 03:29 AM, Dmitry Andreev wrote:
Config file is changed. VIR_DOMAIN_EVENT_DEFINED should be emitted
---
  src/qemu/qemu_driver.c | 5 +++++
  1 file changed, 5 insertions(+)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index ae1d8e7..b32172a 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -15293,6 +15293,7 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot,
      virDomainSnapshotObjPtr snap = NULL;
      virObjectEventPtr event = NULL;
      virObjectEventPtr event2 = NULL;
+    virObjectEventPtr define_event = NULL;
      int detail;
      qemuDomainObjPrivatePtr priv;
      int rc;
@@ -15401,6 +15402,9 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot,
          config = virDomainDefCopy(snap->def->dom, caps, driver->xmlopt, true);
          if (!config)
              goto endjob;
+        define_event = virDomainEventLifecycleNewFromObj(vm,
+                                     VIR_DOMAIN_EVENT_DEFINED,
+                                     VIR_DOMAIN_EVENT_DEFINED_FROM_SNAPSHOT);
      }

      switch ((virDomainState) snap->def->state) {
@@ -15627,6 +15631,7 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot,
      } else if (snap) {
          snap->def->current = false;
      }
+    qemuDomainEventQueue(driver, define_event);

I think this can go right after the generation of the event. That way it
can come "in order"...

Following the rest of the logic, event can be queued as it happens and
then "reused" in a few instances prior to event2 being generated. Then
at cleanup the most recent event and event2 get queued.

As I can see from the code - 'stopped' event is the only event that is queued as it happens. The VM state is changed to STOPPED inside the
switch for few cases. If you queue the 'defined' event before the
switch (or right after the generation) the order will be 'defined' ->
'stopped' -> event -> event2 when the natural order is 'stopped' before
'defined'.

API client will get 'defined' event for VM with cached running state before you send him 'stopped' event.


If you're OK with me moving that, then I can do so and push the two patches.

John
      if (event) {
          qemuDomainEventQueue(driver, event);
          qemuDomainEventQueue(driver, event2);


--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]