<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 9, 2023 at 11:23 AM Budden, Robert M. (GSFC-606.2)[InuTeq, LLC] <<a href="mailto:robert.m.budden@nasa.gov">robert.m.budden@nasa.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="msg7562128309836904564">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="m_7562128309836904564WordSection1">
<p class="MsoNormal"><span style="color:black">Hello Community,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black">We’ve hit a rather pesky bug that I’m hoping someone else has seen before. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black">We have an issue with Nova where a set of Cinder backed VMs are having their XML definitions modified after a live migration. Specifically, the destination host ends up having the disk type changed from ‘qcow2’
 to ‘raw’. This ends up with the VM becoming unbootable upon the next hard reboot (or nova stop/start is issued). The required fix ATM is for us to destroy the VM and recreate from the persistent Cinder volume. Clearly this isn’t a maintainable solution as
 we rely on live migration for patching infrastructure.</span></p></div></div></div></blockquote><div><br></div><div>Can you share the bits of the libvirt XML that are changing?  I'm curious to know what is your storage backend as well (Ceph?  LVM with Cinder?)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="msg7562128309836904564"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_7562128309836904564WordSection1"><p class="MsoNormal"> </p></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="msg7562128309836904564"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_7562128309836904564WordSection1"><p class="MsoNormal"><span style="color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black">Any thoughts, ideas, would be most welcome. Gory details are below.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black">Here’s the key details we have:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black"> <u></u><u></u></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black">Nova boot an instance from the existing volume works as expected.<u></u><u></u></li><li class="MsoNormal" style="color:black">After live migration the ‘type’ field in the virsh XML is changed from ‘qcow2’ -> ‘raw’ and we get a ‘No bootable device’ from the VM (rightly so)<u></u><u></u></li><li class="MsoNormal" style="color:black">After reverting this field automatically (scripted solution), a ‘nova stop’ followed by a ‘nova start’ yet again rewrites the XML with the bad type=’raw’. <u></u><u></u></li><li class="MsoNormal" style="color:black">It should be noted that before a live migration is performed ‘nova stop/start’ functions as expected, no XML changes are written to the virsh definition.<u></u><u></u></li><li class="MsoNormal" style="color:black">Injecting additional logs into the python on these two hosts I’ve narrowed it down to ‘bdm_info.connection_info’ on the destination end is choosing the ‘raw’ parameter somehow (I’ve only got
 so far through the code at this time). The etree.XMLParser of the source hypervisors XML definition is properly parsing out ‘qcow2’ type.</li></ul></div></div></div></blockquote><div><br></div><div>I'm kinda curious how you're hosting `qcow2` inside of a storage backend, usually, the storage backends want raw images only...  Is there any chance you've played with the images and are the images that these cinder volumes by raw/qcow2?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="msg7562128309836904564"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_7562128309836904564WordSection1">
<p class="MsoNormal"><span style="color:black">Some background info:<u></u><u></u></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black">We’re currently running the Wallaby release with the latest patches. <u></u><u></u></li><li class="MsoNormal" style="color:black">Hybrid OS (Stream8 /Rocky 8) on underlying hardware with the majority of the Control Plane Stream aside from our Neutron Network Nodes. Computes are roughly split 50/50 Stream/Rocky.<u></u><u></u></li><li class="MsoNormal" style="color:black">The Cinder volumes that experience this were copied in from a previous OpenStack cloud (Pike/Queens) on the backend. I.e. NetApp snapmirror, new bootable Cinder volume created on the backend,
 and an internal NetApp operation for a zero copy operation over the backing Cinder file. <u></u><u></u></li><ul style="margin-top:0in" type="circle">
<li class="MsoNormal" style="color:black">Other Cinder volumes that don’t exhibit this to mostly be in ‘raw’ format already (we haven’t vetted every single bootable Cinder volume yet).<u></u><u></u></li></ul>
<li class="MsoNormal" style="color:black">We’ve noticed these Cinder volumes lack some metadata fields that other Cinder volumes create by Glance have (more details below).</li></ul></div></div></div></blockquote><div><br></div><div>Are those old running VMs or an old cloud?  I wonder if those are old records that became raw with the upgrade *by default* and now you're stuck in this weird spot.  If you create new volumes, are they qcow2 or raw?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="msg7562128309836904564"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_7562128309836904564WordSection1"><ul style="margin-top:0in" type="disc"><li class="MsoNormal" style="color:black"><span style="color:rgb(34,34,34)"> </span></li></ul></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="msg7562128309836904564"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_7562128309836904564WordSection1"><p class="MsoNormal"></p>
<p class="MsoNormal"><span style="color:black">Ideas we’ve tried:<u></u><u></u></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black">Adjusting settings on both computes for ‘use_cow_images’ and ‘force_raw_images’ seem to have zero effect.<u></u><u></u></li><li class="MsoNormal" style="color:black">Manually setting the Cinder metadata parameters to no avail (i.e. openstack volume set --image-property disk_format=qcow2).<u></u><u></u></li></ul>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks!<u></u><u></u></p>
<p class="MsoNormal">-Robert<u></u><u></u></p>
</div>
</div>

</div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Mohammed Naser<br>VEXXHOST, Inc.</div></div>