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?
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
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
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.
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
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.
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
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.
and no errors occurred during the upgrade?
and no errors occurred during the upgrade?
no errors.
>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
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.
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
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.
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
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.
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