In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!
Build DC VM without network or Internal network and then redeploy and place onto a teamed fabric
Hey All,
Trying to get ahead of the game build a virtual environment as I am upgrading from physical to a HyperV Host for all roles.
Servers not here yet, so was going to start building the DC VMs on another server and either use NOT CONNECTED or create an internal Virtual Switch and use this while I build the DC, DNS, DHCP .. VM.
Then when servers are here, move onto the server and after using Converged Fabric for teaming and setting up an External VSwitch on this.
Sound all good, or will I come into problems when building the DC or after I move it.
Trying to get things ahead as I only have the weekend to build.. Which option would you choose?
Many thanks in advance
R
Trying to get ahead of the game build a virtual environment as I am upgrading from physical to a HyperV Host for all roles.
Servers not here yet, so was going to start building the DC VMs on another server and either use NOT CONNECTED or create an internal Virtual Switch and use this while I build the DC, DNS, DHCP .. VM.
Then when servers are here, move onto the server and after using Converged Fabric for teaming and setting up an External VSwitch on this.
Sound all good, or will I come into problems when building the DC or after I move it.
Trying to get things ahead as I only have the weekend to build.. Which option would you choose?
Many thanks in advance
R
Asked:
2-
2
2 Solutions
But a Private one could suffice for the build and then change it when I move onto the actual Host?
Thanks
R
Thanks
R
Yes, as long as you have some networking communication between ALL servers, however you implement it does not matter.
To be clear, when you create an internal switch and create the VM, the VM will get its own virtual NIC. The details of which will differ depending on whether the VM is gen1, gen2, or if a legacy adapter is added to the VM properties...all are independent of the switch.
Then if/when you change over to an external switch and bind that switch to a team, the *VM's* virtual NIC is remaining unchanged. This is equivalent to taking a physical server and plugging it into a new unmanaged switch. The VM won't know or really care. It has the same NIC so no binding or IPv4/6 properties change.
This is true for a VM that is a DC as well as any other VMs you create. They can be "plugged into" the same virtual switch or different virtual switches. Hyper-V definitely makes a separation between the virtual NICs that VMs use and virtual switches that run within the hypervisor itself. This increases reliability and portability, and addresses exactly concerns such as yours.
Then if/when you change over to an external switch and bind that switch to a team, the *VM's* virtual NIC is remaining unchanged. This is equivalent to taking a physical server and plugging it into a new unmanaged switch. The VM won't know or really care. It has the same NIC so no binding or IPv4/6 properties change.
This is true for a VM that is a DC as well as any other VMs you create. They can be "plugged into" the same virtual switch or different virtual switches. Hyper-V definitely makes a separation between the virtual NICs that VMs use and virtual switches that run within the hypervisor itself. This increases reliability and portability, and addresses exactly concerns such as yours.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
Join & Write a Comment Already a member? Login.
Featured Post
Tackle projects and never again get stuck behind a technical roadblock.
Join Now
the VMs will need to have network communication between them, so virtual switch required.