vSphere
VMware vSphere Client in Parallels Desktop
This is a quick solution to a problem I suffered, and thought it was a bug in Parallels Desktop for Mac. You run the vSphere Client application, open a Console to a virtual machine, and after that all your Windows keystrokes and mouse clicks go into the Console and not into any other Windows applications at all, not even the taskbar or Start menu.
The key is that the vSphere Client uses the same "Ctrl Alt" key combination to get out of the console, as does Parallels to get out of Windows programs.
When running in Coherence or Crystal mode, you never really need this key combination as it works automatically anyway when you click in any other Mac application.
The solution is to change the Parallels "Release Input" key combination. Get out of Crystal mode, then go to the Parallels / Preferences window. Select the "Keyboard & Mouse" pane of the dialog box, and work through each Profile in turn. In each profile, set the key combination for "Release Input" to "Cmd-Ctrl-Space" (that's what I used).
Then quit and re-run Parallels and you will find the problem has gone away.
The key is that the vSphere Client uses the same "Ctrl Alt" key combination to get out of the console, as does Parallels to get out of Windows programs.
When running in Coherence or Crystal mode, you never really need this key combination as it works automatically anyway when you click in any other Mac application.
The solution is to change the Parallels "Release Input" key combination. Get out of Crystal mode, then go to the Parallels / Preferences window. Select the "Keyboard & Mouse" pane of the dialog box, and work through each Profile in turn. In each profile, set the key combination for "Release Input" to "Cmd-Ctrl-Space" (that's what I used).
Then quit and re-run Parallels and you will find the problem has gone away.
Comments
Fast VMware VCB Backups
Update 11th Mar 2010 : Less noisy output and retries backup request if it failed
Update 29th Nov 2009 : Major improvement to VM selection rules
Update 18th Nov 2009 : Bug fix release.
Update 15th Nov 2009 : Now handles zombie processes correctly so will terminate correctly when called from .cmd batch scripts.
Update 10th Nov 2009 : Now deletes old backup snapshots left behind by failed previous backups.
This is a new program which uses the VMware "Virtual Consolidated Backup" (or VCB) system to work, and will run on any Windows system. It is highly parallel, very fast and will easily saturate a 1Gbps network link. I have had performance of over 100Mbytes/second across our network, with a sustained rate of over 70Mbytes/second for several hours.
It is far faster than my previous JKFBackup.sh script mentioned in a previous article. It also does not require any ssh or other "unsupported" access to the VMware host server.
It takes a command-line parameter which is the full pathname of the configuration file that it uses. This can be surrounded in double-quotes (") if there are spaces in the path or filename.
The configuration file is a simple text file:
The INCLUDE and EXCLUDE lines work like rules in a firewall. A rule can match several VMs by using “*” wildcard characters in them. As a simple example, the line “INCLUDE kanga-*” would tell the program to backup all VMs whose names start with “kanga-”. The first rule that matches the name of the VM says whether it will be backed up or not. I strongly advise you put either “INCLUDE *” or “EXCLUDE *” as the last rule in the file, to specify the default action for any VMs that do not match any other rules, such as VMs that have been added since you updated the configuration file.
Currently the script uses a different directory for each day of the week, so you have the last week's worth of backups on the disk. If you want to change this, learn a little Perl and you will find the code is very simple and straightforward.
As an example, the backups for Thursday for the VM named "Dummy" will be stored in DIRECTORY\Thu\Dummy.
If you want to backup several VMware host servers, then have a separate configuration file for each server. This script is currently aimed at relatively small vSpheres where you only have a few VMware host servers. If you have hundreds of VMware host servers, then please feel free to rip the script apart and use any bits of it you want. If you are prepared to let me include your improvements in a future release, then please contact me!
To backup VMs as fast as possible, the script splits the list of VMs into 3 and does 3 backups simultaneously in parallel.
Using VCB, data recovery is very simple. Just look in the directory named after the VM you want to restore, and use the VMware Standalone Converter to turn the files in there back into a VM on your VMware server. Easy as that!
You can download version 1.10 of VCBBackup.pl here.
I suggest you right-click on that link and choose "Save as..." to download the file.
It is written in Perl so you will need to install the free Perl distribution from www.activestate.com. You will also need to download and install the "VMware Consolidated Backup" distribution from VMware, which you should be able to access if you have purchased VMware products.
I do my backups onto a little Dell 860 1U rackmount server running Windows Server 2008R2 x64. It backs up to cheap external disk connected via a Firewire-800 interface. This is quite sufficient and can maintain over 700 Mbits/second backup speed.
Every couple of nights I swap out the hard disk and take it off-site. That provides us with backups of the last fortnight with some off-site storage.
I always welcome constructive feedback, and suggestions and requests for new features. If you need any help, just contact me!
Update 29th Nov 2009 : Major improvement to VM selection rules
Update 18th Nov 2009 : Bug fix release.
Update 15th Nov 2009 : Now handles zombie processes correctly so will terminate correctly when called from .cmd batch scripts.
Update 10th Nov 2009 : Now deletes old backup snapshots left behind by failed previous backups.
This is a new program which uses the VMware "Virtual Consolidated Backup" (or VCB) system to work, and will run on any Windows system. It is highly parallel, very fast and will easily saturate a 1Gbps network link. I have had performance of over 100Mbytes/second across our network, with a sustained rate of over 70Mbytes/second for several hours.
It is far faster than my previous JKFBackup.sh script mentioned in a previous article. It also does not require any ssh or other "unsupported" access to the VMware host server.
It takes a command-line parameter which is the full pathname of the configuration file that it uses. This can be surrounded in double-quotes (") if there are spaces in the path or filename.
Configuration
The configuration file is a simple text file:
- All leading and trailing spaces are ignored
- All blank lines are ignored
- Comments start with a hash character (pound sign in the USA) like this "#" and continue to the end of the line
- Each line must start with one of the following keywords, followed by its single parameter:
- DIRECTORY : the full path, including drive letter, under which all the backups will be stored
- HOST : the name of the VMware host server running the VMs to be backed up
- USER : the username to access the VMware host server (usually root)
- PASSWORD : the password for the stated USER
- INCLUDE : backup this named VM. Use the “*” character as a wildcard to mean “0 or more characters” to specify several VMs
- EXCLUDE : do not backup this named VM. Use the “*” character as a wildcard to mean “0 or more characters” to specify several VMs
The INCLUDE and EXCLUDE lines work like rules in a firewall. A rule can match several VMs by using “*” wildcard characters in them. As a simple example, the line “INCLUDE kanga-*” would tell the program to backup all VMs whose names start with “kanga-”. The first rule that matches the name of the VM says whether it will be backed up or not. I strongly advise you put either “INCLUDE *” or “EXCLUDE *” as the last rule in the file, to specify the default action for any VMs that do not match any other rules, such as VMs that have been added since you updated the configuration file.
Currently the script uses a different directory for each day of the week, so you have the last week's worth of backups on the disk. If you want to change this, learn a little Perl and you will find the code is very simple and straightforward.
As an example, the backups for Thursday for the VM named "Dummy" will be stored in DIRECTORY\Thu\Dummy.
If you want to backup several VMware host servers, then have a separate configuration file for each server. This script is currently aimed at relatively small vSpheres where you only have a few VMware host servers. If you have hundreds of VMware host servers, then please feel free to rip the script apart and use any bits of it you want. If you are prepared to let me include your improvements in a future release, then please contact me!
To backup VMs as fast as possible, the script splits the list of VMs into 3 and does 3 backups simultaneously in parallel.
Data Recovery
Using VCB, data recovery is very simple. Just look in the directory named after the VM you want to restore, and use the VMware Standalone Converter to turn the files in there back into a VM on your VMware server. Easy as that!
Download
You can download version 1.10 of VCBBackup.pl here.
I suggest you right-click on that link and choose "Save as..." to download the file.
It is written in Perl so you will need to install the free Perl distribution from www.activestate.com. You will also need to download and install the "VMware Consolidated Backup" distribution from VMware, which you should be able to access if you have purchased VMware products.
My Setup
I do my backups onto a little Dell 860 1U rackmount server running Windows Server 2008R2 x64. It backs up to cheap external disk connected via a Firewire-800 interface. This is quite sufficient and can maintain over 700 Mbits/second backup speed.
Every couple of nights I swap out the hard disk and take it off-site. That provides us with backups of the last fortnight with some off-site storage.
Feedback
I always welcome constructive feedback, and suggestions and requests for new features. If you need any help, just contact me!
Add cron Job to VMware ESX/ESXi
01/11/09 14:49 Filed in: VMware
This explains how to add a cron job to VMware in such a way that it will still be there after reboots.
Having enabled ssh access to your ESX/ESXi server, ssh in as root.
Firstly, add the cron job to the root crontab:
For details of the meaning of "5 0 * * *" (5 minutes past midnight every day) read the man page for crontab(5) on any Unix/Linux server, or else on the web.
Now, add a command to /etc/rc.local to re-generate the cron job when ESX/ESXi reboots
Every time you change the cron job, remember to update /etc/rc.local as well and run the "auto-backup.sh" command to backup the new /etc/rc.local file.
Having enabled ssh access to your ESX/ESXi server, ssh in as root.
Firstly, add the cron job to the root crontab:
- Edit /var/spool/cron/crontabs/root
- Add the line (all on one line)
5 0 * * * /full/path/to/script arguments/with/full/path > /full/path/to/logfile 2>&1 - Run the command "cat /var/run/crond.pid"
That will print the process number of the running crond, such as 12345 - Run the command "kill 12345"
where "12345" should be replaced with the number output by the previous command
For details of the meaning of "5 0 * * *" (5 minutes past midnight every day) read the man page for crontab(5) on any Unix/Linux server, or else on the web.
Now, add a command to /etc/rc.local to re-generate the cron job when ESX/ESXi reboots
- Edit /etc/rc.local, using a command such as "vi /etc/rc.local".
- At the end of the file, add 3 lines (using "G" then "O" in vi). The first kills crond, the second adds the new cron job to the root crontab file, ad the third restarts crond:
/bin/kill $(cat /var/run/crond.pid)
/bin/echo '5 0 * * * /full/path/to/script arguments/with/full/path > /full/path/to/logfile 2>&1' >> /var/spool/cron/crontabs/root
/bin/busybox crond - Save and exit the editor (Press the "Esc" key then ":wq" then press "Return" in vi)
- Run the command "auto-backup.sh" so that the change to /etc/rc.local survives a reboot.
Every time you change the cron job, remember to update /etc/rc.local as well and run the "auto-backup.sh" command to backup the new /etc/rc.local file.
Enable SSH access in VMware
31/10/09 17:56 Filed in: VMware
This simply describes how to enable ssh access to a VMware ESX or ESXi server.
Now you will be able to "ssh root@<your-ESX/ESXi-server-name>" from a Unix/Linux prompt, or use "PuTTY" on Windows to connect to it as the user "root" with your root password.
- From the ESX/ESXi console press Alt-F1.
- Type in the word unsupported and press return (nothing will appear as you type).
- Type in your root password.
- Edit the /etc/inetd.conf file by typing the command "vi /etc/inetd.conf".
- Scroll through the file (j=down, k=up) until you find the line that starts "#ssh" and delete the "#" symbol by pressing "x" and save the file by typing ":wq". If you make a mistake then type ":q!" and press return, and start editing it again.
- Type the command "exit".
- Press Alt-F2.
- Reboot the ESX/ESXi server.
Now you will be able to "ssh root@<your-ESX/ESXi-server-name>" from a Unix/Linux prompt, or use "PuTTY" on Windows to connect to it as the user "root" with your root password.
VMware Backups
31/10/09 17:39 Filed in: VMware
Update: I have now written another backup script which is based on VMware Consolidated Backup (VCB) which you can download from VMware for Windows systems. It is about 10 times faster at backing up than JKFBackup.sh and will totally saturate a 1Gbps ethernet link. I can get networked backup speeds of 100Mbytes/second with it!
I have written my own script to backup VMware volumes. On a vSphere, it can mount all the datastores available on a node simply by running on that node. It backups to an NFS datastore which it will optionally mount and dismount for you. It will also optionally backup just VMs that are powered on, VMs that are powered off and templates, and compress the virtual hard disk files.
As far as I am aware it probably does not yet handle a VM that is spread across several datastores, it assumes the files are kept together in one directory for each VM.
It was written to suit our environment, and we don't spread a VM across several datastores.
The usage is
JKFBackup.sh [ --off ] [ --on ] [ --compress ]
or
JKFBackup.sh --help
to get the command-line usage.
--off tells it to backup templates and VMs that are powered off.
--on tells it to backup VMs that are powered on.
--compress tells it to compress the virtual hard disk files of the VMs and templates that is backing up.
The 3 command line options may be specified in any order.
There are a few things you will need to set in your script to fit your local environment, these are documented at the top of the script so you can quickly get started. These defined the NFS datastore where you want all the backups to go, what backup rota you want, and what datastores to backup. It's all pretty obvious.
To get this onto your VMware server you will need to enable ssh logins, and if you want it to run regularly then you will need to add it to your root crontab.
You can download version 1.00 of the script. Note that you should not try to edit it on Microsoft Windows systems, certainly not using Notepad, as it is a Unix text file and the line-ending characters are different so Windows will tend to screw the file completely. Learn the basics of using the "vi" text editor and edit it on your VMware server. You will need to edit it a little bit to set it appropriately for your VMware organisation.
Install the script within /vmfs/volumes/*. In other words, it must be stored on one of your VMware datastores. Otherwise it will be automatically deleted every time your ESX/ESXi server boots as part of its house-keeping. If you store it in one of your datastores it will be left alone when the server boots up.
Don't forget to back up your backup scripts!
When you come to need to recover from a backup, copy the files back onto your VMware server using the "Browse datastore" functionality, then uncompress the .vmdk.gz files if necessary using the "gunzip" command while logged into your ESX/ESXi server using ssh or PuTTY, then register the .vmx files by right-clicking on them in the "Browse datastore" function in the vSphere client. That will re-register your restored virtual machines.
I have written my own script to backup VMware volumes. On a vSphere, it can mount all the datastores available on a node simply by running on that node. It backups to an NFS datastore which it will optionally mount and dismount for you. It will also optionally backup just VMs that are powered on, VMs that are powered off and templates, and compress the virtual hard disk files.
As far as I am aware it probably does not yet handle a VM that is spread across several datastores, it assumes the files are kept together in one directory for each VM.
It was written to suit our environment, and we don't spread a VM across several datastores.
The usage is
JKFBackup.sh [ --off ] [ --on ] [ --compress ]
or
JKFBackup.sh --help
to get the command-line usage.
--off tells it to backup templates and VMs that are powered off.
--on tells it to backup VMs that are powered on.
--compress tells it to compress the virtual hard disk files of the VMs and templates that is backing up.
The 3 command line options may be specified in any order.
There are a few things you will need to set in your script to fit your local environment, these are documented at the top of the script so you can quickly get started. These defined the NFS datastore where you want all the backups to go, what backup rota you want, and what datastores to backup. It's all pretty obvious.
To get this onto your VMware server you will need to enable ssh logins, and if you want it to run regularly then you will need to add it to your root crontab.
You can download version 1.00 of the script. Note that you should not try to edit it on Microsoft Windows systems, certainly not using Notepad, as it is a Unix text file and the line-ending characters are different so Windows will tend to screw the file completely. Learn the basics of using the "vi" text editor and edit it on your VMware server. You will need to edit it a little bit to set it appropriately for your VMware organisation.
Install the script within /vmfs/volumes/*. In other words, it must be stored on one of your VMware datastores. Otherwise it will be automatically deleted every time your ESX/ESXi server boots as part of its house-keeping. If you store it in one of your datastores it will be left alone when the server boots up.
Don't forget to back up your backup scripts!
When you come to need to recover from a backup, copy the files back onto your VMware server using the "Browse datastore" functionality, then uncompress the .vmdk.gz files if necessary using the "gunzip" command while logged into your ESX/ESXi server using ssh or PuTTY, then register the .vmx files by right-clicking on them in the "Browse datastore" function in the vSphere client. That will re-register your restored virtual machines.
VMware Converter - Converting an Existing Windows System
The Converter is a client/server program, where the converter server runs on ecsvm-admin.ecs and the client can run anywhere, such as win-admin.
Firewall Rules
If the source physical Windows system is in the DMZ, you will need to add a couple of rules to the firewall "Short-Term Rules" section allowing all traffic from ECS-internal to the source host and from the source host to ECS-internal. You should remove these rules again once the conversion has completed.
Starting the Conversion
Start the VMWare Converter Standalone Client program.
IP Address/Name = ecsvm-admin:7443
Username = administrator (or your own sys* username if you are registered on the vSphere with an account).
Password = Windows-infrastructure password
Click the "Convert Machine" button in the toolbar.
Source type = Powered-on machine
Give remote machine full hostname.
Give username and password of a user in the "Administrators" group on the source Windows system, such as the "ECS2000\administrator" account and domain password..
OS Family = Windows.
Next.
It should connect to the source physical system.
If it fails, then give it the IP address of the source physical system instead of the name of it.
If it still fails, then Remote Desktop to the source physical system, download the converter (from browsing the datastores starting at http://ecsvm-admin.ecs.soton.ac.uk/) and install the converter agent (not the client/server setup) onto the source system, then run it again from there.
When it asks for the name of the source system to convert, give it the IP address of the source system (which is the same system you are now running the Converter on).
Tell it to automatically uninstall the files when the import succeeds.
It will then deploy the agent, which takes a few seconds.
VMware Infrastructure server details:
Server = ecsvm-admin
Username = administrator (or your sys* username if you have an account on vSphere).
Password = Windows-infrastructure password (or yours).
Next.
Select host to run the VM on = ecsvm-admin1.ecs.soton.ac.uk.
Virtual machine name = short hostname (eg. major-backup).
Datastore = infrastore1-Vol2 (an infrastore volume with plenty of free space).
Virtual machine version = Version 7.
Next.
Options
Destination Attributes: Name = short hostname, Folder = ecs
Data to copy: Click "Advanced...", then "Target Layout...".
Set all large, non-swap filesystems to "Thin provisioning" (this is "Dynamic disks" in Microsoft speak, where only the disk space in use is actually allocated on disk, used disk space expands as necessary to hold the data, up to the maximum set by the size of the filesystem).
Set the Size of the normal large filesystems (eg. "C:") to a reasonable number, no point in making them huge, most will fit in 60Gbytes.
Switch to the "Source Volumes" tab to see how much space is actually in use at the moment.
Normally set C: to thin provisioning, 60GBytes or more.
It is important not to waste disk space on Flat-provisioned disks that are not going to use all their space. Disk is relatively expensive.
Devices: Numer of processors = 1.
Disk controller = SCSI LSI Logic or SCSI Buslogic.
Memory = usually the default will be fine.
Networks: Network adapters to connect = 1
Set the network for the network adapter to be the same Virtual Machine Network VLAN as the physical machine you are converting.
The new virtual machine will take over the IP address of the physical source machine.
Services: Source Services: switch off services that should not be left running when the VM is created (such as SQL Server or WWW Publishing Service, and Hyper-V services if moving from Hyper-V to VMware). Destination Services: set all Hyper-V services to "Disabled".
Advanced Options: Power on target machine = yes
Power off source machine = yes
Install VMware Tools on the imported virtual machine = yes
Configure guest preferences for the virtual machine = no
Remove System Restore checkpoints on destination = yes
Reconfigure destination virtual machine = yes
Next.
It should now just show you the final option settings and then start the process of converting the host. Wait for the whole process to finish before touching either the source (physical) or destination (virtual) machines.
How long it takes depends on the quantity of data that has to be moved. You can expect about 20 to 25 MBytes/second conversion speed. A machine with about 7GB of used disk takes about 25 minutes to convert.
As the process is run by the Converter Server (running on ecsvm-admin), it doesn't matter if you quit the Windows app used to watch the process, you can track the progress of the conversion from the Converter Windows app running on any PC.
After the Conversion has Finished
Open a console on the new VM.
In the "VM/Guest" menu, install the VM tools. This will insert a CD into the virtual CD drive, what happens then is dependent on the Windows Autoplay preferences in the virtual machine.
This will force a restart of the virtual machine.
Shutdown the virtual machine.
Once the VM has stopped, edit the settings of the VM and choose the middle "Options" tab. In the "VMware Tools" settings, right at the bottom right of the dialog there is an option to "Synchronize guest time with host". Tick this box.
Okay that, then power on the VM.
It should successfully boot.
The VM should now be fully running happily and serving its services to the users.
Now just remove the two temporary firewall rules you added at the start of this process.
Firewall Rules
If the source physical Windows system is in the DMZ, you will need to add a couple of rules to the firewall "Short-Term Rules" section allowing all traffic from ECS-internal to the source host and from the source host to ECS-internal. You should remove these rules again once the conversion has completed.
Starting the Conversion
Start the VMWare Converter Standalone Client program.
IP Address/Name = ecsvm-admin:7443
Username = administrator (or your own sys* username if you are registered on the vSphere with an account).
Password = Windows-infrastructure password
Click the "Convert Machine" button in the toolbar.
Source type = Powered-on machine
Give remote machine full hostname.
Give username and password of a user in the "Administrators" group on the source Windows system, such as the "ECS2000\administrator" account and domain password..
OS Family = Windows.
Next.
It should connect to the source physical system.
If it fails, then give it the IP address of the source physical system instead of the name of it.
If it still fails, then Remote Desktop to the source physical system, download the converter (from browsing the datastores starting at http://ecsvm-admin.ecs.soton.ac.uk/) and install the converter agent (not the client/server setup) onto the source system, then run it again from there.
When it asks for the name of the source system to convert, give it the IP address of the source system (which is the same system you are now running the Converter on).
Tell it to automatically uninstall the files when the import succeeds.
It will then deploy the agent, which takes a few seconds.
VMware Infrastructure server details:
Server = ecsvm-admin
Username = administrator (or your sys* username if you have an account on vSphere).
Password = Windows-infrastructure password (or yours).
Next.
Select host to run the VM on = ecsvm-admin1.ecs.soton.ac.uk.
Virtual machine name = short hostname (eg. major-backup).
Datastore = infrastore1-Vol2 (an infrastore volume with plenty of free space).
Virtual machine version = Version 7.
Next.
Options
Destination Attributes: Name = short hostname, Folder = ecs
Data to copy: Click "Advanced...", then "Target Layout...".
Set all large, non-swap filesystems to "Thin provisioning" (this is "Dynamic disks" in Microsoft speak, where only the disk space in use is actually allocated on disk, used disk space expands as necessary to hold the data, up to the maximum set by the size of the filesystem).
Set the Size of the normal large filesystems (eg. "C:") to a reasonable number, no point in making them huge, most will fit in 60Gbytes.
Switch to the "Source Volumes" tab to see how much space is actually in use at the moment.
Normally set C: to thin provisioning, 60GBytes or more.
It is important not to waste disk space on Flat-provisioned disks that are not going to use all their space. Disk is relatively expensive.
Devices: Numer of processors = 1.
Disk controller = SCSI LSI Logic or SCSI Buslogic.
Memory = usually the default will be fine.
Networks: Network adapters to connect = 1
Set the network for the network adapter to be the same Virtual Machine Network VLAN as the physical machine you are converting.
The new virtual machine will take over the IP address of the physical source machine.
Services: Source Services: switch off services that should not be left running when the VM is created (such as SQL Server or WWW Publishing Service, and Hyper-V services if moving from Hyper-V to VMware). Destination Services: set all Hyper-V services to "Disabled".
Advanced Options: Power on target machine = yes
Power off source machine = yes
Install VMware Tools on the imported virtual machine = yes
Configure guest preferences for the virtual machine = no
Remove System Restore checkpoints on destination = yes
Reconfigure destination virtual machine = yes
Next.
It should now just show you the final option settings and then start the process of converting the host. Wait for the whole process to finish before touching either the source (physical) or destination (virtual) machines.
How long it takes depends on the quantity of data that has to be moved. You can expect about 20 to 25 MBytes/second conversion speed. A machine with about 7GB of used disk takes about 25 minutes to convert.
As the process is run by the Converter Server (running on ecsvm-admin), it doesn't matter if you quit the Windows app used to watch the process, you can track the progress of the conversion from the Converter Windows app running on any PC.
After the Conversion has Finished
Open a console on the new VM.
In the "VM/Guest" menu, install the VM tools. This will insert a CD into the virtual CD drive, what happens then is dependent on the Windows Autoplay preferences in the virtual machine.
This will force a restart of the virtual machine.
Shutdown the virtual machine.
Once the VM has stopped, edit the settings of the VM and choose the middle "Options" tab. In the "VMware Tools" settings, right at the bottom right of the dialog there is an option to "Synchronize guest time with host". Tick this box.
Okay that, then power on the VM.
It should successfully boot.
The VM should now be fully running happily and serving its services to the users.
Now just remove the two temporary firewall rules you added at the start of this process.
VMware Converter - Converting an Existing Linux System
The Converter is a client/server program, where the converter server runs on ecsvm-admin.ecs and the client can run anywhere, such as win-admin.
Firewall Rules
If the source physical Linux system is in the DMZ, you will need to add a couple of rules to the firewall "Short-Term Rules" section allowing all traffic from ECS-internal to the source host and from the source host to ECS-internal. You should remove these rules again once the conversion has completed.
Before You Start
On the final virtual machine, you will need to install the VMware tools and set the VM settings to synchronise the time on the VM with that of the ecsvm-admin server. So you won't want ntpd to be running. Also, you are going to need to reboot the VM at least once after you have converted it, so stop and disable the primary user services (e.g. httpd, mysqld) that are running on the server. You can start up the user services again as the last step after getting the VM Linux system running. So I would start with
service ntpd stop
service httpd stop
service mysqld stop
chkconfig ntpd off
chkconfig httpd off
chkconfig mysqld off
Also, if the physical source machine is actually a Windows 2008 Hyper-V VM, then you will want to do the same to the "inputvsc" service, and copy the seth0 device settings to eth0 (remembering to change the device name in /etc/sysconfig/network-scripts/ifcfg-eth0 after copying the ifcfg-seth0 file onto it) as VMware will use the eth0 device and not the seth0 device.
Once running in VMware, the kernel will need to be able to "probe" the disk controllers in order to be able to find the controller types. So in /boot/grub/grub.conf, edit the kernel command line arguments and remove any settings that set "hda=noprobe" or similar. You don't need to reboot after this change, this will be applied once the VM conversion has finished and VMware starts the new VM.
Starting the Conversion
Start the VMWare Converter Standalone Client program.
IP Address/Name = ecsvm-admin:7443
Username = administrator (or your own sys* username if you are registered on the vSphere with an account).
Password = Windows-infrastructure password
Click the "Convert Machine" button in the toolbar.
Source type = Powered-on machine
Give remote machine full hostname.
Give root username and password.
Next.
VMware Infrastructure server details:
Server = ecsvm-admin
Username = administrator (or your sys* username if you have an account on vSphere).
Password = Windows-infrastructure password (or yours).
Next.
Select host to run the VM on = ecsvm-admin1.ecs.soton.ac.uk.
Virtual machine name = short hostname (eg. gander).
Datastore = infrastore1-Vol2 (an infrastore volume with plenty of free space).
Virtual machine version = Version 7.
Next.
Options
Destination Attributes: Name = short hostname, Folder = ecs
Data to copy: Click "Advanced...", then "Target Layout...".
Set all large, non-swap filesystems to "Thin provisioning" (this is "Dynamic disks" in Microsoft speak, where only the disk space in use is actually allocated on disk, used disk space expands as necessary to hold the data, up to the maximum set by the size of the filesystem).
Set the Size of the normal large filesystems (eg. "/") to a reasonable number, no point in making them huge, most will fit in 40Gbytes.
Switch to the "Source Volumes" tab to see how much space is actually in use at the moment.
Normally set / to thin provisioning, 40GBytes, leave /boot and swap alone.
Devices: Numer of processors = 1.
Disk controller = SCSI LSI Logic or SCSI Buslogic.
Memory = usually the default will be fine.
Networks: Network adapters to connect = 1
Set the network for the network adapter to be the same Virtual Machine Network VLAN as the physical machine you are converting.
The new virtual machine will take over the IP address of the physical source machine.
Advanced Options: Power on target machine = yes
Power off source machine = yes
Reconfigure destination virtual machine = yes
Helper VM Network: Look up the IP address of the host "ecsvm--helper" which is a spare IP address unused by anything else in the same "" as the physical host you are converting. There are currently hosts defined such as "ecsvm-systems-helper", "ecsvm-dmz-helper" and "ecsvm-servers-helper". The IP configuration parameters and DNS setup for the Helper VM Network must all be consistent with its IP address. This "helper" machine is a temporary system setup by the VMware Converter just for use during the process of converting a Linux box, it disappears again at the end.
Next.
It should now just show you the final option settings and then start the process of converting the host. Wait for the whole process to finish before touching either the source (physical) or destination (virtual) machines.
How long it takes depends on the quantity of data that has to be moved. You can expect about 20 to 25 MBytes/second conversion speed. A machine with about 7GB of used disk takes about 25 minutes to convert.
As the process is run by the Converter Server (running on ecsvm-admin), it doesn't matter if you quit the Windows app used to watch the process, you can track the progress of the conversion from the Converter Windows app running on any PC.
After the Conversion has Finished
Open a console on the new VM.
In the "VM/Guest" menu, install the VM tools.
mount /dev/cdrom /mnt
cd /tmp
tar xzf /mnt/VM*
umount /mnt
cd vmware*
./vmware-tools-install.pl
Accept all the defaults. It will find suitable modules for your kernel, or else will compile them itself, and build a new initrd, grub.conf and modprobe.conf for your kernel.
Assuming that succeeded, then
shutdown -h now
Once the VM has stopped, edit the settings of the VM and choose the middle "Options" tab. In the "VMware Tools" settings, right at the bottom right of the dialog there is an option to "Synchronize guest time with host". Tick this box.
Okay that, then power on the VM.
It should successfully boot.
The only remaining tasks are to enable and start up the user services, but not ntpd.
chkconfig mysqld on
chkconfig httpd on
service mysqld start
service httpd start
The VM should now be fully running happily and serving its services to the users. If you prefer, you can always reboot the VM again instead of running those last two "service ... start" commands to prove it is all okay and booting correctly.
Now just remove the two temporary firewall rules you added at the start of this process.
Firewall Rules
If the source physical Linux system is in the DMZ, you will need to add a couple of rules to the firewall "Short-Term Rules" section allowing all traffic from ECS-internal to the source host and from the source host to ECS-internal. You should remove these rules again once the conversion has completed.
Before You Start
On the final virtual machine, you will need to install the VMware tools and set the VM settings to synchronise the time on the VM with that of the ecsvm-admin server. So you won't want ntpd to be running. Also, you are going to need to reboot the VM at least once after you have converted it, so stop and disable the primary user services (e.g. httpd, mysqld) that are running on the server. You can start up the user services again as the last step after getting the VM Linux system running. So I would start with
service ntpd stop
service httpd stop
service mysqld stop
chkconfig ntpd off
chkconfig httpd off
chkconfig mysqld off
Also, if the physical source machine is actually a Windows 2008 Hyper-V VM, then you will want to do the same to the "inputvsc" service, and copy the seth0 device settings to eth0 (remembering to change the device name in /etc/sysconfig/network-scripts/ifcfg-eth0 after copying the ifcfg-seth0 file onto it) as VMware will use the eth0 device and not the seth0 device.
Once running in VMware, the kernel will need to be able to "probe" the disk controllers in order to be able to find the controller types. So in /boot/grub/grub.conf, edit the kernel command line arguments and remove any settings that set "hda=noprobe" or similar. You don't need to reboot after this change, this will be applied once the VM conversion has finished and VMware starts the new VM.
Starting the Conversion
Start the VMWare Converter Standalone Client program.
IP Address/Name = ecsvm-admin:7443
Username = administrator (or your own sys* username if you are registered on the vSphere with an account).
Password = Windows-infrastructure password
Click the "Convert Machine" button in the toolbar.
Source type = Powered-on machine
Give remote machine full hostname.
Give root username and password.
Next.
VMware Infrastructure server details:
Server = ecsvm-admin
Username = administrator (or your sys* username if you have an account on vSphere).
Password = Windows-infrastructure password (or yours).
Next.
Select host to run the VM on = ecsvm-admin1.ecs.soton.ac.uk.
Virtual machine name = short hostname (eg. gander).
Datastore = infrastore1-Vol2 (an infrastore volume with plenty of free space).
Virtual machine version = Version 7.
Next.
Options
Destination Attributes: Name = short hostname, Folder = ecs
Data to copy: Click "Advanced...", then "Target Layout...".
Set all large, non-swap filesystems to "Thin provisioning" (this is "Dynamic disks" in Microsoft speak, where only the disk space in use is actually allocated on disk, used disk space expands as necessary to hold the data, up to the maximum set by the size of the filesystem).
Set the Size of the normal large filesystems (eg. "/") to a reasonable number, no point in making them huge, most will fit in 40Gbytes.
Switch to the "Source Volumes" tab to see how much space is actually in use at the moment.
Normally set / to thin provisioning, 40GBytes, leave /boot and swap alone.
Devices: Numer of processors = 1.
Disk controller = SCSI LSI Logic or SCSI Buslogic.
Memory = usually the default will be fine.
Networks: Network adapters to connect = 1
Set the network for the network adapter to be the same Virtual Machine Network VLAN as the physical machine you are converting.
The new virtual machine will take over the IP address of the physical source machine.
Advanced Options: Power on target machine = yes
Power off source machine = yes
Reconfigure destination virtual machine = yes
Helper VM Network: Look up the IP address of the host "ecsvm-
Next.
It should now just show you the final option settings and then start the process of converting the host. Wait for the whole process to finish before touching either the source (physical) or destination (virtual) machines.
How long it takes depends on the quantity of data that has to be moved. You can expect about 20 to 25 MBytes/second conversion speed. A machine with about 7GB of used disk takes about 25 minutes to convert.
As the process is run by the Converter Server (running on ecsvm-admin), it doesn't matter if you quit the Windows app used to watch the process, you can track the progress of the conversion from the Converter Windows app running on any PC.
Open a console on the new VM.
In the "VM/Guest" menu, install the VM tools.
mount /dev/cdrom /mnt
cd /tmp
tar xzf /mnt/VM*
umount /mnt
cd vmware*
./vmware-tools-install.pl
Accept all the defaults. It will find suitable modules for your kernel, or else will compile them itself, and build a new initrd, grub.conf and modprobe.conf for your kernel.
Assuming that succeeded, then
shutdown -h now
Once the VM has stopped, edit the settings of the VM and choose the middle "Options" tab. In the "VMware Tools" settings, right at the bottom right of the dialog there is an option to "Synchronize guest time with host". Tick this box.
Okay that, then power on the VM.
It should successfully boot.
The only remaining tasks are to enable and start up the user services, but not ntpd.
chkconfig mysqld on
chkconfig httpd on
service mysqld start
service httpd start
The VM should now be fully running happily and serving its services to the users. If you prefer, you can always reboot the VM again instead of running those last two "service ... start" commands to prove it is all okay and booting correctly.
Now just remove the two temporary firewall rules you added at the start of this process.
Install VMware Tools on a Linux Client
First, log in to the VM as root and "yum update".
Then "yum install gcc make binutils kernel-devel kernel-headers".
Then reboot the VM.
Then start up the vSphere Client, right click on the VM and choose Guest - Install VMware Tools.
Back into the VM's root session.
mount /dev/cdrom /mnt
cd /tmp
tar xzf /mnt/VM*
umount /mnt
cd vmware-tools-distrib
./vmware-install.pl
Accept all the defaults, and let it do everything it wants. If you have a fully updated and correct system, it should install flawlessly.
Check the "ifconfig -a" and ensure that all the network devices that exist have startup scripts in /etc/sysconfig/network-scripts/ifcfg-eth*.
Go into the vSphere Client again and right-click on the VM. Look in the "Guest" sub-menu and tell it to stop installing the VMware Tools if it offers you that.
Reboot the VM.
If you have problems...
The most likely problem is that you are running an el5xen kernel or some other xen kernel, which you don't want to be doing.
Once you've done a yum update, take the xen kernel you are running (uname -a will tell you) and do something like this:
yum install kernel-2.6.18-164.el5
Then edit /boot/grub/grub.conf and ensure that the "default=" setting at the top is set to boot the kernel you just installed and not the xen kernel (they start numbering from the top of the file from 0).
Then reboot so you are running the non-xen kernel.
Then
yum install kernel-devel-2.6.18-164.el5
Then re-run /tmp/vmware-tools-distrib/vmware-install.pl and if it asks you for the kernel headers location, give it
/usr/src/kernels/2.6.18-164.el5/include
But you will most likely find that it just happily works on its own!
Then just reboot to pick up all the VMware tools in a fresh boot.
Then "yum install gcc make binutils kernel-devel kernel-headers".
Then reboot the VM.
Then start up the vSphere Client, right click on the VM and choose Guest - Install VMware Tools.
Back into the VM's root session.
mount /dev/cdrom /mnt
cd /tmp
tar xzf /mnt/VM*
umount /mnt
cd vmware-tools-distrib
./vmware-install.pl
Accept all the defaults, and let it do everything it wants. If you have a fully updated and correct system, it should install flawlessly.
Check the "ifconfig -a" and ensure that all the network devices that exist have startup scripts in /etc/sysconfig/network-scripts/ifcfg-eth*.
Go into the vSphere Client again and right-click on the VM. Look in the "Guest" sub-menu and tell it to stop installing the VMware Tools if it offers you that.
Reboot the VM.
If you have problems...
The most likely problem is that you are running an el5xen kernel or some other xen kernel, which you don't want to be doing.
Once you've done a yum update, take the xen kernel you are running (uname -a will tell you) and do something like this:
yum install kernel-2.6.18-164.el5
Then edit /boot/grub/grub.conf and ensure that the "default=" setting at the top is set to boot the kernel you just installed and not the xen kernel (they start numbering from the top of the file from 0).
Then reboot so you are running the non-xen kernel.
Then
yum install kernel-devel-2.6.18-164.el5
Then re-run /tmp/vmware-tools-distrib/vmware-install.pl and if it asks you for the kernel headers location, give it
/usr/src/kernels/2.6.18-164.el5/include
But you will most likely find that it just happily works on its own!
Then just reboot to pick up all the VMware tools in a fresh boot.
VMware Converter Fails for Linux Client
You need to change the installed SCSI controller to be a LSI Logic controller. The original machine may have been configured for a Transtec 3Ware SCSI controller.
The main relevant article is here:
http://tipstricksandmore.blogspot.com/2009/01/after-converting-physical-rhel4-system.html
Once the VM has been converted, you can change the hardware of the VM in the "Edit Settings..." menu from right-clicking on the VM. You can only change it when the VM is powered off.
Edit the VM settings and connect the DVD drive to a "Datastore ISO File": infra1-localDisk/vSphere Management Assistant/rhel-5-server-i386-dvd.iso.
Set the Device Status to "Connected" and "Connect at power on".
In the VM options page, set it to go into the BIOS setup at next boot.
Open a console on the VM and power it on. It will go into the BIOS setup.
In the "Boot" BIOS menu, select the DVD drive and press + to move it to the top.
Save and exit the BIOS setup.
It will boot from DVD.
Enter "linux rescue".
You don't need any network interfaces.
Let it look for the installed system to mount under /mnt/sysimage.
chroot /mnt/sysimage
Replace hda with sda in /etc/fstab, /boot/grub/device.map and /boot/grub/grub.conf
grub-install /dev/sda
Make sure /etc/modules.conf is empty or non-existent.
Edit /etc/modprobe.conf and set
alias eth0 pcnet32
alias eth1 pcnet32
alias scsi_hostadapter mptbase
alias scsi_hostadapter1 mptscsih
Work out the full path to the initrd image you are going to rebuild. They are in /boot and are called initrd*.
The /boot/grub/grub.conf will point to the right one.
So in my example it is "/boot/initrd-2.6.18-128.7.1.el5xen.img".
There should be a directory under /lib/modules called the same version number.
Then you use a command like this to rebuild it
mkinitrd -v -f /boot/initrd-2.6.18-128.7.1.el5xen.img 2.6.18-128.7.1.el5xen
exit
reboot
Press Esc to get the boot menu and force it to boot from the hard disk.
Hopefully it will boot this time!
Shut it down again, edit the VM settings and set the DVD drive back to "Client Device".
Boot your VM normally.
The main relevant article is here:
http://tipstricksandmore.blogspot.com/2009/01/after-converting-physical-rhel4-system.html
Once the VM has been converted, you can change the hardware of the VM in the "Edit Settings..." menu from right-clicking on the VM. You can only change it when the VM is powered off.
Edit the VM settings and connect the DVD drive to a "Datastore ISO File": infra1-localDisk/vSphere Management Assistant/rhel-5-server-i386-dvd.iso.
Set the Device Status to "Connected" and "Connect at power on".
In the VM options page, set it to go into the BIOS setup at next boot.
Open a console on the VM and power it on. It will go into the BIOS setup.
In the "Boot" BIOS menu, select the DVD drive and press + to move it to the top.
Save and exit the BIOS setup.
It will boot from DVD.
Enter "linux rescue".
You don't need any network interfaces.
Let it look for the installed system to mount under /mnt/sysimage.
chroot /mnt/sysimage
Replace hda with sda in /etc/fstab, /boot/grub/device.map and /boot/grub/grub.conf
grub-install /dev/sda
Make sure /etc/modules.conf is empty or non-existent.
Edit /etc/modprobe.conf and set
alias eth0 pcnet32
alias eth1 pcnet32
alias scsi_hostadapter mptbase
alias scsi_hostadapter1 mptscsih
Work out the full path to the initrd image you are going to rebuild. They are in /boot and are called initrd*.
The /boot/grub/grub.conf will point to the right one.
So in my example it is "/boot/initrd-2.6.18-128.7.1.el5xen.img".
There should be a directory under /lib/modules called the same version number.
Then you use a command like this to rebuild it
mkinitrd -v -f /boot/initrd-2.6.18-128.7.1.el5xen.img 2.6.18-128.7.1.el5xen
exit
reboot
Press Esc to get the boot menu and force it to boot from the hard disk.
Hopefully it will boot this time!
Shut it down again, edit the VM settings and set the DVD drive back to "Client Device".
Boot your VM normally.
VMware Hot Clone of an Existing System
This article describes how to create a VMware virtual machine from an existing live (Windows) system.
The same process should work with Linux but I've not tested it yet.
Starting the Client
1. Open a Remote Desktop session to ecsvm-admin.ecs.soton.ac.uk and login as ecs2000\administrator
2. Start the VmWare Converter Standalone Client on ecsvm-admin. Start --> All Programs --> VMWare --> Converter Standalone Client
3. Select "Connect to local Server" and click ok.
4. The client software should start
Creating the VM
1. Click the "Convert Machine" button (towards the top left)
2. Select the "A Remote machine" radio button
3. Enter the IP address of the machine to be cloned
4. Enter the user ID and password of an Administrator on the machine being cloned
5. Click Next
6. You should see a prompt asking if you want to "Automatically uninstall" the agent software when the clone has finished. Select the option and click Yes.
7. It'll now wait while the client agent is installed.
8. Next you're prompted for the VMware Virtual Infrastructure details:
Server=ecsvm-admin.ecs.soton.ac.uk
User Name=ecs2000\administrator
9. You should now see a view of our VI Infrastructure:
a. Click server "ecsvm-infra1.ecs.soton.ac.uk"
b. Select one of the infrastore1 disk volumes for the datastore
c. Type the virtual machine name you want to use (normally just the host name and not the FQDN)
10. Click next
11. You now get a chance to configure the VM "hardware" and select which disks to clone etc
12 Click Next
13. Click finish and the clone should start.
14 After the clone has finished you need to make sure the VM is connected to the correct virtual network:
Using the Vsphere client right click on the VM and click edit settings.
Click the network adapter, choose the correct network in the list box and click OK.
15. Install/Upgrade VMware tools:
Using vSphere client right click on the VM and click Guest --> Install/Upgrade VMware tools
The same process should work with Linux but I've not tested it yet.
Starting the Client
1. Open a Remote Desktop session to ecsvm-admin.ecs.soton.ac.uk and login as ecs2000\administrator
2. Start the VmWare Converter Standalone Client on ecsvm-admin. Start --> All Programs --> VMWare --> Converter Standalone Client
3. Select "Connect to local Server" and click ok.
4. The client software should start
Creating the VM
1. Click the "Convert Machine" button (towards the top left)
2. Select the "A Remote machine" radio button
3. Enter the IP address of the machine to be cloned
4. Enter the user ID and password of an Administrator on the machine being cloned
5. Click Next
6. You should see a prompt asking if you want to "Automatically uninstall" the agent software when the clone has finished. Select the option and click Yes.
7. It'll now wait while the client agent is installed.
8. Next you're prompted for the VMware Virtual Infrastructure details:
Server=ecsvm-admin.ecs.soton.ac.uk
User Name=ecs2000\administrator
9. You should now see a view of our VI Infrastructure:
a. Click server "ecsvm-infra1.ecs.soton.ac.uk"
b. Select one of the infrastore1 disk volumes for the datastore
c. Type the virtual machine name you want to use (normally just the host name and not the FQDN)
10. Click next
11. You now get a chance to configure the VM "hardware" and select which disks to clone etc
12 Click Next
13. Click finish and the clone should start.
14 After the clone has finished you need to make sure the VM is connected to the correct virtual network:
Using the Vsphere client right click on the VM and click edit settings.
Click the network adapter, choose the correct network in the list box and click OK.
15. Install/Upgrade VMware tools:
Using vSphere client right click on the VM and click Guest --> Install/Upgrade VMware tools
vSphere Client will not Run on Windows 7
When you start the vSphere Client on Windows 7, you get an error about it being unable to read the "clients.xml" file, followed by an another error "The type initializer for "VirtualInfrastructure.Utils.HttpWebRequestProxy" threw an exception".
The workaround is this:
You can now use the VpxClient.cmd (or the shortcut) to launch the vSphere client in Windows 7.
This workaround bypasses the normal .NET Framework loading mechanism. Assembly versions found in the DEVPATH folder are not checked.
The workaround is this:
- Create a folder (e.g. Lib) in the Windows 7 machine where the vSphere client is installed (%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\).
- Obtain a copy of %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\System.dll from a non-Windows 7 machine that has .NET 3.5 SP1 installed. Copy this file into the folder created in Step 1.
- In the vSphere client launcher directory, open the VpxClient.exe.config file in a text editor and add a <runtime> element and a <developmentMode> element within the <configuration> element. Save the file.
- <?xml version="1.0" encoding="utf-8"?>
<configuration>
...
<runtime>
<developmentMode developerInstallation="true"/>
</runtime>
</configuration>
- Create a batch file (e.g. VpxClient.cmd) in a suitable location (e.g. Desktop). In this file add a command to set the DEVPATH environment variable to the folder where you copied the System.dll assembly in step 2 and a second command to launch the vSphere client. Save the file.
- SET DEVPATH=%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib
"%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe"
You can now use the VpxClient.cmd (or the shortcut) to launch the vSphere client in Windows 7.
This workaround bypasses the normal .NET Framework loading mechanism. Assembly versions found in the DEVPATH folder are not checked.