However, once an OVA/OVF has been deployed and running as a standard Virtual Machine, I found there were no out of the box cmdlets for manipulating the OVF properties for a VM as shown in the screenshot below.
Online searches also did not yield any results and hence the opopournity and article 🙂
Just like any VM reconfiguration, you will need to use the vSphere API ReconfigVM_Task() and to update various OVF settings for a VM, you will need to pass in VAppConfigSpec along with a VAppPropertySpec containing the individual OVF property values to update.
During the development of my automated NSX-T 2.0 lab deployment script, I had created several PowerCLI functions using the new NSX-T cmdlets and NSX-T APIs to help me test and troubleshoot. I finally got a chance to clean up the code as well as package them all up into an NSXT.psm1 module which hopefully can benefit others. For those of you who are looking for a primer on how to get started with the new NSX-T PowerCLI cmdlets and the NSX-T APIs, check out this awesome post from Romain Decker.
The NSXT module contains the following 8 functions:
Since publishing my Automating Cross vCenter vMotion between the same and different SSO Domain article back in early 2016, I have had a large number of customers reach out to me and share their success stories of allowing them to perform datacenter migrations to consolidating vCenter Servers all due to this awesome capability that was introduced in vSphere 6.0. In fact, many of the VM migration numbers were in the 4,000 to 8,000+ range which completely blew me away. It was great to hear from customers on how the xMoveVM.ps1 script had enabled them to do things that was simply not possible before, especially without impacting their workloads.
I still get pinged on a regular basis from customers about using my script and one thing that surprises many customers when I mention to them that this functionality has already been ported over to the native Move-VM cmdlet that was introduced with the PowerCLI 6.5 release. This had always been my original intention to provide an example using our vSphere API and enabling our customers in the short term and working with Alan Renouf and the PowerCLI team to get this folded back into the official PowerCLI cmdlets. This means, you no longer have to use my script for basic Cross vCenter vMotions whether that is between the same or different SSO Domain, which is quite nice as the number of user inputs is significantly reduced by using Move-VM cmdlet.
Lets take a look at an example below where I have a VM called TestVM-1 which is residing in vcenter65-1 and I want to vMotion it to vcenter65-3:
With just 5 simple and easy to read lines of PowerCLI, you can perform this operation:
Last week, I had spent some time exploring and getting myself more familiar with NSX-T, which is the next generation release of the NSX platform from VMware. One of the first thing I do when learning about a new product is to setup a lab environment that I can using. Having gone through the deployment once by hand, I realized it would be quite painful if I needed to do this again, which I know I will and I did 🙂 I wanted to have a simliar experience to my vGhetto Automated vSphere Lab deployment script which also including setting up the entire vSphere infrastructure along with deploying and configuring NSX-V and extending it to support NSX-T.
Since my original script leverages PowerCLI to access both the vSphere and NSX APIs, I wanted to do the same with NSX-T. Funny enough, the PowerCLI team had just published an update release (6.5.3) which also added support for NSX-T and I thought this was perfect timing to try out the NSX-T APIs, which I had never used before.
I was recently doing some work with my VMware Cloud on AWS instance and I needed to verify something in the vSphere API. Since I already had a browser open, rather than context switch, I decided to quickly open up the vSphere MOB which is a debugging tool that provides a browser interface to the vSphere SOAP API. While going through the Virtual Machine view, I was pleasantly surprised to see a new VM config property called createDate which looks to give you the original date/time of when the VM was first created!
This is probably one of the most frequently asked question that I have seen from VI Admins around basic VM management and I am sure everyone has probably had a need to pull this type of information at least once in their career. Historically, VM creation date was not an easy thing to thing to find and success of retrieving that data was dependent on the retention of your vCenter Server Events database since that is where the information is stored. This means if you only retain 6 months worth of historical events, you will not be able to retrieve creation dates for VMs that were created prior to that.