vmware

You are currently browsing the archive for the vmware category.

Converting a linux server on the internet to VM behind firewall

10:03 am, February 15, 2010 in vmware | 1 comment

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:

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:

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.

Tags: , , , , ,

Blades vs. rack servers for virtualization

10:32 am, October 14, 2009 in tech, vmware | No comments

Occasionally I am interviewed for articles about VDI or Virtualization in the healthcare field, but this is the first time I have been asked to contribute to the article myself!

Nothing inspires debate among IT managers like the question of which server hardware platform to choose for their virtualization deployment. On one hand, some organizations opt for generic rack servers, which typically feature a lower entry cost, and do not require any modifications to a data center’s power supplies.

Other IT managers feel that the benefit of the centralized management console offered by blade servers is great, and that the integrated blade enclosure provides important power, cabling and infrastructure efficiencies that IT managers grappling with cramped data center quarters cannot afford to pass up.

In this face-off, two seasoned IT professionals and virtualization architects debate rack vs. blade servers, explaining the benefits of each architectural choice in a virtual environment.

Rick Vanover: Server racks the way to go
Chris House: Blade servers always win

via Blades vs. rack servers for virtualization. (Free registration required)

Rick makes some good points in why rack-mount servers may be a better choice for a virtualization platform, but I’m sticking with blades for sure, partially because we have already absorbed any start-up cost in purchasing enclosures and infrastructure components, and if we went with rack-mount servers, we’d have to get a dozen or so more racks in the datacenter which would all contribute heat and suck up power.

As with any infrastructure choice, your mileage may vary and a cost/benefit analysis must be done to see which solution will be more financially appropriate given the initial and ongoing cost, as well as growth opportunities.

Tags: , ,

Published: VDI adds new wrinkle to data center storage management

10:18 pm, September 30, 2009 in metro, vmware | No comments

Got myself interviewed and mentioned in another VDI article, Virtual desktop infrastructure adds new wrinkle to data center storage management, though this one for some reason pegs me as being at The MetroHealth System in Cleveland. Oh well. I emailed the correction but got an out-of-office auto-reply.

One administrator in a large VDI environment said his IT staff still doesn’t back up desktop data, though it lives on data center storage. “If an individual desktop goes down, we’re just going to assign the user to a new one and reinstall their applications,” said Chris House, senior network analyst at The MetroHealth System, a hospital network based in Cleveland. MetroHealth uses 1,500 VMware virtual desktops and stores data on a Hewlett-Packard Co. StorageWorks XP1024 high-end disk array.

House said the initial VDI deployment was done using a midrange HP StorageWorks EVA8000 array, but with more than a thousand desktops, the IOPS required pushed it up to tier 1 storage. “The VDI environment was averaging between 4,000 and 9,000 IOPS most of the time, but once a week at 2 a.m. it would spike to 40,000 IOPS,” he said.

The spike was accounted for by an inventory scan process that involved all the desktops. “The [XP] array can handle it, but you lose some ROI going with more expensive storage,” House said.

We are also mentioned in a new VMware case study on VDI and there’s still that video…

Tags: , ,

Published: Virtual desktop infrastructure case study: Metro Health

5:50 am, March 17, 2009 in metro, vmware | No comments

Virtual desktop infrastructure case study: Metro Health

The storage issues that are more critical in a VDI environment include capacity planning and management and performance, as illustrated by a case study of early adopter Metro Health, an independent health care system serving the greater Grand Rapids area and western Michigan.

via Virtual desktop infrastructure tutorial: Part 1 .

A very excellent two-part article (though Metro is only featured in the first part) based on content from an interview I gave to SearchStorage back in February regarding our experience with VDI and the storage issues/expense we have encountered.

Tags: , , , ,

Changing VM host isolation response in ESX 3.0 & VC 2.0

9:55 am, January 5, 2009 in vmware | No comments

I had a need to change the host isolation response of all the VMs in a VMware ESX cluster. The ESX hosts are 3.0.1 and the VirtualCenter server is 2.0.2.

Since the beautiful VI client only allows changing one VM setting at a time, it would take forever to change all 1,500 VMs that I need to adjust across 4 clusters and 2 VC servers.

Powershell scripts turned out to be the answer. Here is a script that will change the isolation response to “Leave powered on” by changing the property powerOffOnIsolation to false. This script only works against VirtualCenter 2.0.x. For a script that works against VC 2.5, check out this post in the VMware forums.

If this script doesn’t work, make sure you change the “Connect-VIServer” line to connect to the proper hostname, and the “Get-Cluster” line to use the proper cluster.

Also, if the VC task fails saying “a specified parameter was incorrect”, try changing the Operation to “edit” instead of “add”.

Connect-VIServer vdi_vc_bdc
$cs = Get-Cluster "Cluster4"
$csadv = get-view $cs.id
$allvms = $cs | Get-VM

$i = 0
$csspec = new-object VMware.Vim.ClusterConfigSpec

foreach ($vm in $allvms) {
  $csspec.dasVMConfigSpec += new-object VMware.Vim.ClusterDasVmConfigSpec
  $csspec.dasVMConfigSpec[$i].info = new-object Vmware.Vim.ClusterDasVmConfigInfo
  $csspec.dasVMConfigSpec[$i].Info.Key = ($vm | get-view).moref
  $csspec.dasVMConfigSpec[$i].Operation = "add"
  $csspec.dasVMConfigSpec[$i].info.powerOffOnIsolation = $false

  $i++
}

$csadv.ReconfigureCluster_Task($csspec,$true)

Good luck!

Tags: , ,

« Older entries