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
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
As long as you have network connectivity between servers and services, in virtual world or physical, there will be no issues.
the VMs will need to have network communication between them, so virtual switch required.
the VMs will need to have network communication between them, so virtual switch required.
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.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial