Re: [PATCH 1/8] Add on_migrate element to domainXML

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>
>> +  ...
>> +  &lt;on_migrate&gt;
>> +    &lt;bandwidth peak="1024"&gt;
>> +  &lt;/on_migrate&gt;
>> +  ...</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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]