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

Re: [Xen-devel] [PATCH v3 COLOPre 11/26] tools/libxl: introduce a new API libxl__domain_restore() to load qemu state





On 06/30/2015 12:38 AM, Ian Campbell wrote:
On Thu, 2015-06-25 at 14:25 +0800, Yang Hongyang wrote:
Secondary vm is running in colo mode. So we will do
the following things again and again:
1. suspend both primay vm and secondary vm
2. sync the state
3. resume both primary vm and secondary vm
We will send qemu's state each time in step2, and
slave's qemu should read it each time before resuming
secondary vm. Introduce a new API libxl__domain_restore()
to do it. This API should be called before resuming
secondary vm.

I think before this patch the state was passed to qemu as a parameter
when it was launched, is that correct? If so then that would be worth
mentioning for completeness.

Inaccurate I think. What you said before is the normal migration, in that
case, yes, the state was passed to qemu as a parameter. With COLO, the
first step is live migration, so the state is still passed to qemu as a
parameter when the live migration ended. The new introduced API only used
when we need to restore the DM state after a checkpoint, at this point,
guest QEMU already started, we can not pass the state as a parameter like
we do on first boot, so we introduce this API to restore the state after
QEMU has started.


Signed-off-by: Yang Hongyang <yanghy@xxxxxxxxxxxxxx>
Signed-off-by: Wen Congyang <wency@xxxxxxxxxxxxxx>
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>
---
  tools/libxl/libxl_dom_save.c | 49 ++++++++++++++++++++++++++++++++++++++++++++
  tools/libxl/libxl_internal.h |  3 +++
  tools/libxl/libxl_qmp.c      | 10 +++++++++
  3 files changed, 62 insertions(+)

diff --git a/tools/libxl/libxl_dom_save.c b/tools/libxl/libxl_dom_save.c
index 8fe1625..0ad2894 100644
--- a/tools/libxl/libxl_dom_save.c
+++ b/tools/libxl/libxl_dom_save.c
@@ -639,6 +639,55 @@ int libxl__toolstack_restore(uint32_t domid, const uint8_t 
*buf,
      }
      return 0;
  }
+
+static int libxl__domain_restore_device_model(libxl__gc *gc, uint32_t domid);
+
+int libxl__domain_restore(libxl__gc *gc, uint32_t domid)

We don't have any libxl__domain_save counterpart, but we do have
libxl__domain_save_device_model, so I wonder if the upcoming callers
ought to just call that direct? Especially given that this function
isn't any kind of generic domain restore, but has rather specific
functionality (in particular it fails for PV guests).

Maybe we just introduce libxl__domain_restore_device_model() and call
this when needed, discard the new libxl__domain_restore() API, what do
you think?



.


--
Thanks,
Yang.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.