When it comes to security there is always the concerns about the security of the ESXi hypervisor. Its always the hypervisor that is nominated as the layer that can’t be trusted within the IT infrastructure. The whitepaper by Mike Foley tries to give you more insight on how the VMware ESXi hypervisor from a security perspective and what things to look at when securing the hypervisor.
The topics covered in the white paper are:
Secure Virtual Machine Isolation in Virtualization
Backup is hot topic when discussing your vCloud Director architecture setup. Until recently there was no real integration with vCloud Director and most backup vendors. Most of them could backup vCloud vApps, but did so without the metadata that is required to restore the vApp in the vCloud (i.e. which organization, which organizational vDC, etc.)
Over the last period several vendors have come up with an vCD 5.1 integrated solution, which is of course great for everybody running vCloud Director.
More information on backing up vApps for vCD Tenants can be found in the VMware whitepaper here.
Most backup products use vStorage API for Data Protection (VADP). VADP uses snapshots to create backups of running virtual machines in a vApp. This is were it becomes challenging. vCloud Director 5.1 will only support one snapshot (see here for more info).
So what happens when VADP takes a snapshot?
The snapshot action by VADP will commit the already existing snapshot of the virtual machine. This results in a single VMDK being backed up to the backup solution. In the event of a restore the backup solution will restore the consolidated virtual machine. The last state known, but without the snapshot.
Take this into account when designing your vCloud Director backup solution. Ask your backup solution provider what the backup solution does in the event that it recognises a snapshot. For now it would be better to skip / create a warning in the event of snapshot detection within vCD.
VMware has announced the release of the new vSphere 5.1 solution. Together with this new release, VMware has also announce it’s new VMware vCloud Suite 5.1 licensing model. This model combines multiple components (vSphere Enterprise Plus, vCloud Director, vCloud Networking and Security, etc.) into a single product with a single license. All virtual machines running on a properly licensed vCloud Suite processor can use all components included in that vCloud Suite edition.
Licensing per processor
As mentioned above the licensing unit takes place per-processor. VMware no longer limits it’s customers physical resources and on the number of virtual machines!!! VMware has listened to the VMware Community and no longer applies the vRAM principle. Or like other call it, the vTax. The VMware vCloud Suite 5.1 is licensed per physical processor. With all physical processors licensed in a server a customer can run all VMware products on top of this server that are licensed within the bundle.
vCloud Suites Editions
There are 3 editions available for the vCloud Suites :
1. VMware vCloud Suite Standard; vSphere Enterprise Plus, vCloud Director, vCloud Connector & VMware vCloud Network and Security Suite Standard.
2. VMware vCloud Suite Advanced;vSphere Enterprise Plus, vCloud Director, vCloud Connector & VMware vCloud Network and Security Suite Advanced and vCOPs Advanced.
3. VMware vCloud Suite Enterprise; vSphere Enterprise Plus, vCloud Director, vCloud Connector & VMware vCloud Network and Security Suite Enterprise, vCOPS Enterprise, vFabric Application Director and SRM.
So what’s the deal?
In my opinion VMware tried to simplify the whole licensing part of building a vCloud solution. Most customers that build a private cloud in general want to build such a vCloud solution in an easy manner, but it also needs to be easy to manage, must be monitored and should work in case of a disaster.
All of these components are in the bundle that is licensed with vCloud Suite Enterprise edition. An easy licensing path on the road to your own private vCloud. Most companies already have VMware vSphere licenses and VMware also provide an upgrade path toward the new VMware vCloud Suite licenses. For upgrading VMware has introduced the Fair Value Conversion Program that can be found at http://www.vmware.com/go/ vcloud-suite-licensing.
A vApp is a container in vSphere. It works the same way as a resource pool, but has extra options that help define a more structured approach to hosting virtual machines. With vApps you can build application stacks of virtual machines that have a relations with one another.
The most common example is always the three tiered app; a webserver, application server and a database server. With a vApp these virtual machines can be grouped together and besides grouping them together you can also control the startup order of the VMs in the vApp and allocate a specific amount of resources to the vApp.
Note : vSphere vApps are not the same as vCloud vApps! Both group workloads together, but they are not the same thing.
The allocation of resources for a vApp works with the same construct as that of a resource pool. The vApp can be allocated a specific amount of CPU and RAM resources. By default the vApp is set to unlimited and resources are expandable if needed, just like a resource pool. These settings can be changed in the same way as with normal resource pools. Reservations, limits and shares can be defined on a vApp level and can help to allocates resources depending on the requirments of the application stack.
VMs in a vApp share the resources that have been allocated to the vApp only with the other VMs in the vApp. In this way VMs are isolated from other VMs, vApps and resource pools outside of its own vApp. When resource contention takes place all VMs in a vApp will have to compete over the amount om resource that are available to the vApp.
If expendable reservations are configured, the vApp can allocate more resources if the parent resource pool has those available. However if there are no resources available the VMs in the vApp will need to compete over the resource available to the vApp. This is where normal resource mechanisms apply such as shares, limits and reservations.
Lets take the vApp with the three tier vApp (web-app-db) as an example. By default all VMs are equal in a vApp. However the database is the most important VM in this three tiered vApp and needs to be given enough resources when resource contention takes place. To define this one can set the shares for the database VM on High. By default this is set to Normal. This will give the database VM twice as much resource shares as the other two VMs in the vApp. This will elevate its priority within the vApp and provide it with half of the resources when resource contention takes places. In this way one can set a specific priority to VMs within a vApp.