WilliamLam.com

Use cases for Anti-Affinity VM-Host Rules

by // 6 Comments

I was in a meeting last week with Engineering and a question had come up on whether customers were actively using the Anti-Affinity (AA) VM-Host Rules capability and if so, what are some of the use cases?  We know that Anti-Affinity VM-VM Rules are used quite regularly by customers and the use cases are pretty well understood, but what is not clear was the usage and frequency of AA VM-Host rules. I figured I could help Engineering by asking some of my Twitter folllowers, the following question:

In an attempt to avoid any confusion, I also included a screenshot of the AA VM-Host Rules in the vSphere UI which you can see above. However, it looks like my attempt had failed and I actually received a number of replies that described AA VM-VM Host Rules (separate certain groups of VMs from each other, regardless of host groups), rather than AA VM-Host Rules (do not run certain groups of VMs on specific host groups). Perhaps the question could have been better phrased or it was just a simple misinterpretation, but overall it was a very useful exercise and it was great learn about all the different use cases for BOTH AA VM-VM and AA VM-Host Rules, so thank you to everyone who shared their feedback.

[Read more...]

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

 

Feedback on default behavior for VM Storage Policy

by // 1 Comment

Today, the vCenter REST (vSphere Automation) APIs currently does not support the use of VM Storage Policies when relocating (vMotion, Cross Datacenter vMotion & Storage vMotion) or cloning an existing Virtual Machine. Customers have provided feedback that this is something that they would like to see get added to the current REST APIs and while this is being looked at, there were a couple of open questions from Engineering.

The following 2-question survey below is to help us understand what the "default" behavior should be when a Virtual Machine is being relocated or cloned within a vCenter Server and a VM Storage Policy is NOT specified when using the APIs. The reason for this is that our existing APIs for relocate and clone today are very flexible and not everything needs to be specified as part of the relocate or clone API specification. However, due to this flexibility, you may observe different behaviors and we would like to understand what the default behavior should be when some of these paraemters are not specified. In the case where you want to be explicit, you can always specify the VM Storage Policy, but the survey is to understand when it is not specified.

Survey: https://goo.gl/forms/aQjVTly2MmVHeRsp1

Thank you  for taking the time to provide your feedback, this will help us build an easy and robust API when dealing with relocate and clone operations using the vCenter REST APIs.