On 18.06.2013 16:05, Jiri Denemark wrote:
> To be used by new migration APIs with extensible set of parameters.
> ---
> include/libvirt/libvirt.h.in | 56 ++++++++++++++++++++++++++++++++++++++++++++
> src/libvirt_internal.h | 5 ++++
> 2 files changed, 61 insertions(+)
>
> diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> index acf3218..35bffea 100644
> --- a/include/libvirt/libvirt.h.in
> +++ b/include/libvirt/libvirt.h.in
> @@ -1191,6 +1191,62 @@ typedef enum {
> VIR_MIGRATE_ABORT_ON_ERROR = (1 << 12), /* abort migration on I/O errors happened during migration */
> } virDomainMigrateFlags;
>
> +
> +/**
> + * VIR_MIGRATE_PARAM_URI:
> + *
> + * virDomainMigrate* params field: URI to use for initiating domain migration
> + * as VIR_TYPED_PARAM_STRING. It takes a hypervisor specific format. The
> + * uri_transports element of the hypervisor capabilities XML includes details
> + * of the supported URI schemes. When omitted libvirt will auto-generate
> + * suitable default URI. It is typically only necessary to specify this URI if
> + * the destination host has multiple interfaces and a specific interface is
> + * required to transmit migration data.
> + *
> + * This filed may not be used when VIR_MIGRATE_TUNNELLED flag is set.
> + */
> +#define VIR_MIGRATE_PARAM_URI "migrate_uri"
> +
> +/**
> + * VIR_MIGRATE_PARAM_DEST_NAME:
> + *
> + * virDomainMigrate* params field: the name to be used for the domain on the
> + * destination host as VIR_TYPED_PARAM_STRING. Omitting this parameter keeps
> + * the domain name the same. This field is only allowed to be used with
> + * hypervisors that support domain renaming during migration.
> + */
> +#define VIR_MIGRATE_PARAM_DEST_NAME "destination_name"
> +
> +/**
> + * VIR_MIGRATE_PARAM_DEST_XML:
> + *
> + * virDomainMigrate* params field: the new configuration to be used for the
> + * domain on the destination host as VIR_TYPED_PARAM_STRING. The configuration
> + * must include an identical set of virtual devices, to ensure a stable guest
> + * ABI across migration. Only parameters related to host side configuration
> + * can be changed in the XML. Hypervisors which support this will validate
... Hypervisors which support this field will validate it and refuse to
allow migration ...
> + * this and refuse to allow migration if the provided XML would cause a change
> + * in the guest ABI. This field cannot be used to rename the domain during
> + * migration (use VIR_MIGRATE_PARAM_DEST_NAME field for that purpose). Domain
> + * name in the destination XML must match the original domain name.
> + *
> + * Omitting this parameter keeps the original domain configuration. Using this
> + * field with hypervisors that do not support changing domain configuration
> + * during migration will result in a failure.
> + */
> +#define VIR_MIGRATE_PARAM_DEST_XML "destination_xml"
> +
> +/**
> + * VIR_MIGRATE_PARAM_BANDWIDTH:
> + *
> + * virDomainMigrate* params field: the maximum bandwidth (in MiB/s) that will
> + * be used for migration as VIR_TYPED_PARAM_ULLONG. If set to 0 or omitted,
> + * libvirt will choose a suitable default. Some hypervisors do not support this
> + * feature and will return an error if this field is used and is not 0.
> + */
> +#define VIR_MIGRATE_PARAM_BANDWIDTH "bandwidth"
> +
> +
> /* Domain migration. */
> virDomainPtr virDomainMigrate (virDomainPtr domain, virConnectPtr dconn,
> unsigned long flags, const char *dname,
> diff --git a/src/libvirt_internal.h b/src/libvirt_internal.h
> index 29f2043..434d795 100644
> --- a/src/libvirt_internal.h
> +++ b/src/libvirt_internal.h
> @@ -110,6 +110,11 @@ enum {
> * Support for offline migration.
> */
> VIR_DRV_FEATURE_MIGRATION_OFFLINE = 12,
> +
> + /*
> + * Support for migration parameters.
> + */
> + VIR_DRV_FEATURE_MIGRATION_PARAMS = 13,
Isn't it a bit too soon for this chunk? I think it fits into 11/21 better.
> };
>
>
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list