Bug 1269908 (RHEV_auto_start_vms_local_dc)

Tentatively setting whiteboard=virt, as it seems like more of that domain that storage.

Michal, if your team needs a hand from mine, you'll get it, of course.

Changing to SLA as we are monitoring similar RFEs.
However, you should understand that currently the HA functionality
requires an additional host to migrate to in order to achieve HA.
There is no Auto start concept currently and we may consider it for the future.

We're nearing 2 years on this. Frankly, this lack of functionality is kind of pathetic. The solution seems conceptually simple, and at the lowest level should be trivial to implement: When a hypervisor restarts, any VMs assigned to it with a last known target-state of "running" should be returned to that state.

(In reply to Otheus from comment #3)
> We're nearing 2 years on this. Frankly, this lack of functionality is kind
> of pathetic. The solution seems conceptually simple, and at the lowest level
> should be trivial to implement: When a hypervisor restarts, any VMs assigned
> to it with a last known target-state of "running" should be returned to that
> state.

Thanks for your comments. Patches are always welcomed to the oVirt project and it seems you may want to contribute if this is needed for you.

Here are several things you'd need to consider:
- Hosts with local storage are single clusters, and there's no live migration between them. This is a limitation which you will need to accept.
- Who keeps track of which VMs are running and what happens on host crash? 
- How do you synchronize this to avoid conflicts with the engine?
- Stored VM configuration may not be the same (changes are not updated immediately) as the latest config
- How do you ensure a proper back up and restore and how do you handle disk corruption?

> Patches are always welcomed to the oVirt project

Ah, no thanks, that's why we've hired RedHat for support. Besides, I've seen the oVirt code. 

> - Hosts with local storage are single clusters, and there's no live migration between them. This is a limitation which you will need to accept.

This is the limitation we want! We just want the VMs to startup again if the hypervisor/host goes down. Is this so difficult a concept?

> - Who keeps track of which VMs are running 

What do you think the RHEV-M suite does? 

> and what happens on host crash? 

VM crash or host crash? VM crash: depends on watchdog settings. Host crash: should restore to latest-known state on startup, based on user coniguration option. I mean, anyone who has looked at a BIOS configuration since the late 1990s understands the concept: after power-resume, host should (1) power on, (2) stay off, (3) resume previous state. 

> - How do you synchronize this to avoid conflicts with the engine?
> - Stored VM configuration may not be the same (changes are not updated immediately) as the latest config

Synchronize what? why? Who cares if stored VM config is not the same as latest. Use latest known config.

> - How do you ensure a proper back up and restore and how do you handle disk corruption?

"Back up and restore"? Are we talking storage backups? Disk corruption: like any catastrophic failure on a a host, the VM will not run. This isn't some kind of super-bulletproof-high availability option; this is simply: if the hypervisor loses power, restore the VMs to what they were doing before.

(In reply to Otheus from comment #5)
> > Patches are always welcomed to the oVirt project
> 
> Ah, no thanks, that's why we've hired RedHat for support. Besides, I've seen
> the oVirt code. 
> 
> > - Hosts with local storage are single clusters, and there's no live migration between them. This is a limitation which you will need to accept.
> 
> This is the limitation we want! We just want the VMs to startup again if the
> hypervisor/host goes down. Is this so difficult a concept?
> 
> > - Who keeps track of which VMs are running 
> 
> What do you think the RHEV-M suite does? 
Doron, if the host is a single host 
> 
> > and what happens on host crash? 
> 
> VM crash or host crash? VM crash: depends on watchdog settings. Host crash:
> should restore to latest-known state on startup, based on user coniguration
> option. I mean, anyone who has looked at a BIOS configuration since the late
> 1990s understands the concept: after power-resume, host should (1) power on,
> (2) stay off, (3) resume previous state. 
> 
> > - How do you synchronize this to avoid conflicts with the engine?
> > - Stored VM configuration may not be the same (changes are not updated immediately) as the latest config
> 
> Synchronize what? why? Who cares if stored VM config is not the same as
> latest. Use latest known config.
> 
> > - How do you ensure a proper back up and restore and how do you handle disk corruption?
> 
> "Back up and restore"? Are we talking storage backups? Disk corruption: like
> any catastrophic failure on a a host, the VM will not run. This isn't some
> kind of super-bulletproof-high availability option; this is simply: if the
> hypervisor loses power, restore the VMs to what they were doing before.
I think what was meant here is what if anything happened on VM disk due to the failure of the host / local disk and the disk got corrupted - either physical corruption or data corruption and then VM won't start without fsck at a very least. But I see your point. 
Probably with the hosted engine solution, you can do it and use local disks as nfs exports to provide the storage. It will lack some of the HA features, but seems like it will give you exactly what you want.

This is being worked on as part of rhbz#1325468, and will be resolved there

*** This bug has been marked as a duplicate of bug 1325468 ***