Recently, I downloaded and tried VMware Converter Beta. It is VMware's new P2V (and V2V) product. This publicly available download is the Starter Edition and is free to use. There is also an Enterprise edition with additional features. When compared to their previous P2V product, P2V Assistant, VMware Converter has the following extra features that jump out:

Online P2V
The source machine (physical or virtual) keeps running during the P2V process. This is similar to what vendors like Leostream and PlateSpin offer. Obviously, this is not a good method for all your servers but might be for some. Note that the Starter Edition only supports this method. Another limitation of the Starter Edition is the fact that you cannot initiate P2V conversions of remote servers. In other words, you have to install the full package (agent and management tool) on the source machine to convert it. The Enterprise edition supports installing the management tool on a separate machine to push agents to remote machines to convert them. In that case, multiple P2V conversions can be initiated at the same time and followed from the management tool.

Offline P2V with a WinPE boot cd
The source machine is turned off and booted with a WinPE boot cd. A tool is provided to inject new Windows drivers into the cd image. The P2V Assistant boot cd was based on Knoppix and thus required Linux drivers. The boot cd is only for the Enterprise Edition and is the method of choice to create a consistent image of the source server.

No need for a helper virtual machine
With ESX as the destination, the P2V Assistant required a helper virtual machine. This is not the case for VMware Converter. When you configure a conversion, you just specify the target ESX server or VirtualCenter and VMware Converter takes care of creating the destination virtual machine, the disks, etc… This makes it much simpler and easier to use.

VMware Tools and reconfiguration
When you configure a conversion, you can specify that the VMware Tools have to be installed automatically. You can also reconfigure the virtual machine and give it a new name, new IP, etc… The reconfiguring is done with sysprep.

I tried a few conversions and had a couple of issues. First of all, make sure you have name resolution correctly configured so that the name of your target ESX server can be resolved to an IP address. That should not be an issue in a production environment but in a test environment, that is easily overlooked (as I did). I also had an issue with the imaging process itself. Apparently, VMware Converter uses Volume Shadow Copy services on operating systems that support it. On my test source machine, these services were disabled and naturally, the imaging process failed. After starting the Volume Shadow Copy service and the MS Software Shadow Copy Provider services everything worked like a charm.

VMware Converter looks promising but VMware should make the enterprise flavour free as well and this for several reasons. The first reason is that P2V in itself is not what matters most. Granted, it is an important process in a virtualization project but in the end, it is the virtualization itself and the management of the virtualized environment that counts. Secondly, the product only makes P2V just a bit easier. With some 3^rd party imaging tools and VMware's Virtual Machine Importer 2.0, you can also achieve the same end result.

Integrating ESX 3.0 with Active Directory is often requested by customers where we implement ESX. At the moment, I am doing an ESX implementation at one of our larger customers and of course, AD integration is part of the project. Naturally, they will use VirtualCenter 2.0 most of the time, but at times they will need to connect to individual ESX servers using VI Client, ssh or web access. In that case, they want to use their AD account and password.

VMware recently published a small whitepaper about Active Directory integration. With ESX 3.0, the process is very straightforward and only requires one command:

esxcfg-auth --enablead --addomain=domain.com --addc=domain.com

The VMware document uses the FQDN of a domain controller for the --addc parameter, but you can use the FQDN of the domain. That way, DNS is used to find domain controllers and use one of those. The command above modifies a few files like /etc/krb5.conf and also the system-auth file in /etc/pam.d. The ESX firewall is also automatically configured to open the needed ports for AD authentication.

Before you can logon with an AD account, you need to create a console user on the ESX box that has the same name as your AD account. For example, if you have an AD account domain\esxadmin, you need to add a user to the ESX console called esxadmin. The command to use is useradd esxadmin. You can also use VI Client to create the user. You can now logon with the account and use the AD password. I tested this with ESX 3.0.1 servers against Windows 2000 and Windows 2003 domains and it worked as advertised.

A couple of other things to think of:

• If you create a user in AD with account name root, you can logon as root with its AD password.
  
• If you don't want AD authentication for root, you can edit /etc/pam.d/system-auth. On the line that starts with auth and also includes pam_krb5.so, add this to the end: minimum_uid=1. Authentication for root (uid=0) will now be done locally only.
  
• If you want the AD user to have the same rights as root, you can set the user's UID to 0 (usermod -u 0 -c username). Of course, if you have used minimum_uid, that won't work.
  
• Alternatively, use sudoers to allow users to use sudo to execute specific tasks as root.
  

If you want administrators to use their AD account to connect to ESX with the VI Client or web access, you need to configure that with VI Client first. Start VI Client and connect to the ESX server as root. Use CTRL-P to add a permission at the server level. For example, to grant the user all rights, give the user the Administrator role (see below). That user will then be able to logon with his/her AD account and password in both VI Client and web access.

There are some issues with AD integration when done this way:

• When you configure the AD account to change its password the next logon, you will get a warning in the ESX console but you can still logon. That should not happen.
  
• If you do change your password with the passwd command, you change it locally only.
  

To get around some of these issues, you can use a product such as Centrify DirectControl for ESX. DirectControl has deeper integration with Active Directory and many more features:

• An AD computer account is created for your ESX servers.
  
• Active Directory Group Policies can be used to push down policies to ESX computer objects.
  
• When you create a new user in AD, you can directly create a user account on your ESX machines and set properties such as the home directory.
  
• Active Directory Group Policies can be applied to users that logon to ESX. For example, you can push down sudo configuration using a group policy.
  
• When a password expires or you set the change at next logon flag, you need to change the password in the ESX console. When you change your password, it is the AD password that you change, not the local password.
  
• When a user uses passwd, the AD password is modified and not the local password.
  
• Using group policies, you can configure logon banners.
  
• You can install a modified SSH daemon that is "kerberized". With Centrify's modified putty client, you can use ssh to logon without retyping your AD password.
  

We are in the process of evaluating DirectControl and it is very easy to deploy and work with. Pricing is reasonable and the product supports ESX 3.0.x.

Normally, I make ssh connections to ESX using an ssh client such as Putty or Bitvise Tunnelier. Out of the box, ESX enables ssh access but disallows login as root. To perform tasks as root, you have to logon with a regular user account and then get root privileges with su. This means you have to type two passwords each time, which is annoying. Using passwords is also a less secure way of connecting and with ESX, security is a top concern.

So, instead of using passwords, you can authenticate by using key pairs. The full process is explained in a very well written tutorial you can find here. In short, the steps are as follows:

• Generate a public/private key pair
• Put the public key on the server (ESX)
• Configure your client (e.g. Putty) to use the private key to authenticate
• (optionally) Use Pageant to avoid having to type the pass phrase to the private key each time you logon

On my system, all I have to do is to click an icon on my desktop that connects to the target ESX server. Then Putty opens and logs me on automatically to the ESX server:

If you want, you can also disable the use of passwords and require that everyone use a private key to authenticate. Less flexible, but more secure!

ESX 3.0.1 and VirtualCenter 2.0.1 can now be downloaded. The release comes with a few things such as support for some newer hardware like the Intel Tulsa processor, full support for some 64-bit operating systems and critical bugfixes. I hope that display (GUI) issues in VirtualCenter have been addressed as well.

Also in the package is improved upgrade support. See the updated guide.

UPDATE: some info about the upgrade process can be found here.