I expect one particular type of “problem” quite a bit when people start putting Dynamic Memory (a new feature in W2008 R2 SP1) into production: some people will deploy a new virtual machine with a small amount of start up memory (which is supported) and then they will try to install software in the virtual machine. This software will have much greater requirements and it will fail the hardware checks, thus preventing the install. Take this specification for example:
Windows Server 2008 R2 VM ABC:
- Startup Memory: 512 MB
- Maximum Memory: 4096 MB
- Hard Disk: 100 GB
You might try to install application XYZ into VM ABC. Application XYZ has the following requirements:
- Minimum Memory: 2048 MB
- Minimum Disk: 10 GB
OK, so the VM expands up to 4096 GB and there’s loads of free disk space. All is well, right? Maybe not!
When that VM powers up with just the OS installed, it might only use 512 MB of RAM. If the buffer is set low then it might only have 615 MB of allocated RAM. You need to remember that a VM with dynamic memory will only be allocated whatever memory it is using + a buffer ammount. The setup.exe for application XYZ will check for the 1024 MB requirement and see that only 615 MB is present. That’s a fail, even if the VM can expand up to 4096 MB.
There’s a couple of ways to get around this.
The VM’s operating system will always believe that it has the amount of RAM that was the dynamic memory high water mark. In other words, if the VM expanded up to 3000 MB and balloons back down to 615 MB then the VM’s OS thinks that it still has 3000 MB. The unused 2385 is acutally returned to the host thanks to the Dynamic Memory balloon. This high water mark resets with the restart of a VM.
You can cause the VM to reach a high water mark that exceeds the memory requirements of the application that you want to install. It is a bit crude but it will work. I picked up a handy trick from one of the Hyper-V product group members for my Dynamic Memory testing/demonstrations. I use MS Paint, and expand the canvas size to the maximum number of pixels. That EATS up memory and drives up the highwater mark. Close MS Paint and the memory is returned to the host, as will be seen in the Hyper-V Manager. Check Task Manager in the VM’s OS and it’ll think it still has the high water mark amount of RAM. Now you can install your software.
I’m waiting for some enterprising developer to create a tool to query for an amount of RAM, which will then consume that memory with little CPU utilisation. All of the performance testing tools that I have tried will hammer the CPU which is not useful in these circumstances.
Temporarily Disable Dynamic Memory
With this approach, you will configure the VM to have the required amount of static memory for a short amount of time. Shut down the VM. Change the memory from dynamic to static. Power up the VM and install the software. Now you can shut it down again, reconfigure Dynamic Memory, and power up the VM once more.
What if the software always checks for memory availablity before starting? There is a chance that the developers put this check in place. If so, you need to know what the requiremed memory is, and reconfigure the VM’s Dynamic Memory settings to ensure that the Startup Memory setting at least matches that amount. For example, application XYZ requires 1024 MB RAM. We can reconfigure VM ABC with 1024 MB startup memory. Now the machine will boot up with 1 GB of RAM and the startup checks that are performed by XYZ will be passed.
The usual advice for startup memory that is floating about is that you “should set startup memory to match the minimum memory requirements of the VM’s OS”. This example is one of the reasons why I don’t like that advice and I go with “should be set for the normal amount of memory required by the VM’s OS and the server applications installed”. I know that sounds a bit more wooly, and it detracts from the RAM right-sizing benefit fo Dynamic Memory a wee bit – but not so much if you use the minimum requirements of the app rather than the reccomended, etc.