On 02/24/2011 01:41 PM, Barak Azulay wrote:
On Wednesday 23 February 2011 21:53:25 Perry Myers wrote:
>>> If a guest boots in the cloud but no network is there to connect to
>>> it, does it really exist?
>> Yes it does and it consumes valubale CPU and memory.
>> The question what happens in such a case.
> Very simple answer... if you spin up a guest in a cloud, and it doesn't
> get a network interface/ip address, you wait a bit (configurable) and
> then you shoot it violently in the head. A guest in the cloud with no
> network is not worth keeping around :)
This is correct , but this is the easy part.
Now the management stack needs to:
1 - notify the user - that actually tried to bring up this VM
Sure, the Aeolus Conductor would do this when it got feedback that the
VM was started by Deltacloud, but no heartbeat was received. 'how long
do you wait for the initial heartbeat' needs to be a configurable policy
2 - may be try to run it somewhere else ? depends on QOS
yep. policy might dictate that you shoot the node and relaunch on
different cloud, or it might dictate you report failure and allow user
to decide what to do
3 - enable the administrator to understand the reason for failure
that would be part of #1 I think. Unfortunately, w/o network access
getting logs off of the node will not be easy (or possible)
In addition what do you do when a VM looses network for some reason ?
happen...) Do you also shoot it?
Policy decision. If your VM is marked as needing to be HA, then you
absolutely would need to shoot it and restart (again depending on policy).
At the least you would mark the VM as 'no heartbeat' even if you don't
end up shooting it automatically. This might be for a case where the
user would rather manually shoot instead of automatically.
Basically there are several states a guest can be in, since node health
detection can come from two places: guest heartbeat vs. deltacloud
DC says guest is up, HB says guest is up: Normal
DC says guest is up, HB says guest is down: OS failure
DC says guest is down, HB says guest is down: VM failure
DC says guest is down, HB says guest is up: shouldn't happen, but if it
does likely this is a bug in DC or the cloud providers APIs
What about the case a VM has several nics and only some of them got
Each guest needs to have a notion of what it's management interface is
(i.e. the interface that it uses to talk to the external qpid broker).
If the mgmt iface is down, see above. If the non-mgmt ifaces are down,
that doesn't affect the HB of the guest, but it would affect service
health. So depending on policy you might need to shoot the node anyhow.