WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

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

disable-vmotion-for-vm-1
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.

disable-vmotion-for-vm-0
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.

  1. Credentials to your vCenter Server
  2. Name of the VM you wish to either disable or enable vMotion capability on
  3. 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.

disable-vmotion-for-vm-5
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.

disable-vmotion-for-vm-3
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.

disable-vmotion-for-vm-4
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.

disable-vmotion-vm-6

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

disable-vmotion-for-vm-5

Categories // Automation, PowerCLI, vSphere, vSphere Web Client Tags // Cross vMotion, disableMethods, enableMethods, ExVC-vMotion, Managed Object Browser, MigrateVM_Task, PowerCLI, RelocateVM_Task, Storage vMotion, svmotion, vSphere, vSphere MOB, xVC-vMotion

Unable to apply VSAN VM Storage Policy on NSX Controller/Edge VMs?

01.07.2015 by William Lam // 6 Comments

This post was inspired by a recent Twitter conversation with Joep Piscaer who ran into an interesting challenge with VSAN and NSX.

I want to apply a VSAN VM Storage Policy to a NSX Controller, but I’m getting an "The method is disabled by ‘vShield_SVM’” error. Any ideas?

— Joep Piscaer (@jpiscaer) December 31, 2014

The issue that Joep encountered was not being able to apply a VSAN VM Storage Policy onto an NSX Controller VM which resided on a VSAN Datastore. Below is a screenshot of the error message "The method is disabled by vShield_SVM" if you tried to apply the VM Storage Policy.

disabled_methods_on_vms_1
The reason Joep is seeing this error is because the NSX Controller VM is a special "Service VM" that is being managed by a specific solution, in this case it is VMware NSX. To ensure that users do not accidentally modify these "Service VMs", certain set of functionality has been disabled on these VMs from regular users. Any configuration changes that are required are initiated through the solution itself which has full administrative access to these VMs. This issue is actually not specific to the NSX Controller VMs but also applies to the NSX Edge VMs: ESR (Edge Service Router) and DLR (Distributed Logical Router).

In fact, this applies to any "Service VMs" which are being managed by a VMware Solution or 3rd party Solution. You will notice that you will not be able to edit these VMs like you would normally on other VMs. One suggestion from a community member was to check out the VMware KB 2008957 which has users manually tweaking the VCDB, which I am not a big fan of if I can help it. If you want to know why I do not recommend this, check out this post here where kittens might get harmed. Now, getting back to Joep's request, is there a solution for him? After all, his request is a valid one where he has deployed an NSX Controller VM on a VSAN Datastore and wishes to apply a specific VSAN VM Storage Policy.

Luckily, there is cleaner work around that does not involve messing around with the VCDB and crafting ugly SQL queries. The way these "methods" or operations are disabled on a particular set of VMs is through the use of a private vSphere API available through vCenter Server called disableMethods. You can actually view the list of disableMethods by viewing a particular VM using the vSphere MOB under config->disableMethod property as seen in the screenshot below.

disabled_methods_on_vms_2
The list of disableMethods map to the specific vSphere API calls for a VM and in the case of modifying a VM which includes applying a VM Storage Policy, the method that is used is is called the ReconfigVM_Task which we can see in the screenshot mapping to vim.VirtualMachine.reconfigure. If we want to be able to apply a VM Storage Policy, we simply just need to temporarily remove this particular operation from the disabbleMethods list.

Here are the instructions for enabling ReconfigVM_Task method:

Step 1 - You will need to find the MoRef (Managed Object Reference) ID of the VM that you wish to enable the method on. You can do this by either browsing through the vSphere MOB, using this vSphere SDK for Perl script or this PowerCLI snippet:

Get-VM -Name [VM-NAME] | ft -Property Id

Step 2 - Open a web browser to the following URL:

https://[VC-IP]/mob/?moid=AuthorizationManager&method=enableMethods

Step 3 - You will need to replace the following two parameters (make sure to replace the VM MoRef ID with the one you found in Step 1):

parameter value
entity <entity type="ManagedEntity" xsi:type="ManagedObjectReference">vm-35</entity>
method <method>ReconfigVM_Task</method>

Step 4 - Once you have updated fields as shown in the screenshot below, to execute the API call you just need to click on the "Invoke Method" link on the bottom right.

disabled_methods_on_vms_3
If everything was successful, you should see some output from the operation listing the methods that are still currently disabled. You can also confirm that everything is working by refreshing the vSphere Web Client or if you are using the vSphere C# Client, the "Edit Settings" option should now be available. Lastly, if I now apply a VSAN VM Storage Policy, I will no longer get the error and as you can see from the screenshot below, I now have successfully applied my "VSAN-Platinum-VM-Storage-Policy" for my NSX Controller VM. I would strongly recommend that you re-enable the original disable method by following the instructions below.

disabled_methods_on_vms_4

Here are the instructions for disabling ReconfigVM_Task method:

Step 1 - You will need to find the MoRef (Managed Object Reference) ID of the VM that you wish to enable the method on. You can do this by following Step 1 from the enable instructions

Step 2 - Open a web browser to the following URL:

https://[VC-IP]/mob/?moid=AuthorizationManager&method=disableMethods

Step 3 - You will need to replace the following three parameters (make sure to replace the VM MoRef ID with the one you found in Step 1 and any random number works for sourceId property):

parameter value
entity <entity type="ManagedEntity" xsi:type="ManagedObjectReference">vm-35</entity>
method <DisabledMethodRequest><method>ReconfigVM_Task</method><DisabledMethodRequest>
sourceId 1234

Step 4 - Once you have updated fields as shown in the screenshot below, to execute the API call you just need to click on the "Invoke Method" link on the bottom right.

disabled_methods_on_vms_5
If everything was successful, you should see a void output and if you go to your vSphere Web/C# Client, you should see that the "Edit Settings" option is now disabled again for this VM. Though applying a VSAN VM Storage Policy is pretty trivial, there are some additional things to be aware of when working with special "Service VMs" like the NSX Controller. Hopefully we can improve this workflow in the future and provide for a better user experience but in the mean time, you can use this workaround.

Categories // Automation, ESXi, NSX, VSAN Tags // disableMethods, enableMethods, mob, NSX, vm storage policy, vm storage profile, VSAN

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...