2008-11-04 23:22:06 +00:00
|
|
|
/*
|
2013-05-29 15:05:33 +00:00
|
|
|
* libvirt_internal.h: internally exported APIs, not for public use
|
2008-11-04 23:22:06 +00:00
|
|
|
*
|
event: server RPC protocol tweaks for domain lifecycle events
This patch adds some new RPC call numbers, but for ease of review,
they sit idle until a later patch adds the client counterpart to
drive the new RPCs. Also for ease of review, I limited this patch
to just the lifecycle event; although converting the remaining
15 domain events will be quite mechanical. On the server side,
we have to have a function per RPC call, largely with duplicated
bodies (the key difference being that we store in our callback
opaque pointer whether events should be fired with old or new
style); meanwhile, a single function can drive multiple RPC
messages. With a strategic choice of XDR struct layout, we can
make the event generation code for both styles fairly compact.
I debated about adding a tri-state witness variable per
connection (values 'unknown', 'legacy', 'modern'). It would start
as 'unknown', move to 'legacy' if any RPC call is made to a legacy
event call, and move to 'modern' if the feature probe is made;
then the event code could issue an error if the witness state is
incorrect (a legacy RPC call while in 'modern', a modern RPC call
while in 'unknown' or 'legacy', and a feature probe while in
'legacy' or 'modern'). But while it might prevent odd behavior
caused by protocol fuzzing, I don't see that it would prevent
any security holes, so I considered it bloat.
Note that sticking @acl markers on the new RPCs generates unused
functions in access/viraccessapicheck.c, because there is no new
API call that needs to use the new checks; however, having a
consistent .x file is worth the dead code.
* src/libvirt_internal.h (VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK):
New feature.
* src/remote/remote_protocol.x
(REMOTE_PROC_CONNECT_DOMAIN_EVENT_CALLBACK_REGISTER_ANY)
(REMOTE_PROC_CONNECT_DOMAIN_EVENT_CALLBACK_DEREGISTER_ANY)
(REMOTE_PROC_DOMAIN_EVENT_CALLBACK_LIFECYCLE): New RPCs.
* daemon/remote.c (daemonClientCallback): Add field.
(remoteDispatchConnectDomainEventCallbackRegisterAny)
(remoteDispatchConnectDomainEventCallbackDeregisterAny): New
functions.
(remoteDispatchConnectDomainEventRegisterAny)
(remoteDispatchConnectDomainEventDeregisterAny): Mark legacy use.
(remoteRelayDomainEventLifecycle): Change message based on legacy
or new use.
(remoteDispatchConnectSupportsFeature): Advertise new feature.
* src/remote_protocol-structs: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-01-08 20:59:35 +00:00
|
|
|
* Copyright (C) 2006-2014 Red Hat, Inc.
|
2008-11-04 23:22:06 +00:00
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2012-09-20 22:30:55 +00:00
|
|
|
* License along with this library. If not, see
|
2012-07-21 10:06:23 +00:00
|
|
|
* <http://www.gnu.org/licenses/>.
|
2008-11-04 23:22:06 +00:00
|
|
|
*
|
2009-10-02 13:43:22 +00:00
|
|
|
* NB This file is ABI sensitive. Things here impact the wire
|
|
|
|
* protocol ABI in the remote driver. Same rules as for things
|
|
|
|
* include/libvirt/libvirt.h apply. ie this file is *append* only
|
2008-11-04 23:22:06 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __LIBVIRT_H_
|
2010-03-09 18:22:22 +00:00
|
|
|
# define __LIBVIRT_H_
|
2008-11-04 23:22:06 +00:00
|
|
|
|
2010-03-09 18:22:22 +00:00
|
|
|
# include "internal.h"
|
2008-11-04 23:22:06 +00:00
|
|
|
|
2012-10-31 19:03:55 +00:00
|
|
|
typedef void (*virStateInhibitCallback)(bool inhibit,
|
|
|
|
void *opaque);
|
|
|
|
|
2013-05-29 15:05:33 +00:00
|
|
|
# ifdef WITH_LIBVIRTD
|
2012-10-31 19:03:55 +00:00
|
|
|
int virStateInitialize(bool privileged,
|
|
|
|
virStateInhibitCallback inhibit,
|
|
|
|
void *opaque);
|
2008-11-17 11:03:25 +00:00
|
|
|
int virStateCleanup(void);
|
|
|
|
int virStateReload(void);
|
2012-10-31 19:03:52 +00:00
|
|
|
int virStateStop(void);
|
2010-03-09 18:22:22 +00:00
|
|
|
# endif
|
2008-11-04 23:22:06 +00:00
|
|
|
|
2009-10-02 13:43:22 +00:00
|
|
|
/* Feature detection. This is a libvirt-private interface for determining
|
|
|
|
* what features are supported by the driver.
|
|
|
|
*
|
|
|
|
* The remote driver passes features through to the real driver at the
|
|
|
|
* remote end unmodified, except if you query a VIR_DRV_FEATURE_REMOTE*
|
2011-09-22 11:47:07 +00:00
|
|
|
* feature. Queries for VIR_DRV_FEATURE_PROGRAM* features are answered
|
|
|
|
* directly by the RPC layer and not by the real driver.
|
2009-10-02 13:43:22 +00:00
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
/* Driver supports V1-style virDomainMigrate, ie. domainMigratePrepare/
|
|
|
|
* domainMigratePerform/domainMigrateFinish.
|
|
|
|
*/
|
|
|
|
VIR_DRV_FEATURE_MIGRATION_V1 = 1,
|
|
|
|
|
|
|
|
/* Driver is not local. */
|
|
|
|
VIR_DRV_FEATURE_REMOTE = 2,
|
|
|
|
|
|
|
|
/* Driver supports V2-style virDomainMigrate, ie. domainMigratePrepare2/
|
|
|
|
* domainMigratePerform/domainMigrateFinish2.
|
|
|
|
*/
|
|
|
|
VIR_DRV_FEATURE_MIGRATION_V2 = 3,
|
2009-09-17 17:10:04 +00:00
|
|
|
|
|
|
|
/* Driver supports peer-2-peer virDomainMigrate ie source host
|
|
|
|
* does all the prepare/perform/finish steps directly
|
|
|
|
*/
|
|
|
|
VIR_DRV_FEATURE_MIGRATION_P2P = 4,
|
|
|
|
|
|
|
|
/* Driver supports migration with only the source host involved,
|
|
|
|
* no libvirtd connetions on the destination at all, only the
|
|
|
|
* perform step is used.
|
|
|
|
*/
|
|
|
|
VIR_DRV_FEATURE_MIGRATION_DIRECT = 5,
|
Introduce yet another migration version in API.
Migration just seems to go from bad to worse. We already had to
introduce a second migration protocol when adding the QEMU driver,
since the one from Xen was insufficiently flexible to cope with
passing the data the QEMU driver required.
It turns out that this protocol still has some flaws that we
need to address. The current sequence is
* Src: DumpXML
- Generate XML to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Kill off VM if successful, resume if failed
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if unsuccessful
The problems with this are:
- Since the first step is a generic 'DumpXML' call, we can't
add in other migration specific data. eg, we can't include
any VM lease data from lock manager plugins
- Since the first step is a generic 'DumpXML' call, we can't
emit any 'migration begin' event on the source, or have
any hook that runs right at the start of the process
- Since there is no final step on the source, if the Finish
method fails to receive all migration data & has to kill
the VM, then there's no way to resume the original VM
on the source
This patch attempts to introduce a version 3 that uses the
improved 5 step sequence
* Src: Begin
- Generate XML to pass to dst
- Generate optional cookie to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Generate optional cookie to pass to dst
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if failed, resume if success
- Generate optional cookie to pass to src
* Src: Confirm
- Kill off VM if success, resume if failed
The API is designed to allow both input and output cookies
in all methods where applicable. This lets us pass around
arbitrary extra driver specific data between src & dst during
migration. Combined with the extra 'Begin' method this lets
us pass lease information from source to dst at the start of
migration
Moving the killing of the source VM out of Perform and
into Confirm, means we can now recover if the dst host
can't successfully Finish receiving migration data.
2010-11-02 12:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Driver supports V3-style virDomainMigrate, ie domainMigrateBegin3/
|
|
|
|
* domainMigratePrepare3/domainMigratePerform3/domainMigrateFinish3/
|
|
|
|
* domainMigrateConfirm3.
|
|
|
|
*/
|
|
|
|
VIR_DRV_FEATURE_MIGRATION_V3 = 6,
|
2011-07-19 00:27:32 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Driver supports protecting the whole V3-style migration against changes
|
|
|
|
* to domain configuration, i.e., starting from Begin3 and not Perform3.
|
|
|
|
*/
|
|
|
|
VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION = 7,
|
2011-10-21 08:00:37 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Support for file descriptor passing
|
|
|
|
*/
|
API: add VIR_TYPED_PARAM_STRING
This allows strings to be transported between client and server
in the context of name-type-value virTypedParameter functions.
For compatibility,
o new clients will not send strings to old servers, based on
a feature check
o new servers will not send strings to old clients without the
flag VIR_TYPED_PARAM_STRING_OKAY; this will be enforced at
the RPC layer in the next patch, so that drivers need not
worry about it in general. The one exception is that
virDomainGetSchedulerParameters lacks a flags argument, so
it must not return a string; drivers that forward that
function on to virDomainGetSchedulerParametersFlags will
have to pay attention to the flag.
o the flag VIR_TYPED_PARAM_STRING_OKAY is set automatically,
based on a feature check (so far, no driver implements it),
so clients do not have to worry about it
Future patches can then enable the feature on a per-driver basis.
This patch also ensures that drivers can blindly strdup() field
names (previously, a malicious client could stuff 80 non-NUL bytes
into field and cause a read overrun).
* src/libvirt_internal.h (VIR_DRV_FEATURE_TYPED_PARAM_STRING): New
driver feature.
* src/libvirt.c (virTypedParameterValidateSet)
(virTypedParameterSanitizeGet): New helper functions.
(virDomainSetMemoryParameters, virDomainSetBlkioParameters)
(virDomainSetSchedulerParameters)
(virDomainSetSchedulerParametersFlags)
(virDomainGetMemoryParameters, virDomainGetBlkioParameters)
(virDomainGetSchedulerParameters)
(virDomainGetSchedulerParametersFlags, virDomainBlockStatsFlags):
Use them.
* src/util/util.h (virTypedParameterArrayClear): New helper
function.
* src/util/util.c (virTypedParameterArrayClear): Implement it.
* src/libvirt_private.syms (util.h): Export it.
Based on an initial patch by Hu Tao, with feedback from
Daniel P. Berrange.
Signed-off-by: Eric Blake <eblake@redhat.com>
2011-10-12 09:26:34 +00:00
|
|
|
VIR_DRV_FEATURE_FD_PASSING = 8,
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Support for VIR_TYPED_PARAM_STRING
|
|
|
|
*/
|
|
|
|
VIR_DRV_FEATURE_TYPED_PARAM_STRING = 9,
|
2011-09-22 11:47:07 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Remote party supports keepalive program (i.e., sending keepalive
|
|
|
|
* messages).
|
|
|
|
*/
|
|
|
|
VIR_DRV_FEATURE_PROGRAM_KEEPALIVE = 10,
|
2012-10-19 14:58:05 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Support for VIR_DOMAIN_XML_MIGRATABLE flag in domainGetXMLDesc
|
|
|
|
*/
|
|
|
|
VIR_DRV_FEATURE_XML_MIGRATABLE = 11,
|
2012-11-21 08:28:49 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Support for offline migration.
|
|
|
|
*/
|
|
|
|
VIR_DRV_FEATURE_MIGRATION_OFFLINE = 12,
|
2013-05-20 14:59:08 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Support for migration parameters.
|
|
|
|
*/
|
|
|
|
VIR_DRV_FEATURE_MIGRATION_PARAMS = 13,
|
event: server RPC protocol tweaks for domain lifecycle events
This patch adds some new RPC call numbers, but for ease of review,
they sit idle until a later patch adds the client counterpart to
drive the new RPCs. Also for ease of review, I limited this patch
to just the lifecycle event; although converting the remaining
15 domain events will be quite mechanical. On the server side,
we have to have a function per RPC call, largely with duplicated
bodies (the key difference being that we store in our callback
opaque pointer whether events should be fired with old or new
style); meanwhile, a single function can drive multiple RPC
messages. With a strategic choice of XDR struct layout, we can
make the event generation code for both styles fairly compact.
I debated about adding a tri-state witness variable per
connection (values 'unknown', 'legacy', 'modern'). It would start
as 'unknown', move to 'legacy' if any RPC call is made to a legacy
event call, and move to 'modern' if the feature probe is made;
then the event code could issue an error if the witness state is
incorrect (a legacy RPC call while in 'modern', a modern RPC call
while in 'unknown' or 'legacy', and a feature probe while in
'legacy' or 'modern'). But while it might prevent odd behavior
caused by protocol fuzzing, I don't see that it would prevent
any security holes, so I considered it bloat.
Note that sticking @acl markers on the new RPCs generates unused
functions in access/viraccessapicheck.c, because there is no new
API call that needs to use the new checks; however, having a
consistent .x file is worth the dead code.
* src/libvirt_internal.h (VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK):
New feature.
* src/remote/remote_protocol.x
(REMOTE_PROC_CONNECT_DOMAIN_EVENT_CALLBACK_REGISTER_ANY)
(REMOTE_PROC_CONNECT_DOMAIN_EVENT_CALLBACK_DEREGISTER_ANY)
(REMOTE_PROC_DOMAIN_EVENT_CALLBACK_LIFECYCLE): New RPCs.
* daemon/remote.c (daemonClientCallback): Add field.
(remoteDispatchConnectDomainEventCallbackRegisterAny)
(remoteDispatchConnectDomainEventCallbackDeregisterAny): New
functions.
(remoteDispatchConnectDomainEventRegisterAny)
(remoteDispatchConnectDomainEventDeregisterAny): Mark legacy use.
(remoteRelayDomainEventLifecycle): Change message based on legacy
or new use.
(remoteDispatchConnectSupportsFeature): Advertise new feature.
* src/remote_protocol-structs: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-01-08 20:59:35 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Support for server-side event filtering via callback ids in events.
|
|
|
|
*/
|
|
|
|
VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK = 14,
|
2009-10-02 13:43:22 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2013-04-22 17:26:01 +00:00
|
|
|
int virConnectSupportsFeature(virConnectPtr conn, int feature);
|
2008-11-04 23:22:06 +00:00
|
|
|
|
2008-11-17 11:03:25 +00:00
|
|
|
int virDomainMigratePrepare (virConnectPtr dconn,
|
|
|
|
char **cookie,
|
|
|
|
int *cookielen,
|
|
|
|
const char *uri_in,
|
|
|
|
char **uri_out,
|
|
|
|
unsigned long flags,
|
|
|
|
const char *dname,
|
2009-10-02 14:05:11 +00:00
|
|
|
unsigned long resource);
|
2008-11-17 11:03:25 +00:00
|
|
|
int virDomainMigratePerform (virDomainPtr domain,
|
|
|
|
const char *cookie,
|
|
|
|
int cookielen,
|
|
|
|
const char *uri,
|
|
|
|
unsigned long flags,
|
|
|
|
const char *dname,
|
2009-10-02 14:05:11 +00:00
|
|
|
unsigned long resource);
|
2008-11-17 11:03:25 +00:00
|
|
|
virDomainPtr virDomainMigrateFinish (virConnectPtr dconn,
|
|
|
|
const char *dname,
|
|
|
|
const char *cookie,
|
|
|
|
int cookielen,
|
|
|
|
const char *uri,
|
|
|
|
unsigned long flags);
|
|
|
|
int virDomainMigratePrepare2 (virConnectPtr dconn,
|
|
|
|
char **cookie,
|
|
|
|
int *cookielen,
|
|
|
|
const char *uri_in,
|
|
|
|
char **uri_out,
|
|
|
|
unsigned long flags,
|
|
|
|
const char *dname,
|
2009-10-02 14:05:11 +00:00
|
|
|
unsigned long resource,
|
2008-11-17 11:03:25 +00:00
|
|
|
const char *dom_xml);
|
|
|
|
virDomainPtr virDomainMigrateFinish2 (virConnectPtr dconn,
|
|
|
|
const char *dname,
|
|
|
|
const char *cookie,
|
|
|
|
int cookielen,
|
|
|
|
const char *uri,
|
|
|
|
unsigned long flags,
|
|
|
|
int retcode);
|
2009-10-02 14:05:11 +00:00
|
|
|
int virDomainMigratePrepareTunnel(virConnectPtr dconn,
|
2009-09-30 10:51:54 +00:00
|
|
|
virStreamPtr st,
|
|
|
|
unsigned long flags,
|
|
|
|
const char *dname,
|
|
|
|
unsigned long resource,
|
|
|
|
const char *dom_xml);
|
2008-11-04 23:22:06 +00:00
|
|
|
|
Introduce yet another migration version in API.
Migration just seems to go from bad to worse. We already had to
introduce a second migration protocol when adding the QEMU driver,
since the one from Xen was insufficiently flexible to cope with
passing the data the QEMU driver required.
It turns out that this protocol still has some flaws that we
need to address. The current sequence is
* Src: DumpXML
- Generate XML to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Kill off VM if successful, resume if failed
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if unsuccessful
The problems with this are:
- Since the first step is a generic 'DumpXML' call, we can't
add in other migration specific data. eg, we can't include
any VM lease data from lock manager plugins
- Since the first step is a generic 'DumpXML' call, we can't
emit any 'migration begin' event on the source, or have
any hook that runs right at the start of the process
- Since there is no final step on the source, if the Finish
method fails to receive all migration data & has to kill
the VM, then there's no way to resume the original VM
on the source
This patch attempts to introduce a version 3 that uses the
improved 5 step sequence
* Src: Begin
- Generate XML to pass to dst
- Generate optional cookie to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Generate optional cookie to pass to dst
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if failed, resume if success
- Generate optional cookie to pass to src
* Src: Confirm
- Kill off VM if success, resume if failed
The API is designed to allow both input and output cookies
in all methods where applicable. This lets us pass around
arbitrary extra driver specific data between src & dst during
migration. Combined with the extra 'Begin' method this lets
us pass lease information from source to dst at the start of
migration
Moving the killing of the source VM out of Perform and
into Confirm, means we can now recover if the dst host
can't successfully Finish receiving migration data.
2010-11-02 12:43:44 +00:00
|
|
|
|
|
|
|
char *virDomainMigrateBegin3(virDomainPtr domain,
|
2011-05-18 09:26:30 +00:00
|
|
|
const char *xmlin,
|
Introduce yet another migration version in API.
Migration just seems to go from bad to worse. We already had to
introduce a second migration protocol when adding the QEMU driver,
since the one from Xen was insufficiently flexible to cope with
passing the data the QEMU driver required.
It turns out that this protocol still has some flaws that we
need to address. The current sequence is
* Src: DumpXML
- Generate XML to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Kill off VM if successful, resume if failed
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if unsuccessful
The problems with this are:
- Since the first step is a generic 'DumpXML' call, we can't
add in other migration specific data. eg, we can't include
any VM lease data from lock manager plugins
- Since the first step is a generic 'DumpXML' call, we can't
emit any 'migration begin' event on the source, or have
any hook that runs right at the start of the process
- Since there is no final step on the source, if the Finish
method fails to receive all migration data & has to kill
the VM, then there's no way to resume the original VM
on the source
This patch attempts to introduce a version 3 that uses the
improved 5 step sequence
* Src: Begin
- Generate XML to pass to dst
- Generate optional cookie to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Generate optional cookie to pass to dst
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if failed, resume if success
- Generate optional cookie to pass to src
* Src: Confirm
- Kill off VM if success, resume if failed
The API is designed to allow both input and output cookies
in all methods where applicable. This lets us pass around
arbitrary extra driver specific data between src & dst during
migration. Combined with the extra 'Begin' method this lets
us pass lease information from source to dst at the start of
migration
Moving the killing of the source VM out of Perform and
into Confirm, means we can now recover if the dst host
can't successfully Finish receiving migration data.
2010-11-02 12:43:44 +00:00
|
|
|
char **cookieout,
|
|
|
|
int *cookieoutlen,
|
|
|
|
unsigned long flags,
|
|
|
|
const char *dname,
|
|
|
|
unsigned long resource);
|
|
|
|
|
|
|
|
int virDomainMigratePrepare3(virConnectPtr dconn,
|
|
|
|
const char *cookiein,
|
|
|
|
int cookieinlen,
|
|
|
|
char **cookieout,
|
|
|
|
int *cookieoutlen,
|
|
|
|
const char *uri_in,
|
|
|
|
char **uri_out,
|
|
|
|
unsigned long flags,
|
|
|
|
const char *dname,
|
|
|
|
unsigned long resource,
|
|
|
|
const char *dom_xml);
|
|
|
|
|
|
|
|
int virDomainMigratePrepareTunnel3(virConnectPtr dconn,
|
|
|
|
virStreamPtr st,
|
|
|
|
const char *cookiein,
|
|
|
|
int cookieinlen,
|
|
|
|
char **cookieout,
|
|
|
|
int *cookieoutlen,
|
|
|
|
unsigned long flags,
|
|
|
|
const char *dname,
|
|
|
|
unsigned long resource,
|
|
|
|
const char *dom_xml);
|
|
|
|
|
|
|
|
|
|
|
|
int virDomainMigratePerform3(virDomainPtr dom,
|
2011-05-18 09:26:30 +00:00
|
|
|
const char *xmlin,
|
Introduce yet another migration version in API.
Migration just seems to go from bad to worse. We already had to
introduce a second migration protocol when adding the QEMU driver,
since the one from Xen was insufficiently flexible to cope with
passing the data the QEMU driver required.
It turns out that this protocol still has some flaws that we
need to address. The current sequence is
* Src: DumpXML
- Generate XML to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Kill off VM if successful, resume if failed
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if unsuccessful
The problems with this are:
- Since the first step is a generic 'DumpXML' call, we can't
add in other migration specific data. eg, we can't include
any VM lease data from lock manager plugins
- Since the first step is a generic 'DumpXML' call, we can't
emit any 'migration begin' event on the source, or have
any hook that runs right at the start of the process
- Since there is no final step on the source, if the Finish
method fails to receive all migration data & has to kill
the VM, then there's no way to resume the original VM
on the source
This patch attempts to introduce a version 3 that uses the
improved 5 step sequence
* Src: Begin
- Generate XML to pass to dst
- Generate optional cookie to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Generate optional cookie to pass to dst
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if failed, resume if success
- Generate optional cookie to pass to src
* Src: Confirm
- Kill off VM if success, resume if failed
The API is designed to allow both input and output cookies
in all methods where applicable. This lets us pass around
arbitrary extra driver specific data between src & dst during
migration. Combined with the extra 'Begin' method this lets
us pass lease information from source to dst at the start of
migration
Moving the killing of the source VM out of Perform and
into Confirm, means we can now recover if the dst host
can't successfully Finish receiving migration data.
2010-11-02 12:43:44 +00:00
|
|
|
const char *cookiein,
|
|
|
|
int cookieinlen,
|
|
|
|
char **cookieout,
|
|
|
|
int *cookieoutlen,
|
Add a second URI parameter to virDomainMigratePerform3 method
The virDomainMigratePerform3 currently has a single URI parameter
whose meaning varies. It is either
- A QEMU migration URI (normal migration)
- A libvirtd connection URI (peer2peer migration)
Unfortunately when using peer2peer migration, without also
using tunnelled migration, it is possible that both URIs are
required.
This adds a second URI parameter to the virDomainMigratePerform3
method, to cope with this scenario. Each parameter how has a fixed
meaning.
NB, there is no way to actually take advantage of this yet,
since virDomainMigrate/virDomainMigrateToURI do not have any
way to provide the 2 separate URIs
* daemon/remote.c, src/remote/remote_driver.c,
src/remote/remote_protocol.x, src/remote_protocol-structs: Add
the second URI parameter to perform3 message
* src/driver.h, src/libvirt.c, src/libvirt_internal.h: Add
the second URI parameter to Perform3 method
* src/libvirt_internal.h, src/qemu/qemu_migration.c,
src/qemu/qemu_migration.h: Update to handle URIs correctly
2011-05-18 13:18:53 +00:00
|
|
|
const char *dconnuri, /* libvirtd URI if Peer2Peer, NULL otherwise */
|
|
|
|
const char *uri, /* VM Migration URI */
|
Introduce yet another migration version in API.
Migration just seems to go from bad to worse. We already had to
introduce a second migration protocol when adding the QEMU driver,
since the one from Xen was insufficiently flexible to cope with
passing the data the QEMU driver required.
It turns out that this protocol still has some flaws that we
need to address. The current sequence is
* Src: DumpXML
- Generate XML to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Kill off VM if successful, resume if failed
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if unsuccessful
The problems with this are:
- Since the first step is a generic 'DumpXML' call, we can't
add in other migration specific data. eg, we can't include
any VM lease data from lock manager plugins
- Since the first step is a generic 'DumpXML' call, we can't
emit any 'migration begin' event on the source, or have
any hook that runs right at the start of the process
- Since there is no final step on the source, if the Finish
method fails to receive all migration data & has to kill
the VM, then there's no way to resume the original VM
on the source
This patch attempts to introduce a version 3 that uses the
improved 5 step sequence
* Src: Begin
- Generate XML to pass to dst
- Generate optional cookie to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Generate optional cookie to pass to dst
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if failed, resume if success
- Generate optional cookie to pass to src
* Src: Confirm
- Kill off VM if success, resume if failed
The API is designed to allow both input and output cookies
in all methods where applicable. This lets us pass around
arbitrary extra driver specific data between src & dst during
migration. Combined with the extra 'Begin' method this lets
us pass lease information from source to dst at the start of
migration
Moving the killing of the source VM out of Perform and
into Confirm, means we can now recover if the dst host
can't successfully Finish receiving migration data.
2010-11-02 12:43:44 +00:00
|
|
|
unsigned long flags,
|
|
|
|
const char *dname,
|
|
|
|
unsigned long resource);
|
|
|
|
|
Fix the signature of virDomainMigrateFinish3 for error reporting
The current virDomainMigrateFinish3 method signature attempts to
distinguish two types of errors, by allowing return with ret== 0,
but ddomain == NULL, to indicate a failure to start the guest.
This is flawed, because when ret == 0, there is no way for the
virErrorPtr details to be sent back to the client.
Change the signature of virDomainMigrateFinish3 so it simply
returns a virDomainPtr, in the same way as virDomainMigrateFinish2
The disk locking code will protect against the only possible
failure mode this doesn't account for (loosing conenctivity to
libvirtd after Finish3 starts the CPUs, but before the client
sees the reply for Finish3).
* src/driver.h, src/libvirt.c, src/libvirt_internal.h: Change
virDomainMigrateFinish3 to return a virDomainPtr instead of int
* src/remote/remote_driver.c, src/remote/remote_protocol.x,
daemon/remote.c, src/qemu/qemu_driver.c, src/qemu/qemu_migration.c:
Update for API change
2011-05-24 12:05:33 +00:00
|
|
|
virDomainPtr virDomainMigrateFinish3(virConnectPtr dconn,
|
|
|
|
const char *dname,
|
|
|
|
const char *cookiein,
|
|
|
|
int cookieinlen,
|
|
|
|
char **cookieout,
|
|
|
|
int *cookieoutlen,
|
|
|
|
const char *dconnuri, /* libvirtd URI if Peer2Peer, NULL otherwise */
|
|
|
|
const char *uri, /* VM Migration URI, NULL in tunnelled case */
|
|
|
|
unsigned long flags,
|
|
|
|
int cancelled); /* Kill the dst VM */
|
Introduce yet another migration version in API.
Migration just seems to go from bad to worse. We already had to
introduce a second migration protocol when adding the QEMU driver,
since the one from Xen was insufficiently flexible to cope with
passing the data the QEMU driver required.
It turns out that this protocol still has some flaws that we
need to address. The current sequence is
* Src: DumpXML
- Generate XML to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Kill off VM if successful, resume if failed
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if unsuccessful
The problems with this are:
- Since the first step is a generic 'DumpXML' call, we can't
add in other migration specific data. eg, we can't include
any VM lease data from lock manager plugins
- Since the first step is a generic 'DumpXML' call, we can't
emit any 'migration begin' event on the source, or have
any hook that runs right at the start of the process
- Since there is no final step on the source, if the Finish
method fails to receive all migration data & has to kill
the VM, then there's no way to resume the original VM
on the source
This patch attempts to introduce a version 3 that uses the
improved 5 step sequence
* Src: Begin
- Generate XML to pass to dst
- Generate optional cookie to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Generate optional cookie to pass to dst
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if failed, resume if success
- Generate optional cookie to pass to src
* Src: Confirm
- Kill off VM if success, resume if failed
The API is designed to allow both input and output cookies
in all methods where applicable. This lets us pass around
arbitrary extra driver specific data between src & dst during
migration. Combined with the extra 'Begin' method this lets
us pass lease information from source to dst at the start of
migration
Moving the killing of the source VM out of Perform and
into Confirm, means we can now recover if the dst host
can't successfully Finish receiving migration data.
2010-11-02 12:43:44 +00:00
|
|
|
|
|
|
|
int virDomainMigrateConfirm3(virDomainPtr domain,
|
|
|
|
const char *cookiein,
|
|
|
|
int cookieinlen,
|
|
|
|
unsigned long flags,
|
|
|
|
int restart); /* Restart the src VM */
|
|
|
|
|
2013-05-20 14:59:08 +00:00
|
|
|
char *virDomainMigrateBegin3Params(virDomainPtr domain,
|
|
|
|
virTypedParameterPtr params,
|
|
|
|
int nparams,
|
|
|
|
char **cookieout,
|
|
|
|
int *cookieoutlen,
|
|
|
|
unsigned int flags);
|
|
|
|
|
|
|
|
int virDomainMigratePrepare3Params(virConnectPtr dconn,
|
|
|
|
virTypedParameterPtr params,
|
|
|
|
int nparams,
|
|
|
|
const char *cookiein,
|
|
|
|
int cookieinlen,
|
|
|
|
char **cookieout,
|
|
|
|
int *cookieoutlen,
|
|
|
|
char **uri_out,
|
|
|
|
unsigned int flags);
|
|
|
|
|
|
|
|
int virDomainMigratePrepareTunnel3Params(virConnectPtr conn,
|
|
|
|
virStreamPtr st,
|
|
|
|
virTypedParameterPtr params,
|
|
|
|
int nparams,
|
|
|
|
const char *cookiein,
|
|
|
|
int cookieinlen,
|
|
|
|
char **cookieout,
|
|
|
|
int *cookieoutlen,
|
|
|
|
unsigned int flags);
|
|
|
|
|
|
|
|
int virDomainMigratePerform3Params(virDomainPtr domain,
|
|
|
|
const char *dconnuri,
|
|
|
|
virTypedParameterPtr params,
|
|
|
|
int nparams,
|
|
|
|
const char *cookiein,
|
|
|
|
int cookieinlen,
|
|
|
|
char **cookieout,
|
|
|
|
int *cookieoutlen,
|
|
|
|
unsigned int flags);
|
|
|
|
|
|
|
|
virDomainPtr virDomainMigrateFinish3Params(virConnectPtr dconn,
|
|
|
|
virTypedParameterPtr params,
|
|
|
|
int nparams,
|
|
|
|
const char *cookiein,
|
|
|
|
int cookieinlen,
|
|
|
|
char **cookieout,
|
|
|
|
int *cookieoutlen,
|
|
|
|
unsigned int flags,
|
|
|
|
int cancelled);
|
|
|
|
|
|
|
|
int virDomainMigrateConfirm3Params(virDomainPtr domain,
|
|
|
|
virTypedParameterPtr params,
|
|
|
|
int nparams,
|
|
|
|
const char *cookiein,
|
|
|
|
int cookieinlen,
|
|
|
|
unsigned int flags,
|
|
|
|
int cancelled);
|
2014-10-24 15:54:29 +00:00
|
|
|
|
|
|
|
int
|
|
|
|
virTypedParameterValidateSet(virConnectPtr conn,
|
|
|
|
virTypedParameterPtr params,
|
|
|
|
int nparams);
|
|
|
|
|
2008-11-04 23:22:06 +00:00
|
|
|
#endif
|