2008-11-04 23:22:06 +00:00
|
|
|
/*
|
|
|
|
* libvirt.h: publically exported APIs, not for public use
|
|
|
|
*
|
|
|
|
* Copyright (C) 2006-2008 Red Hat, Inc.
|
|
|
|
*
|
|
|
|
* 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
|
|
|
|
* License along with this library; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
*
|
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
|
|
|
|
2010-03-09 18:22:22 +00:00
|
|
|
# ifdef WITH_LIBVIRTD
|
2009-06-12 13:20:13 +00:00
|
|
|
int virStateInitialize(int privileged);
|
2008-11-17 11:03:25 +00:00
|
|
|
int virStateCleanup(void);
|
|
|
|
int virStateReload(void);
|
|
|
|
int virStateActive(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*
|
|
|
|
* feature.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
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,
|
2009-10-02 13:43:22 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2008-11-17 11:03:25 +00:00
|
|
|
int virDrvSupportsFeature (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 */
|
|
|
|
|
2008-11-04 23:22:06 +00:00
|
|
|
#endif
|