With contributions from: Massimo Re Ferre, Eric Fulton, Tomas Fojta, Ray Budavari, Jesse Schachter, Kyle Smith, Francois Misiak, Benham Chia, Ranga Maddipudi, Trevor Gerdes and Ben Byer
We hope you enjoy this month’s vCloud Suite Digest. This is where we take some questions that we get and disseminate the answers in the hopes that it will help someone else who might have a similar question. This month, we have some great tidbits on guest OS clustering, elastic VDCs, and networking among other things. Enjoy!
With thanks to many sources including: Michael Haines, Jesse Schachter, Zach Shepherd, Vegard Sagbakken, Trevor Gerdes, Michael Haines
Hello and welcome to the third vCloud Suite Digest, a compilation of common technical questions and answers on vCloud Suite architecture and implementation. Behind us is a legion of people a group of people far too numerous to mention (for us these are the unsung heroes of VMware) who provide definitive answers and guidance. People fixing problems on a daily basis, that don’t get half the spotlight that jumped up evangelists do. In this months edition we cover such topics as:
vCloud Director Database Encryption
vCloud Director Database Settings
vCloud Director and NFS Transfer Share
vCloud Director: Maximum Number of VMs
vCloud Director: Sticky Sessions
vCNS Edge Gateway: vNIC Maximum
vCNS Edge Gateway Load Balancing
vCloud Connector: Copying vApps from vCD 1.5 to 5.1
In case you haven’t read the post here already, there’s a great screencast available that demonstrates how to use the vCloud metadata policy descriptors and mechanisms to trigger the enforcement of policies in a cloud environment.
This screencast highlights several products included in the vCloud Suite, such as vCloud Director (vCD), VMware vCloud Networking and Security, and VMware vCenter Orchestrator (vCO). Additionally, it also demonstrates how someone can leverage VMware vCloud Automation Center (vCAC) to provide more governance around policies within cloud environments.
Overall, this is a great example of how you can leverage several of the components contained within the vCloud Suite in your environment. If your interested in finding out more about the products shown in this screencast, or any of the other products that are contained within the vCloud Suite, you can visit the vCloud Suite page on VMware.com.
After many months of hard work, VMware has helped make a vCloud Director plugin for BOSH available today.
BOSH (BOSH Outer Shell) is an open source tool chain designed for supporting release engineering and the deployment and lifecycle management of large scale distributed services. Originally, BOSH was developed to support the Cloud Foundry Application-as-a-Service. One of its advantages however is that the framework is built to be generic in nature and abstracted from any single Infrastructure-as-a-Service (IaaS) offering. This allows distributed services to be deployed on multiple Infrastructure-as-a-Service offerings, such as VMware vSphere, Amazon Web Services, or OpenStack.
Cloud Foundry leverages BOSH to provide an open Platform-as-a-Service (PaaS) offering. By being open, Cloud Foundry provides users with the ability to choose different cloud services, developer frameworks, and application services to suit their needs. Ultimately, Cloud Foundry makes it easier to build, test, deploy, and scale applications and decrease the time associated with these activities.
You can read more about this on the Cloud Foundry blog here:
VMware just released a update for vCloud Director. The vCloud Director 1.5.2 release notes can be found here.
You’ll notice that there are several fixes included with this release. Some of which include:
Cannot upload an OVF as a vApp template
In vCloud Director 1.5.1, when you upload an OVF file as a vApp template, the upload could fail. In some circumstances, vCloud Director would choose a network that is not accessible to the resource pool to which the OVF is uploaded, resulting in the failure. This issue is resolved in vCloud Director 1.5.2.
The UI freezes when using a non-English client browser to connect to vCloud Director
In certain circumstances, the vCloud Director 1.5.1 UI could become unusable when viewing log events from a non-English client browser. This issue is resolved in vCloud Director 1.5.2.
Two vApps within an organization can have the same name after upgrading vCloud Director
After upgrading from vCloud Director 1.0.x to 1.5 or 1.5.1, you are able to create a vApp with the same name as another vApp in an organization. This issue is resolved for vCloud Director 1.5.2, which ensures that each vApp within an organization has a unique name.
IP addresses not being released for reallocation
Released IP addresses were not cleaned up in vCloud Director 1.5.1, even after the IP address release timeout. The IPs were cleaned up only during the vApp creation workflow and not during the workflow of adding IPs to the list of external IPs for an organization network. vCloud Director 1.5.2 fixes this issue.
Guest customization issues
In vCloud Director 1.5.1, when performing guest customization on a virtual machine, network configuration was performed after sysprep. As a result, virtual machines were not able to access a network during customization. vCloud Director 1.5.2 fixes this issue.
This is just a small sample. I’d invite you to read the release notes for more details. The binaries are available from the usual places.
As a provider of public cloud services, it is very desirable to establish multiple tiers of service that can be delivered to customers. This helps in the establishment of pricing models and extends choices to the customers for performance. Private cloud administrators have the same need, though for a slightly different reason. Instead of using service tiers to establish a payment model, private cloud admins use service tiers to more effectively allocate resources to the organizations within the enterprise.
With the 5.1 release of vCloud Director, it is now possible to define multiple tiers of storage easily though the use of the storage profiles feature. Continue reading →
VMware currently has a beta program available for the VMware vCenter Support Assistant. This product is designed to help customers accelerate the support process when they have issues by allowing them to open support cases and automatically collect and send diagnostic information to VMware right from their vSphere client.
There’s a lot of information on the functionality of the VMware vCenter Support Assistant on the TAM blog here. If interested, you can sign up for the beta here and it will run through from now until mid-December.
With the release of vCloud Director 5.1, it is now possible to take advantage of snapshots. This highly requested feature allows you to capture the state of a VM or vApp at a particular point of time. At a later time, you can then revert back to the snapshot.
This is great for environments where you are performing destructive testing or are experimenting with something as you can quickly return to a baseline.
The snapshot functionality works for both virtual machines and vApps. In the case of vApps, a snapshot request will create snapshots for all of the virtual machines within that vApp. It works with both powered on and powered off VMs. You also have the ability to snapshot the disk and the memory contents as well.
Currently, it does not support multiple snapshots however. This means that if you have a existing snapshot and then take another, the previous snapshot will be overwritten. Users of Workstation where one can have a tree of snapshots may find this somewhat limiting, but it can only get better in the future. Snapshots also do not save the network config. You’ll notice that after you take a snapshot, the ability for you to change the networking settings is disabled. The reason for this to avoid any issues where one tries to revert a snapshot back after changes to the network have taken place, thereby causing things not to work.
For a demonstration of the snapshot feature in vCloud Director 5.1, the following short video will show you how easy it is to use.
Today, VMware has released vCloud Director 5.1.1. This minor release has a few important updates, including:
The vCD Appliance now has sets net.ipv4.conf.all.rp.filter = 0 in the /etc/sysctl.conf file. This fixes an issue with a loss of network connectivity that was observed with the 5.1 release.
Snapshots were unnecessarily created. This occurred when fast provisioning was enabled and a copy of a vApp template across datastores was performed.
An exception would be generated in cases where an external network was created without any available DVportgroups. The exception returned would look similar to:
HTTP ERROR 500
Problem accessing /cloud/. Reason: could not load an entity:
Some changes were introduced into the Allocation Model with vCloud Director 5.1 to enable elastic VDCs. With these changes, some customers had issues if they configured the vCPU to Mhz mapping too low which would result in VM performance issues for some initial VMs in the resource pool as the limit is set too low. If these same customer set the vCPU to Mhz mapping too high it would result in limiting the maximum number of VMs that can be provisioned in the pool significantly.
There have been some changes to assist our partners in the development of solutions. This includes enhancing the ability to insert 3rd party services on VXLAN networks, and other minor fixes.
One of the outstanding enhancements provided in the vCloud Director 5.1 release was the ability to select between two different deployment models of the Edge Gateway. It is now possible for you to deploy the Edge Gateway in a Compact or Full model, with the difference between the two being the performance they provide and the amount of resources they utilize.
But did you know there is a third Edge Gateway deployment model called X-Large?
If you use your vSphere Client and under the Network Virtualization tab for the Datacenter Object you try to add a Edge Gateway, you’ll see that there are three possible selections:
If you’ve already deployed vCloud Director 5.1 however, you may notice that you are only able to select between the Compact and Full models. What happened to the X-Large model?
The answer is pretty simple: The X-large model of deployment for the Edge Gateway is not supported with vCloud Director 5.1 currently. As the picture above shows, the X-Large deployment model has some limitations, such as a lack of SSL VPN support.
Can you possibly get this super-sized Edge Gateway to work? Possibly. Again though, it is not supported at the current time with vCloud Director 5.1.