Sure, basically a way around this is to do migration of the VM's on the
host u are doing maintenance on.
That¹s one way y! has its ops folks work around this.
Another solution is just don't do local_deletes :-P
It sounds like your 'zombie' state would be useful as a way to solve this
also.
To
+1 to what Chris suggested. Zombie state that doesn't affect quota, but
doesn't create more problems by trying to reuse resources that aren't
available. That way we can tell the customer that things are deleted, but
we don't need to break our cloud by screwing up future schedule requests.
-Mike
On 10/08/2013 02:19 PM, Mike Wilson wrote:
+1 to what Chris suggested. Zombie state that doesn't affect quota, but
doesn't create more problems by trying to reuse resources that aren't
available. That way we can tell the customer that things are deleted,
but we don't need to break our cloud by
On 08/10/13 01:01, Russell Bryant wrote:
On 10/07/2013 06:34 PM, Vishvananda Ishaya wrote:
There is a configuration option stating what to do with instances that are
still in the hypervisor but have been deleted from the database. I think you
want:
running_deleted_instance_action=reap
On 10/07/2013 12:44 PM, Russell Bryant wrote:
On 10/07/2013 02:28 PM, Chris Friesen wrote:
I've been doing a lot of instance creation/deletion/evacuate and I've
noticed that if I
1)create an instance
2) power off the compute node it was running on
3) delete the instance
4) boot up the compute
There is a configuration option stating what to do with instances that are
still in the hypervisor but have been deleted from the database. I think you
want:
running_deleted_instance_action=reap
You probably also want
resume_guests_state_on_host_boot=true
to bring back the instances that
This brings up another question, do people actually like/use the
'local_delete' feature in nova?
In general it seems to free resources that are not actually capable of
being freed and has been problematic for y! usage.
Deleting from the DB allows another request to actually take those
resources
On 10/07/2013 06:34 PM, Vishvananda Ishaya wrote:
There is a configuration option stating what to do with instances that are
still in the hypervisor but have been deleted from the database. I think you
want:
running_deleted_instance_action=reap
You probably also want
On Oct 7, 2013, at 3:49 PM, Joshua Harlow harlo...@yahoo-inc.com wrote:
This brings up another question, do people actually like/use the
'local_delete' feature in nova?
In general it seems to free resources that are not actually capable of
being freed and has been problematic for y! usage.
A scenario that I've seen:
Take 'nova-compute' down for software upgrade, API still accessible since
you want to provide API uptime (aka not taking the whole cluster offline).
User Y deletes VM on that hypervisor where nova-compute is currently down,
DB locally deletes, at this point VM 'A' is
10 matches
Mail list logo
