gerrit at gerr1t
Feb 7, 2012, 1:36 AM
Post #7 of 7
(132 views)
Permalink
|
Hi Armando!
Using the code of live migration is an idea I should have
thought of sooner ;).
Do you have any idea where I can find the
live_migration class/function?
Regards,
Gerrit
On Mon, 6 Feb 2012
12:01:23 +0000, Armando Migliaccio wrote:
Hi Gerrit,
This is an
interesting approach and certainly worth pursuing in the most general case,
and in the kvm in particular. As for the xenapi case (or esx one for that
matter), I was more inclined to leverage HA capabilities that the
hypervisor layer provides you with?clearly with some cloud drizzle on top J
As for rebuilding the networking config for the instance, have you
thought about leveraging the code path for live migration? Only in this
case the migration will assume a shutdown instance.
Thanks!
Armando
FROM: Gerrit Tamboer [mailto:gerrit at gerr1t.nl]
SENT: 31 January 2012
09:27
TO: Armando Migliaccio
CC:
openstack-operators at lists.openstack.org
SUBJECT: RE: [Openstack-operators]
A couple of questions regarding Nova
Hi Armando,
We are working on a
custom implementation for nova-ha. It is going to be a PHP daemon which
decides whether a compute-node is down by ping results of a combination of
the node itself and the instances running on it.
The algorithm which
decides the appriopriate actions is done, now we are working on how to
start an instance on another node.
This (in my view) can be done with the
following steps;
1. Start the instance in virsh
* Add the NWfilter by
the XML file
* Add the instance information by the (qemu) XML file
*
Start the instance
2. Update IPtables
* Add the standard instance firewall
rules
* Add the extra firewall rules provided by the instance's security
group
3. Add floating IP's
* Add the instance's floating IP's with 'ip
addr add'
* Add the IPtables rules to forward the IP to the instance
*
Arping the floating IP's (?)
4. Update the nova database
* Make sure the
controller knows that the instance is running on a different compute node
by updating the instances table
These steps should be enough to bring an
instance up on another node, or am I missing something?
The first step is
actually quite easy if your running shared storage, the only thing we need
to make sure is that the libvirt xml files are also on the shared storage
space to make sure other nodes can add the XML files.
Step 2 and 3 is
scriptable, allthough it would be nice if there is any way to trigger the
nova-api to rebuild the nova-networking for an instance. I have tried
rebooting an instance but that does not trigger it.
Anyone has any idea if
this is possible?
Thanks!
ps. Armando, when we are done and
successfully implemented our patch, I will leave a note on the blueprint
with our findings.
---
Met vriendelijke groet,
Gerrit Tamboer
On Mon,
30 Jan 2012 15:12:01 +0000, Armando Migliaccio wrote:
As for issue 1,
have you thought of implementing the stop functionality as a combination of
Snapshot+Terminate?
As for issue 2, there is a blueprint [1] to deal with
these sorts of scenarios. Unfortunately that's not going to help you in the
immediate term because the effort hasn't started yet (for lack of time more
than anything else).
Hope this help!
Armando
FROM:
openstack-operators-bounces at lists.openstack.org
[mailto:openstack-operators-bounces at lists.openstack.org] ON BEHALF OF
Gerrit Tamboer
SENT: 29 January 2012 09:38
TO:
openstack-operators at lists.openstack.org
SUBJECT: Re: [Openstack-operators]
A couple of questions regarding Nova
Hi!
Unfortunately, no reply
yet.
Does anyone have an idea how to solve these issues?
Especially the
second question is a pain :)
Regards,
Gerrit
On Fri, 27 Jan 2012
09:25:41 +0100, Gerrit Tamboer wrote:
Hi!
We are currently testing the
Openstack Nova product, but we have 2 problems/questions which we haven't
find a decent solution for yet.
1. In The Nova-api v1.1 there is no
option to Stop and Start an instance, only Reboot and Terminate. I know
that these options are available in v2.0 which is in Beta right
now.
Because we would like to work with the stable version of the Nova-Api
we are not planning to move to v2.0 for now.
We are wondering if anyone
has managed to find a solution for this issue? Is there a 'clean' way to
implement and use a Stop and Start function in the API? We can of course
make an exception by using custom shell scripts for the stop and start
function (using virsh destroy/start) but this is kinda nasty ;)..
2. On
our Nova-Compute machines we have shared storage using an iSCSI target
which gives us the ability to use Live Migration. This is working
perfectly! The only problem we are facing at this moment is that we want to
be able to start an instance on a different Compute Node when the original
Compute Node goes down. Is there an easy way or (even better) an API call
which can be used for this? The Live Migration function does not work when
the original Nova Compute node is down. We are currently planning to
implement our own patch which detects a compute node going down and
automatically starts the instances on different compute nodes using various
algorithms. Only the last part (starting an instance on a different node)
is something we need to figure out, hopefully you guys can help! :)
Regards,
Gerrit
Links:
------
[1]
https://blueprints.launchpad.net/nova/+spec/guest-ha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120207/5c7f04e4/attachment.html>
|
