VMware Cloud Community
ejward
Expert
Expert
Jump to solution

Automatic VM startup when host reboots not working.

I've configured all my VM's (Well, most of them anyway) to automatically start up when the ESX host is rebooted. I look back now and all VMs are now set to manual startup. I've configured this several times in the past year and I don't know what keeps setiing it back. I usually find out when I have to reboot a host. Does anybody else have this issue?

Reply
0 Kudos
1 Solution

Accepted Solutions
PerryWhittle
Enthusiast
Enthusiast
Jump to solution

the settings dont stick when a VM moves hosts, as you pointed out how can they. You have to edit the config on the new host and configure the VM startup within the new collection of objects it joins.

the data issues you encountered were undoubtedly because you missed the upgrade path to v1.2 before going to v2.0

regards

Pez

##################################################

please remember to award points if you find this useful/correct Smiley Wink

Please rememeber to award points if you found this helpful or correct

View solution in original post

Reply
0 Kudos
16 Replies
PerryWhittle
Enthusiast
Enthusiast
Jump to solution

Hi

what version of vcentre/ESX server are you using?

VM's can be set to auto start in a given order, auto any order or manual or combination of all 3. What time delay settings have you configured?

Pez

Please rememeber to award points if you found this helpful or correct
ejward
Expert
Expert
Jump to solution

VC v2.1

ESX v3.02

I understand that the settings can be set. My issue is that I set them and they don't stick. My startup delay was set to 60 seconds. This is just a guess because it reverted back to not starting up automatically. I could understand if I forgot to click "OK" after I set it but, to forget to click OK on 10 ESX servers, i don't think so.

Reply
0 Kudos
jparnell
Hot Shot
Hot Shot
Jump to solution

Do you mean VC 2.0.1? If so, ESX 3.0.2 is only compatible with VC 2.0.2 so I would suggest you upgrade VC and then try again.

Reply
0 Kudos
PerryWhittle
Enthusiast
Enthusiast
Jump to solution

Hi

that's why i asked your ESX and VC version, yes for esx 3.0.2 you should be using virtual centre 2.0.2

VC 2.0.2 is backward compatible for previous ESX versions but not the other way round

upgrade vc then try applying the settings again

########################################

please award points if you find this useful/correct Smiley Wink

Please rememeber to award points if you found this helpful or correct
Reply
0 Kudos
ejward
Expert
Expert
Jump to solution

Yes, we are using VC v2.02. We've got the latestest and greatest of everything. We've also applied all current ESX and VC patches.

Reply
0 Kudos
PerryWhittle
Enthusiast
Enthusiast
Jump to solution

Hi

did you upgrade to Vc 2.0.2 or new install VC 2.0.2?

what database platform are you using? (SQL,Oracle,etc)

Regards

Pez

Please rememeber to award points if you found this helpful or correct
ejward
Expert
Expert
Jump to solution

It was an upgrade to 2.02 with SQL. It was done almost the day it was released. Actually our VC server was 1.0 upgraded to 2.0, upgraded to 2.01, upgraded to 2.02. Maybe that's the answer. When 2.5 comes out, I think I'll start fresh.

Reply
0 Kudos
PerryWhittle
Enthusiast
Enthusiast
Jump to solution

and no errors occurred during the upgrade?

Please rememeber to award points if you found this helpful or correct
Reply
0 Kudos
ejward
Expert
Expert
Jump to solution

and no errors occurred during the upgrade?

no errors.

Reply
0 Kudos
PerryWhittle
Enthusiast
Enthusiast
Jump to solution

>Actually our VC server was 1.0 upgraded to 2.0, upgraded to 2.01, upgraded to 2.02. Maybe that's the answer.

The upgrade path from v1.0 has to go to v1.2 first then to v2.0 onwards. Build a temporary VM and use it to upgrade a copy of the v1.0 db to v1.2, then go to v2.0 and on up to v2.02.

othwerwise just install a fresh VC database and you should be fine from there

#######################################

please award points if you find this useful/correct

Please rememeber to award points if you found this helpful or correct
Reply
0 Kudos
ejward
Expert
Expert
Jump to solution

Before I take such a radical approach as wiping out VC or the database, are we really sure it's a VC issue? Because I get the same issue connecting directly to the ESX host. To me, it sounds like those settings are stored on the ESX host rather than in Virtual Center.

Reply
0 Kudos
PerryWhittle
Enthusiast
Enthusiast
Jump to solution

that sounds slightly strange, one thing i do know is the upgrade path you took for VC was not supported. If moving from v1.0 you must go through v1.2 first before going to v2.0

what was the upgrade path you took with the ESX servers? (i.e. from what version to what version)

i'm not saying wipeout the db i'm saying re run through the upgrades against a backup of the v1.0 db going through the appropriate upgrade paths (you could use a VM for this and destroy it when finished) then integrate in place of the db you have at the moment

Regards

Pez

##################################'#################

please remember to award points if you found this useful/correct Smiley Wink

Please rememeber to award points if you found this helpful or correct
Reply
0 Kudos
ejward
Expert
Expert
Jump to solution

i apologize, I'm not sure of the specific upgrade path with Virtual Center. It was a long time ago. Now that I think of it, there was a historical data issues when upgrading from one version to another so, we wiped it out and started over. As far as ESX goes, the specific server I'm referring to is our newest server and has had 3.02 from the beginning. It's only been in production for a few weeks. When DRS does it's magic, could settings be lost then? Maybe the settings don't follow the VM from host to host? Thinking about it now, how could it? If ESX 1 says start up VM A, then B, then C and ESX 2 says start VM 1, 2, then 3 and DRS takes over, ESX1 may end up with VMs A, 1, and B ...... who gets started first? We did have a lot of DRS activity a while ago when I accidentally did a P2V of a quad box with 16GB of RAM. Good way to test DRS. Anyway, just thinking out loud at this point. I checked the servers today and it looks like the settings have stuck for now.

Reply
0 Kudos
PerryWhittle
Enthusiast
Enthusiast
Jump to solution

the settings dont stick when a VM moves hosts, as you pointed out how can they. You have to edit the config on the new host and configure the VM startup within the new collection of objects it joins.

the data issues you encountered were undoubtedly because you missed the upgrade path to v1.2 before going to v2.0

regards

Pez

##################################################

please remember to award points if you find this useful/correct Smiley Wink

Please rememeber to award points if you found this helpful or correct
Reply
0 Kudos
ejward
Expert
Expert
Jump to solution

the settings dont stick when a VM moves hosts, as you pointed out how can they. You have to edit the config on the new host and configure the VM startup within the new collection of objects it joins.

WOW!! That's a HUGE issue. Especially with DRS moving things around all the time. What's the point of even having a startup squence if DRS is going to be turned on? There should be some sort of global list of VM's in VC where this is set then, that list is replicated to each host in and cluster. This way, the host will know what to do on a reboot regardless of what VMs it holds at the time. The good news is ... I'm not going nuts. Not over this anyway. Thanks.

Reply
0 Kudos
PerryWhittle
Enthusiast
Enthusiast
Jump to solution

WOW!! That's a HUGE issue. Especially with DRS moving things around all the time. What's the point of even having a startup squence if DRS is going to be turned on? There should be some sort of global list of VM's in VC where this is set then, that list is replicated to each host in and cluster. This way, the host will know what to do on a reboot regardless of what VMs it holds at the time. The good news is ... I'm not going nuts. Not over this anyway. Thanks.

well no not really. HA and DRS handle that for you, if you power off a host all its VM's will be powered on, onto another host. The VM should never power off unless you tell it to

I think you'll find the auto stratup options are for VM's on hosts that are not cluster and so HA/DRS controlled.

Regards

Pez

Please rememeber to award points if you found this helpful or correct
Reply
0 Kudos