Open Stack

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 ☺

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 <Armando.Migliaccio at eu.citrix.com> 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<https://blueprints.launchpad.net/nova/+spec/guest-ha> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120206/b2936bbf/attachment-0002.html>