svmotion

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

Automatically Remediating SvMotion / VDS Issue Using vCenter Alarms

04.20.2012 by William Lam // 8 Comments

UPDATE 07/13/2012 - vSphere 5.0 Update 1a has just been released which resolves this issue, please take a look here for more details for the patch as this script is no longer required.

In my previous article Identifying & Fixing Virtual Machines Affected By SvMotion / VDS Issue, I provided a script for users to easily identify the impacted VMs as well as a way to remediate them. Though the the issue was only temporarily fixed, as any of the remediated VMs can be re-impacted if they are Storage vMotion again (manually or automatically) by Storage DRS. This meant that users would to re-run these scripts every so often to ensure their environment is not affected by this problem.

I decided to look into a more automated and hands-off approach in which a Storage vMotion of a VM will automatically trigger the execution of the remedation script. I was able to successfully accomplish this by leveraging vCenter Alarms and running a script on the vCenter Server (Here's a cool thing I did with alarms awhile back) .

Disclaimer: This script is not officially supported by VMware, please test this in a development environment before using on production systems.

You can create the alarm at any level of the inventory hierarchy, but I would recommend placing it at least at the datacenter or cluster level. The alarm type will be for a VirtualMachine and it we use "monitor for specific events". For the trigger, we will need to use "VM migrated" and set the status to "Unset" which will not create an alarm icon when it is triggered.

You might wonder why we selected "VM migrated" versus "VM relocated" and this is actually due to the fact that a Storage vMotion starts out just like a vMotion and if you manually perform a vMotion or Storage vMotion, only this event type will be triggered. Due to this single event being triggered by two completely different operations, it has an interesting impact which we will discuss in a bit.

Next we need to create an action for this alarm which will be running a command, you will need to specify the full path to perl.exe (assuming you're using my script which is based on vSphere SDK for Perl and you will need to have vCLI installed on the vCenter Server) as well as the path to the alarm script which in this example is called alarm.pl. Also ensure you set the green->yellow action to execute once.

You will need to create the alarm.pl script on your vCenter Server and here is what it looks like:

#!/usr/bin/perl -w
# William Lam
# http://www.virtuallyghetto.com/

use strict;
use warnings;

my $scriptlocation = "C:\\querySvMotionVDSIssue.pl";
my $server = "localhost"
my $username = "VC-USERNAME";
my $password = "VC-PASSWORD";
my $debug = 0;

###########################
# DO NOT MODIFY PAST HERE #
###########################

my $start1 = "from";
my $start2 = "to";
my $end = ",";

# extract VMware env variables from alarm
my $eventstring = $ENV{'VMWARE_ALARM_EVENTDESCRIPTION'};
my $vmname = $ENV{'VMWARE_ALARM_EVENT_VM'};

my @sourcehost = $eventstring =~ /$start1 (.*?)$end/;
my @destinationhost = $eventstring =~ /$start2 (.*?)$end/;


# Output environmental variables to see what's up
if($debug) {
 open(FILE,"&gt;C:\\output.txt");
 foreach my $key (keys %ENV) {
  print FILE $key . "=" . $ENV{$key} . "\n";
 }
 close(FILE);
}

# if the source/destination host is the same, means we had a Storage vMotion instead of vMotion
# and we execute the remediation script on the VM
if($sourcehost[0] eq $destinationhost[0]) {
 `"$scriptlocation --server $server --username $username --password $password --vmname $vmname --fix true"`;
}

You will need to fill in the script location, in this example I have all scripts stored in C:\ and you will also need to populated the credentials which will be used to execute the script.

Earlier we mentioned that both a Storage vMotion and vMotion trigger the same event and because of that, we need to be able to identify when a Storage vMotion actually happens to run the script. The alarm.pl script above will be executed when the alarm is triggered and using the VMware specific environmental variables that is populated from the vCenter Alarm, we can extract from the event description to figure out whether it was a vMotion or Storage vMotion. Once we confirm it is a Storage vMotion, we then execute our remediation script which is from my previous article.

Note: Ensure you download the latest version of of the querySvMotionVDSIssue.pl from the previous article, as it has been updated to handle single remediation and targeted for this use case.

Now to verify that our alarm is functioning as expected, we can perform a manual Storage vMotion of a VM and we should see our alarm.pl execute and then after the Storage vMotion has completed, we should see some VM reconfiguration tasks which is from our remediation script.

So there you have it, you no longer have to worry about running the script every so often to ensure your VMs are not being impacted by the SvMotion / VDS problem. Again, I would like to stress though we are able to automate this remediation, this is not a real solution and VMware is actively working on a fix for this problem.

If you have any questions, feel free to leave a comment.

Identifying & Fixing Virtual Machines Affected By SvMotion / VDS Issue

04.16.2012 by William Lam // 24 Comments

UPDATE 07/13/2012 - vSphere 5.0 Update 1a has just been released which resolves this issue, please take a look here for more details for the patch as this script is no longer required.

Duncan Epping recently wrote an article about Clarifying the SvMotion / VDS problem in which he describes the scenario that would impact your VMs as well as a way to remediate those impacted VMs. I would recommend you go through Duncan's article before moving any further.

The challenge now, is how to easily identify all VMs that are currently impacted by this problem in your environment? The answer is of course Automation and leveraging the vSphere API! I created the following vSphere SDK for Perl script called querySvMotionVDSIssue.pl which searches for all VMs that are connected to a VDS and checks whether or not it's expected dvPortgroup file exists in the appropriate datastore. To use the script, you just need a system with the vCLI installed or you can just use the vMA appliance.

UPDATE: The script has now been updated to support remediation for VMs connected to both a VMware VDS as well as Cisco N1KV. The solution, thanks to one of our internal engineers was to "move" the VM's dvport from one to another, all while staying within the existing dvPortgroup which will also force the creation of the .dvsdb port file. Once the dvport move has successfully completed, we will move it back to it's original dvport that it initially resided on. We no longer have to rely on creating a temporally dvPortgroup and best of all, we can now remediate both VDS and N1KV. The script now combines both the "query" and "remediation" into single script. Please take a look at the examples below on usage.

Disclaimer: This script is not officially supported by VMware, please test this in a development environment before using on production systems.

Here is a sample output of the script running in "query" mode:

Only impacted VMs will be listed in the output. To remediate, I have combined the remediation script into the query script, if you wish to remediate ALL VMs that were listed as being impacted, you can specify the --fix flag and providing the option "true". This will go ahead and remediate all impacted VMs that were listed as before.

Here is a sample output of the script running in "remediation" mode:

In the screenshot above, you may noticed a few interesting details with VM3 and VM4. If you run out of dvports in a dvPortgroup, the script will automatically increase the number of ports to satisfy the swap (max of 10 due to number of ethernet interfaces a VM can have). Once the VM has been remediated, the dvportgroup will be reconfigured to it's original configured number of ports as shown with VM3.

If you have an impacted VM that is connected to an ephemeral dvportgroup, we will not be able to remediate due to the nature of how an ephemeral binding works. You will get a message on the specific interface and you will need to manually remediate using the steps outlined by Duncan or using the "old" remediation script which will create a temporally dvPortgroup (again, this will only work for VMware VDS' only).

If you run into any issues or have questions, feel free to leave a comment.