Commit Graph

15 Commits

Author SHA1 Message Date
Daniel P. Berrange
2593f9692d 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-25 11:47:48 -04:00
Daniel P. Berrange
f9f2d4e147 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-25 11:47:48 -04:00
Daniel P. Berrange
7ad4b6b9cc Extend v3 migration protocol to allow app supplied XML for target
This extends the v3 migration protocol such that the
virDomainMigrateBegin3 and virDomainMigratePerform3
methods accept an application supplied XML config for
the target VM.

If the 'xmlin' parameter is NULL, then Begin3 uses the
current guest XML as normal. A driver implementing the
Begin3 method should either reject all non-NULL 'xmlin'
parameters, or strictly validate that the app supplied
XML does not change guest ABI.

The Perform3 method also needed the xmlin parameter to
cope with the Peer2Peer migration sequence.

NB it is not yet possible to use this capability since
neither of the public virDomainMigrate/virDomainMigrateToURI
methods have a way to pass in XML.

* daemon/remote.c, src/remote/remote_driver.c,
  src/remote/remote_protocol.x, src/remote_protocol-structs:
  Add 'remote_string xmlin' parameter to begin3/perform3
  RPC messages
* src/libvirt.c, src/driver.h, src/libvirt_internal.h: Add
  'const char *xmlin' parameter to Begin3/Perform3 methods
* src/qemu/qemu_driver.c, src/qemu/qemu_migration.c,
  src/qemu/qemu_migration.h: Pass xmlin parameter around
  migration methods
2011-05-25 11:47:47 -04:00
Daniel P. Berrange
65043d2dff 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.
2011-05-16 15:09:19 +01:00
Eric Blake
36d8e7d8d7 build: consistently indent preprocessor directives
* global: patch created by running:
for f in $(git ls-files '*.[ch]') ; do
    cppi $f > $f.t && mv $f.t $f
done
2010-03-09 19:22:28 +01:00
Daniel P. Berrange
fae0da5c13 Support a new peer-to-peer migration mode & public API
Introduces several new public API options for migration

 - VIR_MIGRATE_PEER2PEER: With this flag the client only
   invokes the virDomainMigratePerform method, expecting
   the source host driver to do whatever is required to
   complete the entire migration process.
 - VIR_MIGRATE_TUNNELLED: With this flag the actual data
   for migration will be tunnelled over the libvirtd RPC
   channel. This requires that VIR_MIGRATE_PEER2PEER is
   also set.
 - virDomainMigrateToURI: This is variant of the existing
   virDomainMigrate method which does not require any
   virConnectPtr for the destination host. Given suitable
   driver support, this allows for all the same modes as
   virDomainMigrate()

The URI for VIR_MIGRATE_PEER2PEER must be a valid libvirt
URI. For non-p2p migration a hypervisor specific migration
URI is used.

virDomainMigrateToURI without a PEER2PEER flag is only
support for Xen currently, and it involves XenD talking
directly to XenD, no libvirtd involved at all.

* include/libvirt/libvirt.h.in: Add VIR_MIGRATE_PEER2PEER
  flag for migration
* src/libvirt_internal.h: Add feature flags for peer to
  peer migration (VIR_FEATURE_MIGRATE_P2P) and direct
  migration (VIR_MIGRATE_PEER2PEER mode)
* src/libvirt.c: Implement support for VIR_MIGRATE_PEER2PEER
  and virDomainMigrateToURI APIs.
* src/xen/xen_driver.c: Advertise support for DIRECT migration
* src/xen/xend_internal.c: Add TODO item for p2p migration
* src/libvirt_public.syms: Export virDomainMigrateToURI
  method
* src/qemu/qemu_driver.c: Add support for PEER2PEER and
  migration, and adapt TUNNELLED migration.
* tools/virsh.c: Add --p2p and --direct args and use the
  new virDomainMigrateToURI method where possible.
2009-10-09 12:35:07 +01:00
Daniel P. Berrange
f6c66d01fb Remove unneccessary uri_in parameter from virMigratePrepareTunnel
Since virMigratePrepareTunnel() is used for migration over the
native libvirt connection, there is never any need to pass the
target URI to this method.

* daemon/remote.c, src/driver.h, src/libvirt.c, src/libvirt_internal.h,
  src/qemu/qemu_driver.c, src/remote/remote_driver.c,
  src/remote/remote_protocol.c, src/remote/remote_protocol.h,
  src/remote/remote_protocol.x: Remove 'uri_in' parameter from
  virMigratePrepareTunnel() method
2009-10-09 12:35:06 +01:00
Daniel P. Berrange
dd26096ad1 Move the VIR_DRV_FEATURE* constants
Move the VIR_DRV_FEATURE* constants into libvirt_internal.h
since these flags are indicating whether  APIs in the
libvirt_internal.h file are supported by a driver

* src/driver.h: Remove VIR_DRV_FEATURE* constants
* src/libvirt_internal.h: Add VIR_DRV_FEATURE* constants, using
  an enum instead of #define
* src/internal.h: pull in libvirt_internal.h
2009-10-09 12:35:06 +01:00
Chris Lalancette
6e16575a37 Tunnelled migration.
Implementation of tunnelled migration, using a Unix Domain Socket
on the qemu backend.  Note that this requires very new versions of
qemu (0.10.7 at least) in order to get the appropriate bugfixes.

Signed-off-by: Chris Lalancette <clalance@redhat.com>
2009-10-02 11:43:26 +02:00
Miloslav Trmač
ecc5c82985 Mask out flags used internally for virSecretGetValue
Add a VIR_SECRET_GET_VALUE_INTERNAL_CALL flag value, replacing the
originally separate libvirt_internal_call parameter.  The flag is used
to differentiate external virSecretGetValue() calls from internal calls
by libvirt drivers that need to use the secret even if it is private.

* src/libvirt_internal.h Remove VIR_DOMAIN_XML_FLAGS_MASK
* src/driver.h Add VIR_SECRET_GET_VALUE_FLAGS_MASK constant and
  VIR_SECRET_GET_VALUE_INTERNAL_CALL. Re-add the
  VIR_DOMAIN_XML_FLAGS_MASK constant
* src/libvirt.c (virSecretGetValue): Don't allow the user to specify
  internal flags.
2009-09-10 15:54:54 +01:00
Mark McLoughlin
aa98871c77 Add internal XML parsing/formatting flag
We need to store things like device names and PCI slot numbers in the
qemu domain state file so that we don't lose that information on
libvirtd restart. Add a flag to indicate that this information should
be parsed or formatted.

Make bit 16 and above of the flags bitmask for internal use only and
consume the first bit for this new status flag.

* include/libvirt/libvirt.h: add VIR_DOMAIN_XML_FLAGS_MASK

* src/libvirt.c: reject private flags in virDomainGetXMLDesc()

* src/domain_conf.h: add VIR_DOMAIN_XML_INTERNAL_STATUS

* src/domain_conf.c: pass the flag from virDomainObjParseXML() and
  virDomainSaveStatus
2009-07-22 11:34:05 +01:00
Daniel P. Berrange
0420a03240 Remove use of getuid()==0 for privilege checks 2009-06-12 13:20:13 +00:00
Daniel P. Berrange
25047e7cf8 Use a versioned linker script 2008-11-17 11:03:25 +00:00
Daniel Veillard
df285bdd8d KVM/QEmu migration support
* qemud/remote.c qemud/remote_dispatch_localvars.h
  qemud/remote_dispatch_proc_switch.h qemud/remote_dispatch_prototypes.h
  qemud/remote_protocol.c qemud/remote_protocol.h
  qemud/remote_protocol.x src/driver.h src/libvirt.c
  src/libvirt_internal.h src/libvirt_sym.version src/lxc_driver.c
  src/openvz_driver.c src/qemu_conf.h src/qemu_driver.c
  src/remote_internal.c src/test.c src/virsh.c: large patch to
  add migration support for KVM/QEmu, based on the work of Rich Jones
  and Chris Lalancette. This introduce a new version of the prepare
  and finish steps of the migration, so changes the driver API and
  a lot of code.
Daniel
2008-11-14 08:42:47 +00:00
Daniel P. Berrange
6ace5a39c3 Move some API declarations out of internal.h & hash.c into dedicated files 2008-11-04 23:22:06 +00:00