Floating desktop pool and DHCP releases

[oreoo]

Hey there!

We are getting ready to deploy desktops on a larger scale soon,

(1000 vm's)

we are setting up view to delete desktops at logoff and recreate when needed.

this all works fine except windows XP wont clean up its IP lease leaving us with a deminishing amount of IP adresses available

we shortened the lease to 4 hours however if we calculate a concurrent use of 600 machines we will be running out of IP adresses because of the lease time not expiring before we run out of pool adresses

we found the following behaviour:

Windows XP dous not release its ip adress before shutdown,

User logs off

VM is forcefully shut down by view composer( no guest OS shutdown)

desktop gets deleted

desktop gets recreated when needed

we tried implementing a shutdown script by means of GPO however this is not being run since the view composer shuts down the VM without letting the guest OS handle its shutdown process including the script

We also tried a logoff script again by means of GPO however our users are not local administrators and dont have the rights to do a ipconfig /release

Our next step is to look at shut-down scripts from the vmware view administrator pool settings,

however we cant seem to get the script to run the way we are expecting it to run

its a simple cmd file situated at the c:\ of the parent image that will :

ipconfig /release

ping -w 50000 -n 1.1.1.1

The ping is to ensure that the script has time to finish before resuming shutdown

we configured it at our floating desktop pool quickprep > shutdown scripts (see screenshot)

however at shutdowns/recreation of the vm we dont see our IP getting released at the side of the DHCP server

we found in the logfile of one of our shutdown guests:

Running the Presync script: c:\shutdown.cmd with timeout: 20000

it seems to run however no further acknowledgement within the logging that the script has been run succesfully

ontop of that we are not sure if the script runs at all when view composer shuts down the VM forcefully instead of using the guest os shutdown

Did anyone run into the same problem we are and are there options that we are overlooking?

[mittim12]

So the power off script compeltes before the 20 second timout?

View Composer terminates a post-synchronization or power-off script that takes longer than 20 seconds. If your script takes longer than 20 seconds, you can increase the timeout limit. For details, see Increase the Timeout Limit of QuickPrep Customization Scripts.

[oreoo]

Hey Mittim,

the script should only run for a max of 10 ish seconds 5 normally

Is the way i configured the variables correct?

is there someone who has experience with power-off scripts?

[mittim12]

This link should show you how to extend the time outs for the scripts.

http://pubs.vmware.com/view-50/index.jsp?topic=/com.vmware.view.administration.doc/GUID-5EBD194C-EDC...

[Jrock79]

Not sure if it matters in your situation, but the line:

ping -w 50000 -n 1.1.1.1

is missing a value after -n.  In other words, it will try to pass 1.1.1.1 to -n which will cause an error because no IP address is provided.

[Camek]

Even if you could allocate more IP why don't you use the "Refresh" option on logoff instead of delete? The refresh uses VMWare snapshot feature and so you still get a clean fresh desktop and because you are just "reverting" the desktop back to an early state you will get the exact same IP back from DHCP because the "hardware" should look the same.... Plus a Refresh is very, very fast which will reduce IOPS in building new desktops and will save you hardware and makes your configuration much cleaner and hence more reliable....

We don't do this on logon but each night we use a View Powercli script with refreshes all our floating desktop pools.   

[oreoo]

Thank you Camek that makes alot of sense!

refresh instead of delete makes sense

However how will this affect the automatic scaling of the pool?

for instance we start out with 20 desktops and want the cluster to scale on demand to a max of 1000 vm's

using refresh at logoff will affect the setup?

[blakebevard]

That was the problem that I have run into with refresh vs delete.  It will not scale back the pool size automatically if you do it that way.  You said that it will scale to 1000 VM's.  Does that mean that you will usually have close to 1000 running, but there will be times that you have less (off-peak hours) or do you expect this to fluctuate from day to day?

Also, shouldn't your ping command look more like this? Ping 1.1.1.1 -n 1 -w  20000 (for 20 seconds)

[oreoo]

Hi Blakebevard,

we expect it to fluctuate and that is fine the cluster is designed to handle the increasing load

in the morning will be alot less then at peak times.

our ultimate goal is to shutdown servers from the cluster when not in use and power up when required.

if we use the refresh method (we will still have trouble recomposing because of the DHCP pool deminishing)

we will be running 1000 vm's and it will not scale down

My colleague told me that view 5.1 properly shuts down guest OS instead of forcefully shutting VM's down the way 4.6 is

so shutdown scripts become viable

anyone can confirm this?

our current platform is 4.6 but for our new cluster we are looking at 5.1

if this is the case a simple shutdown script should be sufficient instead of the workarounds we are thinking of now

[Camek]

In our experince using the refresh is a much better option because you avoid all the thrashing of rebuilding, and then provisioning desktop which takes a lot of CPU and IOPS on all your system (DHCP, DNS, AD, etc.). We have a great array with VNX 5500 with SSD drives but I have found I would much rather make sure the desktops needed for the day are running which provides a must more stable and manageable desktop pool.  If you feel you still need to shutdown things during the day run a View PowerCLI script and delete some desktops out of the pool, then set your DHCP lease to be say 5 min and any if you are still running out of DHCP leases then tune how many desktop you are taking offline because you need to leave more running using the refresh so they don't ask for new DHCP address.  Each situation is different but for me this method works the best and take the least amount of resources.