Tag Archives: vCloud Director

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

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

Creating Policy Based Backup Jobs for vCloud Director Self Service Portal with Tenant Creation

For a long time Veeam has lead the way in regard to the protection of workloads running in vCloud Director. Veeam first released deep integration into vCD back in version 7 of Backup & Replication 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.

This portal leverages Enterprise Manager and allows service providers to grant their tenants self-service management of their vCD workloads. 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 want to talk about how to use the Veeam APIs and PowerShell SnapIn to automatically enable a tenant, create 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.

Having worked with a service provider recently, they requested to have previously defined service definitions for tenant backups ported to Veeam and the vCD Self Service Portal. Part of this requirement was to have tenants apply backup policies to their VMs…this included short term retention and longer term GFS based backup.

One of the current caveats with the Veeam vCD Self Service Portal is that backup copy jobs are not configurable via the web based portal. The reason for this is that It’s our belief that service providers should be in control of longer term restore operations, however some providers and their tenants still request this feature.

Translated to a working solution, the PowerShell script combines a previously released set of code by Markus Kraus that uses the Enterprise Manager API to setup a new tenant in the vCD Self Service portal and a set of new functions that create default backup and backup copy jobs for vCD and then imports them into the portal ready for use. The variables are controlled by a JSON file making the script portable for Veeam Cloud and Service Providers to use as a base and build upon.

The end result is that when a tenant first logs into the vCD Self Service Portal they have jobs, dictated by the desired polices ready for use. The backup jobs are set to disabled without a schedule set. The scope of the default jobs is the tenant’s Virtual Datacenter. If there is a corresponding backup copy job, this is tied to the backup job and is ready to do its thing.

From here, the tenant can choose which policy that want to apply to their workloads and edit the desired job, change or leave the scope and add a schedule. The job name in the Backup and Replication console is modified to indicate which policy the tenant selected.

Again, if the tenant chooses a policy that requires longer term retention, the corresponding backup copy job is enabled in the Backup & Replication console…though not managed by the tenant.

Self service recovery is possible by the tenant for through the portal as per usual, including full VM recovery, file and application item level recovery. For recovery of the longer term workloads and/or items, this is done by the Service Provider.

This is a great example of the power of the Veeam API and PowerShell SnapIn providing a solution to offer more than what is out of the box and enhance the offering around the backup of vCloud Director workloads with Veeam’s integration. Feel free to use as is, or modify and integrate into your service offerings.

GitHub Page: https://github.com/anthonyspiteri/powershell/tree/master/vCD-Create-SelfServiceTenantandPolicyJobs

Adding Let’s Encrypt SSL Certificate to vCloud Director Keystore

For the longest time the configuring of vCloud Director’s SSL certificate keystore has been the thing that makes vCD admins shudder. There are lots of posts on the process…some good…some not so good. I even have a post from way back in 2012 about fronting vCD with a Citrix NetScaler and if I am honest, I cheated in having HTTPS at the load balancer deal with the SSL certificate while leaving vCD configured with the self signed cert. With the changes to the way the HTML5 Tenant Portal deals with certs and DNS I’m not sure that method would even work today.

I wanted to try and update the self signed certs in both my lab environments to assist in resolving the No Datacenters are available issue that cropped up in vCD 9.1. Instead of generating and using self signed certs I decided to try use Let’s Encrypt signed certs. Most of the process below is curtesy of blog posts from Luca Dell’Oca and it’s worth looking at this blog post from Tom Fojta who has a PowerShell script to automate Let’s Encrypt SSL certs for us on NSX Edge load balancers.

In my case, I wanted to install the cert directly into the vCD Cell Keystore. The manual end to end the process is listed below. I intend to try and automate this process so as to overcome the one constraint with using Let’s Encrypt…that is the 90 day lifespan of the certs. I think that is acceptable and it ensures validity of the SSL cert and a fair caveat given the main use case for this is in lab environments.

Generating the Signed SSL Cert from Let’s Encrypt:

To complete this process you need the ACMESharp PowerShell module. There are a couple of steps to follow which include registering the domain you want to create the SSL cert against, triggering a verification challenge that can be done by creating a domain TXT record as shown in the output of the challenge command. Once submitted, you need to look out for a Valid Status response.

Once complete, there is a script that can be run as show on Luca’s Blog. I’ve added to the script to automatically import the newly created SSL cert into the Local Computer certificate store.

From here, I exported the certificate with the private key so that you are left with a PFX file. I also saved to Base-64 X.509 format the Root and Intermediate certs that form the whole chain. This is required to help resolve the No Datacenters are available error mentioned above. Upload the three files to the vCD cell and continue as shown below.

Importing Signed SSL from Let’s Encrypt into vCD Keystore:

Next, the steps to take on the vCD Cell can be the most complex steps to follow and this is where I have seen different posts do different things. Below shows the commands from start to finish that worked for me…see inline for comments on what each command is doing.

Once that has been done and the vCD services has restarted, the SSL cert has been applied and we are all green and the Let’s Encrypt SSL cert is in play.

Released: vCloud Director 9.1.0.1 – API Tweaks and Resolved Issues

There was a point release of vCloud Director 9.1 (9.1.0.1 Build 8825802) released last week, bringing with it an updated Java Runtime plus new API functions that allow additional configuration of advanced settings for virtual machines. There was also a number of bug fixes from the initial 9.1 release earlier in the year. Some of the issues that are resolved are significant and worth looking into if you have 9.1 GA deployed.

I haven’t been able to find an exact list of the new API functions, however traversing the Org Admin rights API call I did spot something new relating to Latency as show below.

And when I granted this right through the API mechanism I was able to allocate the right to the Org Admin via the administrator web interface.

I’m trying get a list of all the new API rights that where added as part of this release and will update this post when I have them.

Some of the bigger issues that where resolved are listed below:

  • In vCloud Director Tenant Portal, the Configure Services tab is disabled for Advanced Edge Gateway. In vCloud Director Tenant Portal, you cannot configure Advanced Edge Gateway settings as an administrator with any of the Gateway Advanced Services rights.
  • When importing a virtual machine from vCenter Server, vCloud Director relocates it to the primary resource pool. When you import a virtual machine created on a non-primary cluster in vCenter Server to vCloud Director, the machine is always relocated to the primary cluster.
  • In the vCloud Director Tenant Portal, the administrator of one organization can see virtual machines that belong to other vCloud Director organizations. When you configure the organizations in vCloud Director to use an LDAP server for authentication, an administrator of one organization, who is logged in vCloud Director Tenant Portal, can see virtual machines that belong to other organizations.
  • Importing a virtual machine from the vCenter Server deletes the original virtual machine after cloning it. When importing a virtual machine from the vCenter Server to vCloud Director involves changing its datastore, the process consists in cloning the source virtual machine and deleting it, while effectively changing its Managed Object Reference (MoRef).
  • Enabling High Availability for existing edge gateways in a data center with installed NSX Edge 6.4.0 fails.  In a data center with installed NSX Edge 6.4.0, you cannot enable High Availability for existing edge gateways that belong to a datastore cluster with enabled Storage Distributed Resource Scheduler (SDRS).
  • vCloud Director Tenant Portal does not display existing organization virtual data centers. When you use a self-signed SSL certificate for vCloud Director and you log in to vCloud Director Tenant Portal, you do not see a list of the existing organization virtual data centers.

The rest can be found here.

Just to finish up, there is still a lingering issue from the GA release that changed the behaviour of the HTML5 Tenant UI in scenarios where the SSL self signed certificates are used which is covered in this VMwareKB. Even though (as shown above) it’s been listed as resolved…I have run into it again in two different installs.

Obviously, if you are using legit SSL certificates you won’t have the issue, however the work around is not doing it’s thing for me. Hopefully I can resolve this ASAP as I am about to start some validation testing for Veeam and vCloud Director as well as start to test out our new functionality coming in Update 4 of Backup & Replication for Cloud Connect Replication.

For those with the correct entitlements…download here.

#LongLivevCD

References:

https://docs.vmware.com/en/vCloud-Director/9.1/rn/rel_notes_vcloud_director_9-1-0-1.html

Released: vCloud Director 9.1 – New HTML5 Features, vCD-CLI and more!

Overnight VMware released vCloud Director 9.1 (build 7905680) which builds on the 9.0 release that came out last September. This continues to deliver on VMware’s promise to release major vCD updates every six months or so. This update, on the surface contains fewer big ticket items than the 9.0 release however the enhancements included are actually significant and continue to build on where 9.0 left off.

New Features and Enhancements:
  • Enhanced Tenant Portal
  • HTML Provider Portal
  • User Interface Extensibility
  • Service Integration
  • Standalone VMRC
  • Multi-Site Management View
  • SR-IOV
  • FIPS Mode
  • Python SDK
  • vCD-CLI
  • vRealize Orchestrator Integration
Enhanced Tenant Portal:

The new Tenant UI features include vApp and Catalog enhancements while delivering on probably the biggest pain point with the Flex UI tenant portal…that is OFV/OVA management. We now have native upload and download integration without the need for the client integration plugin.

You now also get an overview of resources consumed in your Virtual Datacenters and also get a view of the multiple organisation feature introduced into 9.0.

A new Provider Portal has been seeded in this release and at the moment can only be used for the new vRealise Orchestrator extensibility functionality. The administrator can import workflows from vRO through the import option. An administrator clicks the import workflow button, selects the vRO instance, and then chooses all the workflows they would like to import. On that note, there is an updated vRO Plug-In that allows both providers and tenants to automate tasks from the portal which is an excellent feature.

There is also a new workflow for the provision of standalone VMs and vApps.

Standalone VMRC:

If the management of OVAs/OVFs wasn’t the number one pain point with the FlexUI then the next one would have had to be the pain caused by the lack of functionality in the Console window. A HTML VM console is supported in version 9.0, but 9.1 now adds support for standalone VMware Remote Console. The VMRC provides more functions such for the tenant and significantly improves access to the VM consoles and gives greater flexibility accessing the VMs.

vCD-CLI:

I’ve blogged about the old VCA-CLI on a number of occasions and it’s great to see the project officially brought back into the vCD world. Development on this stopped for a while with the demise of vCloud Air, however I’m glad to see it picked up on as it’s a great tool for managing vCloud Director tenant Organisations and objects from a command line without having to get stuck into the APIs directly. It’s also used for the new Container Services Extension that has also been released side by side with this release of vCD.

Compatibility with Veeam, vSphere 6.5 and NSX-v 6.4.x:

vCloud Director 9.1 is compatible with vSphere 6.5 Update 1 and NSX-v 6.4 and supports full interoperability with other versions as shown in the VMware Product Interoperability Matrix. With regards to Veeam support, I am sure that our QA department will be testing the 9.1 release against our integration pieces at the first opportunity they get, but as of now, there is no ETA on offical support.

A list of known issues can be found in the release notes.

Conclusion:

Overall this is a very strong release with a lot of emphasis on extensibility behind the visual enhancements and functionality of the ever evolving HTML Tenant UI. As usual, I’ll look to write a few more blog posts on specific 9.1 features over the next couple of weeks.

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

#LongLivevCD

References:

https://blogs.vmware.com/vcloud/files/2018/03/vcd91newfeatureswp.pdf

VMware vCloud Director 9.1 is out!

« Older Entries