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.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|