virtuallyGhetto

vSphere

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...] about Use cases for Anti-Affinity VM-Host Rules

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:

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.

How do you “log a reason” using PowerCLI when rebooting or shutting down ESXi host?

by 1 Comment

I am sure many of you have seen this UI prompt asking you to specify a reason before issuing a reboot or shutdown of an ESXi host and I assume most of you spend a few seconds to type in a useful message and not just random characters, right? 😉


Have you ever tried performing the same reboot or shutdown operation using the vSphere API or PowerCLI (which leverages the API)? Have noticed, there is not a way to specify a message like you can in the UI?

Here is a table of the PowerCLI cmdlets and the respective vSphere API that is used to perform these two operations:

Operation Cmdlet vSphere API
Reboot  Restart-VMHost  RebootHost_Task
Shutdown  Stop-VMHost  ShutdownHost_Task

When looking at either the PowerCLI and/or vSphere API documentation, we can confirm that there are no fields to specify a message which can lead to an assumption that this is simply not possible or that the functionality might be provided by a private API. Fortunately, this is not the case and the functionality is in fact in the public vSphere API and has been for quite some time.

When you specify a message prior to rebooting or shutting down, this message is actually persisted and implemented as an Event within vCenter Server as shown in the screenshot below.

Instead of being able to specify a message that is only applicable to an ESXi host, I believe the original vSphere API designers thought that this functionality could also be useful and applied more broadly across any number of the vSphere Inventory objects, not just ESXi hosts. As such, this functionality which the vSphere UI uses is provided by the LogUserEvent() method which is part of the EventManager API. Customers or solutions can leverage this mechanism to log custom user defined events which is then persisted with the lifecycle fo the vSphere Inventory Object or as far back as your retention period for vCenter Server Events.

Going back to our original question, if you want to specify a message prior to rebooting or shutting down an ESXi host, the following snippet below demonstrates the use of the vSphere API via PowerCLI:

New VMware Configuration Maximum Tool

by 1 Comment

VMware has just released a new web-based tool that will enable customers to easily view and compare product configuration maximums across different VMware product versions. You can access the easy to remember URL by going to: https://configmax.vmware.com

In this first release of this tool, customers will have the ability to look up configuration maximums for vSphere (includes VSAN) which will initially support vSphere 6.0, vSphere 6.5, vSphere 6.5 Update 1 & the recently released vSphere 6.7 as well as comparing across versions. To view the existing vSphere configuration maximum, simply click on the "Get Started" button.


As you can see from the screenshot below, you now have a single place where you can view the vSphere configuration maximums across different versions. Once you have selected the target version, you can either view all maximums or you can selectively choose the sections you are interested in.


The other really neat feature is the ability to compare the configuration maximums across different vSphere versions. This is really useful for customers to be able to quickly tell what improvements and enhancements have been made, especially as customers plan for vSphere upgrades. To begin, simply click on the "Compare Limits" button at the top. Next, select  the target vSphere version and then you can add one or more versions to compare against.


Once you click on the Compare button, a new window will popup providing you the comparison between the target and selected vSphere versions. You can quickly see how the maximums have changed across these vSphere versions. You can even export the results to Excel by click on export option on the upper right hand corner and you be prompted to save a CSV file.


I can tell you, this definitely beats having to manually Google for the correct vSphere configuration maximum document since I can never remember the long URL to the static PDF documents! I am excited to see the improved user experience when consuming our product maximums and I know the team will be working on adding more products and features in the future. Definitely keep an eye on this site and also be sure to update your bookmarks. If you have any feedback or things you would like to see, feel free to leave a comment and I will make sure it reaches the Product and Development teams.

Converting a vSphere Content Library from Subscriber to a Publisher?

by Leave a Comment

This is a blog post on some old Content Library research which I had looked into several months back for a customer inquiry and realized I never got a chance to write about. When you create a Subscriber Content Library (CL) which synchronize content from a Published CL, the Subscriber CL is basically in read-only mode. Not only can you not edit or modify the content, but the CL itself is also locked as a Subscriber forever. Why might this be a concern or an issue?

Consider the following scenario, where you have a single master CL that contains all the images you wish to distribute amongst your remote sites as efficiently as possible and ideally leveraging CL's built-in replication mechanism. Lets say the master CL is in Palo Alto and you have several vCenter Servers that can be configured as Subscriber CLs in Cork, Ireland. Instead of having configuring each Subscriber to pull remotely from PA, why not replicate that to a single Subscriber located in Ireland and re-publish that content locally to the remainder CL? The ideal workflow would look something like the diagram below.

However, today you can not simply convert a Subscriber CL to also become a Publisher CL. The only option that I could think of without relying on something like externally replicating a CL is to create an additional Published CL from the Subscriber CL. The idea is you would clone from your Subscriber CL in the same vCenter Server to a new Publisher CL and then that CL can then be used by the other local Subscriber CL as depicted in the diagram below.

This functionality currently does not exist in the vSphere Web/Flex Client, however it can be automated using the Content Library REST APIs. I had created a Content Library PowerCLI Module a few months back and one of the functions that would be useful for this workflow is the Copy-ContentLibrary.

The function is pretty straight forward to use, it accepts the name of a source CL that has already been configured as a Subscriber CL and the name of a new Published CL that you have created but is empty.


After that, the contents of the source CL will be copied into the destination CL as shown in the screenshot below.


Depending on the size of your CL, this can take some time but once it has completed, you should that your Published CL is now populated with content from your source CL.

The PowerCLI function also does a few additional things such as checking if a file already exists and will skip the file and move on to help with the copy.


If your intention is to only replicate from your master CL and then create a local publisher CL, there is an additional flag that you can set to $true called -DeleteSourceFile which will delete the files from the Subscriber CL. This is useful if you only have a single Datastore in which both the Subscriber and Publisher CL is storing, which means after the CL copy, you would be consuming 2x the storage as everything has been duplicated. For this particular customer, they only required an initial sync to populate content in their EMEA office and after that, they would be managing it local and not require additional replications from their master CL.