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.
