You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@vcl.apache.org by Kelly Patrice Robinson <kr...@gsu.edu> on 2011/07/05 18:12:44 UTC

Re: VCL2.2.1 & Windows 7 slow boot time

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


From: Kelly Robinson <kr...@gsu.edu>>
Date: Tue, 14 Jun 2011 10:32:58 -0400
To: "vcl-user@incubator.apache.org<ma...@incubator.apache.org>" <vc...@incubator.apache.org>>
Subject: Re: VCL2.2.1 & Windows 7 slow boot time


Not sure which of these changes made the most difference, but I removed the floppy disk from the base image (since the cloned image is not configured with one).  I also removed the iso image that was mounted on the cd/dvd drive of the base image and turned off netbios on each interface.  The startup appears to be faster.  I will continue testing and let you know if there are any issues.


Thanks,

Kelly


>>> Andy Kurth <an...@ncsu.edu>> 06/14/11 9:23 AM >>>
I'd try to configure the image to not show the GUI "Starting Windows"
screen so you can see where it is hanging.
-Run msconfig
-Select the Boot tab
-Select "No GUI boot" and "Boot log"

If the delay is happening each time you restart the image you can just
manually reboot at this point.  If not, you'll have to save a revision
with these settings applied.

When the VM boots you should see a list of items being loaded.  The
last one to appear before the delay doesn't really tell you much by
itself but it is useful when you Google the problem.

My guess would be a driver problem.  Have you tried reinstalling VMware tools?

-Andy



On Mon, Jun 13, 2011 at 4:43 PM, Kelly Robinson <is...@langate.gsu.edu>> wrote:
> It remains on the "Starting Windows" screen.  It happens when I perform the
> "Create/Update Image" function and the image is cloned to create the new vm.
>  The Windows (System) log doesn't show anything out of the ordinary,
> although I did notice that there is about a 9min delay from the
> "Kernel-Processor-Power" entry and "Service Control Manager" entry.  Details
> of both entries are listed below:
>
> --------------------------------------------------
>
> Information  6/13/2011 4:13:25 PM Kernel-Processor-Power:
>
> Event Properties -Event 26, Kernel-Processor Power
>
> Processor 0 in group 0 exposes the following:
>
> 1 idle state(s)
>
> 0 performance state(s)
>
> 8 throttle states(s)
>
> ---------------------------------------------------
>
> Information 6/13/2011 4:21:56 EventLog:
>
> Event Properties - Event 6005, EventLog
>
> The Event Log service was started.
>
> ---------------------------------------------------
>
> Any ideas on the issue(s)?
>
> -Kelly
>
>
>>>> Andy Kurth <an...@ncsu.edu>> 06/06/11 10:12 AM >>>
>
> I haven't experienced this.  What is on the console during this time?
> Do you see the "Starting Windows" screen.  Does it happen every time
> you reboot the VM or only the first time it is powered on?  There may
> also be helpful information in the Windows event log.
>
> -Andy
>
> On Fri, May 27, 2011 at 3:25 PM, Kelly Robinson <is...@langate.gsu.edu>>
> wrote:
>> I'm testing a Windows 7 image (on ESXi 4.1) and have experienced extremely
>> slow boot times which causes imaging reservations (or reloading) of the
>> Windows 7 image to fail due to timeouts.  The vm eventually boots, but it
>> takes about 12 minutes for the login screen to appear.  The Windows 7
>> image
>> is configured with 2Gs of memory, 1 CPU and with the LSI Logic Parallel
>> SCSI
>> controller.  Are there other values that need to be tweaked?   I was able
>> to
>> successfully perform imaging reservations for Windows XP, but Window 7 has
>> given us problems.  Has anyone else experienced this issue?
>>
>> Kelly
>>
>> Georgia State University
>

Re: VCL2.2.1 & Windows 7 slow boot time

Posted by Andy Kurth <an...@ncsu.edu>.
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
<kr...@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