In this article, Paul Angus Cloud Architect at ShapeBlue looks into a few interesting settings when using CloudStack to orchestrate VMware environments
Working with CloudStack 4.3 and VMware 5.5 in our lab recently, I came to using some very interesting global settings which renewed a project I had on the back burner…
This global setting changes the VM name as seen in vCenter or on the ESXi host. Instead of the VM appearing as i-34-1234-VM, which is the account ID followed by the sequential VM number, the VM will appear with the name given to it when creating the instance i.e. SB-TestVC01. In a public cloud this could be a bit of a nightmare as each name has to be unique, but in a private cloud it makes a lot more sense to see VMs with the same naming convention as in the rest of the environment.
The biggest thing to note about this global setting is that the default is ‘true’ meaning that when using VMware, guest instances created from templates are full copies of the original template, not simply difference disks (deltas), as opposed to XenServer which isn’t currently configurable and always creates linked clones of the template.
If the speed of deployment and primary storage usage are your main concerns then you may want to change this setting to ‘false’ as less data is written to disks.
However there are the potential issues with linked clones:
1. As the original template is a parent of all instances based upon that template, then you have a single point of failure, which, if it becomes corrupted will make all of the VMs based on that template instance also corrupt.
2. There is a performance loss when the hypervisor has to figure out which (parent) file a disk read has to be performed on.
3. Rescuing VM disks from messed up storage becomes extremely tricky because the vDisk is not in one handy piece.
If these are a concern, then leave the global variable as it is.
This setting is very exciting for those of us who build a lot of testing and teaching environments. For the uninitiated, nested virtualisation is the ability to run fully functional hypervisors as virtual instances. It requires certain features on the processor and chipset, and I dependant on the version of ESXi/vCenter you’re running, but if you have those features you are able to deploy virtual KVM, XenServer, ESXi, Hyper-V instances.
Using a ‘parent’ CloudStack, you can then deploy these hypervisors and virtualised CloudStack management farms (with a bit of configuration management wizardry) from templates, all within self-contained VLANs on these ESXi ‘super-hosts’. Deployment of environments is now a whole lot quicker and easier…
However we’re still missing an element, and that is being able to create interfaces which allow packets which have been VLAN tagged by a virtual host to pass through to other virtual hosts. This is required if we want guests on different hypervisor hosts to be able to communicate with each other.
So what we want is our parent CloudStack to set the port group on a vSwitch of the ESXi super-hosts to trunk VLANs between virtual hosts. As it happens, ESXi uses the VLAN ID 4095 as the ‘code’ for ‘trunk all tagged VLAN packets’. So if you create a shared network with a VLAN ID of 4095, then connect the guest interfaces on your virtual hosts to that network and they’ll pass your virtual guest traffic.
About the author
Paul Angus is a Senior Consultant & Cloud Architect at ShapeBlue the leading independent CloudStack integrator & consultancy. He has designed numerous CloudStack environments for customers across 4 continents, based on Apache Cloudstack ,Citrix CloudPlatform and Citrix Cloudportal. Paul has spoken at all Apache Cloudstack collaboration conferences and is an active contributor to the CloudStack community. When not building Clouds, Paul likes to create scripts that build clouds……..and he very occasionally can be seen trying to hit a golf ball.