<div dir="ltr">That's a good point. So i will try migration to see what happens. Thanks!</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/22 Belmiro Moreira <span dir="ltr"><<a href="mailto:moreira.belmiro.email.lists@gmail.com" target="_blank">moreira.belmiro.email.lists@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
do not confuse migration, resize, live-migration, evacuate, … :)<br>
Rafi is talking about resize/migrate over shared storage.<br>
<br>
cheers,<br>
Belmiro<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On May 22, 2013, at 8:11 PM, Juan José Pavlik Salles <<a href="mailto:jjpavlik@gmail.com">jjpavlik@gmail.com</a>> wrote:<br>
<br>
> Good to know! So, whether i use shared storage or not, i won't be able to use live migration (a safe migration) with stable/grizzly (unless i apply the patch Rafi mentions)?<br>
><br>
><br>
> 2013/5/21 Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>><br>
> Thank Rafi,<br>
><br>
> That is a pretty sad state of things. Hoping things get better (and simpler) in havana. Resizing now scares me more than it did.<br>
><br>
> From: Rafi Khardalian <<a href="mailto:rafi@metacloud.com">rafi@metacloud.com</a>><br>
> Date: Tuesday, May 21, 2013 3:53 PM<br>
> To: Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>><br>
> Cc: Ryan Lane <<a href="mailto:rlane@wikimedia.org">rlane@wikimedia.org</a>>, Juan José Pavlik Salles <<a href="mailto:jjpavlik@gmail.com">jjpavlik@gmail.com</a>>, "<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>" <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>><br>
><br>
> Subject: Re: [Openstack-operators] resizing an instance<br>
><br>
> Unfortunately resizes are much worse than what's being described here.<br>
><br>
> 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.<br>
><br>
> 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" target="_blank">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" target="_blank">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.<br>
><br>
> 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.<br>
><br>
> - Rafi<br>
><br>
><br>
> On Tue, May 21, 2013 at 3:24 PM, Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>> wrote:<br>
> Hi Ryan,<br>
><br>
> 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.<br>
><br>
> I think your concern is valid though and could/should(?) be fixed.<br>
><br>
> 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.<br>
><br>
> -Josh<br>
><br>
> From: Ryan Lane <<a href="mailto:rlane@wikimedia.org">rlane@wikimedia.org</a>><br>
> Date: Tuesday, May 21, 2013 2:25 PM<br>
> To: Juan José Pavlik Salles <<a href="mailto:jjpavlik@gmail.com">jjpavlik@gmail.com</a>><br>
> Cc: "<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>" <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>><br>
> Subject: Re: [Openstack-operators] resizing an instance<br>
><br>
> On Tue, May 21, 2013 at 2:20 PM, Juan José Pavlik Salles <<a href="mailto:jjpavlik@gmail.com">jjpavlik@gmail.com</a>> wrote:<br>
> 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 "ssh root@node2 mkdir -p /var/lib/nova/instances/instances_dir" when trying to resize a VM. Tomorrow i'll trying resizing with shared storage and i'll let you know.<br>
><br>
><br>
> 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.<br>
><br>
> Is there some really great reasoning behind this?<br>
><br>
> - Ryan<br>
><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>
><br>
><br>
><br>
><br>
> --<br>
> Pavlik Salles Juan José<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Pavlik Salles Juan José</div>
</div>