CSH.us

As an experiment, I wanted to see if I could convert and Internet-based linux host in to a guest VM on my internal ESX cluster. That’s right, the target host for converting is an Ubuntu Linux server out on the internet (located across the state) used for hosting a few dozen websites.

The destination is my internal ESXi host which is behind a firewall. My PC which is also behind the same fierwall will act as the Converter Standalone Client and SSH tunnel manager. We can connect out to any port on the Linux Internet host (most importantly SSH and 443) but it can’t connect back to us. Physically dealing with the linux host (such as booting off a Converter CD/ISO) is out of the question given its remote location. This will have to be a hot-clone.

Here is the process – my apologies for the rough descriptions, I needed to get this written out before I forgot everything, and now that the conversion is finally running, it hasn’t finished yet so I haven’t been able to re-run it and capture screenshots.

Hosts involved:

• linux01 (source host out on the Internet)
• esxi02 (internal ESXi v4 target host behind the firewall)
• pc03 (internal PC which will run the Converter Standalone Client and SSH tunnels behind the firewall)
• Helper VM (internal VM created during conversion on esxi02 with same hostname as linux01)

Software needed:

• VMware Converter Standalone agent/server
• Bitvise Tunnelier (free for personal use, easy SSH tunnel manager)

First, download and install the Converter Standalone agent/server on linux01. See this post, How to P2V linux into VMware ESX Server for the installation.

• Don’t install the client
• Accept most defaults
• Change the HTTP proxy port to something else
• Change the HTTPS proxy port to something else

After installation, follow these KB articles to enable logging in to the Helper VM and preventing shutdown of the helper VM when the task finishes:

• Enabling Logging in to Helper Virtual Machine During Conversion of Powered-On Linux Sources
• Disabling Automatic Shutdown of Helper Virtual Machines After Converting Powered-On Linux Sources
• You’ll need to kill the running agent for these changes to take effect. The agent will get restarted when the GUI connects in to start setting up the conversion process.

After the agent is installed and running, open a web browser on pc03 and visit linux01’s Converter agent SSL-enabled website port that you chose during the installation. You should be presented with a webpage that allows you to download the Converter Standalone Client for Windows. Download and install it on pc03. I had to uninstall Converter Enterprise before this would install successfully. Just do a typical installation and install the GUI only, not the server/agent.

After the Client is installed, also install the Tunnelier SSH client on pc03.

On pc03, Launch vCenter Client to esxi02 and login as root.

Also on pc03, SSH to linux01 and run tail -f /var/log/vmware-vcenter-converter-standalone/vmware-converter-agent.log

Within Tunnelier, setup an SSH connection to linux01. Make sure to use the right SSH port if you’ve changed it as I have from the default of 22 to something else to foil automated password guessing bots. Make sure to login as root because we’ll want to set up listening SSH tunnels for port numbers less than 1024.

Click on the S2C Forwarding tab for Server to Client forwarding. On this tab, “Listen Interface” is the IP address of the interface on linux01 that we will listen on, and “List. Port” is the port to use. “Destination Host” is the destination hostname/IP behind the firewall as pc03 sees it, so it can be an IP or a hostname, and “Dest. Port” is the port on the destination host to connect the other end of the tunnel to.

Set up three tunnels:

• 127.0.0.1:8999 to esxi02:443
• 127.0.0.1:902 to esxi02:902
• 127.0.0.1:443 to Helper VM:443 (be sure to grab a static IP address that is not in use and plan to use it for the Helper VM. Also note that this method will need to use port 443 on linux01 so SSL-enabled Apache will have to be shutdown or just not used for SSL during the process)

Connect Tunnelier and make sure all the port forwarding requests are accepted in the status window at the bottom. Requests may be rejected if the Listen Port is already in use on linux01 by another process. Unfortunately, only the port 8999 in this procedure can be changed. The listen ports 443 and 902 must remain those numbers, so if there is a process interfering with those ports, it will have to be stopped.

Launch Converter Standalone and click on the “Convert Machine” button in the toolbar. Leave “source type” as “Powered-on machine”. Select “A remote machine” and enter the Internet IP address or fully qualified DNS hostname of linux01. If you have changed the SSH port away from the default of 22, enter the IP/hostname as “hostname:port” where port is the non-standard SSH port. Login as root with linux01’s root password and make sure “OS Family” is set to Linux. Click Next.

In the “Specify Destination” step, specify the ESX Server as “localhost:8999″. This is for the Converter agent on linux01 to use to communicate through the SSH tunnel that we set up to listen on 8999 and point to esxi02 port 443. Enter a valid user on esxi02 (such as root) and its password, and then click Next.

Customize the Virtual Machine as necessary changing the VM name, destination datastore, and VM hardware version. I left the hostname the same as the linux01 server and Datastore was just a local vmfs datastore with sufficient room. I also left the vm at Version 7. Click Next.

In View/Edit Options step, edit the “Data to copy” task and resize the linux01 volumes as necessary. Possibly set them to be thin provisioned instead of thick.

Adjust Processors and Memory as necessary.

Make sure Networks has at least two NICs even if you don’t have two on linux01 and won’t need two on the final guest VM. We need two in order for the Helper VM to be able to communicate with the source server and fool the source server in to using 127.0.0.1 as its connection to the Helper VM so we can use an SSH tunnel.

Make sure under Advanced options that any power on/off are set to no and Reconfigure is set to yes (makes the VM bootable).

Edit the Helper VM network and set the following:

• Use the following IP address
• IP Address: 127.0.0.1
• Subnet mask: 255.0.0.0
• Default gateway: (the default gateway that a VM on esxi02 would use normally)
• Preferred/Secondary DNS servers (the preferred/secondary DNS server IPs that a VM on esxi02 would use normally)
• This combination of settings may not make any sense now, but we need the agent on linux01 to think the IP of the Helper VM is 127.0.0.1 so we can redirect localhost:443 through a tunnel to the real Helper VM. It doesn’t matter that the default gateway and DNS do not correspond with the 127 network.

Click Next, review the choices and click Finish. The task will now start.

Watch the tail of vmware-converter-agent.log on linux01 to see what the agent is doing and what it’s trying to connect to.

Also make sure to watch in vCenter client for when the Helper VM gets created (using same name as linux01 hostname).

As soon as the helper VM has been created, open the console for the VM and watch it boot. After it gets up to the login prompt, login as root. The password is the same as linux01’s root password (convenient eh?). You must be quick because the agent on linux01 will only retry the connection so many times before it fails.

Now the helper VM will have two NICs assigned since we set that earlier during task setup. The first NIC (eth0) will be set to the Helper VM IP that we set during task setup (127.0.0.1, and it doesn’t seem to matter that the loopback adapter lo0 also has this IP set). The 2nd nic will not be activated. So while the agent on linux01 is trying to connect 127.0.0.1:443 (and reidrected through the SSH tunnel which will be complaining at you that it can’t connect to the helper VM), we need to set up eth1.

Make sure /etc/network.conf has USE_GATEWAY set to “yes” and GATEWAY set to the default gateway that a VM on esxi02 would normally use. Then in /etc/network.d, make a copy of template.interface.eth0.static and name it interface.eth1. Edit interface.eth1 and set INTERFACE to “eth1″, make sure DHCP is set to “no” and then set IPADDRESS to a valid static IP address that a VM on esxi02 could use. Also set a valid NETMASK for this address. Leave BROADCAST blank. Save and close the file and then run “service network restart” to restart networking on the Helper VM which will also enable eth1. Ping the default gateway from the helper VM and make sure it’s pingable. Also ping the helper VM from pc03 and make sure it’s pingable.

Make sure that the SSH tunnel in Tunnelier for 127.0.0.1:443 is connecting to the correct internal static IP of the Helper VM (eth1) on port 443. If you need to Logout of the connections that Tunnelier has set up, be quick about it or the task will fail since the connection was lost between the agent and the hosts behind the firewall.

Make sure the Helper VM can resolve and connect directly to linux01 out on the Internet through the port that sshd listens on. Make sure the firewall does not block outgoing connections from Helper VM to this internet host.

The agent on linux01 should have noticed by now that it can now connect to 127.0.0.1:443 and get to the Helper VM (through the SSH tunnel) so the conversion task should continue by formatting the disks in the Helper VM. After this, the Helper VM will connect out over the Internet through SSH directly to linux01 to start importing the filesystems. It will not use the SSH tunnels that we set up earlier but will directly connect out to the host. This is why DNS resolution is important and the firewall should not block the Helper VM’s attempts to reach the internet host.

The agent log at linux01:/var/log/vmware-vcenter-converter-standalone/vmware-converter-agent.log will be periodically updated every few minutes entries indicating the percentage of filesystem transferred and the transfer rate.

This configuration can be complicated and there are a lot of places that the task could get hung up and fail to connect, but just pay close attention to vmware-converter-agent.log on linux01 and you’ll spot the problems pretty quickly.