<div dir="ltr"><div class="gmail_extra"><div style>Unfortunately resizes are much worse than what's being described here.</div><div style><br></div><div style>Aside from the SSH, which we all agree has a number of associated problems, there are 3 separate image conversions which occur (assuming you are using raw backed qcow, which is the default). The first conversion flattens the image, eliminating the backing file. This occurs on the origin hypervisor, with the result being SCP'd to the destination. Once complete, the second conversion kicks off, which converts from qcow2 to raw. This is done in an attempt to resize the filesystem contained within the image. This resize will fail unless you're using AMIs, as there is no logic in place to resize images containing partitions. The third conversion occurs as the raw is converted back into qcow2.</div>
<div style><br></div><div style>Until recently, there was absolutely nothing taking shared storage into account. In fact, if you are using shared storage, be absolutely certain to apply the patch associated with this bug (<a href="https://bugs.launchpad.net/nova/+bug/1177247">https://bugs.launchpad.net/nova/+bug/1177247</a>). Otherwise, there are a number of cases where *you will lose data*. If you want to go a step further, you're welcome to apply my patch to make the entire process a lot more efficient (<a href="https://gist.github.com/rmk40/ab2c6f518a7a40a261af">https://gist.github.com/rmk40/ab2c6f518a7a40a261af</a>). The patch copies the disk file around untouched and relies on code introduced in Grizzly to repopulate the backing files on the destination via Glance.</div>
<div style><br></div><div style>The good news is, we know how much work migrate/resize needs and are committed to fixing it in the Havana cycle. I haven't submitted the aforementioned patch for this very reason, we're overhauling the code path entirely. Nonetheless, Grizzly represents stable today, so if you're doing resizes on a regular basis, take a look at the patch. It has zero chance of going into stable/grizzly, because of the constraints around how the stable tree is managed. </div>
<div style><br></div><div style>- Rafi</div><div style><br></div><br><div class="gmail_quote">On Tue, May 21, 2013 at 3:24 PM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@yahoo-inc.com" target="_blank">harlowja@yahoo-inc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>Hi Ryan,</div>
<div><br>
</div>
<div>Yes it is a little bit weird, I think the reasons its doing this is likely due to it being the most generic solution to the resizing problem. I believe there is a flag like 'resize_same_host' but I haven't used it that might help.</div>
<div><br>
</div>
<div>I think your concern is valid though and could/should(?) be fixed. </div>
<div><br>
</div>
<div>You could imagine the scheduler 'preferring' the origin compute and the origin compute node in this case doing a 'fast path' resize path that would trigger the compute manager to just move some folders around (instead of invoking the ssh sequence you talked
about). This would seem to make sense to me and would avoid the 'slow path' of actually moving the instance (and disks and so on) to a new node since the origin node doesn't have enough space/cpu/memory… That would make sense to me and likely with beefy enough
compute nodes the 'fast path' would be the common case.</div>
<div><br>
</div>
<div>-Josh</div>
<div><br>
</div>
<span>
<div style="border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;text-align:left;font-size:11pt;font-family:Calibri;border-top-color:rgb(181,196,223)">
<span style="font-weight:bold">From: </span>Ryan Lane <<a href="mailto:rlane@wikimedia.org" target="_blank">rlane@wikimedia.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, May 21, 2013 2:25 PM<br>
<span style="font-weight:bold">To: </span>Juan José Pavlik Salles <<a href="mailto:jjpavlik@gmail.com" target="_blank">jjpavlik@gmail.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>" <<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openstack-operators] resizing an instance<br>
</div><div><div class="h5">
<div><br>
</div>
<div>
<div>
<div dir="ltr">On Tue, May 21, 2013 at 2:20 PM, Juan José Pavlik Salles <span dir="ltr">
<<a href="mailto:jjpavlik@gmail.com" target="_blank">jjpavlik@gmail.com</a>></span> wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">I'm not sure about your deployment, but i noticed that when i try to resize a vm nova also tries to move the vm to another compute-node, so if you don't have a shared storage for the VMs this is not possible (unless your compute-node can ssh
to the other compute-node ofcourse). I found in my logs thigs like "<b>ssh root@node2 mkdir -p /var/lib/nova/instances/instances_dir"</b> when trying to resize a VM. Tomorrow i'll trying resizing with shared storage and i'll let you know. </div>
<div class="gmail_extra"><br>
</div>
</blockquote>
<div><br>
</div>
<div>Yes. This is the weirdest behavior. Why in the world is it necessary to move the instance to another compute node just to do a resize? It requires ssh between instances, makes the process *much* slower and also makes it way more error prone. I
don't get it. This seems like a really convoluted way of handling resizes.</div>
<div><br>
</div>
<div>Is there some really great reasoning behind this?</div>
<div><br>
</div>
<div>- Ryan</div>
</div>
</div>
</div>
</div>
</div>
</div></div></span>
</div>
<br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div></div>