WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Exploring new VCSA VAMI API w/PowerCLI: Part 9

03.02.2017 by William Lam // Leave a Comment

In Part 9, we were initially going to cover the new backup and restore capability that was introduced in vSphere 6.5 for the VCSA. However, it looks like Brian Graf has already created an awesome PowerCLI module (Backup-VCSA.psm1) that can be used to backup the VCSA, which you can find more details here.

While going through the VAMI APIs for the backup feature, I did notice there was one interesting backup VAMI API that Brian may not have looked at, at least I did not see a function consuming this API. Prior to initiating a backup for either a VCSA or PSC, you can query the expected size of the backup. This information can be pretty helpful beyond just for backups, but understanding the size of your system at any point in time.

VAMI UI Area of Focus

The backup and restore feature for the VCSA is located in the VAMI UI, but there is not a UI for retrieving the current expected backup size.

VAMI APIs Used

  • GET /appliance/recovery/backup/parts

PowerCLI Function

  • Get-VAMIBackupSize

Sample Output

The output is pretty straight forward, it provides the total expected backup size (MB) as well as the breakdown of the total size into "configuration" data and the "Stats, Events, Alarms and Tasks" (SEAT) data.


With this new API, you can now easily see how large your vCenter Server Database is and take appropriate action such as truncating the data or reducing the retention period which can especially help with the performance of vCenter Server as well as the time it takes during upgrades.

  • Exploring new VCSA VAMI API w/PowerCLI: Part 1
  • Exploring new VCSA VAMI API w/PowerCLI: Part 2
  • Exploring new VCSA VAMI API w/PowerCLI: Part 3
  • Exploring new VCSA VAMI API w/PowerCLI: Part 4
  • Exploring new VCSA VAMI API w/PowerCLI: Part 5
  • Exploring new VCSA VAMI API w/PowerCLI: Part 6
  • Exploring new VCSA VAMI API w/PowerCLI: Part 7
  • Exploring new VCSA VAMI API w/PowerCLI: Part 8
  • Exploring new VCSA VAMI API w/PowerCLI: Part 9
  • Exploring new VCSA VAMI API w/PowerCLI: Part 10

Categories // Automation, PowerCLI, vSphere 6.5 Tags // PowerCLI, vami, vcenter server appliance, vSphere 6.5

Cross vCenter Server operations (clone / migrate) between versions of vSphere 6.x

02.27.2017 by William Lam // 7 Comments

When cross vCenter Server operations such as clone and migrate was first introduced in vSphere 6.0, it required that both the source and destination vCenter Server (includes ESXi hosts) to be running the same vSphere version. With the release of vSphere 6.5, this base requirement still holds true (e.g. vSphere 6.5 for both source and destination), especially when performing these operations using the vSphere Web Client where mixed-vSphere versions is not supported outside of a rolling upgrade.

Having said that, it is possible and supported to clone or migrate a VM across different versions of vSphere 6.x, for example a vSphere 6.5 and a vSphere 6.0 Update 3 environment. This can be accomplished by performing a xVC-vMotion or xVC-Clone operation using the vSphere API. For the the xVC-vMotion use case, I have extensively written about it here and here and with PowerCLI 6.5r1, the Move-VM cmdlet has even been updated based on my feedback to support this capability natively. Furthermore, you can even perform these operations across completely different vCenter Single Sign-On Domains, which enables a new level of mobility for your VMs and access to resources of independently deployed vCenter Server instances.

UPDATE (11/01/17) - The following VMware KB 2106952 has just been updated to reflect what is officially supported in terms of Cross vCenter Operations ( Clone / Migrate) across different versions of vSphere. The matrix in the KB reflects what has been tested by Engineering and one thing you may notice is that Cross vCenter vMotion/Clone from vSphere 6.x to vSphere 6.5 is only supported when running at least vSphere 6.0 Update 3. After speaking with the PM, the reason for this change is that pre-vSphere 6.0 Update 3, there were no pre-checks in the code to prevent Cross vCenter Operations for un-supported target hosts such as ESXi 5.5, which could lead to poor user experience as well as undefined failure scenarios. In addition, vSphere 6.0 Update 3 also includes additional enhancements to properly clean up failed provisioning operations which will make Cross vCenter Operations much more robust. Due to these reasons, though it is possible to perform Cross vCenter vMotion from earlier versions, it will not be officially supported. I have also updated my summarized table below to reflect what is in the VMware KB, but please use the KB as your official source of truth for what VMware supports.

To help make sense of the different combinations of vMotions and cloning operations, below are a few tables to help outline what is possible and supported today.

vMotion

Source vCenter Server Destination vCenter Server Supported UI or API
vSphere 6.0 vSphere 6.0 Yes UI and API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 Possible but Not Supported N/A
vSphere 6.0 Update 3 vSphere 6.5 Yes API
vSphere 6.5 vSphere 6.5+ Yes UI and API
vSphere 6.5 vSphere 6.x No No
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Cold Migrate

Source vCenter Server Destination vCenter Server Supported UI or API
vSphere 6.0 vSphere 6.0 Yes UI and API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 Possible but Not Supported API
vSphere 6.0 Update 3 vSphere 6.5 Yes API
vSphere 6.5 vSphere 6.5 Yes UI and API
vSphere 6.5 vSphere 6.x No No
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Clone

Source vCenter Server Destination vCenter Server Supported  UI or API
vSphere 6.0 vSphere 6.0 Yes UI and  API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 No N/A
vSphere 6.0 Update 3 vSphere 6.5 No N/A
vSphere 6.5 vSphere 6.5+ Yes UI and API
vSphere 6.5 vSphere 6.x No N/A
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Virtual Networking Migration

Source Type Destination Type Supported
VDS VDS Yes
VDS VSS No
VSS VSS Yes
VSS VDS Yes

Note1: vMotioning and/or cloning of VMs which uses the new vSphere Encryption feature introduced in vSphere 6.5 is not supported.

Note2: "Compute" only xVC-vMotion insufficient space issue has now been resolved with vSphere 6.0 Update 3, see this post here for more details.

Note3: xVC-vMotion is not supported on 3rd party switches as we can not checkpoint the switching state.

Here are some additional xVC-vMotion and vMotion articles that may also useful to be aware of:

  • Are Affinity/Anti-Affinity rules preserved during Cross vCenter vMotion (xVC-vMotion)?
  • Duplicate MAC Address concerns with xVC-vMotion in vSphere 6.0
  • Network Compatibility Checks During vMotion Between vCenter Server Instances
  • Auditing vMotion Migrations

Categories // Automation, vSphere 6.0, vSphere 6.5 Tags // Cross vMotion, ExVC-vMotion, vSphere 6.0, vSphere 6.5, vSphere API, xVC-vMotion

Quick Tip - Connect-OMServer throws The request was aborted: Could not create SSL/TLS secure channel.

02.23.2017 by William Lam // 3 Comments

While doing some work with PowerCLI and vRealize Operations Manager (vROps), I ran into the following error message when trying to connect to my vROps instance using PowerCLI:

Connect-OMServer : 2/17/2017 5:27:50 AM Connect-OMServer The request was aborted: Could not create SSL/TLS secure channel.
At line:1 char:1
+ Connect-OMServer -Server vrops.primp-industries.com -User admin -Password VMware ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (VMware.VimAutom...tionServiceImpl:OMConnectionServiceImpl) [Connect-OMServer], OMException
+ FullyQualifiedErrorId : OM_ConnectivityServiceImpl_ConnectOMServer_ByUserNameAndPassword_ConnectError,VMware.VimAutomation.vROps.Commands.Cmdlets.ConnectOMServer

Although there were some hits on Google, none of the suggestions has worked. I had also found that this issue was only happening in one of my lab environments which was running Windows 2008 R2, for my other system which had Windows 8.1, the issue was not observed.

I had reached out to the PowerCLI Engineering team and it looks like the issue is due to a change in the hashing algorithm (SHA512) that vROps uses for its SSL Certificates. When using TLS 1.2, SHA512 is not supported by default. The fix is to simply install the following patch here which will resolve the problem.

Categories // Automation, PowerCLI Tags // PowerCLI, SHA512, TLS 1.2, vRealize Operations Manager

  • « Previous Page
  • 1
  • …
  • 145
  • 146
  • 147
  • 148
  • 149
  • …
  • 224
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Automating the vSAN Data Migration Pre-check using vSAN API 06/04/2025
  • VCF 9.0 Hardware Considerations 05/30/2025
  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...