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