RE: Reservation Error:
Hi All, Looking closely it looks like there is an issue when, the esx.pm picks all the parameters to initiate a poweroff command on the VMguest using the VMware Perl toolkit API Please advise ...if my understanding below is right or wrong? 2010-03-22 16:51:09|15553|2:2|image|esx.pm:capture(646)|found previous name= 2010-03-22 16:51:09|15553|2:2|image|esx.pm:capture(648)|SSHing to node to configure currentimage.txt 2010-03-22 16:51:09|15553|2:2|image|utils.pm:run_ssh_command(6180)|executing SSH command on resxi000: |15553|2:2|image| /usr/bin/ssh -i /etc/vcl/vcl.key -l root -p 22 -x resxi000 'echo esx3-basewinxp-v0 /root/currentimage.txt' 21 2010-03-22 16:51:10|15553|2:2|image|utils.pm:run_ssh_command(6262)|run_ssh_command output: |15553|2:2|image| bash: /root/currentimage.txt: No such file or directory 2010-03-22 16:51:10|15553|2:2|image|utils.pm:run_ssh_command(6272)|SSH command executed on resxi000, command: |15553|2:2|image| /usr/bin/ssh -i /etc/vcl/vcl.key -l root -p 22 -x resxi000 'echo esx3-basewinxp-v0 /root/currentimage.txt' 21 |15553|2:2|image| returning (1, bash: /root/currentimage.txt: ...) 2010-03-22 16:51:10|15553|2:2|image|esx.pm:capture(658)|Power off command: /usr/lib/vmware-vcli/apps/vm/vmcontrol.pl --server '128' --vmname resxi000 --operation poweroff --username 0 --password 'xxx' # 1. Here the server info seems to be wrong. 2. --vmname should actually be esx3-basewinxp-v0 and not the VMguest name; 3. NOT sure if the username 0 is associated with root ??? if yes then that seems right. When I corrected the above info and executed on command line it powered off the VMguest. I am still looking into where the above incorrect info is pulled from so that I can correct it. Any idea ?? Any database tables ?? I am also curious to know if we are supposed to name our Vmguest based on the vmnames? Just for imaging purpose? Thank you, Amit
Re: Reservation Error:
I believe when you are creating a base image, the vmguest name should be the same as the name of the image you are creating it should be in a format like vmwarewinxp-base7-v1. Note that the vm you are imaging should have this name as well as the vmdk file. Your other problem with the hostname is that you need to use the hostname of the esxi server in the hostname column of the computer table entry you have for your esxi server (rather than the IP address). Because VCL just uses the hostname and not the fully qualified name, make sure you have an entry for the hostname in your /etc/hosts file on the management node. On Tue, Mar 23, 2010 at 11:01 AM, Kumar, Amit H. ahku...@odu.edu wrote: Hi All, Looking closely it looks like there is an issue when, the esx.pm picks all the parameters to initiate a poweroff command on the VMguest using the VMware Perl toolkit API Please advise ...if my understanding below is right or wrong? 2010-03-22 16:51:09|15553|2:2|image|esx.pm:capture(646)|found previous name= 2010-03-22 16:51:09|15553|2:2|image|esx.pm:capture(648)|SSHing to node to configure currentimage.txt 2010-03-22 16:51:09|15553|2:2|image|utils.pm:run_ssh_command(6180)|executing SSH command on resxi000: |15553|2:2|image| /usr/bin/ssh -i /etc/vcl/vcl.key -l root -p 22 -x resxi000 'echo esx3-basewinxp-v0 /root/currentimage.txt' 21 2010-03-22 16:51:10|15553|2:2|image|utils.pm:run_ssh_command(6262)|run_ssh_command output: |15553|2:2|image| bash: /root/currentimage.txt: No such file or directory 2010-03-22 16:51:10|15553|2:2|image|utils.pm:run_ssh_command(6272)|SSH command executed on resxi000, command: |15553|2:2|image| /usr/bin/ssh -i /etc/vcl/vcl.key -l root -p 22 -x resxi000 'echo esx3-basewinxp-v0 /root/currentimage.txt' 21 |15553|2:2|image| returning (1, bash: /root/currentimage.txt: ...) 2010-03-22 16:51:10|15553|2:2|image|esx.pm:capture(658)|Power off command: /usr/lib/vmware-vcli/apps/vm/vmcontrol.pl --server '128' --vmname resxi000 --operation poweroff --username 0 --password 'xxx' # 1. Here the server info seems to be wrong. 2. --vmname should actually be esx3-basewinxp-v0 and not the VMguest name; 3. NOT sure if the username 0 is associated with root ??? if yes then that seems right. When I corrected the above info and executed on command line it powered off the VMguest. I am still looking into where the above incorrect info is pulled from so that I can correct it. Any idea ?? Any database tables ?? I am also curious to know if we are supposed to name our Vmguest based on the vmnames? Just for imaging purpose? Thank you, Amit
RE: Reservation Error:
Hi Ryan, Thank you for your quick response. I just realized the part with giving hostname rather than just the IP for VMhost by looking at the regular expression parsing for hostname. I didn't know that we need to have the same name for Vmguest and the base image. Now that you mentioned it makes sense why the code is looking for vmguest name. I will give this a try. Thank you!!! Amit -Original Message- From: Ryan Johnson [mailto:rjoh...@gwmail.gwu.edu] Sent: Tuesday, March 23, 2010 12:50 PM To: vcl-dev@incubator.apache.org Subject: Re: Reservation Error: I believe when you are creating a base image, the vmguest name should be the same as the name of the image you are creating it should be in a format like vmwarewinxp-base7-v1. Note that the vm you are imaging should have this name as well as the vmdk file. Your other problem with the hostname is that you need to use the hostname of the esxi server in the hostname column of the computer table entry you have for your esxi server (rather than the IP address). Because VCL just uses the hostname and not the fully qualified name, make sure you have an entry for the hostname in your /etc/hosts file on the management node. On Tue, Mar 23, 2010 at 11:01 AM, Kumar, Amit H. ahku...@odu.edu wrote: Hi All, Looking closely it looks like there is an issue when, the esx.pm picks all the parameters to initiate a poweroff command on the VMguest using the VMware Perl toolkit API Please advise ...if my understanding below is right or wrong? 2010-03-22 16:51:09|15553|2:2|image|esx.pm:capture(646)|found previous name= 2010-03-22 16:51:09|15553|2:2|image|esx.pm:capture(648)|SSHing to node to configure currentimage.txt 2010-03-22 16:51:09|15553|2:2|image|utils.pm:run_ssh_command(6180)|executing SSH command on resxi000: |15553|2:2|image| /usr/bin/ssh -i /etc/vcl/vcl.key -l root -p 22 -x resxi000 'echo esx3-basewinxp-v0 /root/currentimage.txt' 21 2010-03-22 16:51:10|15553|2:2|image|utils.pm:run_ssh_command(6262)|run_ssh_command output: |15553|2:2|image| bash: /root/currentimage.txt: No such file or directory 2010-03-22 16:51:10|15553|2:2|image|utils.pm:run_ssh_command(6272)|SSH command executed on resxi000, command: |15553|2:2|image| /usr/bin/ssh -i /etc/vcl/vcl.key -l root -p 22 -x resxi000 'echo esx3-basewinxp-v0 /root/currentimage.txt' 21 |15553|2:2|image| returning (1, bash: /root/currentimage.txt: ...) 2010-03-22 16:51:10|15553|2:2|image|esx.pm:capture(658)|Power off command: /usr/lib/vmware-vcli/apps/vm/vmcontrol.pl --server '128' --vmname resxi000 --operation poweroff --username 0 --password 'xxx' # 1. Here the server info seems to be wrong. 2. --vmname should actually be esx3-basewinxp-v0 and not the VMguest name; 3. NOT sure if the username 0 is associated with root ??? if yes then that seems right. When I corrected the above info and executed on command line it powered off the VMguest. I am still looking into where the above incorrect info is pulled from so that I can correct it. Any idea ?? Any database tables ?? I am also curious to know if we are supposed to name our Vmguest based on the vmnames? Just for imaging purpose? Thank you, Amit
Re: Base image capture failure
On 18 Mar 2010, at 0742h, Andy Kurth wrote: Hi Terry, Sorry for the delay. This information is helpful. You're right, the root cause seems to be that sysprep_cmdlines.cmd isn't running. I have seen the issue where you can't enter a password before. This only seems to happen for the newer style logon screen, not the classic logon screen. I'm not sure of the cause but you can get to the classic logon screen by pressing Ctrl-Alt-Del twice. Under the VMware console, press Ctrl-Alt-Insert twice. Weirdly, sometimes I need the classic logon, sometimes I don't. Whatever. I use it when I need to. You can begin troubleshooting by examining C:\Windows\setuplog.txt file. There should be a few lines that look like the section I have copied to the end of this message. Search setuplog.txt for sysprep_cmdlines.cmd. Does anything show up? Yes, just like in your example, except it returns an exit code of 1. That's bad, right? Except, skipping ahead a bit, all is well when I apply the sysprep_cmdlines.cmd fix I figured out, exit code 0. Keep reading. Next, examine the Sysprep files. A copy of the same exact Sysprep files used when the image loaded should still be on the computer in C:\cygwin\home\root\VCL\Utilities\Sysprep. This directory is copied to C:\Sysprep before an image is captured. Sysprep automatically deletes C:\Sysprep when it finishes, so the VCL code copies everything to C:\cygwin\... and then makes an additional copy in C:\Sysprep so that the files are retained for troubleshooting. Ah, that explains the InstallFilesPath=C:\sysprep\i386 bit. The InstallFilesPath=C:\sysprep\i386 line is correct. Within the Sysprep directory, there should also be the following file: C:\cygwin\home\root\VCL\Utilities\Sysprep\i386\$oem$\cmdlines.txt This InstallFilesPath line in sysprep.inf causes cmdlines.txt to be processed during minisetup. Sysprep automatically calls the commands in cmdlines.txt before the computer boots Windows for the first time. You should see a call to sysprep_cmdlines.cmd in cmdlines.txt. So, make sure of the following: -cmdlines.txt resides in the location noted above -cmdlines.txt includes a line calling sysprep_cmdlines.cmd This all looks good. You can troubleshoot this by manually running Sysprep. But first, load your image by making an imaging reservation (Manage Images - Create/Update image) rather than a normal reservation. The reason for this is because VCL configures the VM to run in persistent mode for imaging reservations and nonpersistent mode for normal reservations. If the VM is running in nonpersistent mode and you reboot the machine, it will likely restart in the initial hard drive state saved in the .vmdk files rather than the state the VM before it was rebooted. If running in persistent mode, the VM's hard drive state is saved when it is rebooted. Manually run Sysprep: -Log in as root -Copy the entire Sysprep directory under C:\cygwin to C:\ -Copy the entire C:\cygwin\home\root\VCL\Drivers directory to C:\Sysprep -Delete C:\cygwin\home\root\VCL\Logs to replicate the original state -Run the command: C:\Sysprep\sysprep.exe /quiet /reseal /mini /reboot You should see the computer reboot into the minisetup phase. Towards the end of this phase, you should see some black command boxes appear then close. This is when sysprep_cmdlines.cmd is being run. It should then reboot again and automatically log on as root. Same results - autologin doesn't happen. If you don't see the black boxes during minisetup and it doesn't autologon, try manually running the command contained within cmdlines.txt after Sysprep is done: -Log in as root -Delete C:\cygwin\home\root\VCL\Logs -Open cmd.exe -Run this command (1 line): cmd.exe /c C:\Cygwin\home\root\VCL\Scripts\sysprep_cmdlines.cmd C:\Cygwin\home\root\VCL\Logs\sysprep_cmdlines.log 21 Logging in manually after running sysprep manually, I still don't have the log folder. Running sysprep_cmdlines manually, entered exactly as you have it here, I get The system cannot find the path specified. Hmm. If I manually create a Logs dir, then rerun the command, stuff happens. Looking at the resulting sysprep_cmdlines.log file, it exits with a status of 0. Ok, I then restart. More promising looking things happen. Autologin, many black boxes, then autologout. I did examine the permissions for root, and all looked good. I even applied the chmod as you suggested, but the problem persisted. I've now tweaked the image to have the Logs folder pre-created, and things seem to work fine. Autologin, many black boxes, and, when I make a reservation, it makes it all the way to Connect! without manual intervention. However, unfortunately, I still can't login with RDC. Manually logging back in again via the console, and looking at the post_load log, I see it's exited with a 1. Looking more closely,
Reservations and Reloading
When testing the service I noticed something curious. If I make a reservation, the vm files are copied and powered on. When I end the reservation, the copied vm files are destroyed and copied again and the vm is powered on again - the vm is reloaded. What is strange to me is that when I create a new reservation, the vm files are destroyed and copied again and the vm is powered on again. Why would the vm be reloaded if only to reload it again on the next reservation for the same image? Does the service maybe think that a different image is being requested?
