This little known fact came up already twice recently so I will write just a short post about it.
In the past when you created allocation pool Organization Virtual Datacenter (Org VDC) and allocated to it for example 20 GB RAM it actually did not allow you to deploy VMs with total memory sum of 20 GB due to virtualization memory overhead being charged against the allocation as well. This behavior forced service providers to add additional 5%-15% to the memory Org VDC allocation. This was also very confusing for the end users who were complaining why their VM cannot power on.
With the elastic allocation pool VDC changes which came with vCloud Director 5.1 it is no longer an issue. The reason is that in the non-elastic VDC it is vSphere (and Org VDC resource pool object with a limit set) who does the admission control – i.e. how many VMs can be deployed into it. In the elastic VDC it is actually vCloud Director who is responsible for the decision if a VM can be deployed into particular VDC.
So to sum it up: if you use elastic allocation pool the tenant can use it up to the last MB. The virtualization VM memory overhead is charged to the provider who must take it into account when doing capacity management.
Just found out there is a known issue with removing datastores in and out of datastore clusters. In vCloud Director 5.1 this was working fine. vCloud Director refers to storage via storage policies (formerly profiles) so you could on-the fly change the datastore cluster structure (as long as all datastore inside had the same storage policy).
However in vCloud Director 5.5.1 if you move a datastore in or out of a datastore cluster, vCloud Director will loose it. The fix is described in KB 2075366 and involves clean up of vCloud Director database inventory data.
I was asked by a customer how to use a VXLAN network as an external network in vCloud Director. I thought there was already written blog article about it bud did not find any. So writing the answer here will benefit hopefully others as well.
First questions would be why would you do it? Aren’t vCloud Director external networks supposed to be the way to connect internal vCloud networks (usually VXLAN based) to the external world via VLAN based networks through a Edge Gateway device? Yes, but there are a few use cases for use of VXLAN network as an external network.
- Usage of different virtual edge router other than vShield Edge that supports needed features (IPv6, dynamic routing protocols). In picture below you see virtual Fortigate router in place of vShield Edge. The router is deployed manually and its internal interface is connected to a VXLAN network (again created manually) which acts as external network that is directly connected to OrgVDC network. This helps saving VLANs which are usually scarce resource in service provider environment.
- Service network spanning multiple pods crossing L3 boundaries. Each pod (cluster) has its own L2 networking so VLAN cannot span all clusters. However VXLAN can. So service network (for example syslog or monitoring network) can be used by any VM in any rack. See this article how to secure such network in multitenant environment.
Although you can easily manually create a VXLAN network directly in vShield Manager (or in vSphere Web Client if you use NSX) you will not see the VXLAN portgroup in vCloud Director GUI.
The fix is simple. vCloud Director is filtering out all portgroups that start with ‘vxw’ string. Rename the portgroup in vCenter Server (remove the string) and you will be able to select the portgroup as an External Network.
I had a question if there is a way to download vCloud Director VMware Remote Console plug-in without the need to actually log in into vCloud Director. For example in order to prepare desktop images for your vCloud users.
Yes, it is possible and here are the links for vCloud Director 5.5:
where vcd-url is the vCloud Director endpoint address. For example in case of vCHS the link looks like:
https://XXX.vchs.vmware.com/cloud/vmrc/VMware-ClientIntegrationPlugin-5.5.0.exe (replace XXX with your particular cloud instance name).
I was always bothered by slow performance of my lab installation of vSphere Web Client (version 5.5). Although my lab is small I have large number of plugins. I use the Windows installable version which is running together with vCenter, Inventory service, Update Manager and database server.
I noticed that the Java process was using over 1 GB of RAM. The fix was simple – add more memory to the VM and to Web Client Tomcat server:
Edit wrapper.conf file which is located in C:\Program Files\VMware\Infrastructure\vSphereWebClient\server\bin\service\conf.
in the JVM Memory section. I increased the value to 3072m.