• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

2008R2 cluster (yeah, I know) - Rename of vnetwork

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    2008R2 cluster (yeah, I know) - Rename of vnetwork

    I've inherited a 2008R2 cluster which isn't able to move VMs. The vNET adaptor name is different between nodes so the moves fail.


    The fix is straightforward enough: rename the vNET to match the other node(s). However... documentation is light on the fall out from this situation and its not something I have needed to do on a prod environment before.

    Question:
    Is a reboot required after the name change (either VM(s) or node(s) ) or just a refresh of VM config to pick up the new name?


    Follow up Q:
    If the latter (refresh only), will the guest VMs continue to function between name change and refresh? (already knowing that moves will not - that's what's getting fixed)


    Cheers in advance!

    M

    #2
    Originally posted by mjcp View Post
    I've inherited a 2008R2 cluster which isn't able to move VMs. The vNET adaptor name is different between nodes so the moves fail.


    The fix is straightforward enough: rename the vNET to match the other node(s). However... documentation is light on the fall out from this situation and its not something I have needed to do on a prod environment before.

    Question:
    Is a reboot required after the name change (either VM(s) or node(s) ) or just a refresh of VM config to pick up the new name?


    Follow up Q:
    If the latter (refresh only), will the guest VMs continue to function between name change and refresh? (already knowing that moves will not - that's what's getting fixed)


    Cheers in advance!

    M
    I would reboot everything and see what comes back up. Name changes and WSFC don't tend to play nice.

    Any help here? :

    Change the node names of a Windows cluster – SQLServerCentral

    Step-by-Step: Configuring a 2-node multi-site cluster on Windows Server 2008 R2 – Part 1 – Clustering For Mere Mortals

    qh
    He had a negative bluety on a quackhandle and was quadraspazzed on a lifeglug.

    I look forward to your all knowing and likely sarcastic and unhelpful reply.

    Comment


      #3
      Originally posted by quackhandle View Post

      Google Uni has a few results, but none for prod environments and therefore, has liberal use of reboots 'cos its windows and that's what we do ;-)


      Re the above links - I need to rename the vNET, not the nodes and the 2nd has a step for renaming the vNETS as part of the setup (which whomever set these up, didn't do!) Annoyingly, you can validate the cluster without them matching and I guess testing the failover aspects didn't occur to the previous keepers!

      Cheers! M

      Comment


        #4
        Not sure I can help, but you haven't said if its a Hyper-V cluster (sounds like it is one) and your vNET is the network defined in Hyper-V not at the WSFC level?

        Comment


          #5
          Originally posted by CheeseSlice View Post
          Not sure I can help, but you haven't said if its a Hyper-V cluster (sounds like it is one) and your vNET is the network defined in Hyper-V not at the WSFC level?

          It is a HV cluster.

          Yes, the name inconsistency IS between the vNETs between the two nodes in Hyper-v.

          Fortunately this site is quite a small environment, so removing from HA and lift/shift moves are do-able (and they haven't had functioning failover anyway, so not something they will miss!)... but would prefer 10 mins of rename and refresh vs a few hours of manual moves...

          Cheers,
          M

          Comment

          Working...
          X