Daniel P. Berrange wrote:
On Fri, Aug 26, 2011 at 12:10:20PM -0600, Jim Fehlig wrote:
> on_migrate can be used to modify default parameters used when
> migrating a domain.
> ---
> docs/formatdomain.html.in | 21 ++++++++++++++++
> docs/schemas/domain.rng | 13 ++++++++++
> tests/domainschemadata/migration-params.xml | 34 +++++++++++++++++++++++++++
> 3 files changed, 68 insertions(+), 0 deletions(-)
> create mode 100644 tests/domainschemadata/migration-params.xml
>
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index f46771d..84dd590 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -692,6 +692,27 @@
> domain will be restarted with the same configuration</dd>
> </dl>
>
> + <p>
> + Default migration parameters, such as maximum or peak bandwidth
> + used during domain migration, can be specified with the
> + on_migrate element. Note that some hypervisors may not support
> + changing migration parameters.
> + </p>
> +
> +<pre>
> + ...
> + <on_migrate>
> + <bandwidth peak="1024">
> + </on_migrate>
> + ...</pre>
> +
> + <dl>
> + <dt><code>bandwidth</code></dt>
> + <dd>Maximum or peak bandwidth consumed during the migration
> + operation can be specified with the <code>peak</code>
> + attribute. Units are MB/s.</dd>
> + </dl>
> +
> <h3><a name="elementsFeatures">Hypervisor
features</a></h3>
>
> <p>
> diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng
> index dd8c41a..b729aa7 100644
> --- a/docs/schemas/domain.rng
> +++ b/docs/schemas/domain.rng
> @@ -1623,6 +1623,19 @@
> <ref name="crashOptions"/>
> </element>
> </optional>
> + <optional>
> + <element name="on_migrate">
> + <optional>
> + <element name="bandwidth">
> + <optional>
> + <attribute name="peak">
> + <ref name="positiveInteger"/>
> + </attribute>
> + </optional>
> + </element>
> + </optional>
> + </element>
> + </optional>
> </interleave>
> </define>
> <!--
> diff --git a/tests/domainschemadata/migration-params.xml
b/tests/domainschemadata/migration-params.xml
> new file mode 100644
> index 0000000..d01229b
> --- /dev/null
> +++ b/tests/domainschemadata/migration-params.xml
> @@ -0,0 +1,34 @@
> +<domain type='qemu'>
> + <name>test-domain</name>
> + <uuid>c3d496e6-fb22-7d89-1e73-9d3e231ba59f</uuid>
> + <memory>524288</memory>
> + <currentMemory>524288</currentMemory>
> + <vcpu>1</vcpu>
> + <os>
> + <type arch='x86_64' machine='pc'>hvm</type>
> + <boot dev='hd'/>
> + </os>
> + <features>
> + <acpi/>
> + <apic/>
> + <pae/>
> + </features>
> + <clock offset='utc'/>
> + <on_poweroff>destroy</on_poweroff>
> + <on_reboot>restart</on_reboot>
> + <on_crash>destroy</on_crash>
> + <on_migrate>
> + <bandwidth peak='1024' />
> + </on_migrate>
> + <devices>
> + <emulator>/usr/bin/qemu</emulator>
> + <disk type='file' device='disk'>
> + <driver name='qemu' type='raw'/>
> + <source file='/path/to/disk.img'/>
> + <target dev='hda' bus='ide'/>
> + <address type='drive' controller='0' bus='0'
unit='0'/>
> + </disk>
> + <controller type='ide' index='0'/>
> + <memballoon model='virtio'/>
> + </devices>
> +</domain>
>
I'm not entirely convinced by the idea of storing extra parameters to
be used by future API calls, in the guest XML. When the guest XML is
being defined, apps likely don't know when/where the guest will be
migrated in the future, so I'm not sure reasonable guesses about
migration bandwidth can be made then. IMHO the guest XML is really
about configuration, and this doesn't feel like a configuration
parameter, rather it is an operational parameter.
Thanks for the comments. I like your suggestion of putting max
bandwidth in qemuDomainObjPrivate struct.
I'll push patches 2 and 5, drop 1 and 3, and provide a v2 of 4, 6-8
using your suggestion.
BTW, what do folks consider a sane libvirt default for migration
bandwidth? Patch 7 sets bandwidth to unlimited when destination is a
file, so default here means network bandwidth. Is qemu's 32MiB/s
reasonable?
Regards,
Jim