<div dir="ltr">Hi team,<div><br><div><div>I agree that it's kind of strange thing that nova dumps xml definition to the disk but doesn't use it(at least I do not aware of it).</div><div>How the proposed changed would be aligned with other drivers? The worst case I could imagine here is that libvirt has an xml as a source of truth, while others use nova for the same purposes. Taking that into account, the question here would be:  why not to store all required information(e.g. boot order) in DB instead?</div><div><br></div><div>Timofey<br><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 30, 2016 at 7:36 PM, Murray, Paul (HP Cloud) <span dir="ltr"><<a href="mailto:pmurray@hpe.com" target="_blank">pmurray@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>
<div><br>
</div>
<div>
<div id="m_-3700237612347897216MAC_OUTLOOK_SIGNATURE"></div>
</div>
</div>
</div>
<div><br>
</div>
<span id="m_-3700237612347897216OLK_SRC_BODY_SECTION">
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div style="font-family:Calibri;font-size:12pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>Matthew Booth<br>
<span style="font-weight:bold">Reply-To: </span>"<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>"<br>
<span style="font-weight:bold">Date: </span>Friday, 30 September 2016 at 17:03<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>"<br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [nova][libvirt] Lets make libvirt's domain XML canonical<br>
</div>
<div><br>
</div>
</blockquote><span class="">
<div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px"></blockquote>
<div>
<div dir="ltr">
<div class="gmail_extra">
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div class="gmail_quote">On Fri, Sep 30, 2016 at 4:38 PM, Murray, Paul (HP Cloud)
<span dir="ltr"><<a href="mailto:pmurray@hpe.com" target="_blank">pmurray@hpe.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
<br>
<br>
On 27/09/2016, 18:12, "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>> wrote:<br>
<br>
>On Tue, Sep 27, 2016 at 10:40:34AM -0600, Chris Friesen wrote:<br>
>> On 09/27/2016 10:17 AM, Matthew Booth wrote:<br>
>><br>
>> > I think we should be able to create a domain, but once created we should never<br>
>> > redefine a domain. We can do adding and removing devices dynamically using<br>
>> > libvirt's apis, secure in the knowledge that libvirt will persist this for us.<br>
>> > When we upgrade the host, libvirt can ensure we don't break guests which are on<br>
>> > it. Evacuate should be pretty much the only reason to start again.<br>
>><br>
>> Sounds interesting.  How would you handle live migration?<br>
>><br>
>> Currently we regenerate the XML file on the destination from the nova DB.  I<br>
>> guess in your proposal we'd need some way of copying the XML file from the<br>
>> source to the dest, and then modifying the appropriate segments to adjust<br>
>> things like CPU/NUMA pinning?<br>
><br>
>Use the flag VIR_MIGRATE_PERSIST_XML and libvirt will write out the<br>
>new persistent XML on the target host automatically.<br>
<br>
We have a problem migrating rescued instances that has a fix in progress based<br>
on regenerating the xml on unrescue, see:<br>
<br>
 <a href="https://blueprints.launchpad.net/nova/+spec/live-migrate-rescued-instances" rel="noreferrer" target="_blank">https://blueprints.launchpad.<wbr>net/nova/+spec/live-migrate-re<wbr>scued-instances</a><br>
<br>
That might be another case for generating the xml.<br>
</blockquote>
<div><br>
</div>
<div>I thought it was a counter-argument (unless I've misunderstood). If you migrate the instance as-is without modification, you don't need to worry about whether it's currently a rescue instance. This problem goes away.</div>
<div><br>
</div>
<div>The major complication I can think of is things which genuinely must change during a migration, for example cpu pinning.</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</span></span>
<div><br>
</div>
<div>Rescue currently saves the libvirt xml in a separate file and replaces it with new xml to define a vm with a rescue boot disk; to unrescue it replaces the libvirt xml used for the rescue with the saved file to go back to the original state. On migration
 that saved xml would be lost because its an arbitrary file that is not handled in the migration. The spec above relies on the fact that we do not need to save it or copy it because we can recreate it from nova. So yes, the migration just works for the rescued
 vm, but when it is unrescued the original libvirt xml would be regenerated.</div><span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>Paul</div>
<span id="m_-3700237612347897216OLK_SRC_BODY_SECTION">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</span>
</font></span></div>

<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>