[Openstack-operators] Disabling VM Copy at Resizing
Mathias Brito
mathiasbrito at gmail.com
Thu Nov 27 12:38:46 UTC 2014
I found that we can do live migration (
http://docs.openstack.org/admin-guide-cloud/content/section_configuring-compute-migrations.html),
If there exists this tight relation between migration and resizing, if I
configure the system to do live migration, it will influence on how the
resizing is done? The resizing will get the benefits of live-migration?
Best Regards,
Mathias
Em Wed Nov 26 2014 at 18:49:32, Kris G. Lindgren <klindgren at godaddy.com>
escreveu:
> Also,
>
> If the vm was booted with any special scheduler requests
> (affinity/anti-affinity rules) those rules are NOT used when finding the
> new host to resize the vm on to. There is a ton of improvement to be had
> in the current resize/migrate code path. Basically, as it is right now a
> resize is a migration and it follows 99% of the same code path.
> ____________________________________________
>
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy, LLC.
>
> From: Juan José Pavlik Salles <jjpavlik at gmail.com>
> Date: Wednesday, November 26, 2014 at 10:36 AM
> To: Mike Smith <mismith at overstock.com>
> Cc: "openstack-operators at lists.openstack.org" <
> openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] Disabling VM Copy at Resizing
>
> My bad, you are right. The flag just allows the actual host to be
> included into the possible-hosts list.
>
> 2014-11-26 14:34 GMT-03:00 Mike Smith <mismith at overstock.com>:
>
>> Note that “allow_resize_to_same_host” doesn’t force it to stay on the
>> same host, it only allows it to happen. It’s still up to the scheduler as
>> to where it goes. Because we use shared storage at Overstock, we had to
>> work around this by disabling all the hypervisors except the one it’s on
>> before doing a resize.
>>
>> We also would love to see a way to prevent copying the disk when the
>> size doesn’t change. It’s annoying when you just want to make a CPU or RAM
>> change and have to wait for the disk copy. The other downside of resizing
>> is that it changes your nice, sparsely-provisioned copy-on-write disk image
>> into a full size image divorced from the qcow source disk.
>>
>> Mike Smith
>> Principal Engineer, Website Systems
>> Overstock.com
>>
>>
>>
>> On Nov 26, 2014, at 10:21 AM, Juan José Pavlik Salles <
>> jjpavlik at gmail.com> wrote:
>>
>> In Grizzly there's a flag "allow_resize_to_same_host=True" that at
>> least shouldn't move the instance from one node to another, but it's not
>> exactly what you want.
>>
>>
>> 2014-11-26 12:30 GMT-03:00 Mathias Brito <mathiasbrito at gmail.com>:
>>
>>> Hello people,
>>>
>>> Is there a away to avoid Openstack of making a copy of the VM when
>>> resizing it?
>>>
>>> Mathias
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>
>>
>> --
>> Pavlik Salles Juan José
>> Blog - http://viviendolared.blogspot.com
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>> ------------------------------
>>
>> CONFIDENTIALITY NOTICE: This message is intended only for the use and
>> review of the individual or entity to which it is addressed and may contain
>> information that is privileged and confidential. If the reader of this
>> message is not the intended recipient, or the employee or agent responsible
>> for delivering the message solely to the intended recipient, you are hereby
>> notified that any dissemination, distribution or copying of this
>> communication is strictly prohibited. If you have received this
>> communication in error, please notify sender immediately by telephone or
>> return email. Thank you.
>>
>
>
>
> --
> Pavlik Salles Juan José
> Blog - http://viviendolared.blogspot.com
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141127/595e76cd/attachment.html>
More information about the OpenStack-operators
mailing list