Managed Object Browser

How to easily disable vMotion & Cross vCenter vMotion for a particular Virtual Machine?

07.20.2016 by William Lam // 6 Comments

The question of disabling vMotion for a specific set of Virtual Machine(s) is not a new one. In fact, this topic comes up on some what of a frequent basis and usually driven by arcane change management processes or worse licensing restrictions. Do not get me wrong, there are definitely some valid use cases where you would not want a particular VM to be migrated off. The classic example is a 3rd Party VM solution that provides Anti-Malware, Intrusion Detection & Firewall capabilities for your workload VMs. For this particular use case, VMware provides our partners with an integration hook into the vSphere platform called ESX Agent Manager (EAM) that ensures these "Service VMs" are not allowed to be powered off or migrated to another ESXi host, even in the case of a Maintenance Mode operation. This solutuion even allows you to configure custom icons for your Service VMs!

For all other use cases outside of the "Service VMs", there really is not an easy way of disabling vMotion for a particular VM. There have been many solutions that have been suggested in the past ranging from disabling DRS for a specific VM, DRS Affinity Rules, VM miss-configurations to break vMotion compatibility to using vSphere Permissions to prevent vMotion operations. However, many of these solutions do not work very well or is very difficult to manage at scale. I actually like the idea of using vSphere Permissions to prevent a vMotion, however, I have seen some customers push back on this because the vSphere Administrator still has the ability to perform this operation. For these cases, customers just want to be able to completely disable vMotion for a given VM and prevent anyone from migrating the VM, including the vSphere Administrators.

Given that this topic had recently come up again, I was wondering if there was an easier way in which this could be achieved and made more manageable for our customers. After thinking about about how EAM handles "disabling" certain operations for a VM and recalling an article I wrote last year which leveraged this exact capability to resolve an NSX Controller issue, I thought why not apply it to this use case here?

UPDATE (09/27/18) - As of vSphere 6.5, the MigrateVM_Task() method has been deprecated in favor of the RelocateVM_Task() which is used to handle BOTH vMotion, Storage vMotion and other variants. This means that as of 6.5, you no longer have the ability to disable a specific migration type and when you apply the settings, both migration types will be disabled for the specific VM.

Disclaimer: The use of internal APIs are not officially supported by VMware and can change at any time. Please use at your own risk.

Each VM has a property called DisableMethod which lists the specific vSphere API methods that are currently disabled. These are not governed by vSphere Permissions but rather the runtime state of the VM. For example, if you have a VM that is currently powered on, then the PowerOnVM_Task API would not be available and would show up in the disabled list.

Here is a quick PowerCLI snippet on how to retrieve the current set of disable methods for a VM:

$vm = Get-Vm -Name TestVM-1
$vm.ExtensionData.DisabledMethod

As mentioned in this article, the ability to enable and disable these methods are only available as an internal vCenter Server API. However, it is possible to access these APIs using the vSphere MOB, but it is not very user friendly nor intuitive. Below is a screenshot of invoking the disableMethods API using the vSphere MOB.

A couple of weeks back I started to investigate on how we might be able to automate against the vSphere MOB. The result of that investigation lead to the creation of a simple PowerCLI script that allows you to automate operations using the vSphere MOB which I had published here. That work became the foundation for the new PowerCLI script that I had created for disabling and enabling the vMotion capability for a particular VM.

You can download the PowerCLI script here called enable-disable-vsphere-api-method.ps1 which includes two functions Enable-vSphereMethod and Disable-vSphereMethod. You will need to edit the script to provide a couple of pieces of information.

Credentials to your vCenter Server
Name of the VM you wish to either disable or enable vMotion capability on
Name of the vSphere API method you wish to disable (by default this is MigrateVM_Task which maps to the vMotion capability)

By default, I have commented out both functions usage, you will need to manually uncomment one of the lines based on the operation you wish to perform.

To Disable the vMotion capability, run the following:

Disable-vSphereMethod -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password -vmmoref $vm_moref -disable_method $method_name

To Enable the vMotion capability if you had disabled it, run the following:

Enable-vSphereMethod -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password -vmmoref $vm_moref -enable_method $method_name

After the script has completed, you can now re-run the command that we ran earlier to see which methods have been disabled and you should see that the MigrateVM_Task is now part of the disable methods.

If we now login to either the vSphere Web/C# Client and right click on the VM that we had disabled vMotion on, you should also see that the Migrate option is now grayed out and unavailable. This behavior will be true for ALL users including those in the vSphere Administrators group.

It is important to note that vMotion is not only disabled from the UI, but it is also disabled from the vSphere API standpoint which the UI is built on top of. Here is an example of trying to perform a vMotion using the PowerCLI Move-VM cmdlet and you can see that an error is thrown immediately stating that the method has been disabled.

Note: The "self" text output from the PowerCLI command is actually something that you can specify as part of disabling the vMotion capability. This might be useful to specify a change control ID or some string to signal to the user who might be trying to perform the operation. Please refer to the script and search for the "self" keyword if you wish to change it.

The really nice thing about this solution is not only is it really easy to enable or disable, but it can also be managed at scale which many of the other solutions mentioned earlier start to break down. The last thing anyone would want is additional operational overhead to manage manage complex DRS rules (which can still be overridden through manual migrations) or additional vSphere Permissions which also runs into the same problem where a vSphere Administrator can still override by performing a manual migration. This solution does prevent both standard vMotion as well as the new Cross vCenter vMotion capability (both between same/different SSO Domain) that was introduced in vSphere 6.0. You do not need to be running vSphere 6.0 to be able to leverage this solution, this should actually work for almost all versions of vSphere. Lastly, enabling or disabling the functionality does not require any type of system restart or impact to your VM other than the ability to vMotion.

Limitations

Beyond artificially limiting what vSphere DRS and HA can do, I did observe an interesting behavior when a Maintenance Mode operation is performed. If you leave the "Move powered-off and suspended virtual machines to other hosts in the cluster" uncheck, then all VMs will be migrated off and the VMs that have vMotion disabled will reside on the ESXi host while it goes into Maintenance Mode. However, if you do check the box, I did find that the system would override setting and actually move the VM to another ESXi host. This is something to be aware of and may not be a bad thing depending on your requirements.

Disabling Storage vMotion

You may have noticed that if the VM is in a powered off state, that the Migrate option is still available in the UI. The reason for this is that we only disabled vMotion but you are still allowed to perform a Storage vMotion. If you wish to also disable the Storage vMotion capability, then you will need to disable RelocateVM_Task vSphere API method as well.

Auditing vMotion and Storage vMotion Operations

With or without this solution, you may still want another level of confidence that a VM has either not migrated or migrated to authorized set of ESXi hosts. We can easily do so by auditing the VM's Event system and looking for migration events. The name of the vMotion event is called VmMigratedEvent and the name of the Storage vMotion event is called VmRelocatedEvent. Here is a sample script using the vSphere SDK for Perl that exercises this specific vSphere API and provides you with all the ESXi hosts a given VM might have migrated to. For those that rather consume the vSphere API using something like PowerCLI, here is a quick one-liner to extract vMotion events:

$vm = Get-VM TestVM-2
Get-VIEvent -Entity $vm | Where { $_.Gettype().Name -eq "VmMigratedEvent"} | Select CreatedTime, UserName, FullFormattedMessage | ft -wrap -AutoSize

How to automate vSphere MOB operations using PowerShell?

07.13.2016 by William Lam // 5 Comments

A couple of weeks back I was investigating something that involved the use of the vSphere Managed Object Browser (MOB) and I needed to automate a particular operation. For those of you not familiar with the vSphere MOB, it is a UI debugging tool that allows you to visualize and invoke vSphere APIs using just a web browser. The vSphere MOB is available on both vCenter Server and ESXi and uses the underlying vSphere API. Outside of learning about the vSphere APIs and potentially for troubleshooting purposes, there really is no good reason to be directly interacting with the vSphere MOB on a regular basis. Customers can use any one of the many vSphere SDK/CLIs to easily automate and interact with the vSphere API.

Having said that, there may be cases where you might want to invoke a specific operation using the vSphere MOB, such as private API for example. Obviously, using any private/internal APIs is not officially supported by VMware and their use will be at your own risk. Nonetheless, I had a specific operation that I needed to call from the vSphere MOB and wanted to do so using PowerShell. Several years back I had demonstrated how you could invoke the vSphere MOB using Python but I could not find any PowerShell examples that actually worked. I figured this would be a good learning opportunity for myself and probably something I or others could benefit in the future.

To provide a concrete example, I will be invoking a supported vSphere API called the QueryOptions which is used for accessing either a vCenter Server or ESXi Advanced Settings. For our example, I will be connecting to the vCenter Server's MOB and will be querying for a specific vCenter Server Advanced Setting. If we were to do this manually in the vSphere MOB, we would first open a web browser and login to the following URL: https://[VC-SERVER]/mob/?moid=VpxSettings&method=queryView

If you wanted to see all advanced settings, you would leave the "name" parameter blank. For our example, we will query for the VirtualCenter.InstanceName property as shown in the screenshot above and then click on the "Invoke Method" to execute the vSphere API operation. If successful, it should display the results which in our case is the IP Address of my vCenter Server. Pretty straight forward vSphere MOB example. OK, onto automating this from PowerShell. I have created a sample PowerShell script called automate-vsphere-mob.ps1 which you will need to edit and provide your vCenter Server Hostname/IP Address and the vCenter Server credentials (can be read-only) since we are not performing any write operations.

Here are some more specific details on what is happening in the script for those interested:

Authenticate to the vSphere MOB URL that you wish to invoke using an HTTP GET operation and storing the session into a variable named vmware (Line 28-29)
Extract the hidden vmware-session-nonce property used to prevent Cross-Site Request Forgery (CSRF) (Line 31-40)
Create the body request which must include the vmware-session-nounce property along with the vSphere API payload (Line 42-45)
Invoke the actual vSphere API call using an HTTP POST along with the existing session from Step 1 and body payload
Process the results (this will be specific to API call) and profit! (Line 50-59)

If you now run the script, you will see that the result is exactly what we saw from interactively using the vSphere MOB. Hopefully this will be useful for anyone who may have a need to automate against the vSphere MOB. For those curious on what I was investigating with the vSphere MOB, stay tuned for more details 🙂

How To Initiate a Wipe & Shrink Operation On an SE Sparse Based Disk

09.10.2012 by William Lam // 6 Comments

In my previous two articles, I showed you how to create your own SE Sparse disks as well as creating new virtual machine Linked Clones leveraging the new SE Sparse disk format. If you recall earlier, one of the features of the SE Sparse disk format is to provide the ability to reclaim unused blocks within the guestOS which is a two step process: wipe and shrink.

Here is a screenshot that describes the process which was taken from the What's New In vSphere 5.1 Storage Whitepaper by my colleague Cormac Hogan. I highly recommend you check out the whitepaper which includes more details about this feature and other storage improvements in vSphere 5.1

The process of kicking off this wipe and shrink operation will be done through an integration with VMware View (a future release from my understanding). Now, it's important to understand that it's not just simply calling these two operations but it is also when they are called. The wipe operation is more CPU intensive as it scans for unused space within the guestOS filesystem and the shrink operation is more I/O intensive as it issues the SCSI unmaps commands. I can only assume that these operations will be scheduled based on the utilization of the guestOS to help reduce the impact to the VM workload.

Now having said that, since the SE Sparse disk format is a feature of the vSphere 5.1 platform, so are both the wipe and shrink operations. Though they are not exposed in the public vSphere API like the SE Sparse disk format, you can still access the private APIs if you know where to look 😉

Disclaimer: This is for educational purposes only, this is not officially supported by VMware. Use at your own risk.

With some help from my good friend the vSphere MOB and some digging, I have located the two vSphere API methods for wipe and shrink operation. Before getting started, ensure you have a VM with at least one SE Sparse disk, else these commands will not be very useful.

Note: In this experiment, I tested the wipe and shrink operation with Windows XP image, this may or may not work on other OSes.

First you will need to search for the VM in question and retrieve it's vSphere MOB URL which is in the format of https://[vcenter-server]/mob/?moid=vm-X where X is the MoRef ID for your VM. You can either navigate through the vSphere MOB or use my MoRef finder script.

Wipe Operation

To issue the wipe API, enter the following URL into your web browser (remember to replace the MoRef ID with the one of your VM)

https://[vcenter-server]/mob/?moid=vm-X&method=wipeDisk

Here is a screenshot of what that looks like if you are able to successfully access the private API:

Go ahead and click on "Invoke Method" which will then execute the wipe operation. If you take a look at the vSphere Web Client, you should now see a new task for the wipe operation.

This can take a bit of time as it scans through the guestOS filesystem for unused space.

Shrink Operation

Once the wipe operation as completed, we then need to issue the shrink API. Enter the following URL into your web browser (remember to replace the MoRef ID with tone of your VM)

https://[vcenter-server]/mob/?moid=vm-X&method=shrinkDisk

Here is a screenshot of what that looks like if you are able to successfully access the private API:

Here you can specify particular disks (requires diskId) that you wish to perform the shrink operation on. If you leave it blank, it will try to shrink all disks associated with your VM. In our example, I will shrink all disks. Go ahead and click on the "Invoke Method" which will kick off the shrink operation. If you go back to the vSphere Web Client, you should now see a shrink task in progress.

Again, this operation can also take some time, but once it has finished, then you have successfully reclaimed any unused blocks within your guestOS.