locked
Moving a Hyper-V group between nodes sometimes leaves artifacts of virtual machines on the other node in saved state RRS feed

  • Question

  • We have a two-node Server 2008 cluster with SAN-based shared storage.  We pass the cluster compatibility checks with flying colors.  We have all of the hotfixes that I know of applied, including Hyper-V final, and the KB951308 cluster update.

    We have created a couple of groups with virtual machines in a multiple VM's per lun arrangement, and everything seems to be working fine, but occasionally after failing a group between nodes, one of the VMs of the group will still be listed on the old node, even though the entire group, including the one that is shown on the old node, is correctly running on the new node.  The erroneous VM is listed in a "saved" state, and no amount of refreshing seems to clear it.

    Occasionally I can delete the extra VM, but usually not.  I typically get an error saying "An error occurred while attempting to delete the selected virtual machine(s).  The operation on the computer XYZ failed."

    This has happened with multiple VMs, on both of our similarly-configured clusters.

    We've had a couple of variations on this problem:

    Sometimes moving the group back to its correct node will clear the old object.

    Other times when moving the group back to its correct node will cause there to be two objects with the same name.  This goofs up my Powershell scripts.

    Any thoughts?  Failover Cluster Manager doesn't show anything out of the ordinary.

    Thanks,

    TJ

    Friday, January 23, 2009 10:18 PM

Answers

  • When this happens, Stop and then restart the Virtual Machine Management service on the node exhibiting the problem.  You should close out of teh Hyper-V snap-in before doing this.  After re-start, open the snap-in again and see if the problem is corrected. 
    Chuck Timon Senior, Support Escalation Engineer (SEE) Microsoft Corporation
    Tuesday, January 27, 2009 2:15 AM

All replies

  • When this happens, Stop and then restart the Virtual Machine Management service on the node exhibiting the problem.  You should close out of teh Hyper-V snap-in before doing this.  After re-start, open the snap-in again and see if the problem is corrected. 
    Chuck Timon Senior, Support Escalation Engineer (SEE) Microsoft Corporation
    Tuesday, January 27, 2009 2:15 AM
  • Thanks for that workaround - I'll try it next time it comes up.  Is this a known issue?  This is happing reasonably frequently on very clean new builds.  Will there be a permanent fix?

     

    Wednesday, January 28, 2009 8:00 PM
  • Mostly intermittent.  No fix for this becasue it is not consistent enough and there is a workaround.  It is 'cosmetic' and does not impact functionality.
    Chuck Timon Senior, Support Escalation Engineer (SEE) Microsoft Corporation
    Friday, January 30, 2009 1:59 AM