You will need to watch the VM console after the VM is turned on in order to troubleshoot this. You should see the following:

-VM is turned on
-Sysprep minisetup runs, VM is rebooted
-When Windows boots up for the first time, the root account is automatically logged on -A few black command boxes appear on the desktop, the one in the back is named post_load.cmd
-When the command boxes close, root is logged off
-At this point, the computer should respond to SSH


You should be able to log on as root via the VMware console. The password should be the one configured as WINDOWS_ROOT_PASSWORD /etc/vcl/vcld.conf. After logging in, view the log files generated by the VCL scripts. All of the output generated by the scripts gets saved into files in C:\cygwin\home\root\VCL\Logs.

The troubleshooting steps depend largely on whether or not you see root being automatically logged on.

If root is not logged on automatically, the problem can probably be found in sysprep_cmdlines.log and the files in Logs\sysprep_cmdlines directory. These files are generated during the Sysprep minisetup stage when Scripts\sysprep_cmdlines.cmd runs. This script configures root's autologon and sets a registry key to cause Scripts\post_load.cmd to run after root is automatically logged on.

If it's attempting to log on root but failing because of a credentials problem, the cause could be that the password was not correctly configured in Scripts\autologon_enable.cmd. Check the "set PASSWORD=" line in this file.

If root is being logged on, first check if the Cygwin SSHD service is running and if the firewall has an exception for TCP port 22. Be sure to check both the middle "Exceptions" tab and the settings for each adapter under the "Advanced" tab for the exception. My guess is that SSHD failed to start. The problem can probably be found in Logs\post_load.log and in the files in the Logs\post_load directory. Check Logs\update_cygwin.cmd for errors.

As you'll see in the log files, there's a lot that has to happen in order for everything to work correctly. The output from the log files will be helpful in order to figure this out.

Regards,
Andy

On 2/17/2010 7:22 PM, Terry McGuire wrote:
Well, I think the base image is officially captured, but I don't seem to be 
able to quite make it work.  I've repeated the capture a few times and always 
end up in a situation where, when I make a reservation for the image, the image 
loads on the VM and various other useful-looking things happen, but ends before 
the reservation is made available to me with this error:

______________________
2010-02-17 17:01:23|16589|3:8|new|vmware.pm:load(848)|vmguest-1 ROUND 1 checks 
loop 19 of 40
2010-02-17 17:01:23|16589|3:8|new|utils.pm:run_ssh_command(6180)|executing SSH 
command on localvmhost:
|16589|3:8|new| /usr/bin/ssh -i /etc/vcl/vcl.key  -l root -p 22 -x localvmhost 
'vmware-cmd /var/lib/vmware/Virtual\ 
Machines/vmwarewinxp-base7-v0vmguest-1/vmwarewinxp-base7-v0vmguest-1.vmx getstate' 
2>&1
2010-02-17 
17:01:24|16589|3:8|new|utils.pm:run_ssh_command(6262)|run_ssh_command output:
|16589|3:8|new| getstate() = on
2010-02-17 17:01:24|16589|3:8|new|utils.pm:run_ssh_command(6276)|SSH command executed on 
localvmhost, returning (0, "getstate() = on")
2010-02-17 17:01:24|16589|3:8|new|vmware.pm:load(852)|rechecking state of vm 
vmguest-1 /var/lib/vmware/Virtual\ 
Machines/vmwarewinxp-base7-v0vmguest-1/vmwarewinxp-base7-v0vmguest-1.vmx
2010-02-17 17:01:24|16589|3:8|new|vmware.pm:load(857)|vm vmguest-1 reports on
2010-02-17 17:01:24|16589|3:8|new|vmware.pm:load(868)|sshd is NOT active on 
vmguest-1 yet
____________________

It tries for a long time to ssh into the machine, but doesn't succeed.  I see in the 
vmware server console that the vm is up and running, but it can't be sshed into.  When I 
try it from the management node's command line, I get "connection refused".  
Obviously, it *was* working, so I guess something went screwy in the capture process, 
yes?  But, well, I haven't been able to figure out what.  Thus, yet another message out 
to you.

Ideas?

Terry

On 10 Feb 2010, at 0940h, Andy Kurth wrote:

It looks like the image capture was successful and the vmware.pm module had 
trouble changing the file names to the new image name.  I don't think it was 
the result of renaming the VM directory.  You had the right idea by changing it 
to match the reservation ID.  I think the problem has to do with the original 
names of the .vmdk files which were named after the manually created VM.  What 
are the contents of /install/vmware_images/vmwarewinxp-base7-v0/?

At this point I would manually fix the captured VM files.  The .vmdk files 
should be named vmwarewinxp-base7-v0-s00x.vmdk.  Rename all of the .vmdk files 
in the /install/vmware_images/vmwarewinxp-base7-v0/ directory to match this 
format.  Change the first part of the names but keep the 's00x.vmdk' as they 
are named now.

There should be one .vmdk file without the 's00x' part.  This should now be named 
vmwarewinxp-base7-v0.vmdk.  This file needs to be edited because it contains the names of 
the other .vmdk files.  You should see an "Extent description" section in the 
file with the original names.  Change each lines to include 
'vmwarewinxp-base7-v0-x00x.vmdk' instead of the old name.

Next, make sure the VCL 'deleted' column in the image and imagerevision tables 
for this image is set to 0.  In the image table, check id=7.  You'll have to 
look at the imagerevision table to figure out which one is for this revision. 
The imagerevision.imagename value will be vmwarewinxp-base7-v0.

Next, make sure there isn't a directory named '/var/lib/vmware/Virtual 
Machines/vmwarewinxp-base7-v0'.  There shouldn't be one but check to make sure. 
 If it exists, rename it for now.

Next, cross your fingers and try to make a reservation for this image.  If you 
created and configured multiple VMs in VCL then another one should already be 
in the available state and you should be able to make a reservation.  If not, 
change the state of your VM to 'available' via Manage Computers.

If you have trouble, the following will be useful:
$ ls -l /install/vmware_images
$ ls -l /install/vmware_images/vmwarewinxp-base7-v0
$ ls -l /var/lib/vmware/Virtual\ Machines/
$ cat /install/vmware_images/vmwarewinxp-base7-v0/vmwarewinxp-base7-v0.vmdk

I'm thinking there's a problem with the instructions that caused this latest 
problem.  I'll go through them.  Stating the obvious, but we obviously need a 
much better way to create base image reservations.

Reply via email to