[libvirt] [PATCH 08/21] Introduce migration parameters

Michal Privoznik mprivozn at redhat.com
Wed Jun 19 17:13:19 UTC 2013


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.

>  };
>  
>  
> 




More information about the libvir-list mailing list