Hi,
Looks like hyper-v management cmdlets have process layer caching where status of vms reported is incorrect if cmdlets are executed from .Net code using the same runspace and if the state of the vm is modified from external powershell window. An example illustrating
this issue:
- Let's say VM-1 is in stopped state and getting from .Net code returns the correct state. (Stop-VM VM-1 from service)
- State of VM-1 is changed from stopped to running using a different powershell window. (Start-VM VM-1 from powershell)
- Querying for the state of VM-1 from .Net service still returns "Stopped" instead of "Running" (Get-VM VM-1 returns Stopped). Further if Stop-VM is executed from the service using the same runspace at this point, the cmdlet fails with
the following warning.
WARNING: The virtual machine is already in the specified state.
This suggests that there is a process level caching for hyperv cmdlets. This can however be overridden using Disable-VMEventing as documented at https://technet.microsoft.com/en-us/library/hh848571.aspx.
The Disable-VMEventing cmdlet
disables virtual machine eventing on a Hyper-V host or hosts. Virtual machine eventing keeps Hyper-V PowerShell objects updated without polling the virtual machine host. Virtual machine eventing is enabled by default.
Question:
Is there any performance impact with using Disable-VMEventing? Are there any other side effects of the same?
This is Windows Server 2012 R2. Any help regarding this issue will be helpful.