vApp Start delay ordering and delays

[pdp2shirts]

Hello all:

I have a question about the vApp Properties > Running dialog box. Page 56 of the User guide states:

"On the Running tab, determine the order of the boot sequence, boot delay, and shutdown delay.

You must type numbers that are in progression, for example, 0, 25, 1000, to set the sequence. Negative numbers are not allowed."

That is all that is mentioned about the start delay functions. I assume that the progression is from low to high -- i.e. that the VM designated as 0 would start before the VM designated as 25. Is this correct? Does the first VM in the sequence have to be designated 0?

My next question has to do with the start delay text box. Assume I have vm1 set to order 0, and vm2 set to order 1. If I want vm2 to start 60 seconds after vm1, do I enter the start delay in the text box for vm1 or for vm2? Put another way, is the start delay used to determine how long after a particular VM is delayed from starting after it is determined to be next in sequence, or is the delay used to determine how long after the VM starts before the next in sequence is allowed to power on?

Paul D. Pindell VCP4

[admin · Accepted solution]

VCD will start VMs in ascending order and stop then in descending order. For example, if you have three VMs with boot order 0, 1, 2, the first one to start is 0 then 1, then 2. When you stop the vapp, the first one to stop is 2, etc.

The VM start delay is the time in seconds from when the previous VM in the boot order starts. Using the same example as above, if the start delay is 60, 180, 120 for VMs 0, 1, 2, The first 60 is IGNORDED!. The VM with boot order 0 will start immediately regardless of what it's boot delay is. Then, VM with boot order 1 will power on 180 seconds after vm 0 is powered on. The last one will start 120 seconds after that. The main thing is that the time is relative to the previous VM's, not absolute time relative to the start of the vapp.

When stopping a vapp, the stop delay applies after the first VM is stopped. The stop delay on the VM with the highest boot order is ignored. Then, the next highest boot order VM is stopped n seconds after the first one is stopped (where n is the stop delay of the second highest boot order VM).

There is another type of boot delay that can be set in VC which causes the VM to pause at the bios load screen for some number of miliseconds. This setting has nothing to do with how VCD starts VMs. In the VCD setting, the delay is applied without even telling VC to start the VM while the VC delay setting is applied after a VM is powered on and pauses at the bios screen. If you are interested in using the setting in VC, you can find it in the "Boot Options" under the options tab in the VM settings dialog.

I hope this helps. Let me know if you have more questions

--Boris

[admin]

Did this answer your questions?

[pdp2shirts]

Boris

Yes this was very helpful. My only remaining question is whether or not the first vm in the sequence must be designated 0.

Paul D. Pindell VCP4

[admin]

no

[admin]

Paul,

I appoligize, but it looks like my answer is not completely correct. Long story short, the boot delays are applied AFTER the VM is started. So if you have 3 VMs whose boot order is 100, 200, 300 and the delays are 60, 120, 180 respectively, this is what happens.

VM-100 will start right away. There will be a 60 second delay before VM-200 is started

VM-200 is started and there is a 120 second delay before VM-300 is started

VM-300 is started and there is a 180 second delay. The only thing this last delay does is keep the state of the vApp in VCD set to 'busy' and you'll see the busy spinner for 180 seconds. During this last delay, the VMs are connected to networks and are fully functional, but the vapp is "busy".

The same thing happens in the stop delay case. The delay is applied AFTER the VM is powered off and the vApp is kept "busy" for the stop delay on the vm with the lowest boot order number. The vapp is kept in a busy state for the delay associated with the VM with the lowest boot order.

Here's the reasoning for why it's implemented like this and not the way I originally described. First of all, VC boot delays work the same way so this implementation keeps everything consistant. Second reason is this hypothetical situation. Lets say VM-100 is a DB server which takes 2 minute to boot and start all required services. As the admin of the VM, you can set a boot delay on the server to 2 minutes which will keep client VMs from attempting to connect to your DB. Then maybe you install more functionality, updates, etc which slows the process down and the services are not available for 2.5 minutes. Rather than modifying properties of the client VM, you should adjust the boot delay property of your server to 150 seconds.

Again, sorry for the initial incorrect information. I hope this clarifies.

--Boris

[pdp2shirts]

Boris,

Thank you for confirming and replying back.

This is very helpful. Exactly what I was looking for.

Paul D. Pindell VCP4