One feature in vCloud Director I’ve been aware of sometime is the ability to import VMs from vSphere. Although I knew it could be done, I’d not tried it in anger until today. Over the last couple of months I’ve been migrating away from using Citrix MetaFrame as the primary method to connect to my lab. The move was prompted by a couple of reasons:

  • The Citrix MetaFrameXP/FR3 VM has been in my lab since 2003 and runs on Windows 2003 – and was getting a bit long in the tooth. It came from the period when I was still a jobbing Citrix Certified Instructor (CCI). 
  • It occasionally had TS Licensing problems that would render it useable, despite having valid Citrix CALs.
  • I felt that now I was with VMware as employee folks might question the use of Citrix to access my personal lab in demos!

[ With all that said, I thought being able to access the legacy Citrix system by RDP/ICA might be useful if I was doing some serious work on my View environment. There’s a bit of chicken-egg thing going on here. The remote access to my lab is on View, and I could be doing work on View where could (if I wasn’t careful) wind-up sawing the very branch off that allowed the access not unlike my friend Mullah Nasruddin. Don’t get me wrong View is very resilent. I recently did a remote de-install of the View 5.2 Beta, and install of the View 5.1 GA plus the Feature Pack to gain access to the HTML5 Access methods (and Unity Touch for my iPAD) whilst connected to View. The trick was to play with the load-balancer settings to force access to SSO1>>CS01 whilst upgrading SS02>>CS02 – and then flipping the LB options (setting one of the LB to 0 disables that path) to flip the connection the other way. It also helped having two Windows 7 Desktops – so I could PCoIP to one, and RDP to the other – to upgrade the View Agent, and install the HTML Access Agent…]

But… anyway, as the great man said. I digress…

I decided to import the ye olde Citrix MetaFrameXP/FR3 box into a vCloud Director – and then use the vCNS Edge Gateway to allow TCP/1494/3389 access to it. To do the import – you must be logged into vCloud Director as the SysAdmin – and the target VM should be powered off…

Screen Shot 2013-03-18 at 12.49.17

Then you can select the VM you wish to import – specifying the vApp name; Description; Virtual Datacenter, Storage Profile and whether you want to move or copy the VM.

Screen Shot 2013-03-18 at 12.50.52

After the copy/move you may well need to review the networking of the VM. In my case this VM had been patched into the “Management” Network of my ESX hosts (and vCenter as well). So I could use it as a “jumpbox” to manage the reset of the lab. Such a configuration wasn’t valid anymore, and so wasn’t brought across.

Screen Shot 2013-03-18 at 12.55.10
Here the vApp has NO networking at all…

So I right clicked the VM, and changed its network settings – patching it into my Organization Network.

Screen Shot 2013-03-18 at 12.57.05

Doing this requires the enablement of Guest Customization to the OS. This affectively rips out any previous IP configuration they might have been, and replaces with it with an IP Address from the vCloud Director Static pool.

All I needed to do next was update the NAT and Firewall rules to enable access again. In my case 3 of my Internet IP address on my physical Juniper Firewall have been mapped to the external interfaces of my Edge Gateway. So for example 81.82.83.84 has been mapped ANY:ANY to 192.168.3.10. This affectively turns off the Juniper Firewall, and make my Edge Gateway the affective system – so by allowing DNAT rule from 192.168.3.10 to 172.168.5.10 for 1494/3389 this allows the legacy ICA Protocol and RDP protocols to work.

Screen Shot 2013-03-18 at 13.17.38

Conclusion:

One things that occurs to me is great though this import process is – it does require SysAdmin rights, and can only take one VM at time – so its not exactly geared up for multi-tenancy and bulk move of many VMs. I’ve been working quite closely with vCloud Connector recently (blogposts will soon be ready to publish) and I’m thinking that perhaps vCC with access to both the Private vSphere and vCloud Director might be slicker method of doing this sort of move. Anyway, that’s a blogpost for another time!