VMware Communities
timofcourse
Enthusiast
Enthusiast

Set Autostart order of Shared VMs

I need to set the autostart order of my Shared VMs to ensure my Domain Controller starts prior to all other VMs. Is this possible at all?

15 Replies
lakshya32
Enthusiast
Enthusiast

Hi

Welcome to the communities.

Yes ,its is quite possible .< /p>

http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.vmadmin.doc_41/vsp_...

"When you fail to plan, you plan to   fail."
0 Kudos
timofcourse
Enthusiast
Enthusiast

Thats for vSphere. We're talking Workstation here.

0 Kudos
Scorpion99
Enthusiast
Enthusiast

0 Kudos
timofcourse
Enthusiast
Enthusiast

Sorry, Im not seeing anything in the KB that mentions how to accomplish this.

0 Kudos
WoodyZ
Immortal
Immortal

I do not use the Shared VM feature however if I did and I also needed to have two or more start in a specific order and there was nothing in the GUI to configure this then here is what I do...

Using two or three Shared VM that were added in a specific order I then see it what order they booted and if this was consistent.  (I'd use information in the KB 2005585 to delay the start to make it easier to investigate the actual times of each starting.)  If the boot order is consistent then I ascertain where the list of these VM for AutoStart was being saved and then modify the order in that list and see if it too is consistent.  On a Windows Host I'd use a tool like Process Monitor to do my initial snooping.  This information is either being stored in the Windows Registry or a configuration file of sorts, or both on a Windows Host although just in files on a Linux Host.

If the boot order is not consistent then I don't have any other suggestions at this time.

0 Kudos
Bernd_Nowak
Hot Shot
Hot Shot

I checked the kb and the help file and it looks like:

You cannot use the AutoStart feature to configure virtual machines to start in a preferred sequence

This is from the VMware Workstation 9.0.2 help file.

But why do you need the domain controller up @ 1st? Since 2003/2008 ... it should not matter that much because the 'clients' save creditentials so that I can still use my domain account + password to login even if I'm not connected to the AD.

There may be thousand reasons why it's preferable but I solve them by starting the VMs when I want to start them. So no autostart for my trials. If I would need it for productive usage I would use the free esxi 5.1, which is able to do what you want.

Just my 2 cents Smiley Wink

0 Kudos
timofcourse
Enthusiast
Enthusiast

Does anyone happen to know how Workstation determines what the order is? Is it just how they appear in the list, which seems to be alphabetically? I suppose I can test this myself, just wasnt sure if someone knew this offhand.

This DC is part of a software demo environment used by one person - me - which Im constantly making changes too so dont want on our vSphere environment. It also includes a Exchange VM that at times gets very angry if it is started before the DC is online which is why Id like to have the DC VM start first.

Thanks all, appreciate your responses and input.

0 Kudos
Scorpion99
Enthusiast
Enthusiast

Did you read this in the KB?

To setup/configure delay between auto startup of multiple shared virtual machines:
  1. Right-click Shared VMs/Server Name/IP Address.
  2. Select Manage AutoStart VMs.
  3. Select the virtual machines that you want to auto start.
  4. Set the delay that you want for the virtual machine in the Delay between starting each virtual machine (in seconds) option available at the bottom of the window.
  5. Click OK to save the settings.

Don't you think that setting up the Delay between your VMs will help you in the boot order? Make the others VMs start after 3 or 4 min from the DC if you want.

0 Kudos
timofcourse
Enthusiast
Enthusiast

Yes, I read that and also saw the setting even before doing so. The fact is, it in no way answers my question. If I have 4 vm's and I need a specific one to start before all others, the delay does nothing to ensure that.

I guess Ill just need to do a little trial and error and hope there's some logic to what Workstation uses for the order (e.g alphabetically) and hope I can tweak my setup to accommodate what I'm looking for.

I'll be sure to post back my results when I do in case anyone else runs into this.

0 Kudos
Scorpion99
Enthusiast
Enthusiast

As I see , you can rename them as aplhabetic for starting order and you can put the delay as you think it could be needed. In case you find another solution or a way out , please share it with us.

0 Kudos
timofcourse
Enthusiast
Enthusiast

In case anyone else run into this in the future, it does in fact appear as though Workstation Auto-Start starts VMs alphabetically. So I simply preceded the name of each VM with the number of the order I wanted them to start in (e.g. "1. DomainVM", "2. OtherVM", etc.).

Azaria
Contributor
Contributor

@timofcourse - Thanks for following up with your solution.  Certainly saved me the hassle of trying myself Smiley Happy

cheers.

0 Kudos
packgreg
Contributor
Contributor

@timofcourse

This method (alphabetically naming or numbering vm's) does not work.  The documentation says that using the vSphere client will allow you to configure advanced options such as the order of the autostart vm feature, but I don't see where to do that.  I am using Workstation 11 and have four vm's each of which must start in a particular order.  I named the first one 1. first, the second one 2. second, etc. but the second one ALWAYS starts first.   What am I doing wrong?

0 Kudos
Dayworker
Enthusiast
Enthusiast

IMO the vSphere-Client is useless in this case because we are talking about VMware-Workstation.

But all your Shared VMs are listed in the file "vmInventory.xml"... The file "vmAutoStart.xml" contains all settings for the start order. In "vmAutoStart.xml" the entry <moid>1</moid> is the same like <objID>1</objID> in "vmInventory.xml". The AutoStartOrder for all shared VMs is viewable in "vmAutoStart.xml" via the entries "<e id="0">" and so on. Each <e id>-entry means a further VM will be started by the VMware-Workstation and the <e id>-number is changeable. I don't know what happened, if you add a further VM after manually changing the "vmAutoStart.xml". Either the existing order will be kept or the Workstation changes this order.

----- Please do not forget to assign reward points, if you find an answer useful.
packgreg
Contributor
Contributor

Hi Dayworker,

Thanks very much for your response.   It took me a while to understand what you were explaining because I had never worked directly with the XML files before in VMWare Workstation.   My shared directories are supposed to be in c:\vmware\shared and I found the XML files, with the correct dates, in c:\users\All Users\Vmware\hostd.  Once I did I could see that by setting the "set autostart VM's" setting in "Shared VM's" within the Workstation GUI and selecting two of the four guests for automatic startup with the host, the two corresponding "<e id="0">" in vmAutoStart.xml should be set to the correct order as the vm selected and found in the vmInventory.xml's "<objID>1</objID>" assignment.  Unfortunately this did not happen in my case so this is what I did:

- I made an offline copy of the vmAutostart.xml so I could edit it offline.

- By looking in the vmInventory.xml file I could see that the moid assignment for the vm I wanted to start first was 4 and second was 2.

- Editing the vmAutoStart.xml offline with a text editor and changed the objid assignments to be in the order I wanted them in starting with XML parent <e id="0">.

- Making sure the text editor would save as "all files" and not with an extension of "txt" I saved the file again, offline, as vmAutoStart.xml and tested it by double-clicking it to make sure it opened as xml in a browser and that the syntax and order were correct.

- I started Windows Explorer as Aministrator and went back to the c:\users\All Users\Vmware\hostd to save a spare copy of the vmAutoStart.xml file and then copied the new one in.

Everything appears to be starting in the right order now.


Thanks again and regards,


Greg