TagvDS

Migration of a Distributed Switch to a new vCenter – Important Things to Know

I promised an article on this topic several times and finally I found the time to do some further testing on this issue I saw a few months ago.

With a customer I had this discussion of how to migrate to a newly created vCenter while keeping ESXi hosts running with the old distributed switch. (There might be several reasons, e.g. migrating the vCenter & DB to a new OS, data-loss and recovery problems, migration p2v or v2p, etc.)

Starting out with a vCenter 5.0, we were thinking about ways to achieve a seamless migration. We came up with 4 solutions:

  1. Migrate virtual machines from vDS to vSS. Then connect ESXi servers to the new vCenter, create a new vDS and migrate VMs back to vDS. Since this can get very complex and also prune to mistakes in a larger environment, we looked for other possibilities….
  2. Automating those steps via scripts… Gabrie van Zanten have written about this and distributed a script for exactly this scenario
  3. The third idea was to check if we can export the vDS settings out of the vCenter database and include it in the new instance…. Since I work around directly in databases only when I see no other options the last idea came in mind by using a new feature in vSphere 5.1
  4. Upgrade the old vCenter… Install a new vCenter 5.1 and use the export/import feature of the web client like it’s explained here

This new feature was exactly what we were looking for…. unfortunately it never really worked out in my environment…

In my opinion the following process should do what I want:

  1. Backup the vDS on the old vCenter
  2. Restore the vDS on the new vCenter (preserve the original distributed switch and port group identifiers)
  3. Disconnect and remove the ESXi hosts from the old vCenter
  4. Connect the ESXi to the new vCenter

Unfortunately my result were the following

Capture21

Even though the import was showing no errors and the vDS ID in net-dvs showed the same ID as in the backup file I wasn’t able to get some harmony between the ESXi and the vCenter (even a second recovery of the vDS now hasn’t worked)

After some troubleshooting I found out that it’s necessary to keep the right order in this migration process:

  1. Backup the vDS on the old vCenter
  2. Disconnect and remove all of the ESXi hosts on the old vCenter
  3. Connect all ESXi hosts to the new vCenter
  4. Restore the vDS on the new vCenter (preserve the original distributed switch and port group identifiers)

Keeping this order is the only way the migration works as expected. If you have done the migration like I have described it the first time or if you don’t migrate all ESXi hosts at the same time (can’t recommend this), you need to add the ESXi hosts to the recovered vDS manually.

Capture5

Capture6

Just make sure you select the same vmnics as you have configured it in the original vDS.

Capture7

and finally the error was gone…migration successful

Capture8

All of those operations can be done without interrupting the Service of the VM….so a seamless migration to a new vCenter can be done very easily once you keep in mind the correct order how to do it

PVLAN – A Widely Underutilized Feature

Hello folks, after some time of laziness I am now back with a short note on Private VLANs. I figured use cases for the Private VLAN feature are widely unknown in the field and therefore PVLAN is probably one of the most underutilized features of vSphere out there. Avoiding redundancy on the internet I don’t want to explain PVLAN here, so please read

in case you are not familiar with the concept, yet.

Use Case 1: Saving VLAN IDs

This is probably the only use case people are usually familiar with. Here is the situation: A hosting provider is concerned with providing network connectivity to multiple customers / tenants. For security reasons maybe, customers are to be isolated on layer 2: VLANs. With a possible values ranging from 0 through 4095 for VLAN IDs, we can create up to 4096 VLANs. Some VLAN IDs will be used by the provider himself (storage, vMotion, FT, Management,  etc etc). Though, I see more and more switches supporting 4096 VLANs, many of them are still restricted to a much lower number – 256 for example. You get the point? Only a fraction of possible VLAN IDs can actually be used restricting the number of customers / tenants a hosting provider can support. Further, using VLANs you will end up defining hundreds of subnets and reconfiguring your routers to support newly created networks.

With PVLAN, a provider can now try to put as many VMs into the Isolated secondary PVLAN only using a single VLAN ID but still separating hundreds of VMs from each other. In case a customer requires multiple VMs to talk to each other that traffic could go over a router in a Promiscuous secondary PVLAN or a Community could be created to relieve load from that router. But that would require a precious VLAN ID.

Use Case 2: DMZ

Yeah, you are reading this right! PVLANs can be used in a DMZ environment perfectly well! Think about it:

  1. In a Primary PVLAN the same IP subnet is to be used.
  2. PVLANs allow to further control traffic flow on layer 2 without the requirement for routers or firewalls.

Doesn’t that sound like something you want in a DMZ?

In a DMZ environment, we usually have two firewalls: an outer one protecting the DMZ from the internet and an inner one protecting the organization network from the DMZ and the internet.

The outer firewall protects VMs by filtering traffic to applications not supposed to be reachable from the internet. Still, DMZ systems can be intruded. In this case, when an attacker has gained control over a certain system in the DMZ, he or she gets unfiltered access to all other systems in the same DMZ. No firewall will stop him or her from accessing systems on certain ports.

PVLANs can help to restrict that access! Put your DMZ routers/firewalls in the Promiscuous secondary PVLAN and create Communities for multi-tiered applications. This way, intruding a VM the attacker will be contained in the Community secondary PVLAN unable to send ANY traffic to systems not part of that application.

pvlan-dmz

This dramatically restrains the attacker in the number of possible targets for further attacks!

Use Case 3: Backup Network

From time to time, I see environments that use the old-school way of making backups of systems: agents in VMs, a dedicated backup network, every VM equipped with a second NIC attached to that backup network and a central backup server. What happens here is that people wrap their heads around security for production VLANs – maybe multiple of them – but then put all VMs together in a backup network that allows every VM to talk to every other VM in the company. That creates a big big broadcast domain and gives viruses and other stuff a red carpet for spreading over to other systems.

Now here is my suggestion: On that backup network create  a PVLAN. Configure the backup server(s) to be in the Promiscuous secondary PVLAN and put all VMs into Isolated. This way every backup agent will be able to connect to the backup server but no VM will be able to talk to another VM!

pvlan-backup

Use Case 4: Desktop Virtualization

In a VDI environment a valid concern regarding security is the ability of desktops to communicate directly with each others. Like this, users can exchange data without using enterprise storage or even viruses could spread easily. With PVLAN just put desktop VMs into an “Isolated” PVLAN and place central storage in “Promiscuous” PVLAN. Done 🙂
pvlan-vdi

 

Hope that inspires you a bit and I will see PVLANs more often in the future.

© 2019 v(e)Xpertise

Theme by Anders NorénUp ↑