none
After KB4012219 Install Live Migration Changes Permissions on SMB Share for Hyper-V

    Question

  • I believe I've discovered a bug caused by installing KB4012219 under my configuration.  I'll try to give as much detail as possible.

    My Setup:

    2-Node Windows Server 2012 R2 Cluster running Storage Spaces
    - 8.5 TB CSVFS Volume created
    - Scale-Out Share created called VMs1
    - Full Permissions granted on the VMs1 share to Hyper-V Servers (HV1 and HV2), SYSTEM, and Cluster Name as recommended here https://technet.microsoft.com/en-us/library/jj134187(v=ws.11).aspx#BKMK_Step3

    2-Node Windows Server 2012 R2 Cluster running Hyper-V Server
    - vhdx files and Virtual Machines stored on VMs1

    This setup has been up and running with no issues for over 18 months.  It's a low usage/dev setup, but live migrations are performed when updates are run or randomly for testing and there haven't been issues for as long as I can remember.

    This week after installing all updates including the recommended update KB4012219 (March, Monthly Preview Update) I was running into issues live migrating VMs from node to node.  In Failover Cluster Manager it would just fail to move with no message.  In the Event Viewer I was getting Event IDs 1205 and 1069 from FailoverClustering and Warnings 21501 from Hyper-V-High-Availability. I noticed that 1069 referenced "access denied" so that led me to checking permissions on the VMs1 share on the storage cluster.  I noticed that HV1$ and HV2$ computer accounts no longer had full access to the share.  They now had "Special Permissions" listed with essentially Read and Execute on "This Folder and Subfolders".

    I made note of the current settings and reset the permissions giving HV1$ and HV2$ full access to "This folder, subfolder, and files".  After making this change I was able to live migrate a VM from HV1 to HV2.  However, when I tried to migrate back from HV2 to HV1 it failed.  I went back to the Storage sever and checked permissions and they had changed back to Read and Execute.  I changed them again, and was again able to migrate.

    For brevity I'll skip a few things I tried, but ultimate I started to suspect the update may be the culprit.  I uninstalled KB4012219 from HV2 and rebooted.  Then I migrated all VMs to to HV2 (having to reset the permissions before doing each server).  I uninstalled KB4012219 from HV1 and rebooted.  After both servers were back up and running I was able to live migrate back and forth between servers dozens of times for testing.  I checked permissions on the share and they were staying as I had set them.

    Thinking maybe it had been a fluke with the update, and because it contains many other updates/fixes, I tried to reinstall the update on HV1.  After reinstalling I could migrate all the servers back to HV1 from HV2, but as soon as I migrated one server to HV2 it reset the permissions on the share so that HV2$ only had Read and Execute and thus I could no longer migrate other servers back to HV2

    I've uninstalled KB4012219 from HV1 again and all is working as expected for now.  However, I don't know what to do from here.  If this is a bug not just affecting me, as I suspect, I'm not sure how/where to report it.  When the updates contained in this "preview" become readily available next month as full updates I'm not sure that I will be able to hold off installing other things included with the roll-up package.

    Thanks to anyone that took the time to read this and I appreciate any feedback and/or suggestions.


    Friday, March 31, 2017 3:48 AM

All replies

  • Hi Sir,

    Does this issue can be reproduced by using "quick migration" ?

    ( In my lab , it is a embedded virtualization lab , the 2012 R2 VM won't startup )

    Best Regards,

    Elton


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Monday, April 03, 2017 5:44 AM
    Moderator
  • Before I rolled back the update, yes, even if I did a quick migration the VM would not startup on the other host server until I made the permission change.
    Monday, April 03, 2017 3:06 PM
  • Hi Sir,

    There are two clustered hyper-v servers , one node of the cluster was installed latest windows updates (include KB4012219) .

    But the issue didn't arise during quick migration in my lab .

    The difference in my lab is the file share is a domain joined windows server .

    Have you tried to put the VM on a simple SMB share for test ?

    Best Regards,

    Elton


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, April 04, 2017 2:22 AM
    Moderator
  • I had the same problem. I removed the update and now everything is working properly. I am going to do some more research into this but I'm surprised I'm not seeing more about this when doing a Google search.

    Tuesday, April 18, 2017 5:41 PM
  • For what it's worth I'm also still having this issue now with the April update KB4015550.  I tried installing it on one node of the cluster.  When I try to live migrate a server back and forth to that node the permissions on the share get changed and I have to manually fix them.  I uninstalled KB4015550 and all is well. I'm also surprised I haven't found more about this. I'm close to opening up a support ticket with Microsoft.
    Monday, May 01, 2017 2:55 PM
  • I am having the same problem with KB4015550. The strange thing is that I have a similar setup at home (2 node Hyper-V cluster with an EQL SAN) and it gave me no problems. There must be something unique to our installations.

    If you find a solution, please post.  I will do the same.

    Brian

    Tuesday, May 09, 2017 12:40 PM
  • I checked my event logs and I am not getting the same event ids even though I am having similar symptoms.  I have two host servers (HS2 and HS3).  I paused HS2 and migrated all the VMs to HS3, applied KB4015550 to HS2 and rebooted.  When I resumed HS2 and tried to live migrate the VMs back to it, they failed.  I was able to Quick Migrate them but some machines crashed when they started up on the other server but then booted up ok.  After that the ones with their storage and config files on CSV 1 would migrated back and forth with no errors.  However the ones with storage and config on CSV 2 would always fail when trying to LM from HS3 to HS2.  They would only LM from HS2 to HS3.  When I uninstalled KB401550 from HS2, everything works fine.

    The Errors and Warnings that appear to be related are listed below for each server:

    HS2

    Hyper-V-VMMS: Event ID 21002: The description for Event ID 21002 from source Microsoft-Windows-Hyper-V-VMMS cannot be found.

    Hyper-V VMMS: Event ID 21028: Virtual machine migration for 'xxxx' failed because configuration data root cannot be changed for a clustered virtual machine. (Virtual machine ID E69D5314-88AA-4DF4-9881-BAE03A81D3E3)

    WMI: Event ID 63: A provider, NetEventPacketCapture, has been registered in the Windows Management Instrumentation namespace root\standardcimv2 to use the LocalSystem account. This account is privileged and the provider may cause a security violation if it does not correctly impersonate user requests.

    HS3

    Hyper-V-VmSwitch: Event ID 113: Failed to allocate VMQ for NIC B79CB906-415B-43DD-8A03-6B42D6B3B8E2--114F6DFF-1A36-4B55-96C9-014B95EE7E17 (Friendly Name: Network Adapter) on switch 40979F9C-DCA1-4D7C-A616-23A179B584DC (Friendly Name: VMSwitch). Reason - Maximum number of VMQs supported on the Protocol NIC is exceeded. Status = Insufficient system resources exist to complete the API.

    Hyper-V-VMMS: Event ID 20406: The description for Event ID 20406 from source Microsoft-Windows-Hyper-V-VMMS cannot be found.

    Brian

    Tuesday, May 09, 2017 5:26 PM
  • sapalmerBCS,

    I have created a new question

    https://social.technet.microsoft.com/Forums/en-US/63c6ed94-fbf6-48a1-bab0-1565c8f14652/live-migration-fails-after-kb4012219-kb4015550-or-kb4019215?forum=winserverhyperv

    I don't know if my root cause is the same as yours and I am also getting the issue with KB4019215.

    Brian

    Monday, May 15, 2017 3:49 PM