Deploying and managing a vCNS Edge device with vCloud Director is a pretty easy task to deploy. You just spin up the appliance, integrate it with vCenter and then hook it up to vCloud Director. Piece of vCAC!
But I was trying to dig deeper into the structure of how vCNS Edge devices work and wanted to log in to the Edge device itself. The only problem I was faced with was the fact that I couldn’t log into console of the Edge appliance that was deployed by vCNS manager on my virtual infrastructure. Thankfully the vCNS Manager interface provides you with the possibility to reset the password. So to reset the password and be able to log into the vCNS edge device you have to:
1. Log into the vCNS web interface
2. Select Edges at “View:” in the left corner
3. Select the Edge Gatway you want to log into
4. Click on Actions and select “Change CLI Credentials”
This allows you to set the password for the “admin” account. With these credentials you can login to the vCNS Edge device.
Lately I’ve been hitting some strange issues in vSphere and vCloud installations. First it was things around SSO not being able to connect and then it was the VMRC console in vCloud that started giving weird “invalid ticket” errors that resulted in vCloud VMRC console being accesible .. or not!
Both issues seemed unrelated, but the solution was the same : incorrect time settings on one of the vSphere / vCloud components.
So from a troubleshooting perspective we can add another check to the default checklist:
1. Check firewall.
2. Check time (NTP) settings!!!
It maybe a simple solution, but something to keep in mind while troubleshooting. It can save you a lot of frustation.
Some resource with regards to time and vSphere / vCloud :
“If you can create it with physical devices, you can build it in your own vCloud”. That’s something I always tell my customers when advising on VMware vCloud. Same goes for VMware vCloud Network and Security, which in my opinion hasn’t shown its full potential to customer yet. Thankfully Shubha Bheemarao and Ranga Maddipudi have created an excellent whitepaper on implementing vCloud Network and Security for a DMZ zone. This paper demonstrates how securing a virtual DMZ environment using VMware vCloud Networking and
Summary of the paper:
This paper highlights how securing a virtual DMZ environment using vCloud Networking and Security can be a strategic enabler to your organization as it helps you to reduce your capital expenditure and increase agility, while building a cloud ready, secure and scalable environment for business applications. The paper also highlights the different design approaches to securing business critical applications and enables you to make the choice that is most suited to your organization in the cloud journey. Further, it gives prescriptive configuration guidance to help you get started with the deployment of your preferred approach.
For more information on vCloud Networking and Security follow @vCloudNetSec on Twitter.
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.
VMware introduces vCenter Single Sign-On with vSphere 5.1. This solution creates a new layer between the vSphere solutions and the customers identity sources. The figure below gives a graphical representation where to position vCenter Single Sign-On.
The vCenter Single Sign-On server is the vSphere platform service that will be in between the vSphere solution, such as vSphere Web Client, vCenter, vCloud Director,etc., and the identity sources that are available within the customer infrastructure.
vCenter Single Sign-On has been introduced within the vSphere environment for the following reasons:
·Provide one single sign-on solution for authentication across all management applications;
·Support for multiple user identity repository solutions;
·One central point for authorization and auditing within the vSphere environement;
·Trust between components using token exchange, in stead of each solution having it’s own identity creation and authorization process;
·Support for open standard authentication protocols: SAML 2.0 and WS-TRUST.
Besides the improvements mentioned above, vCenter Single Sign-On can now also be setup with a in a more resilient setup. This will result in a high availability level for authentication in the vSphere environment.
For more information about the vCenter Single Sign-On Server look at the “vSphere 5.1 – What’s New vCenter Server”
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.
Lately I’ve been playing around with vCloud and all the whistles and bells that come along with it. One of the tools that really got my attention was vCloud Connector. Although it might seem as a simplistic tool, it actually is pretty powerful. Especially when you take a look at the use cases for this tool. That when it shows its real value : being the interconnect between vClouds, the hybrid cloud facilitator.
The construct of vCloud Connector
To get a better understanding of vCloud Connector we have to first look at the construct. The following picture gives a good representation of how vCloud Connector is setup.
vCloud Connector is constructed via a server-slave principle. One vCloud Connnection Server (vCCS) is needed. This is the central point access point and responsible for managing the nodes. The nodes are vCloud Connector Nodes (vCCN). Per vCloud instance or vSphere instance a node has to be installed and the have to be attached to the Connection Server. Both the vCloud Connector Server and the vCloud Connector Node can be downloaded at the VMware site
Through the User Interface (UI) the Connection Server can be controlled. The UI is available as a vSphere Client plugin or can be accessed via the web portal http://vcloud.vmware.com. This is were the nodes can be attached and after that the fun can start.
Use Cases for vCloud Connector
Fun being no more that copy-ing or moving workloads between vSphere and / or vCloud instances. Simple, but so effective. I’ve defined the 5 use cases I see. Bare in mind that workload need to be power off. It’s not a (long-distance) vMotion yet, it’s a start. Maybe in the future online will become a reality… Who knows!
#1 Hybrid Cloud; Probably the most referred use case. Moving workload from the private, internal cloud to a vCloud instance provided by a VMware vCloud enabled partner cloud; a public cloud. Drag-and-drop and the workloads will be moved or copied to it’s new home.
#2 Moving between external providers; Nobody likes to be stuck at some provider. At some certain point the decision is made to move your workload from provider A to provider B. Maybe it’s cheaper or the new service provider has got better service levels. Whatever the reason there is always the part of moving from A to B. vCloud Connector makes this task easy as copy-and-past in Windows. Just shut down the vApps and move the workloads to the new vCloud enabled provider.
#3 Migrating to the vCloud; One of the first questions I always get is how to migrate from vSphere to vCloud. vCloud Connector is the way to do this. It connects to the vCenter server and give the option to move or copy virtual machines and templates to a vCloud Director Organization vDC (Org vDC). Easy and simple.
#4 Moving vApps (Templates) between Org vDCs in different organizations; vCloud Connecor can be setup to move vApp (Templates) between Org vDC in different organizations. Normally an organization is a boundary within vCloud Director. By using vCloud Connector vApp (Templates) can be moved or copied between Org vDCs in different organizations.
#5 vCenter to vCenter; Maybe not the first use case to be thought of, but actually you can setup vCloud Connector to copy / move workloads between vCenter instances. This can be done in other ways, I know. We’ve been doing that for years. But vCloud Connector really makes this an easy task. Leveraging this ability through the use of a vSphere Client plugin.
Hopefully this gives a little bit more insight on how vCloud Connector can be used. I would at least advice everybody to install and configure it within their vSphere infrastructure. A powertool to move worlds, at least VM worlds!
Cloud here, cloud there, cloud is everywhere at the moment and private VMware vClouds are being deployed at customers all over the world. But with all great things the start with a design. And before you can design a nice solution to fit your need, you need to understand what vCloud is and what it’s capable of.
For this reason VMware created the vCloud Reference Architecture. A document that helps you design a private vCloud and understand all of it’s components. It will help you in the creation process, building your vCloud, size it for the needs of your organization and give you pointers on how to manage it.
You can download “Architecting a vCloud” over here.
VMware announced that it is going to release the VMware vCloud Connector. With this connector you will be able to connect to public vCloud solutions that are provided by service providers like Bluelock and Colt and in the near future Verizon (currently in beta).
Over the last couple of months these service providers have been building public vClouds based on VMware vCloud technology. The VMware vCloud Connector is the missing piece of linking your private vCloud (a.k.a. vSphere) to one of the public vClouds of the service providers.
The following link gives a graphic representation on how you should visualize the creation of a hybrid vCloud using the VMware vCloud Connector.
The VMware vCloud Connector is a virtual appliance running in your own private vCloud. By using a plugin in your vSphere client you can use the vCloud Connector to connect to public vClouds that are provided by the service providers that have build vClouds that are accessible through the vCloud API.
By using your vSphere Client together with the vCloud Connector you create a “single pain glass” management console for managing both your private vCloud and public vCloud resources.
This creates a hybrid cloud management interface with the following capabilities :
– Visualize workloads and templates across vSphere and private/public vClouds
– Migrate workloads and templates between vSphere and vClouds
– Perform basic power and deployment operations on workloads and templates
– Access console of vApps in vClouds
For more information on the VMware vCloud Connector, have a look at the post created by VMware vCloud Architect Massimo Re Ferre’