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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list