[libvirt] [PATCH 1/8] Add on_migrate element to domainXML
Jim Fehlig
jfehlig at suse.com
Thu Sep 1 17:55:10 UTC 2011
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
More information about the libvir-list
mailing list