There has been many discussions about the future of vCloud Director and if VMware intends to deprecate it. There is not much information from VMware about its vision but recently there is a great emphasis on vCloud Automation Center for cloud management that is now embedded in vRealize Suite. It seems a great product, especially for enterprises considering that it integrates management of different infrastructures (even physical and public cloud) into a single platform; but I still have some questions when I look at both vCloud Director and vCAC in regards to service providers who offer services to completely different, critical isolated organizations. I have read this blog post by VMware that explains VMware vision of Cloud management and transition plan, but still unsatisfied!
By the way, it seems that sooner or later vCAC will be dominant solution for Cloud management and VMware will add features to satisfy different requirements rapidly. So, it’s a good time to get familiar with this product. I saw this post that is a very good practical introduction and hand out that explains and clarifies basic concepts in vCAC. There is also another simple, more detailed manual here. Of course, more information can be found in VMware documentation.
p.s – From business perspective, it’s a smart move from VMware to focus more on enterprises rather than service providers because cloud service provider market is and will be dominated by other players.
An interesting feature in vCloud Director networking is the capability of creating a fenced vApp. Basically, it’s like having an extra (in case you have one for Organization network which means routed) vShield router and firewall on the edge of vApp.
One of the coolest applications for fenced vApps is when you want to have identical machines (same IP and MAC) in your vDC; it means when you want to do a fast clone without customizing guest OS by changing IP’s and names, … In this case vApps are completely isolated while they can have connection to External networks or perhaps internet! See here for a how-to about creating fenced vApp.
After you created a fenced vApp, you will notice that the IP addresses in the vApp are in the same subnet with Organization Network (see the picture above), although a NAT gateway is operating between the vApp and Organization network. So when you want to do a DNAT (Destination NAT), there are 2 places you should configure. In the picture above, suppose you want to give access to a VM with IP 192.168.0.45 in Fenced vApp from External Network. Assume that Edge 1 got IP 192.168.0.3 (specified while fencing). First, you need to create appropriate rules in Edge Gateway of Organization Network, Edge 2 (if there is any) to NAT and open ports for the IP address of Edge 1 (192.168.0.3)
Next step, you need to do NAT and open ports from Edge 1 to specific VM but this configuration is not in Edge Gateways of vDC (unlike Edge 2) but can be found in Networking Tab of the vApp itself.
Click on the vApp, go to Networking tab,
right click on the selected network and choose ‘Configure Services’. there, you can define appropriate NAT and firewall rules.
As you may know, VMworld 2014 is going on with some big announcements. I didn’t have a chance to take part but fortunately we can find more information from a couple of active bloggers writing about new features, products and visions in VMware. So far, the interesting things to me are:
- VMware Integration with OpenStack : Apparently, VMware is less flexible for developers comparing to public clouds and VMware is trying to mitigate this gap by OpenStack.
- EVO: Rail – VMware converged Hardware : While there are some other smaller companies (VMware partners like Nutanix) who provide VMware appliances, I guess VMware sees a demand for this and wants to positively increase competition in converged hardware based on VMware. It’s also getting closer to a Software Defined Data Center. In EVO:RAIL there is a software layer which facilitates deployment of VMware ESXi’s and vCenter and managing VM’s. The interesting thing in EVO:RAIL is the use of VSAN. It’s more suitable for small to medium deployments I would say.
Having templates and cloning VM’s can be very handy for fast deployment. Suppose that you want to deploy an instance of a sophisticated Web application consisting of different functional servers like database, web, mail, messaging, etc. It is desirable to clone the whole application, saving lots of time to configure each server and establish connectivity between them. VMware enables us to do this by using vApp templates. vApp templates are also available in vCloud Director.
However, when it comes to Microsoft SQL Server, an issue is raised when you rename the server during cloning or customize operating system in vCloud! It’s because SQL server contains some internal databases (like master) and metadata that store system name and working with SQL server in this situation will cause problems. To prevent this issue, you can do the following:
1) Enable a sysadmin SQL account (like ‘sa’) before cloning.
2) After clone, login to new SQL Server using a non-Windows sysadmin (like ‘sa’)
3) issue the following commands in a Query window:
exec sp_dropserver ‘OldserverName’
exec sp_addserver ‘NewServerName’, ‘LOCAL’
4) Restart SQL Server services
As virtualization and cloud are getting more common, deploying more and more servers is really tempting for companies because it’s easier and needs less cost.
However it brings the subject of managing servers into attention. System administrators now should find solutions to decrease the time of deployment and applying changes in configurations and fixes. Under the influence of Cloud and Virtualization, business and product owners expect quick reaction from IT department; although cloud and hypervisor infrastructures provide easy and quick ways to deploy servers but still there are many tasks that require novel ideas to be automated and here is where sort of coding and logic meets system administration.
There are some tools designed for this purpose. Web giants like Google and Amazon have long used software that automatically configures the vast collection of machines driving their online services. But as Luke Kanies (CEO and Founder of Puppet Labs) says: “Google does [things] differently, and in many cases, they do it better. Amazon is the same way. But what’s really frustrating is that no one else can use their software, I wanted to build a tool that would help other companies solve the same problem.”
Among them, Puppet is getting more attention and recent investments from big IT groups like VMware and Cisco make it attractive for companies who use virtualization and cloud. By the way, if you are a system administrator, sooner or later you will see the need for using either Puppet or any other management and automation software. Get ready!
One of the great features in vCloud Director is client’s capability to customize general specifications of a VM. Specifications like Hostname and more importantly IP address(es). Customer can even have some scripts for more advanced customizations like joining to a domain, … All these depend on ‘Guest OS Customization’ feature that should be enabled on a VM. Not all the operating systems support ‘Guest OS Customization’. For a list of supported OS’s in vCD 5.x see these links:
– Supported guest operating systems in vCloud Director 5.5
– Supported guest operating systems in vCloud Director 5.1
As you can see, there is no support for Debian Linux! What a pity! If you deploy a Debian and want to change its IP through VM Properties in vCD portal, it will give you an error:
“Guest customization is not supported by the selected OS. Please disable guest customization to proceed.”
Debian is a great OS and many clients may get disappointed! But fortunately, there is a simple work-around for it: change the Operating System type to: Other Linux and Guest Customization will be fine! Of course, try to choose the closest kernel version, for example choose ‘Other 2.6.x Linux (64-bit)’ for a Debian wheezy with kernel 3.2.0-amd64.
By this change, modifying Hostname or assigning IP addresses, Gateway, DNS to Debian NICs would be possible like any other supported OS.
Providing VPN access to vCD customers is a great idea, because usually customers are behind a vCloud created firewall and most likely you created a routed organization VDC network to connect them to external network. So, how they have to get access to their VDC? One approach could be to define different sets of firewall and NAT rules for required access ports (SSH, RDP, …) but when the number of VM’s grow, this would be less flexible but of course still doable. Even a customer can get access to only one VM and go through this single VM to access the others; however sometimes it’s not a simple remote access and remote user wants to do a more advanced task.
By the way, I don’t want to go into the details of benefits of having a VPN for remote clients but it seems like a very helpful facility for cloud customers. We can leave it to the user to install its own VPN server to tunnel through to get access to organization VDC network but VMware provides this excellent capability to setup VPN gateways in vCloud Director or vSphere Cluster. For a Site-to-Site IPsec VPN, VMware vCD is pretty much straight forward. So, if you have a VPN gateway in place, easily you can establish a tunnel between your local network and your organization network in the cloud. I found this guide about setting up an IPSec tunnel in vCloud Director with useful examples, one with a Cisco WAN router. Here is another guide for a Cisco PIX and vCD; although the vCD version is old (1.5) but it’s too similar in terms of VPN tunnelling.
However, if you don’t have a VPN endpoint in-place and still want to establish a secure VPN-connection with your vCD organization network as a remote user, VMware provides this brilliant SSL VPN utility. It’s not as straight forward as IPsec VPN and it’s not present in vCD web portal but it worths deploying (especially for customers). VMware SSL VPN should be configured in vCloud Networking and Security solution (which is a new name for vShield Manager).
I’m not writing a How-To for this here and a complete step by step guide can be found here, very well explained by Ranga Maddipudi. I just wanted to give some idea and as you can see, deploying a SSL VPN gateway is fairly easy and an installable file (.exe file for Windows) will be provided. To get this file, on the client side use should use the browser to download the file. The URL for downloading the package would be: https://external-ip-address-of-gateway:443
After getting the file, user can easily install the VPN client and that’s it.
Running the application and entering the right credentials, VPN connection will be established and given that the configurations are server side are well defined, remote user will get access to VDC organization network in the cloud. In fact, what excites me is that from engineering point of view, VMware did a great job to ease the whole procedure of setup a connection on both server and client side; in specific, generating a custom designed VPN client using SSL (as authentication and encryption protocol) VPN is a brilliant idea.