Open Stack

Hi Samuel, i hadn't thought about deleting the instance file, now you
mentioned i'll think about it. What we do is:

-Suspend the instance
-Update DB
-Resume instance

that way the downtime is even smaller than really stopping the instance (we
have the instances in a shared storage). I still don't know why this work,
but somehow (maybe "magically") the network ovs interfaces are created on
the new node, and everything just work.

We use the same "DB update" trick to resize vpcus and memory, i know it's
not the best way but i couldn't make it with nova so far.

Cheers!


2013/12/17 Samuel Winchenbach <swinchen at gmail.com>

> Juan,
>
> Did you need to modify anything else in the database or delete any files
> other than the instance XML file in  /etc/libvirt/qemu?
>
>
> On Tue, Dec 17, 2013 at 12:38 PM, Juan José Pavlik Salles <
> jjpavlik at gmail.com> wrote:
>
>> I found the exact same solution, couldn't find any cleaner way for my
>> migration problem.
>>
>>
>> 2013/12/16 Samuel Winchenbach <swinchen at gmail.com>
>>
>>> Hi All,
>>>
>>> I have tried everything I can think of to migrate a VM to a node running
>>> a newer processor.  I have tried setting "libvirt_cpu_mode=none" on both
>>> hosts, I have tried creating a custom CPU, etc.  This is what I found
>>> worked:  Stop the instance, change "host", "node" and "launched_on" to the
>>> new hostname in the instances table in the nova database, then hard reboot
>>> the instance.  Something like this:
>>>
>>> ~# nova stop <UUID>
>>> ~# mysql -u root -p
>>> mysql> use nova;
>>> mysql> update instances set host='<NEWHOST>', node='<NEWHOST>',
>>> launched_on='<NEWHOST>' where uuid='<UUID>';
>>> mysql> exit
>>> ~# nova reboot --hard <UUID>
>>>
>>>
>>>
>>> So I have two questions about doing it this way:
>>> 1) Is there anything else in the database I need to change?
>>> 2) Are there any files I need to delete from the old host other than the
>>> instance XML file in  /etc/libvirt/qemu?
>>>
>>>
>>> Thanks!
>>> Sam
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>
>>
>> --
>> Pavlik Salles Juan José
>>
>
>


-- 
Pavlik Salles Juan José
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20131217/5aa416a5/attachment.html>