WilliamLam.com

Search Results for: vmc

OVFTool and VMware Cloud on AWS

by // 1 Comment

Recently, I had noticed a number of questions that have come up regarding the use of OVFTool with the VMware Cloud on AWS (VMC) service. I had a chance to take a look at this last Friday and I can confirm that customers can indeed use this tool to import/export VMs into VMC whether they are from a vSphere/vCloud Director-based environment or simply OVF/OVAs you have on your desktop. Outlined below are the requirements and steps that you must have setup before you can use OVFTool with VMC. In addition, I have also include an OVFTool command snippet which you can use and adapt in your own environment.

Requirements:

  1. You must setup VPN connection between your onPrem environment and the Management Gateway on VMC (direct internet access to ESXi is not supported)
  2. Configure the VMC Firewall to allow access between your onPrem and VMC's ESXi host on port 443 (data transfer occurs at ESXi host level)
  3. Specify the Workload VM Folder as a target
  4. Specify the Compute-ResourcePool Resource Pool as a target
  5. Specify the WorkloadDatastore Datastore as a target

Instructions:

Step 1 - Create a Management VPN connection, please see the official documentation here for more details.

Step 2 - Create a two new Firewall Rules that allow traffic from your onPrem environment to both vCenter Server and ESXi host on port 443. vCenter Server will obviously be used for UI/API access and for ESXi, this is where the data traffic transfer will take place.


Step 3 - Construct your OVFTool command-line arguments and ensure you are using the VM Folder "Workloads", Resource Pool "Compute-ResourcePool" and Datastore "WorkloadDatastore" as your target destination since the CloudAdmin user will have restrictive privileges within VMC.

Here is an example command to upload an OVA from my desktop to the VMC vCenter Server:

ovftool.exe `
--acceptAllEulas `
--name=William-To-The-Cloud `
--datastore=WorkloadDatastore `
--net:None=sddc-cgw-network-1 `
--vmFolder=Workloads `
C:\Users\primp\desktop\William.ova `
'vi://*protected email*:*protected email*/SDDC-Datacenter/host/Cluster-1/Resources/Compute-ResourcePool/'

Note: OVFTool also supports the ability to specify a VM that is residing in your vSphere environment as a source, so you do not have to export it locally to your desktop and you can directly transfer it (your client desktop acting as a proxy) to VMC.

Here is the output from running the above command:


Once the upload has completed, you should see your new VM appear in your vSphere Inventory

 

New Adventure

by // 5 Comments

It is hard to believe this Fall will be my 7th year at VMware! Looking back, it has absolutely been an amazing ride.

For the past six years, I have been very fortunate to have been part of an amazing team of solutions architects working within R&D as part of the Integrated Systems Business Unit (ISBU) at VMware. In the early days, we were known as the Integration Engineering team, most well known for designing, operating and running the original VMware Hands on Lab at VMworld which used to also include on-premises hardware! This team also served as Customer[0] internally for a number of VMware products. In addition, this team also ran the customer on-site Alphas and Betas for vSphere. I still remember building the very first vPod for what eventually became vSphere 6.0 🙂

Over the years, the team had built up a wealth of knowledge in how to build, run and operate the VMware SDDC at scale. A large part of the team had came from either the field or from a customer with past alumnis including Duncan Epping, Cormac Hogan & Paudie O'Riordan to name a few. We wanted to bring these learnings and best practices to our customers and the VMware Validated Design (VVD) was born. What customers most appreciate about the VVDs is not just the Day 0 guidance, but also the prescriptive Day 2 operational guidance (patching/upgrading, maintenance window scheduling, monitoring, disaster recovery, etc) which is not something VMware had historically provided. Customers can then consume the VVD in several ways: build it yourself (DIY), PSO engagement including Automation or through VMware Cloud Foundation (VCF) which codifies the VVD into an integrated hardware/software offering. I am very proud of what the team has built over the years, it was not an easy road and not compromising on our design principles has paid dividends as we continue see the VVD adoption accelerating in our customers environments as the fastest way to deliver a VMware SDDC.

For the last couple of years, I had also been driving an internal project within ISBU called the Enterprise Readiness Initiative (ERi). This effort is focused on ensuring that we have a consistent set of capabilities across Lifecycle, Certificate & Configuration Management for the VMware SDDC. These capabilities must also be exposed programmatically for our customers and partners to consume. One example is the recent Install/Upgrade vCenter REST APIs that was made available as part of the vSphere 6.7 release. There is still plenty more work to be done including other ERi workstreams, but the team has made some great progress and hopefully you will be seeing more of the results in the near future.

As you can see, there is no shortage of oppournitites at VMware and being able to work with so many talented and passionate colleague to help solve our customer challenges is what I wake up every day for. I wanted to take a moment and thank one of the best managers I have had the pleasure of reporting to, Phil Weiss. Not only has he been very supportive of my career development, but has also been a mentor to me over the years and I have learned a tremendous amount from him and about myself. Phil is also occasionally involved when I get called into the lawyers office 😉 I also wanted to extend my thanks to both John Gilmartin (ISBU GM) and Jayanta Dey (ISBU VP of Engineering) who were both extremely supportive of my decision to move on.

[Read more...]

VM Creation Date now available in vSphere 6.7

by // 13 Comments

Last year, I wrote about a new Virtual Machine API property called createDate which provides customers a method of retrieving the original creation date and time of a VM. This vSphere API was first introduced in VMware Cloud on AWS and with the release of vSphere 6.7, it is also now available for on-premises customers to consume.

I know this is a feature that many customers have been asking for (including myself) and I am super happy to finally see this information automatically captured and persisted as part of the VM configuration. Customers no longer have to query the vCenter Server Events API to retrieve this information and store it externally, since it can be rotated out and basically lost due to your vCenter Server Events retention configuration. As of right now, the VM creation date is only available using the vSphere API, it is currently not available in the vSphere H5 Client and hopefully I will be able to convince PM to add this useful piece information into the UI as well!

The createDate property is located under VirtualMachine->Config and can be accessed using any one of the supported vSphere 6.7 Automation SDKs which also includes PowerCLI (you will need to install PowerCLI 10.1.0 which enables support for vSphere 6.7)

Here is an example of retrieving the createDate for a VM named esxi67-01:

(Get-VM -Name esxi67-01).ExtensionData.Config.createDate


Here are a few things to be aware of regarding the createDate behavior:

  • BOTH vCenter Server and ESXi hosts must be upgraded to 6.7 to make use of the new API
  • This API is available on both vCenter Server as well as ESXi hosts running 6.7
  • Only new VMs that were created after upgrading to 6.7 will include this property with the creation date
  • VMs that were created prior to upgrading 6.7 will not have their original creation date, but rather a default value of 1970-01-01T00:00:00Z. If ESXi hosts have not been upgraded but vCenter Server has, then the API property will be unset (null)
  • You can programmatically check whether an ESXi host supports the new createDate property by querying its capabilities using the vSphere API. Here is a PowerCLI example:

    (Get-VMHost -Name 192.168.30.10).ExtensionData.Capability.VmCreateDateSupported

  • VMs created in a vSphere 6.7 environment can be Cross vCenter vMotion to other non-vSphere 6.7 environments and migrated back while retaining its original createDate value. This is done so by storing the value in the extraConfig property of a VM (this is best effort support and we recommend only migrating to vSphere 6.7 or newer environments)