Tag Archives: vCloud Director

First Look: ManageIQ vCloud Director Orchestration

Welcome to 2017! To kick off the year I thought I’d do a quick post on a little known product (at least in my circles) from Red Hat Inc called ManageIQ. I stumbled across ManageIQ by chance having caught wind that they where soon to have vCloud Director support added to the product. Reading through some of the history behind ManageIQ I found out that in December of 2012 Red Hat acquired ManageIQ and integrated it into its CloudForms cloud management program…they then made it open source in 2014.

ManageIQ is the open source project behind Red Hat CloudForms. The latest product features are implemented in the upstream community first, before eventually making it downstream into Red Hat CloudForms. This process is similar for all Red Hat products. For example, Fedora is the upstream project for Red Hat Enterprise Linux and follows the same upstream-first development model.

CloudForms is a cloud management platform that also manages traditional server virtualization products such as vSphere and oVirt. This broad capability makes it ideal as a hybrid cloud manager as its able to manage both public clouds and on-premises private clouds and virtual infrastructures. This acts as a single management interface into hybrid environments that enables cross platform orchestration to be achieved with relative ease. This is backed by a community that contributes workflows and code to the project.

The supported platforms are shown below.

The October release was the first iteration for the vCloud provider which supports authentication, inventory (including vApps), provisioning, power operations and events all done via the use of the API provided by vCloud Director. First and foremost I see this as a client facing tool rather than an internal orchestration tool for vCAN SPs however given it can go cross platform there can be a use for VM or Container orchestration that SPs could tap into.

While it’s still relatively immature compared to the other platforms it supports, I see great potential in this and I think all vCAN Service Providers running vCloud Director should look at this as a way for their customers to better consume and operate vCD coming from a more modern approach, rather than depending on the UI.

Adding vCloud Director as a Cloud Provider:

Once the Appliance is deployed, head to Compute and Add New Cloud Provider. From the Type dropdown select VMware vCloud

Depending on which version of vCD SP your Service Provider is running, select the appropriate API Version. For vCD SP 8.x it should be vCloud API 9.0

Next add in the URL of the vCloud Director endpoint with it’s port…which is generally 443. For the username, you use the convention of [email protected] which allows you to login specifically to your vCD Organization. If you want to login at an admin enter in [email protected] to get top level access.

Once connected you can add as many vCD endpoints as you have. As you can see below I am connected to four seperate instances of vCloud.

Clicking through you get a Summary of the vCloud Zone with it’s relationships.

Clicking on the Instances you get a list of your VM’s, but this also has views for Virtual Datacenter, vApps and other vCD objects. As you can see below there is detailed views on the VM and it does have basic Power functions in this build.

I’ve just started to look into the power of CloudForms and have been reading through the ManageIQ automation guide. It’s one of those things that needs a little research plus some trial and error to master, but I see this form of cloud consumption where the end user doesn’t have to directly manipulate the various API endpoints as the future. I’m looking forward to how the vCloud Director provider matures and I’ll be keeping an eye on the forums and ManageIQ GitHub page for more examples.

Resources:

http://manageiq.org/docs/get-started/
http://manageiq.org/docs/reference/
https://pemcg.gitbooks.io/mastering-automation-in-cloudforms-and-manageiq/content/chapter1.html

OVFTool: vCloud Director OVA Upload PowerShell Script

Earlier this year I put together a quick and nasty PowerShell Script that exports a vApp from vCloud Director using the OVFTool …for those that don’t know the OVFTool is a command line tool that has a powerful set of functions to import/export VMs and vApps from vCenter, ESXi and vCloud Director weather it be from a vCloud Air or a vCloud Air Network Provider.

You can Download and install the tool from here:

This week I needed to upload an Virtual Machine that was in OVA format and for those that have worked with vCloud Director you would know that the OVA format is not supported using the upload functionality in the current web interface. With that I thought it was a good time to round out the export using OVTTool post with an import using OVFTool post. Again, doing some research I found a bunch of posts relating to importing OVAs into vCloud Director and after working through the Admin Guide and some examples I was ready to build out a basic import command and start work on the PowerShell Script. On Windows you can run the tool from CMD but I would suggest using PowerShell/CLI as in the example below I go through building a variable.

What Info is Required:

  • vCloud URL
  • vCloud Username and Password
  • Org Name
  • vDC Name
  • vApp Name
  • Catalog Name
  • Path to OVA

Command Line Example:

Below is a basic example of how to construct the vCloud String and use it as a variable to execute the tool.

PowerShell Script:

Again, I’ve taken it a step further to make it easier for people to import OVAs into vCloud Director and put together another, slightly improved PowerShell Script that I have coded in to work with my old companies vCloud Zones…though this can be easily modified to use any vCloud Air Network vCD endpoint.

The output of the script can be seen below:

It’s a very basic script that gathers all the required components that make up the vCloud Source Connection String and then exports the OVA into the vCD vApp. I’ve even done a little more PowerShell improvements around password security and added a little colour.

Save the code snippet as a .ps1 into the OFVTool Windows Folder and execute the script from the same location. If there are any errors with the inputs provided the OVFTool will fail with an error, but apart from that it’s a very simple straight forward way to import OVAs into any vCloud Director enabled endpoint.

Additional Reading:

http://www.virtuallyghetto.com/tag/ovftool

http://www.vmwarebits.com/content/import-and-export-virtual-machines-command-line-vmwares-ovf-tool 

vCloud Director SP 8.10.1 UI Additions – Boot Options

Last week VMware released vCloud Director SP 8.10.1 Build 4655197 and while it was mainly a patch release there was one new feature added which was a couple of additional UI settings under the General Tab of a Virtual Machine.

  • New boot customization options added to delay the boot time and to enter into the BIOS setup screen. You can use the vCloud Director Web console or the vCloud API to set Boot Delay and EnterBIOS mode options.

This might seem like a small and meaningless setting, but you would be surprised how many times I experienced customers frustrated at the fact they could not get into the BIOS easily via the VM Console or have a long enough boot delay to trigger a boot from alternative media option.

The previous General Tab looked like this:

The 8.10.1 General Tab looks like this:

You can see that you now have an check box to Enter BIOS Setup and set the Boot Delay. These settings follow the rules of vSphere meaning the Boot delay is in milliseconds and can only be modified if the Virtual Machine is powered off. I had this image open with the System Administrator account which explains why you see the a few more VM related bits of information telling you what Host and Datastore the VM is residing on and what the name of the VM is in vSphere.

Again, this is a simple but extremely useful addition but continues to show VMware’s commitment to improving the vCD platform even before the big UI enhancements start to filter through next year.

#LongLivevCD

Released: vCloud Director SP 8.10.1 Important Upgrade for Zerto Clients

This week VMware released vCloud Director SP 8.10.1 Build 4655197. This is the sister build for vCD SP 8.0.2 and like that release, while there a a number of minor bug fixes in this release there is one important fix that will make service providers who offer replication services built upon Zerto happy, as it resolves a bug that had stopped many service providers upgrading from vCD SP 5.6.x…however unlike the release notes in 8.0.2 it doesn’t mention the specific fix in the notes. By all acounts the hot-fix that was released prior to this offical build is in this build…if you still have issues after this build please let VMware know through GSS.

 Apart from the bug fixes, there is one new feature in this build and that is something that will be welcomed by a lot of vCD users and that is Enhanced Boot Options.

  • New boot customization options added to delay the boot time and to enter into the BIOS setup screen. You can use the vCloud Director Web console or the vCloud API to set Boot Delay and EnterBIOS mode options.

There is also official support for NSX-v 6.2.4 and that’s now covered by all the latest vCD SP versions as you can see below.

As usual I’ve gone through the Resolved Issues list and highlighted the ones I feel are most relevant…the ones in red are issues we had seen my old employers vCloud Zones and Zettagrid Labs.

  • Deployment of vApp template in My Cloud with Hardware Modification fails with null UI Error
    Attempts to deploy vApp in My Cloud from the vApp template with hardware modificat
  • After vCloud Director upgrade, the vCloud Director version does not change in vCenter Solutions Manager
    After successful upgrade of the vCloud Director from version 8.0.1 to 8.10.0, the vCloud Director version in vCenter Solutions Manager does not update and remains 8.0.1.
  • Uploading ISO media file does not consume quota that is set after the storage policy is configured to organization vDC
    When you configure the storage policy to organization virtual datacenter (vDC) and set a quota limit, the quota is not consumed while uploading the ISO media file.
  • vCloud Director database upgrade takes long time to complete when the audit_event table contains millions of records
    Database upgrade of vCloud Director from versions 5.5.x, 5.6.x to versions 8.0, 8.0.x, 8.10 might take up to 8 hours time to complete if the audit_event table contains millions of records. This issue is resolved in vCloud Director 8.10.1. The database upgrade might now take up to 20 minutes.
  • VMware vCloud Director (vmware-vcd) services do not start automatically upon a reboot
    The VMware vCloud Director (vmware-vcd) services do not start automatically after a reboot because of an issue in the systemd-219-19.el7 module of Red Hat Enterprise Linux 7.2 that includes the upgrade to Red Hat Enterprise Linux 7.3.

This will more than likely be the last build of the current 8.0 and 8.10 releases with a closed BETA of the next vCD SP currently underway. This next major release of vCD SP promised to deliver on new UI enhancements (HTML5) and deep NSX-v integration.

References:

http://pubs.vmware.com/Release_Notes/en/vcd/8-10/rel_notes_vcloud_director_8-10-1.html

VMware on AWS: vCloud Director and What Needs to be Done to Empower the vCAN

Last week VMware and Amazon Web Services officially announced their new joint venture whereby VMware technology will be available to run as a service on AWS in the form of bare-bones hardware with vCenter, ESXi, NSX and VSAN as the core VMware technology components. This isn’t some magic whereby ESXi is nested or emulated upon the existing AWS platform, but a fully fledged dedicated virtual datacenter offering that clients can buy through VMware and have VMware manage the stack right up to the core vCenter components.

Earlier in the week I wrote down some thoughts around the possible impact to the vCloud Air Network this new offering could have. While at first glance it would appear that I was largely negative towards the announcement, after having a think about the possible implications I started to think about how this could be advantageous for the vCloud Air Network. What it comes down to is how much VMware was to open up the API’s for all components hosted on AWS and how the vCloud Director SP product team develops around those API’s.

From there it will be on vCloud Air Network partners that have the capabilities to tap into the VMC’s. I believe there is an opportunity here for vCAN Service Providers to go beyond offering just IaaS and combine their offerings with the VMware AWS offering as well as help extend out to offer AWS PaaS without the worry that traditional VM workloads will be migrated to AWS.

For this to happen though VMware have to do something they haven’t done in the past…that is, commit to making sure vCAN providers can cash in on the opportunity and be empowered by the opportunity to grow VMware based services… as I mentioned in my original post:

In truth VMware have been very slow…almost reluctant to pass over features that would allow this cross cloud compatibility and migration be even more of a weapon for the vCAN by holding back on features that allowed on-premises vCenter and Workstation/Fusion connect directly to vCloud Air endpoints in products such as Hybrid Cloud Manager. I strongly believed that those products should have been extended from day zero to have the ability to connect to any vCloud Director endpoint…it wasn’t a stretch for that to occure as it is effectively the same endpoint but for some reason it was strategically labeled as a “coming soon” feature.

Extending vCloud Director SP:

I have taken liberty to extend the VMWonAWS graphic to include what I believe should be the final puzzle in what would make the partnership sit well with existing vCloud Air Network providers…that is, allow vCloud Director SP to bridge the gap between the on-premises compute, networking and storage and the AWS based VMware platform infrastructure.

vCloud Director is a cloud management platform that abstracts physical resources from vCenter and interacts with NSX to build out networking resources via the NSX Manager API’s…with that it’s not hard in my eyes to allow any exposed vCenter or NSX Manager to be consumed by vCloud Director.

With that allowed, any AWS vCenter dedicated instance can become a Virtual Datacenter object in vCloud Director and consumed by an organisation. For vCloud Air Network partners who have the ability to programatically interact with the vCloud Director APIs, this all of a sudden could open up another 70+ AWS locations on which to allow their customers to deploy Virtual Datacenters.

Take that one step further and allow vCD to overlay on-premises compute and networking resources and then allow connectivity between all locations via NSX hybridity and you have a seriously rock solid solution that extends a customer on-premises to a more conveniently placed (remember AWS isn’t everywhere) vCloud Air Network platform that can in turn consume/burst into a VMware Dedicated instance on AWS and you now have something that rivals the much hyped Hybrid Cloud Strategy of Microsoft and the Azure Stack.

What Needs to Happen:

It’s pretty simple…VMware need to commit to continued/accelerated development of vCloud Director SP (which has already begun in earnest) and give vCloud Air Network providers the ability to consume both ways…on-premises and on VMware’s AWS platform. VMware need to grant this capability to vCloud Air Network providers from the outset and not play the stalling game that was apparent when it came to feature parity with vCloud Air.

What I have envisioned isn’t far off becoming a reality…vCloud Director is mature and extensible enough to do what I have described above, and I believe that in my recent dealings with the vCloud Director product and marketing teams at VMworld US earlier this year that there is real belief in the team that the cloud management platform will continue to improve and evolve…if VMware allow it to.

Further improving on vCloud Directors maturity and extensibility, if the much maligned UI is improved as promised…with the upcoming addition of full NSX integration completing the network stack, the next step in greater adoption beyond the 300 odd vCAN SPs currently use vCloud Director needs a hook…and that hook should be VMWonAWS.

Time will tell…but there is huge potential here. VMware need to deliver to their partners in order to have that VMWonAWS potential realised.

 

VMware on AWS: Thoughts on the Impact to the vCloud Air Network

Last week VMware and Amazon Web Services officially announced their new joint venture whereby VMware technology will be available to run as a service on AWS in the form of bare-bones hardware with vCenter, ESXi, NSX and VSAN as the core VMware technology components. This isn’t some magic whereby ESXi is nested or emulated upon the existing AWS platform, but a fully fledged dedicated virtual datacenter offering that clients can buy through VMware and have VMware manage the stack right up to the core vCenter components.

Note: These initial opinions are just that. There has been a fair bit of Twitter reaction over the announcement, with the majority being somewhat negative towards the VMware strategy. There are a lot of smart guys working on this within VMware and that means it’s got technical focus, not just Exec/Board strategy. There is also a lot of time between this initial announcement and it’s release first release in 2017 however initial perception and reaction to a massive shift in direction should and will generate debate…this is my take from a vCAN point of view.

The key service benefits as taken from the AWS/VMware landing page can be seen below:

Let me start by saying that this is a huge huge deal and can not be underestimated in terms of it’s significance. If I take my vCAN hat off, I can see how and why this was necessary for both parties to help each other fight off the growing challenge from Microsoft’s Azure offering and the upcoming Azure Stack. For AWS, it lets them tap into the enterprise market where they say they have been doing well…though in reality, it’s known that they aren’t doing as well as they had hoped. While for VMware, it helps them look serious about offering a public cloud that is truly hyper-scale and also looks at protecting existing VMware workloads from being moved over to Azure…and to a lesser extent AWS directly.

There is a common enemy here, and to be fair to Microsoft it’s obvious that their own shift in focus and direction has been working and the industry is taking note.

Erasing vCloud Air and The vCAN Impact:

For VMware especially, it can and should erase the absolute disaster that was vCloud Air… Looking back at how the vCloud Air project transpired the best thing to come out of it was the refocus in 2015 of VMware to prop back up the vCloud Air Network, which before that had been looking shaky with the vCANs strongest weapon, vCloud Director, being pushed to the side and it’s future uncertain. In the last twelve months there has an been apparent recommitment to vCloud Director and the vCAN and things had been looking good…however that could be under threat with this announcement…and for me, perception is everything!

Public Show of Focus and Direction:

Have a listen to the CNBC segment embedded above where Pat Gelsinger and AWS CEO Andy Jassy discuss the partnership. Though I wouldn’t expect them to mention the 4000+ strong vCloud Air Network (or the recent partnership with IBM for that matter) the fact that they are openly discussing about the unique industry first benefits the VMWonAWS partnership brings to the market, in the same breath they ignore or put aside the fact that the single biggest advantage that the vCloud Air Network had was VMware workload mobility.

Complete VMware Compatibility:

VMware Cloud on AWS will provide VMware customers with full VM compatibility and seamless workload portability between their on-premises infrastructure and the AWS Cloud without the need for any workload modifications or retooling.

Workload Migration:

VMware Cloud on AWS works seamlessly with vSphere vMotion, allowing you to move running virtual machines from on-premises infrastructure to the AWS Cloud without any downtime. The virtual machines retain network identity and connections, ensuring a seamless migration experience.

The above features are pretty much the biggest weapons that vCloud Air Network partners had in the fight against existing or potential client moving or choosing AWS over their own VMware based platform…and from direct experience, I know that this advantage is massive and does work. With this advantage taken away, vCAN Service Providers may start to loose workloads to AWS at a faster clip than what was done previously.

In truth VMware have been very slow…almost reluctant to pass over features that would allow this cross cloud compatibility and migration be even more of a weapon for the vCAN by holding back on features that allowed on-premises vCenter and Workstation/Fusion connect directly to vCloud Air endpoints in products such as Hybrid Cloud Manager. I strongly believed that those products should have been extended from day zero to have the ability to connect to any vCloud Director endpoint…it wasn’t a stretch for that to occure as it is effectively the same endpoint but for some reason it was strategically labeled as a “coming soon” feature.

VMware Access to Multiple AWS Regions:

VMware Virtual Machines running on AWS can leverage over 70 AWS services covering compute, storage, database, security, analytics, mobile, and IoT. With VMware Cloud on AWS, customers will be able to leverage their existing investment in VMware licenses through customer loyalty programs.

I had mentioned on Twitter that the image below was both awesome and scary mainly because all I think about when I look at it is the overlay of the vCloud Air Network and how VMware actively promote 4000+ vCAN partners contributing to existing VMware customers in being able to leverage their existing investments on vCloud Air Network platforms.

Look familiar?

 

In truth of those 4000+ vCloud Air Network providers there are maybe 300 that are using vCloud Director in some shape or form and of those an even smaller amount that can programatically take advantage of automated provisioning and self service. There in lies one of the biggest issues for the vCAN…while some IaaS providers excel, the majority offer services that can’t stack up next to the hyper-scalers. Because of that, I don’t begrudge VMware to forgetting about the capabilities of the vCAN, but as mentioned above, I believe more could, and still can be been done to help the network complete in the market.

Conclusion:

Right, so that was all the negative stuff as it relates the vCloud Air Network, but I have been thinking about how this can be a positive for both the vCAN and more importantly for me…vCloud Director. I’ll put together another post on where and how I believe VMware can take advantage of this partnership to truly compete against the looming threat of the Azure Stack…with vCAN IaaS providers offering vCloud Director SP front and center of that solution.

References:

http://www.vmware.com/company/news/releases/vmw-newsfeed.VMware-and-AWS-Announce-New-Hybrid-Cloud-Service,-%E2%80%9CVMware-Cloud-on-AWS%E2%80%9D.3188645-manual.html

https://aws.amazon.com/vmware/

VMware Cloud™ on AWS – A Closer Look

https://twitter.com/search?f=tweets&vertical=default&q=VMWonAWS

Released – vCloud Director SP 8.0.2 Important Upgrade for Zerto Clients

Last week VMware released vCloud Director SP 8.0.2 Build 4348775. While there a a number of minor bug fixes in this release there is one important fix that will make service providers who offer replication services built upon Zerto happy, as it resolves a bug that had stopped many service providers upgrading from vCD SP 5.6.x. Apart from that there are only a couple new things in this build…that being an updated JRE version, some additional language support in the WebMKS console and probably of more importance is official support for NSX-v 6.2.4

 

As usual I’ve gone through the Resolved Issues list and highlighted the ones I feel are most relevant…the ones in red are issues we have seen in our vCloud Zones and Zettagrid Labs.

  • Intermittent failure of vCD vApp deployment
    When you attempt to deploy vApp either manually or through the vCO workflow, the deployment might fail with the following error:
    Could not find resource pool for placement of edge gateway.
  • Downloading a large vApp template as an OVF file from the vCloud Director fails
    Attemps to download a large vApp template as an OVF file from vCloud Director fails due to an operation timeout error in both vCloud Director and vCenter Server. This issue is seen when the size of the vApp template is greater than 100 GB.
  • vCloud Director Cell uses a high percentage of the CPU
    The vCloud Director cell uses more than 90 percent of the CPU. As a result, the vCloud Director workload is affected
  • During a heavy load, vCloud Director can have two or more VMs that have the same CloudUUID in the system
    During a heavy load, vCloud Director can have two or more VMs with the same CloudUUID in the system. This causes the Managed Object Reference (moref) of the VM to be overwritten by another VM. Due to the duplicated CloudUUID, a wrong VM might get deleted.
  • In the latest Mac version (OS X El Capitan), the Upload, or Download dialog box does not close correctly
    After you update your system to the latest Mac version (OS X El Capitan), when you attempt to upload a file from the data store the Upload, or Download dialog box does not close correctly.
  • vApp deployment from a template fails with certain direct organization VDC networks, when there are multiple direct organization VDC networks in a VDC that are mapped to the same external network
    When there are multiple direct organization VDC networks in a VDC that are mapped to a single external network, deploying a vApp from the template is possible with only one of these networks. The deployment fails when other networks are selected.
  • Edge gateway fails to deploy when a create request is invoked from the vCloud Director cell that does not have a vCenter Server proxy listener
    In a multi-cell vCloud Director setup, the Edge gateway creation is successful only when the create request is invoked from the vCloud Director cell that has a vCenter Server proxy listener.

Zerto vs VMware Standoff:

With regards to the Zerto issue, this bug actually exists in vCD SP 8.10 as well and will be resolved in an upcoming build later in November. There is a hotfix available if Service Providers want to deploy vCD SP 8.10 before the official release. There was a significant delay before this that impacted Zerto clients and to be honest it wasn’t handled well from both sides. Zerto claim to offer official support 90 days after the release of vCD however that was not possible and the finger was pointed at VMware to fix the bug rather than try to work around the issue.

“Creating or modifying a VM in vCD fails (VMware KB 2144385)” and Zerto is prevented from recovering into a vCD environment. 

That VMwareKB has been pulled back internally and there isn’t any specific reference to that issue in the release notes, however we do know and have confirmed that the bug has been resolved in this build and the upcoming 8.10 build. It highlights the fact that vendors who partner together in delivering solutions that rely on one an others solutions need to work together so as to not impact their mutual clients.

References:

http://pubs.vmware.com/Release_Notes/en/vcd/802/rel_notes_vcloud_director_802.html

VCA-CLI for vCloud Director: New Networking Features

There is a lot of talk going around how IT Pros can more efficiently operate and consume Cloud Based Services…AWS has lead the way in offering a rich set of APIs for it’s clients to use to help build out cloud applications and infrastructure and there are a ton of programming libraries and platforms that have seen the rise of the DevOps movement…And while AWS has lead the way, other Public Clouds such as Azure (with PowerShell Packs) and Google have also built self service capability through APIs.

vCloud Director has always had a rich set of APIs (API Online Doco Here) and as I blogged about last year Paco Gomez has been developing a tool called VCA-CLI which is based on pyvcloud which is a Python SDK for vCloud Director and vCloud Air. This is an alternative to Web Based creation and management of vCloud Director vDCs and vApps. Being Python based you have the option of running it pretty much on any OS you like…the posts below show you how to install and configure VCA on a Mac OS X OS and Windows and how to connect up to a vCloud Director based Cloud Org.

Initial releases of VCA-CLI didn’t have the capability to configure the Firewall settings of a vDC Edge Gateway, but since the release of version 16, Firewall rule management has been added. In the below example, I connect up to my vCD Org in Zettagrid, gather some information about my vDC, deploy a SexiLog VM template, set the Syslog setting on the Gateway and then configure a new NAT and Firewall rules to open up port 8080 to the SexiLog Web interface.

And the end result:

Again, this highlights the power of the vCloud Director API and what can be done with the pyvcloud Python SDK. Once perfected the set of commands above can be used to deploy vApps and configure networking in seconds instead of having to work through the vCloud Director UI…and that’s a win win!

References:

https://pypi.python.org/pypi/vca-cli

https://github.com/vmware/vca-cli

http://www.sexilog.fr/

 

NSX Bytes: vCloud Director Can’t Deploy NSX Edges

Over the weekend I was tasked with the recovery of a #NestedESXi lab that had vCloud Director and NSX-v components as part of the lab platform. Rather than being a straight forward restore from the Veeam backup I also needed to downgrade the NSX-v version from 6.2.4 to 6.1.4 for testing purposes. That process was relatively straight forward and involved essentially working backwards in terms of installing and configuring NSX and removing all the components from vCenter and the ESXi hosts.

To complete the NSX-v downgrade I deployed a new 6.1.4 appliance and connected it back up to vCenter, configured the hosts, setup VXLAN, transport components and tested NSX Edge deployments through the vCenter Web Client. However, when it came time to test Edge deployments from vCloud Director I kept on getting the following error shown below.

Checking through the NSX Manager logs there was no reference to any API call hitting the endpoint as is suggested by the error detail above. Moving over to the vCloud Director Cells I was able to trace the error message in the log folder…eventually seeing the error generated below in the vcloud-container-info.log file.

As a test I hit the API endpoint referenced in the error message from a browser and got the same result.

This got me thinking that the error was either DNS related or permission related. After confirming that the vCloud Cells where resolving the NSX Manager host name correctly, as suggested by the error I looked at permissions as the cause of the 403 error. vCloud Director was configured to use the service.vcloud service account to connect to the previous NSX/vShield Manager and it dawned on me that I hadn’t setup user rights in the Web Client under Networking & Security. Under the Users section of the Manage Tab the service account used by vCloud Director wasn’t configured and needed to be added. After adding the user I retried the vCD job and the Edge deployed successfully.

While I was in this menu I thought I’d test what level of NSX User was required to for that service account to have in order to execute operations against vCloud Director and NSX. As shown below anything but NSX or Enterprise Administrator triggered a “VSM response error (254). User is not authorized to access object” error.

At the very least to deploy edges, you require the service account to be NSX Administrator…The Auditor and Security Administrator levels are not enough to perform the operations required. More importantly don’t forget to add the service account as configured in vCloud Director to the NSX Manager instance otherwise you won’t be able to have vCloud Director deploy edges using NSX-v.

 

 

vCD SP 8.10 New Features Part 3 – Storage Tiering and Storage Management

vCloud Director SP 8.10 has been out for a couple months now and the general buzz around this release has been extremely positive. The decision to expose the previously API only features has been warmly welcomed by most vCloud Air Network Service Providers and I have heard of quiet a few looking to deploy or plan deployment of vCD SP 8.10 into their hosting platforms.

In Part One I went through the new NSX supportability improvements and in Part Two I went through the tenant ability to configure VM affinity and anti-affinity rules. In Part Three I am going to go through something that’s been available via the API since vCD 5.6.3 SP but is now exposed via the UI and also take a look at a new feature around the limiting of the max size of a tenant VMDKs in a vCD environment.

  • VM Disk Level Storage Profiles – Allows a single virtual machine (VM) to access different tiers of storage such as storage area network (SAN), network-attached storage (NAS), and local storage to help balance storage cost vs. storage performance. VMware vCloud Director 5.6 also supports VMware Virtual SAN.

Fast Provisioning:

Before showing the new UI Storage Profile features it’s worth mentioning that this will not work if you have vDCs configured with fast provisioning enabled. If you try to configure multiple profiles against a VM you will get a “Cannot use multiple storage profiles in a fast-provisioned VDC” error message.

Fast provisioning was introduced with vCloud Director 1.5 and enables speeding up a cloning process when deploying vApps from catalog or copying VMs. It utilizes vSphere linked clones where the base image is not cloned, instead a delta disk is created to record changed blocks.

Great in theory, but also carries some caveats…not allowing VM Disk level storage profiles being one of them. If turned on, head to the Storage Tab of the vDC and uncheck the option as shown below.

VM Disk Level Storage Profiles:

There isn’t a lot that needs explaining in terms of what can now be achieved through the UI to better provision and manage different storage requirements on a per VM disk basis. vCD Storage Profiles directly plug into vCenter Storage Policies and inherit the characteristics passed through from vCenter into vCD via the Provider vDC. These are then allocated to vDCs as shown in the image above. Generally speaking these policies map back to different tiers of storage and allow the Service Provider to offering different service levels at different price points.

As an example a tenant may have a requirement to have a large file server that doubles as a Domain Controller (it happens more than you think) for the System drive the requirements might state that you need SAS backed storage and SATA backed for a secondary volume. This can now be achieved through the vCD UI as shown below.

You can see above that Disk 0 is on ioSTOR-500 and Disk 1 is on ioSTOR-250. The example above is for the adding of new disks to a VM…you can also change the Storage Profile while a VM is on. This will trigger a Storage vMotion in the background if required as shown below.

Limiting Maximum Disk Size:

There are some scenarios where a Service Providers might want to limit the max size of tenant VMDKs in order to comply with capacity planning requirements or storage level constraints. The current max size for a VMDK in vSphere is 62TB and being realistic there are not too many Service Providers out there who provision datastores that size. Typically, the storage limits applied at an allocation pool should limit the creation of stupidly large disks by tenants, but there is the possibility that someone with deep pockets purchasing large amounts of storage could try to provision a VM (thin or not) Disk larger than the datastores underpinning the storage policy.

To set the global disk limit you use the cell-management-tool command on any vCD cell in the instance. Once run the value is honors immediately and without restart of the vCD services as shown in the example below that limits the disks to 500GB.

./cell-management-tool manage-config -n vmlimits.disk.capacity.maxMb -v 500000

Once configured, if a tenant tries to provision a disk bigger than the limit they will get an error stating that the “Requested disk size exceeds maximum allowed capacity“.

References:

https://fojta.wordpress.com/tag/fast-provisioning/

http://pubs.vmware.com/Release_Notes/en/vcd/8-10/rel_notes_vcloud_director_8-10.html

« Older Entries