The SPICE seamless migration process requires data to be passed
back from the target host, to the source host via a cookie.
The cookie includes the target host's hostname, but this was not
stored, merely validated. This patch explicitly records the
remote hostname after parsing the cookie, and uses it when
initiating the SPICE migration

* qemu/qemu_migration.c: Fix SPICE seamless migration hostname

Before running perform in peer-2-peer migration, the current
guest state must be recorded, so that non-live migration can
currently unpause a running guest on completion.

* src/qemu/qemu_migration.c: Move check for offline guest
  to fix non-live migration

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

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

Saving domain to previously created file changes also its ownership.
This is certainly not what users want if some conditions are met:
it is a regular, local file and dynamic_ownership is off.

NB: the enum that uses the string vnet-host (now changed to vhost-net)
is used in XML, but fortunately that hasn't been in an official
release yet, so it can still be fixed.

Since -vnc uses ':' to separate the address from the port, raw
IPv6 addresses need to be escaped like [addr]:port

* src/qemu/qemu_command.c: Escape raw IPv6 addresses with []
* tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc.args,
  tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc.xml: Tweak
  to test Ipv6 escaping
* docs/schemas/domain.rng: Allow Ipv6 addresses, or hostnames
  in <graphics> listen attributes

The qemuMigrationConfirm method shouldn't deal with final VM
cleanup, since it can be called from the peer2peer migration,
which expects to still use the 'vm' object afterwards.

Push the cleanup code out of qemuMigrationConfirm, into its
caller, qemuDomainMigrateConfirm3

* src/qemu/qemu_driver.c: Add VM cleanup code to
  qemuDomainMigrateConfirm3
* src/qemu/qemu_migration.c, src/qemu/qemu_migration.h: Remove
  job handling cleanup from qemuMigrationConfirm

To allow new mandatory migration cookie data to be introduced,
add support for checking supported feature flags when parsing
migration cookie.

* src/qemu/qemu_migration.c: Feature flag checking in migration
  cookie parsing

This adds a streaming-video=filter|all|off attribute. It is used to change
the behavior of video stream detection in spice, the default is filter (the
default for libvirt is not to specify it - the actual default is defined in
libspice-server.so).

Usage:

    <graphics type='spice' autoport='yes'>
      <streaming mode='off'/>
    </graphics>

Tested with the above and with tests/qemuxml2argvtest.
Signed-off-by: NAlon Levy <alevy@redhat.com>

This was discussed in:

  https://www.redhat.com/archives/libvir-list/2011-May/msg01370.html

The capabilities code only sets the flag to allow use of vhost-net if
kvm is detected (set if the help string contains "(qemu-kvm-" or
"(kvm-"), but actually vhost-net is available in some qemu builds that
don't have kvm in their name, so just checking for ",vhost=" is enough.

Otherwise qemu is unable to write to it, with the error:

libvir: QEMU error : internal error unable to execute QEMU command 'memsave': Could not open '/var/cache/libvirt/qemu/qemu.mem.RRNvLv'

The v2 migration protocol had a limit on cookie length that was
too small to be useful for QEMU. Avoid generating cookies with
v2 protocol, so that old libvirtd can still reliably migrate a
guest to new libvirtd uses v2 protocol.

* src/qemu/qemu_driver.c: Avoid migration cookies with v2
  migration

When generating a cookie for a guest with no data, the
QEMU_MIGRATION_COOKIE_GRAPHICS flag was set even if no
graphics data was added. Avoid setting the flag unless
it was needed, also add a safety check for mig->graphics
being non-NULL

* src/qemu/qemu_migration.c: Avoid cookie crash for guest
  with no graphics

Improve invalid argument checks in the size query case. The drivers already
relied on this unchecked behavior.

Relax the implementation of virDomainGet(Memory|Blkio)MemoryParameters
in the drivers and allow to pass more memory than necessary for all
parameters.

params and nparams are essential and cannot be NULL. Check this in
libvirt.c and remove redundant checks from the drivers (e.g. xend).

Instead of enforcing that nparams must point to exact same value as
returned by virDomainGetSchedulerType relax this to a lower bound
check. This is what some drivers (e.g. xen hypervisor and esx)
already did. Other drivers (e.g. xend) didn't check nparams at all
and assumed that there is enough space in params.

Unify the behavior in all drivers to a lower bound check and update
nparams to the number of valid values in params on success.

This typo caused XPath returning improper value and thus not
working spice after migration.

Support for virDomainSetSchedulerParametersFlags of qemu driver.

* src/qemu/qemu_migration.c: Add missing 'ret' initializer
  in qemuMigrationCookieXMLParseStr

By running the doTunnelSendAll code in a separate thread, the
main thread can do qemuMigrationWaitForCompletion as with
normal migration. This in turn ensures that job signals work
correctly and that progress monitoring can be done

* src/qemu/qemu_migration.c: Run tunnelled migration in
  separate thread

virStreamSend already sets an error message, so don't
overwrite it

* src/qemu/qemu_migration.c: Remove bogus error report

Cancelling the QEMU migration may cause QEMU to flush pending
data on the migration socket. This may in turn block QEMU if
nothing reads from the other end of the socket. Closing the
socket before cancelling QEMU migration avoids this possible
deadlock.

* src/qemu/qemu_migration.c: Close sockets before cancelling
  migration on failure

The 'nbytes' variable was not re-initialized to the
buffer size on each iteration of the tunnelled migration
loop. While saferead() will ensure a full read, except
on EOF, it is clearer to use the real buffer size

* src/qemu/qemu_migration.c: Always read full buffer of data

The doTunnelMigrate method forgot to set the bandwidth
resource restriction

* src/qemu/qemu_migration.c: Set resource restriction

The qemuMigrationWaitForCompletion method contains a loop which
repeatedly queries QEMU to check migration progress, and also
processes job signals (pause, setspeed, setbandwidth, cancel).

The tunnelled migration loop does not currently support this
functionality, but should. Refactor the code to allow it to
be used with tunnelled migration.

Implement the v3 migration protocol, which has two extra
steps, 'begin' on the source host and 'confirm' on the
source host. All other methods also gain both input and
output cookies to allow bi-directional data passing at
all stages.

The QEMU peer2peer migration method gains another impl
to provide the v3 migration. This finally allows migration
cookies to work with tunnelled migration, which is required
for Spice seamless migration & the lock manager transfer

* src/qemu/qemu_driver.c: Wire up migrate v3 APIs
* src/qemu/qemu_migration.c, src/qemu/qemu_migration.h: Add
  begin & confirm methods, and peer2peer impl of v3

Merge the doNonTunnelMigrate2 and doTunnelMigrate2 methods
into one doPeer2PeerMigrate2 method, since they are substantially
the same. With the introduction of v3 migration, this will be
even more important, to avoid massive code duplication.

* src/qemu/qemu_migration.c: Merge tunnel & non-tunnel migration

To facilitate the introduction of the v3 migration protocol,
the doTunnelMigrate method is refactored into two pieces. One
piece is intended to mirror the flow of virDomainMigrateVersion2,
while the other is the helper for setting up sockets and processing
the data.

Previously socket setup would be done before the 'prepare' step,
so errors could be dealt with immediately, avoiding need to shut
off the destination QEMU. In the new split, socket setup is done
after the 'prepare' step. This is not a serious problem, since
the control flow already requires calling 'finish' to tear down
the destination QEMU upon several errors.

* src/qemu/qemu_migration.c:

Use the graphics information from the QEMU migration cookie to
issue a 'client_migrate_info' monitor command to QEMU. This causes
the SPICE client to automatically reconnect to the target host
when migration completes

* src/qemu/qemu_migration.c: Set data for SPICE client relocation
  before starting migration on src
* src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h,
  src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_json.h,
  src/qemu/qemu_monitor_text.c, src/qemu/qemu_monitor_text.h: Add
  new qemuMonitorGraphicsRelocate() command

Extend the QEMU migration cookie structure to allow information
about the destination host graphics setup to be passed by to
the source host. This will enable seamless migration of any
connected graphics clients

* src/qemu/qemu_migration.c: Add graphics info to migration
  cookies
* daemon/libvirtd.c: Always initialize gnutls to enable
  x509 cert parsing in QEMU

The migration protocol has support for a 'cookie' parameter which
is an opaque array of bytes as far as libvirt is concerned. Drivers
may use this for passing around arbitrary extra data they might
need during migration. The QEMU driver needs to do a few things:

 - Pass hostname/uuid to allow strict protection against localhost
   migration attempts
 - Pass SPICE/VNC server port from the target back to the source to
   allow seamless relocation of client sessions
 - Pass lock driver state from source to destination

This patch introduces the basic glue for handling cookies
but only includes the host/guest UUID & name.

* src/libvirt_private.syms: Export virXMLParseStrHelper
* src/qemu/qemu_migration.c, src/qemu/qemu_migration.h: Parsing
  and formatting of migration cookies
* src/qemu/qemu_driver.c: Pass in cookie parameters where possible
* src/remote/remote_protocol.h, src/remote/remote_protocol.x: Change
  cookie max length to 16384 bytes

The qemuMigrationPrepareTunnel method should not unlock the
qemu driver, since that is the caller's job.

* src/qemu/qemu_migration.c: Fix qemuMigrationPrepareTunnel
  unlocking of QEMU driver

Add many version number annotations to the internal driver
tables, to allow hvsupport.html to display more accurate
information

Change all the driver struct initializers to use the
C99 style, leaving out unused fields. This will make
it possible to add new APIs without changing every
driver. eg change:

    qemudDomainResume, /* domainResume */
    qemudDomainShutdown, /* domainShutdown */
    NULL, /* domainReboot */
    qemudDomainDestroy, /* domainDestroy */

to

    .domainResume = qemudDomainResume,
    .domainShutdown = qemudDomainShutdown,
    .domainDestroy = qemudDomainDestroy,

And get rid of any existing C99 style initializersr which
set NULL, eg change

     .listPools          = vboxStorageListPools,
     .numOfDefinedPools  = NULL,
     .listDefinedPools   = NULL,
     .findPoolSources    = NULL,
     .poolLookupByName   = vboxStoragePoolLookupByName,

to

     .listPools          = vboxStorageListPools,
     .poolLookupByName   = vboxStoragePoolLookupByName,

Fix some driver names:

  s/virDrvCPUCompare/virDrvCompareCPU/
  s/virDrvCPUBaseline/virDrvBaselineCPU/
  s/virDrvQemuDomainMonitorCommand/virDrvDomainQemuMonitorCommand/
  s/virDrvSecretNumOfSecrets/virDrvNumOfSecrets/
  s/virDrvSecretListSecrets/virDrvListSecrets/

And some driver struct field names:

  s/getFreeMemory/nodeGetFreeMemory/

A qemu domain can get paused when libvirtd is stopped (e.g., because of
I/O error) so we should check its current state when reconnecting to it.

Only in drivers which use virDomainObj, drivers that query hypervisor
for domain status need to be updated separately in case their hypervisor
supports this functionality.

The reason is also saved into domain state XML so if a domain is not
running (i.e., no state XML exists) the reason will be lost by libvirtd
restart. I think this is an acceptable limitation.

Reason is currently always set to 0 (i.e., *_UNKNOWN).

v2:
    Drop libvirt_private.syms changes

v3:
    Adjust for new virDomainEventStateNew argument