Re: [ovirt-users] Autostart VMS

On Fri, 2016-04-08 at 21:50 +0300, Nir Soffer wrote: Hopefully this will go to the list as i"ve been making sure users@ovirt .org is in the To field. I think we need to make sure we distinguish between the start up phase and the running phase which is what happens after everyone is up and running happily.  Based on my experience the crash of a server is considered separately from startup.  As mentioned in my response to the list to someone else's comment the startup sequence is the same as people flipping switches on physical servers following a documented procedure to start or shutdown a datacenter as we did in the "old days".  With physical boxes we had to shutdown/startup manually and we did it in a sequence that we had written down.  With virtualization and since we had VMware we could automate that process so as we spun up the hosts VMware started spinning up the guests in the order specified so we got our DNS boxes up first, then others.  For Active Directory we started the domain controllers first, then other servers such as file servers, application servers in the sequence needed for the applications to run. Crashing of DNS, File Server, Domain Controllers crashing after the datacenter is up and running is handled (or should be) by redundancy of servers or process the service provides.  You have multiple DNS servers and the resolver will try the secondary/tertiary/whatever if the primary is down.  File servers are the same.  For Gluster, CephFS, MS DFS you have (or should have setup) the ability to keep running if one of the servers goes down.  A redundant file server setup will handle a server crash.  For Domain Controllers you should have at least two (we had six in our environment) and when one goes down the others keep the domain running by shifting the services to others and continuing to provide authentication, etc.  Generally what we did when a domain controller crashed is fix it if possible and if it was not fixable pull it's pieces out of the domain and spin up a new one.   Same for DNS or file servers.  When they go down find out why, fix it or replace the server, and get the service redundant again.  Also, oVirt has the watchdog function so if a VM goes down it will try and restart it.  If it can't restart then we're dealing with a crashed server which we should have provided for in our data center design. My wish is to have oVirt allow us to do what VMware does and allow us to say start/don't start these servers up in the order I specify so that when the Engine is ready it looks at the list and begins turning on VMs in the order specified.  Shutdown is done in the reverse order).  For large datacenters with many VMS manual startup is a pain.  Once it's running rely on good practices of having redundant servers (i.e. more than one DNS), file servers that can handle the failure of a server, multiple domain controllers which is not something we need to burden oVirt with.  Handling of failures needs to be done by the people in charge who are supposed to design the data center based on their risk/cost analysis.  If I  understand what you said - I'm not sure we have to define a dependancy list where we define dependancies like we would with systemd or a package manger.  It doesn't need to be complex since just a simple list of priority: VM id/name pairs will work. All we need is to be able to say "start these VMs when the Engine is ready".  The order or dependency is set by where I put the VM in the list.  If it's at the top start it first, then move to the second one, and so on.  There can be settings for delay between starting VMs and how long to wait for a VM to come up before assuming it's dead and moving on to the next.  Tasking oVirt with the job of figuring VM dependancies would be a nightmare for oVirt and whoever had to program it <G>.  We as data center administrators should be handling that task.  Yes, we manually set the list but trying to automate a dependancy chain would be pretty difficult. I envision a web admin portal GUI where we define a simple list of VMs that we want the Engine to autostart. We need to be able to move them up/down the list.  The list is stored somewhere for the Engine (database?, whatever else the Engine has as storage areas - not really familiar with the Engine internals) and when the Engine is up and ready to start VMs it retrieves the list and starts at the first VM in the list and starts it, waits some time (0-?? seconds), and then moves on to the next one.  If the VM hasn't started in the set time the Engine moves on to the next one. Note that Microsoft's Hyper-V also provides automatic VM startup but it is done on a VM level where you just tell the VM to start whenthe Hypr- V starts.  If you want sequencing you have to set time delays.  Auto  start up is better than nothing but Hyper-V is a nightmare trying to sequence VMs. I think VMware did it right in allowing both autostart and being able to sequence the startup of VMS so it's host independent.  As information VMware also allowed delays between VM startups as does Hyper-V. Users(a)ovirt.org&gt; > http://lists.ovirt.org/mailman/listinfo/users Users(a)ovirt.org&gt; > http://lists.ovirt.org/mailman/listinfo/users