Have you disabled User Account Control? Where specifically are the errors occurring?

-Andy

On 2/10/2011 2:36 PM, James Patrick Sigmon wrote:
Thanks Andy.

I'm almost complete with the new Windows 7 image, but Cygwin is not 
cooperating.  I keep getting permission denied errors.  The folders have no 
restrictions and I am the root account with administrator access.  I've tried a 
few work arounds to now avail.  Have you seen this behavior before?






-Patrick

On Feb 9, 2011, at 4:09 PM, Andy Kurth wrote:

I took a closer look at the files you sent.  The base image vmx is using scsi0.virtualDev = 
"lsisas1068".  The vmguest vmx is using scsi0.virtualDev = "LsiLogic".  Setting 
the vmguest vmx file to lsisas1068 should allow the guest to boot.

The VMware SDK and vim-cmd utility return "LsiLogic" even though a virtual hard drive was created 
using the "lsisas1068" controller type. If you look inside the first vmdk file, it probably also 
contains ddb.adapterType = "LsiLogic".  As a result, it's impossible for VCL to know if an image 
was created using LsiLogic or lsisas1068.  LsiLogic is used because that's what VMware reported the disk to 
be using.

I'd like to eventually improve the hardware compatibility by saving the data 
from the original vmx file when an image is captured and using it to generate 
new vmx files when reservations are made.

For now, avoid lsisas1068.  I don't know if the virtual disk can be converted.  I think it will be 
easiest to recreate the base image.  Be sure to expand the "Product Compatibility" option 
under "Guest Operating System" and choose Virtual Hardware version 4.  I believe this 
should cause it to use LsiLogic.  Check the virtualDev value in the vmx file before installing the 
OS.  ESXi allows you to specify which adapter to use but I don't think Server 2.0 has this option.

-Andy



On 2/9/2011 12:18 PM, James Patrick Sigmon wrote:
It still has the same problem with "winvista-64" in the vmx file.  To clarify, 
the original image boots up fine, but the copy VCL makes for a reservation doesn't.

Thanks,

Patrick

On Feb 9, 2011, at 10:53 AM, Andy Kurth wrote:

It looks like VMware Server 2.0 doesn't recognize the Windows 7 guestOS values.  Try 
changing it to "winvista-64" and see if this allows the VM to boot.  If this 
works, I can add an exception in the code to use the winvista guestOS values for Windows 
7 under VMware Server 2.0.

-Andy

On 2/9/2011 3:08 AM, James Patrick Sigmon wrote:
Hey Andy,

Sorry I for not responding earlier; I had to put this issue on the back burner 
for a bit for other things.

Attached is the output for the vcld.log.  Also, the error is currently captured 
in the attached screenshot.  The vmguests for this image still fail to start.

Here is the basic output from VMware:

[root@server15 Virtual Machines]# vmware-vim-cmd vmsvc/getallvms
Vmid                  Name                                                File  
                                  Guest OS       Version   Annotation
208    vmwarewin7-base-v1                    [local] 
vmwarewin7-base-v1/vmwarewin7-base-v1.vmx                 otherGuest        
vmx-07
384    vmguest-3:vmwarewin7-base-v1          [local] 
vmguest-3_8-v0/vmguest-3_8-v0.vmx                         otherGuest        
vmx-07

The guestOS value is "windows7-64."  I've also, attached copies of the vmx 
files for the base image and the vmguest.

Thanks,

Patrick






On Jan 28, 2011, at 2:23 PM, Andy Kurth wrote:

What is the guestOS value in the .vmx file?  Also, it would be helpful to 
include the vcld.log output.

-Andy

On 1/26/2011 3:14 PM, James Patrick Sigmon wrote:
Hey guys,

With the Internet issue resolved, I was able to return to my Windows 7 image 
and complete the Cygwin install.  I proceeded to complete all the necessary 
steps thereafter.

When I make a reservation for the image, it gets to where it boots the image then windows 
fails to load - "Windows failed to start.  A recent hardware or software change 
might be the cause" (see attached screenshot).

I checked the vmware server manager and the only difference I can see is that 
the vmguest is being assigned the Guest OS: Other (32-bit).  As my image is a 
64-bit, I believe this to be a hint at the problem.  I double checked the 
database and the architecture is set to x86_64.  So I'm at a lose as to what's 
going on here.

Any ideas?

Thanks,

Patrick Sigmon




Reply via email to