Am I understanding this correctly... on the NFS datastore with > 1G RAM, the VM boots slow the first time. Subsequent powering on/off through the ESXi console is fast. Is the speed also fast if you issue a reboot command from the Windows 7 OS?
I would first check if ESXi is correcting something in the vmx file when you restart it via the vSphere console. Load the image. Make a copy of the vmx file. Restart it via the vSphere client. Then diff the original and running vmx file. Also look in the vmware.log file that is generated in the vmx directory. Compare it for the same image loaded under conditions where boot time is slow and fast. There may be some clues in this file. Another way to troubleshoot is to view the performance statistics in the vSphere client. Check the latency statistics for the datastores where the vmx and vmdk files reside. Also look at the CPU utilization for the VM. I have seen very high CPU utilization for a VM when it boots if datastore latency is also high. -Andy On Tue, Jul 5, 2011 at 12:12 PM, Kelly Patrice Robinson <krobinso...@gsu.edu> wrote: > Ok, I have another issue with slow boot times. We are testing VCL2.2.1 and > ESXi 4.1. > Observations: > --Provisioning images (on an NFS datastore) is successful if RAM on the > image is < 1G. > --If the RAM on this image is > 1G, the reservation will fail. (Boot time > is > 10 mins). > --Powering off/Powering on this image (from the ESXi console) results in a > much faster boot time (< 1min) > --Provisioning images of > 1G of RAM to the local datastore can be performed > successfully. (note: Nodes have 146GB SAS 15K drives. The SAN connected > through NFS is composed of SATA drives) > I would expect there to be performance differences between the local > datastore and the SAN due to the differences in the types of drives, however > we were able to provision 2G and 3G images successfully using VCL2.1 and > ESXi 3.5. The only notable difference that I'm aware of is that the > provisioning module we used in VCL2.1 made copies of the vmdk file each time > an image was requested and VCL2.2.1 uses the same vmdk file and writes the > deltas for each instance. Would this change cause the images to now fail? > Does any one know of any changes in ESXi 4.1 that could also explain this > occurrence? > Thanks, > Kelly
