On Tue, 2015-01-27 at 16:58 +0000, Andrew Cooper wrote: > The legacy save/restore infrastructure requires several function pointers from > the toolstack (libxl or Xend in the past) in order to work, and for HVM guests > also need to be able to play around in dom0's filesystem to move the device > model save record. > > Migration v2 changes some of this, but is similarly dependent on > toolstack-provided function pointers. > > Someone who wishes to re-architect the interaction of moving parts for running > a domain might be in a position to re-enabled this, but for now, explicitly > fail with ENOSYS (from xc_nomigrate.c) rather than failing with an error about > a missing function pointer (or indeed falling over a NULL pointer on certain > paths).
You are talking about a toolstack which is itself running in a stubdom here, right? As opposed to e.g. an HVM domain using a qemu-stubdom, but being migrated by a normal toolstack in domain 0 (or at least, not in a mini-os based stubdom). Ian. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > CC: Ian Campbell <ian.campb...@citrix.com> > CC: Ian Jackson <ian.jack...@eu.citrix.com> > CC: Wei Liu <wei.l...@citrix.com> > --- > tools/libxc/Makefile | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile > index bd2ca6c..735afdb 100644 > --- a/tools/libxc/Makefile > +++ b/tools/libxc/Makefile > @@ -4,6 +4,11 @@ include $(XEN_ROOT)/tools/Rules.mk > MAJOR = 4.5 > MINOR = 0 > > +ifeq ($(CONFIG_LIBXC_MINIOS),y) > +# Save/restore of a domain is currently incompatible with a stubdom > environment > +override CONFIG_MIGRATE := n > +endif > + > CTRL_SRCS-y := > CTRL_SRCS-y += xc_core.c > CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
