Category Archives: vCloud

vCloud Director is no more… Long Live vCD! [VMware Cloud Director Service for VMC]

There was a very significant announcement at VMworld Barcelona overnight, with the unveiling of a new service targeted at Managed Service Providers. VMware Cloud Director Service (CDS) looks to leverage a hosted SaaS based instance of vCloud Director to offer multi-tenancy on VMware Cloud on AWS. The VMware Cloud on AWS SDDC becomes the provider and MSPs can look to more efficiently consume VMC resources and expand as more capacity is required.

Daniel Paluszek has written a great overview blog post about what the service is, it’s key value points and some questions and answers that those in the VMware Cloud Provider Program may have. I’m personally looking forward to trying out the service myself and start looking at the data protection scenarios that can be supported.

They Said it Would Never Happen:

Back in 2016 when VMware first announced VMware Cloud on AWS, I saw the potential straight away and what it could mean for (at the time vCloud Air) VMware Cloud Provider Partners to extend their Provider vDCs to one that was backed by VMC.

At the time I hacked together what I saw to be the future.

This isn’t quite what this newly announced solution is and it will be interesting to see if VMware eventually allow SP based vCD installs to go out and source a VMware Cloud on AWS SDDC as a Provider of its own. I was told by a number of people that vCD would never be used with VMC…

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.

That said, vCloud Director has evolved tremendously since then and delivered on almost everything that I was after at the time. This seems to be the last piece of the puzzle … though given that the actual Cloud Direct Service is delivered aaS does have me worried a little bit in terms of the ghosts of vCloud Air past.

Targeting MSPs over SPs:

I’ve already had some conversations as to who this new Cloud Director SaaS offering might be targeting. While I need to find out more information, it seems as though the main target of the service initially are MSPs. Depending on where you come from the definition of an MSP will differ to that of an SP. In some regions they are one and the same, however in the North American market an MSP would leverage an SP to offer infrastructure or software as a service.

Which every way you look at it, there is now the ability to spin up an instance of vCD that is managed and have that abstract resources that are in VMware Cloud on AWS. In a way this may lead some MSPs to ditch existing reseller relationships with existing VCPPs offering IaaS with vCD and go direct to VMware to have an end to end managed multi-tenant service and a direct reseller agreement with VMware.

Again, I need some more information before passing judgement and seeing how this fits into existing VCPP service offerings. Obviously the ability for existing VCPPs to land and expand into any VMC enabled AWS Region with this new service is significant also… but will they be able to use their existing provisioning and automation tools with the new service… and will the SaaS based version of Cloud Director be first to market with new features, followed by the VCPP versions?

Dropping the little v:

When VMware acquired Lab Manager and turned it into vCloud Director in 2010 it was hard to envision that the platform would still be going strong nearly ten years later. It’s now stronger that ever and set to go through its next evolution with the platform looking to extend beyond traditional vSphere IaaS based platforms… this explains why the little v has been dropped. We are not just talking about vCloud anymore… The premise is that Cloud Director will span multiple cloud and multiple platforms.

Be interesting to see when the name change takes place for the main product line that’s offered to VMware Cloud Providers… for the time being, it will still be vCD to me!

#LongLivevCD
#VCDpowered

References:

https://cloudsolutions.vmware.com/bite-sized-vmc

VMware Cloud Director – A New Day.

Mapping vCloud Director Backup Jobs to Self Service Portal Tenants

Since version 7 of Backup & Replication, Veeam has lead the way in regard to the protection of workloads running in vCloud Director. With version 7 Veeam first released deep integration into vCD that talked directly to the vCD APIs to facilitate the backup and recovery of vCD workloads and their constructs. More recently in version 9.5, the vCD Self Service Portal was released which also taps into vCD for tenant authentication.

The portal leverages Enterprise Manager and allows service providers to grant their tenants self-service backup for their vCD workloads. More recently we have seen some VCSPs integrate the portal into the new vCD UI via the extensibility plugin which is a great example of the power that Veeam has with vCD today while we wait for deeper, native integration.

It’s possible that some providers don’t even know that this portal exists let alone the value it offers. I’ve covered the basics of the portal here…but in this post, I am going to quickly mention an extension to a project I released last year for the vCD Self Service Portal, that automatically enables a tenant, creates a default backup jobs based on policies, tie backup copy jobs to default job for longer retention and finally import the jobs into the vCD Self Service Portal ready for use.

Standalone Map and Unmap PowerShell Script:

From the above project, the job import part has been expanded to include its own standalone PowerShell script that can also be used to map or unmap existing vCD Veeam Backup jobs to a a tenant to manage from the vCD Self Service Portal. This is done using the Set-VBRvCloudOrganizationJobMapping commandlet.

As shown below, this tenant has already configured a number of jobs in the Portal.

There was another historical job that was created outside of the portal directly from the Veeam console. Seen below as TEST IMPORT.

To map the job, run the PowerShell script is with the -map parameter. A list of all existing vCloud Director Backup jobs will be listed. Once the corresponding number has been entered the commandlet within the script will be run and the job mapped to the tenant linked to the job.

Once that has been run, the tenant now has that job listed in the vCD Self Service Portal.

There is a little bit of error checking built into the script, to that it exits nicely on an exception as shown below.

Finally, if you want to unmap a job from the vCD Self Service portal, run the PowerShell script with the -unmap parameter. Conclusion:

Like most things I work on and then publish for general consumption, I had a request to wrap some logic around the Set-VBRvCloudOrganizationJobMapping commandlet from a service provider partner. The script can be taken and improved, but as-is, provides an easy way to retrieve all vCloud Jobs belonging to a Veeam Server, select the desired job and then have it mapped to a tenant using the vCD Self Service Portal.

References:

https://github.com/anthonyspiteri/powershell/blob/master/vCD-Create-SelfServiceTenantandPolicyJobs/vCD_job.ps1

https://helpcenter.veeam.com/docs/backup/powershell/set-vbrvcloudorganizationjobmapping.html?ver=95u4

Orchestration of NSX by Terraform for Cloud Connect Replication with vCloud Director

That is probably the longest title i’ve ever had on this blog, however I wanted to highlight everything that is contained in this solution. Everything above works together to get the job done. The job in this case, is to configure an NSX Edge automatically using the vCloud Director Terraform provider to allow network connectivity for VMs that have been replicated into a vCloud Director tenant organization with Cloud Connect Replication.

With the release of Update 4 for Veeam Backup & Replication we enhanced Cloud Connect Replication to finally replicate into a Service Providers vCloud Director platform. In doing this we enabled tenants to take advantage of the advanced networking features of the NSX Edge Services Gateway. The only caveat to this was that unlike the existing Hardware Plan mechanism, where tenants where able to configure basic networking on the Network Extension Appliance (NEA), the configuration of the NSX Edge had to be done directly through the vCloud Director Tenant UI.

The Scenario:

When VMs are replicated into a vCD organisation with Cloud Connect Replication the expectation in a full failover is that if a disaster happened on-premises, workloads would be powered on in the service provider cloud and work exactly as if they where still on-premises. Access to services needs to be configured through the edge gateway. The edge gateway is then connected to the replica VMs via the vOrg Network in vCD.

In this example, we have a LAMP based web server that is publishing a WordPress site over HTTP and HTTPs.

The VM is being replicated to a Veeam Cloud Service Provider vCloud Director backed Cloud Connect Replication service.

During a disaster event at the on-premises end, we want to enact a failover of the replica living at in the vCloud Director Virtual Datacenter.

The VM replica will be fired up and the NSX Edge (the Network Extension Appliance pictured is used for partial failovers) associated to the vDC will allow the HTTP and HTTPS to be accessed from the outside world. The internal IP and Subnet of the VM is as it was on-premises. Cloud Connect Replication handles the mapping of the networks as part of the replication job.

Even during the early development days of this feature I was thinking about how this process could be automated somehow. With our previous Cloud Connect Replication networking, we would use the NEA as the edge device and allow basic configuration through the Failover Plan from the Backup & Replication console. That functionality still exists in Update 4, but only for non vCD backed replication.

The obvious way would be to tap into the vCloud Director APIs and configure the Edge directly. Taking that further, we could wrap that up in PowerShell and invoke the APIs from PowerShell, which would allow a simpler way to pass through variables and deal with payloads. However with the power that exists with the Terraform vCloud Director provider, it became a no brainer to leverage this to get the job done.

Configuring NSX Edge with Terraform:

In my previous post around Infrastructure as Code vs APIs I went through a specific example where I configured an NSX Edge using Terraform. I’m not going to go over that again, but what I have done is published that Terraform plan with all the code to GitHub.

The GitHub Project can be found here.

The end result after running the Terraform Plan is:

  • Allowed HTTP, HTTPS, SSH and ICMP access to a VM in a vDC
    • Defined as a variable as the External IP
    • Defined as a variable as the Internal IP
    • Defined as a variable as the vOrg Subnet
  • Configure DNAT rules to allow HTTP, HTTPS and SSH
  • Configure SNAT rule to allow outbound from the vOrg subnet

The variables that align with the VM and vORG network are defined in the terraform.tfvars file and need to be modified to match the on-premises network configuration. The variables are defined in the variables.tf file.

To add additional VMs and/or vOrg networks you will need to define additional variables in both files and add additional entires under the firewall_rules.tf and nat_fules.tf. I will look at ways to make this more elegant using Terraform arrays/lists and programatic constructs in future.

Creating PowerShell for Execution:

The Terraform plan can obviously be run standalone and the NSX Edge configuration can be actioned at any time, but the idea here is to take advantage of the script functionality that exists with Veeam backup and replication jobs and have the Terraform plan run upon completion of the Cloud Connect Replication job every time it is run.

To achieve this we need to create a PowerShell script:

GitHub – configure_vCD_VCCR_NSX_Edge.ps1

The PowerShell script initializes Terraform and downloads the Provider, ensures there is an upgrade in the future and then executes the Terraform plan. Remembering that that variables will change within the Terraform Plan its self, meaning these scripts remain unchanged.

Adding Post Script to Cloud Connect Replication Job:

The final step is to configure the PowerShell script to execute once the Cloud Connect Replication job has been run. This is done via a post script settings that can be found in Job Settings -> Advanced -> Scripts. Drop down to selected ps1 files and choose the location of the script.

That’s all that is required to have the PowerShell script executed once the replication job completes.

End Result:

Once the replication component of the job is complete, the post job script will be executed by the job.

This triggers the PowerShell, which runs the Terraform plan. It will check the existing state of the NSX Edge configuration and work out what configuration needs to be added. From the vCD Tenant UI, you should see the recent tasks list modifications to the NSX Edge Gateway by the user configured to access the vCD APIs via the Provider.

Taking a look at the NSX Edge Firewall and NAT configuration you should see that it has been configured as specified in the Terraform plan.

Which will match the current state of the Terraform plan

Conclusion:

At the end of the day, what we have done is achieved the orchestration of Veeam Cloud Connect Replication together with vCloud Director and NSX… facilitated by Terraform. This is something that Service Providers offering Cloud Connect Replication can provide to their clients as a way for them to define, control and manage the configuration of the NSX edge networking for their replicated infrastructure so that there is access to key services during a DR event.

While there might seem like a lot happening, this is a great example of leveraging Infrastructure as Code to automated as otherwise manual task. Once the Terraform is understood and the variables applied, the configuration of the NSX Edge will be consistent and in a desired state with the config checked and applied on every run of the replication job. The configuration will not fall out of line with what is required during a full failover and will ensure that services are available if a disaster occurs.

References:

https://github.com/anthonyspiteri/automation/tree/master/vccr_vcd_configure_nsx_edge

Infrastructure as Code vs RESTful APIs … A Working Example with Terraform and vCloud Director

Last week I wrote an opinion piece on Infrastructure as Code vs RESTful APIs. In a nutshell, I talked about how leveraging IaC instead of trying to code against APIs directly can be more palatable for IT professionals as it acts as a middle man interpreter between yourself and the infrastructure endpoints. IaC can be considered a black box that does the complicated lifting for you without having to deal with APIs directly.

As a follow up to that post I wanted to show an example about the differences between using direct APIs verses using an IaC tool like Terraform. Not surprisingly the example below features vCloud Director…but I think it speaks volumes to the message I was trying to get across in the introduction post.

The vCloud Director Terraform Provider was recently upgraded with the release of vCloud Director 9.7 and now sits at version 2.1 itself.

The Terraform Provider has been developed using Python and GO. It uses Client-Server model inside the hood where the client has been written using GO and server has been written using Python language. The core reason to use two different languages is to make a bridge between Terraform and Pyvcloud API. Pyvcloud is the SDK developed by VMware and provides an medium to talk to vCloud Director. Terraform uses GO to communicate where Pyvcloud has been written in Python3.

The above explanation as to how this provider is doing its thing highlights my previous points around any IaC tools. The abstraction of the infrastructure endpoint is easy to see… and in the below examples you will see it’s benefit for those who have not got the inclination to hit the APIs directly.

The assumption for both examples is that we are starting without any configured Firewall or NAT rules for the NSX Edge Services Gateway. Both methods are connecting as tenant’s of the vCD infrastructure and authenticating with Organisation level access.

The end result will be:

  • Allow HTTP, HTTPS and ICMP access to a VM living in a vDC
    • External IP is 82.221.98.109
    • Internal IP of VM is 172.17.0.240
    • VM Subnet is 172.17.0.0/24
  • Configure DNAT rules to allow HTTP and HTTPS
  • Configure SNAT rule to allow outbound from the VM subnet
Configuring Firewall and NAT Rules with RESTful API:

Firstly, to understand what vCD API operations need to be hit, we need to be familiar with the API Documentation. This will cover initial authentication as either a SYSTEM or Organizational admin and then what calls need to be made to get information relating to the current configuration and schema. Further to this, we need to also be familiar with the NSX API for vCD Documentation which covers how to interact with the network specific API operations possible from the vCD API endpoint.

We are going to be using Postman to execute against the vCD API. Postman is great because you can save your call history and reuse them at a later date. You can also save variable into Workspaces and also insert specific code to assist with things like authentication.

First step is to authenticate against the API and get a session authorization key that will allow you to feed that key back into subsequent requests. This authorization key will only last you a finite amount of time and will need to be regenerated.

Because we are using a decent RESTful API Client like Postman, there is a better way to programatically authenticate using a bearer access token as described in Tom Fojta’s post here when talking to the vCD API.

Once that is done we are authenticated as a vCD Organizational Admin and we can now query the NSX Edge Services Gateway (ESG) Settings for Firewall and NAT rules. I’ll walk through configuring a NAT rule for the purpose of the example, but the same method will be used to configure the Firewall as well.

A summary of the NAT requests can be seen below and found here.

Below we are querying the existing NAT rules using a GET request against the NSX ESG. What we are returned is an empty config in XML.

What needs to be done is to turn that request into a POST and craft an XML payload into the Body of the request so that we can configure the NAT rules as desired.

Redoing the GET request will now show that the NAT rules have been created.

And will be shown in the vCD Tenant UI

From here we can update, append, reset or delete the NAT rules as per the API documentation. Each one of those actions will require a new call to the API and the same process followed as above.

Configuring Firewall and NAT Rules with Terraform:

For a primer on the vCloud Director Terraform Provider, read this post and also head over to Luca’s post on Terraform with vCD. As with the RESTful API example above, I will use Terraform IaC to configure the same Tenant NSX Edge Gateway’s Firewall and NAT rules. What will become clear using Terraform for this is that it is a lot more efficient and elegant that going at it directly against the APIs.

Initially we needs to setup the required configuration items in order for the Terraform Provider to talk to the vCD API endpoint. To do this we need to setup a number of Terraform files that declare the variables required to connect to the vCD Organization and then configure the terraform.tfvars file that contains the specific variables.

We also create a provider .tf file to specifically call out the required Terraform provider and set the main variables.

We contain all this in a single folder (seen in the left pane above) for organization and portability…These folders can be called as Terraform Modules if desired in more complex, reusable plans.

We then create two more .tf files for the Firewall and NAT rules. The format is dictated by the Provider pages which gives examples. We can make things more portable by incorporating some of the variables we declared elsewhere in the code as shown below for the Edge Gateway name and Destination IP address.

Once the initial configuration work is done, all that’s required in order to apply the configuration is to initialize the Terraform Provider, make sure that the Terraform Plan is as expected… and then apply the plan against the Tenant’s Organization.

As the video shows… in less than a minute we have the NSX Firewall and NAT rules configured. More importantly, we now have a desired state which can be modified at any time by simple additions or subtractions to the Terraform code.

Wrapping it up:

From looking at both examples, it’s clear that both methods of configuration do the trick and it really depends on what sort of IT Professional you are in terms of which method is more suited to your day to day. For those that are working as automation engineers, working with APIs directly and/or integrating them into provisioning engines or applications is going to be your preferred method. For those that want to be able to deploy, configure and manager their own infrastructure in a more consumable way, using a Terraform provider is probably a better way

The great thing about Terraform in my eyes is the fact that you have declared the state that you want configured and once that has been actioned, you can easily check that state and modify it by changing the configuration items in the .tf files and reapplying the plan. For me it’s a much more efficient way to programatically configure vCD than doing the same configuration directly against the API.

Ohhh… and don’t forget… you are still allowed to use the UI as well… there is no shame in that!

Quick Fix: Upgrading to vCloud Director 9.7 fails During Database Script Updates

While looking to upgrade one of my vCloud Director instances I came across an error during the database upgrade process which is the second step of updating vCloud Director from version to version. I must admit, it the eight to nine years of using vCloud Director, this was the first time that had an error during this process… I was kind of shocked!

Unable to upgrade the database: java.lang.IllegalStateException: Exception encountered while altering idle transaction session timeout in vcloud database:

This was upgrading a PostGreSQL 9.5 database in a single cell all in one setup. Initially I was going from 9.1.x to 9.7 so I decided to roll back and try a 9.5 upgrade first. That worked without issue, however the subsequent upgrade from 9.5 to 9.7 also failed with the same error. Talking in the VMware Cloud Provider Slack Channel I got a few pointers to permissions and/or the version of PostGreSQL being not supported by 9.7.

Looking at the supportability Matrix for vCloud Director against supported databases we see:

vCloud Director 9.7 only supports MSSQL 2017 (last release that will support MSSQL) and PostGreSQL 10 which suggests 10.x. I was running PostGreSQL 9.5, so decided to upgrade to 10.7 using this guide from Yves Sandfort.

After upgrading to 10.7 I tried the upgrade again but still got the same error. Because of the fact that the same instance upgraded successfully from 9.1 to 9.5 I didn’t really consider the database permissions to be a problem so continued to investigate with the help of VMware Support. What we found was an exception that mentioned ownership of the vcloud database from the current user which is vcloud.

Sure enough, logging into PostgreSQL admin it showed that the existing owner of the vcloud database was postgreS its self.

Strangely for me, during the PostgreSQL upgrade and migration the ownership of the database did not carry across. After changing the ownership back to the vcloud user the upgrade worked.

Take Away:

There seems to be two potential triggers for the error during the database upgrade:

  • Being on a non supported version of PostgreSQL (not 10x)
  • Not having the correct ownership permissions against the vcloud database

So if that error pops up during an upgrade to vCloud Director 9.7 check either of the above (or both) and give it another shot.

Update 4 for Service Providers – Targeting vCloud Director with Cloud Connect Replication

When Veeam Backup & Replication 9.5 Update 4 went Generally Available in late January I posted a What’s in it for Service Providers blog. In that post I briefly outlined all the new features and enhancements in Update 4 as it related to our Veeam Cloud and Service Providers. As mentioned each new major feature deserves it’s own seperate post. I’ve covered off the majority of the new feature so far, and for the final post in the series I am looking at something that is close to my heart…vCloud Director Support for Veeam Cloud Connect Replication.

As a reminder here are the top new features and enhancements in Update 4 for VCSPs.

Leveraging the Best of vCloud Director for Stronger DRaaS:

VMware vCloud Director is the de facto standard for service providers who offer Infrastructure as a Service based on VMware and Veeam has had a long history supporting vCloud Director, with the industry’s first support for vCloud Director aware backups released in Veeam Backup & Replication v7 following on with the first stand alone Self Service Backup Portal in v9.5.

With the release of Update 4, we have added support for Veeam Cloud Connect to replicate directly into vCloud Director virtual datacenters, allowing both our Cloud and Service Provider Partners (VCSP) and customers to take advantage of the enhancements VMware has built into the platform. While this has been a long time coming, this support represents a significant enhancement to the way in which our VCSPs offer DRaaS.

With tenants consuming vCloud Director resources, it allows them to take advantage of more powerful features when dealing with full disaster, or the failure of individual workloads. Full and partial failovers will be more transparent with the use of the vCloud Director HTML5 Tenant UI and the vCloud Director HTML5 UI will also allow tenants to see what is happening to workloads as they boot and interact with the guest OS directly. This takes the pressure of the VCSPs helpdesk and gives tenants more control of their replicas once failed over.

Enhanced Edge Networking with NSX:

From a networking point of view, being able to access the NSX Edge Gateway for replicated workloads means that tenants can leverage the advanced networking features available on the NSX Edge Gateway. The Network Extension Appliance did a great job in offering basic network functionality however the NSX Edge offers:

  • Advanced Firewalling and NAT
  • Advanced Dynamic Routing (BGP, OSPF and more)
  • Advanced Load Balancing
  • IPsec and L2VPN
  • SSL VPN
  • SSL Certificate Services

Once a failover has been triggered from the Veeam Backup & Replication Console or via the VCSPs own Portals, the ability to manage and configure everything through the vCloud Director HTML5 UI utilizing NSX via vCloud Director enhances Cloud Connect Replication for both service providers and tenants.

Network Automation During Partial Failovers with the NEA:

There are a number of options that can be used to extend the tenant network to the service provider cloud network when actioning a partial failover. Tenants and service providers can configure:

  • Custom IPsec VPN
  • IPsec or L2VPN via the NSX Edge Gateway
  • NEA to NEA L2 VPN

The Network Extension Appliance is still available for deployment in the same way as before Update 4 and can be used directly from within a vCloud Director virtual datacenter. The NEA’s automate the extension of a tenant network so that the failed over workload can be accessible from the tenant network, even though it resides in the service provider’s environment. The NEA to NEA option is the simplest and most effective way to extend the tenants network to the cloud network.

NOTE: I will be dedicating a seperate blog post to this feature as I believe this is one of the leading innovative features we have as part of Cloud Connect Replication.

vCloud Director 9.7 Compatibility:

Just a quick note to finish that at the time of writing this post, Veeam Backup & Replication 9.5 Update4a does not officially support vCloud Director 9.7. We currently support up to vCloud Director 9.5 but will be looking to add supportability for 9.7 within the next 90 days.

Wrap Up:

DRaaS is something that is only just becoming recognized as something that organizations require as part of their overall data protection strategy. Veeam has had a strong offering delivered through our VCSPs for a while now, with a strong focus on network automation which is typically the hardest part of any DRaaS offering. With Cloud Connect Replication now targeting vCloud Director we now have a very compelling DRaaS product that is simple, flexible and reliable…yet still delivers enterprise grade functionality.

Quick Post – vCloud Director 9.5.0.3 Released as Critical Update

Late last week, on the same day as vCloud Director 9.7 was released to GA, an update was also released for vCloud Director 9.5.x which has been marked are critical. Specifically it relates to a vulnerability in previous vCloud Director 9.5.x with identifier CVE-2019-5523. Ironically this threat targets the new Tenant and Provider Portals.

VMware vCloud Director for Service Providers update resolves a Remote Session Hijack vulnerability in the Tenant and Provider Portals. Successful exploitation of this issue may allow a malicious actor to access the Tenant or Provider Portals by impersonating a currently logged in session.

Obviously given that vCloud Director 9.7 has just been release it’s unlikely that most Service Providers will upgrade right away, therefore the majority will be running vCloud Director 9.5.x for some time yet.

vCloud Director 9.0.x and 9.1.x are not affected.

References:

https://docs.vmware.com/en/vCloud-Director/9.5/rn/vCloud-Director-9503-for-Service-Providers-Release-Notes.html

https://www.vmware.com/security/advisories/VMSA-2019-0004.html

Quick Post – vCloud Director 9.5.0.2 Released

While we wait for the upcoming release of vCloud Director 9.7 next month (after the covers where torn off the next release in a blog post last week by the vCloud Team), VMware have released a new build (9.5.0.2 Build 12810511) of vCloud Director 9.5 that contains a number of resolved issues and is a recommended patch update.

Looking through the resolved issues it seems like the majority of fixes are around networking and to do with NSX Edge Gateway deployments as well as a few fixes around OVF template importing and API interactions.

While looking through the new layout of the VMware Docs page for vCloud Director I noticed that a few new builds for 9.1, 9.0 and 8.20 had shipped out over the past few months or so. I updated the vCloud Director Release History to reflect all the latest builds across all versions.

References:

https://docs.vmware.com/en/vCloud-Director/9.5/rn/vCloud-Director-9502-for-Service-Providers-Release-Notes.html

https://blogs.vmware.com/vcloud/2019/03/the-hybrid-cloud-gets-better-meet-vcloud-director-9-7.html

 

Released: vCloud Director 9.5 – Full HTML5 Tenant UI, NSX-T Thoughts and More!

Last week VMware released vCloud Director 9.5 (build 10266189) which builds on the 9.1 release that came out earlier this year. This continues to deliver on VMware’s promise to release major vCD updates every six months or so. This update completes the HTML5 Tenant Portal port as well as continuing to enhance the usability of the HTML5 interface by extending the Provider UI to be more functional. Under the hood there are a number of networking enhancements as well as the initial introduction of a vCD Cell Appliance.

New Features and Enhancements:

  • Fully Functional HTML5 Tenant Portal
  • Cross-OrgVDC and Multi-Site Cross-VDC Networking
  • Initial Support for NSX-T
  • Enhanced Role Base Access Control (RBAC)
  • vCloud Director Appliance
  • IPv6 Support for Guest VMs
  • Updated Plugin for vRealize Orchestrator
  • API and SDK Enhancements
  • Container Service Extension (CSE) 1.2

In this post, I am going to focus more on the HTML5 Tenant and Provider Portal as well as touch on some of the important changes to supportability this release brings. As you can see from the list above, there are a number of major features to talk about, and i’ll try to put together a few more posts over the next few weeks digging into them specifically.

Tenant UI Reaches Feature Parity:

Starting from this release the reliance on the old Flex based portal is no more. All tenant tasks have been ported over to the HTML5 portal along with a lot of additional enhancements. If I think back a couple years ago when vCloud Director was at a cross roads in terms of how VMware continued to develop it, it’s amazing to see this new UI fully complete.

Everything that Tenant’s could see in the Flex UI is present in the HTML5 UI. Some of the additions include a recent tasks pane, support for independent disks is not only an API only feature now and can be accessed via the UI as well as Affinity Rules being configurable from the HTML portal.

Provider UI Improvements:

Heading over to /provider will get you into the HTML5 Provider UI. This now lists all vCD Organizations and you can create a new Org and then click through to the Tenant UI as Administrator to perform configuration tasks

You can also manage Catalogs and as with vCD 9.1 you can manage the Content Library through the provider UI. What else is new in 9.5 is the ability to allow the management of users, groups, roles, global roles.

Depreciated APIs and Functionality:

vCD 9.5 brings with it the end of support for Oracle Database which brings full circle the requirement for Oracle. Many of you who started on vCD when it was in Beta or v1 remember that it needed an Oracle database and didn’t support MSSQL. With the support of PostgreSQL it’s now ironcially MSSQL’s days that are numbered with 9.5 being the last release to support MSSQL as the vCD Database. 

For those that use vCloud Network Isolation (VCDNI), that is now also no longer supported as well as a continued end of support for Older API Versions with version 19.0 and earlier no longer supported.

From a networking point of view vCD 9.5 is the last release to support the creation edge devices in the non-advanced mode which is effectively the old vShield mode. Only edge devices that have been created or converted to advanced will be supported by the HTML5 UI.

Compatibility with Veeam, vSphere 6.5, 6.7, NSX-v 6.4.x and NSX-T 2.2 Support:

On the NSX-T front…from the release notes:

vCloud Director 9.5 is the first version to support NSX-T, which can be combined with the existing support for NSX-V in the same vCloud Director installation. You can add a NSX-T Manager and the corresponding vCenter(s) as a resource in vCD (via API) and create a Provider VDC (PVDC) that is backed by NSX-T. All the vCenters in this PVDC should be backed the same NSX-T manager. All the hosts in these vCenters then will be installed with the DPDK switch. A VLAN backed network pool for each OrgVDC can be created,
from this the network configuration on tenant side is the same as with NSX-V.

NSX-T is something that VMware is pushing very hard now, and i’ll be honest in saying that i’ve not had a chance to tinker with it. I’m still very much in tune with NSX-v however it’s clear from the push of NSX-T into VMware Cloud on AWS and now into vCD that it is the network virtualization platform of choice moving forward…though I must check on the progress of the Edge devices. These are critical to tenant edge services that front a vDC and there is a lot of power in the current NSX-v edges.

Current NSX Platform? Future Direction?

View Results

Loading ... Loading ...

vCloud Director 9.5 is compatible with the latest vSphere 6.7, 6.5 Update 2 (but not 6.5 GA) and NSX-v 6.4.3 and supports full interoperability with other versions as shown in the VMware Product Interoperability Matrix. Interestingly enough, 9.5 has more supportability for NSX-v and obviously with NSX-T having initial limited support.

With regards to Veeam support, I am sure that our QA department will be testing the 9.5 release against our integration pieces at the first opportunity they get, but as of now, there is no ETA on offical support.

There are only two resolved issues in this build and there are a number of known issues that can be found here.

Conclusion:

Overall this is again, a very strong release and it’s clear to now see that vCD is 100% supported and backed by VMware. You can start to see a shift of the platform away from just being an abstraction layer to becoming what could be a brokerage engine expanding on the extensibility thats being built into the product under the hood. vCloud Director 9.5 continues to fulfil the promise of enabling SDDC functionality to VMware service providers.

There is a White Paper where you can find more details about what’s contained in the 9.5 release. Tom Fojta and Daniel Paluszek from VMware have a what’s new blog posts as well.

#LongLivevCD

References:

https://cloudsolutions.vmware.com/assets/blt4e4a9fe9b7954100/What’s%20New%20with%20vCloud%20Director%209.5.pdf

https://docs.vmware.com/en/VMware-vCloud-Director-for-Service-Providers/9.5/rn/vmware-vcloud-director-for-service-providers-95-release-notes.html

Quick Fix: Specified vCloud Director is not supported when trying to add vCD 9.1 to Veeam ONE

Back in May when VMware released vCloud Director 9.1 they also depreciated support for a number of older API versions:

End of Support for Older vCloud API Versions

  • vCloud Director 9.1 no longer supports vCloud API versions 1.5 and 5.1. These API versions were deprecated in a previous release.
  • vCloud Director 9.1 is the last release of vCloud Director to support any vCloud API versions earlier than 20.0. Those API versions are deprecated in this release and will not be supported in future releases.

Due to this, and being mid release cycle, Veeam ONE had issues connecting to vCD instances that where running version 9.1.

The error you would get if you tried to connect was:

Over the past few months i’ve had questions around this and if it was going to be fixed by way of a patch. While we are waiting for the next release of Veeam ONE that is due with Veeam Backup & Replication 9.5 Update 4 there is a way to get vCD 9.1 instances connected into the current build of Veeam ONE.

There is a HotFix available through Veeam Support to resolve the Known Issue. It involves stopping the Veeam ONE services, replacing a couple of DLL’s and then re-starting the services. Once implemented Veeam ONE is able to connect to vCD 9.1.

So if you have this problem, raise a support case, grab the HotFix and the issue will be sorted.

References:

https://docs.vmware.com/en/vCloud-Director/9.1/rn/rel_notes_vcloud_director_91.html#deprecated

« Older Entries