Import of vSphere Distributed Switch with "Preserve original distributed switch and port group identifiers" does not work

[Bill_Oyler]

Hello,

I have run into a problem with the export/import routine for vSphere Distributed Switches.  The export works great, but the import with "Preserve original distributed switch and port group identifiers" does not seem to actually preserve all of the dvPortGroup identifiers.  As a result, certain applications will break if they expect the dvPortGroup identifiers to remain identical (such as Citrix and VMware Site Recovery Manager).  This occurred at a customer site (on vCenter 5.5U2), and I was able to easily reproduce it in our lab (running vCenter 6.0).  The only way to view the identifiers is to use PowerCLI, so I was able to capture the identifiers "before" and "after" the import.  Basically I created a VDS with a few dvPortGroups, exported the config, and then deleted the VDS, and imported it using the "Preserve original distributed switch and port group identifiers".  The result is that the "imported" VDS has mis-matching values for the "Key, "Id," and "Uid" numbers.  This is what seems to break Citrix and VMware Site Recovery Manager.  The work-around is to delete and re-create all the dvPortGroups (which gives them brand new identifiers), and then re-configure Citrix and VMware SRM.  This works, but it is time consuming and sort of renders the VDS export/import routine useless.  I am curious if this is a known bug and whether VMware is going to fix it.  Anyone know?  I don't see a whole lot of value for the export/import routine if things are going to break...

Below are my "before" and "after" results:

BEFORE (notice the matching numbers):

VlanConfiguration : VLAN 123

Name              : TestServers123

ExtensionData     : VMware.Vim.DistributedVirtualPortgroup

Key               : dvportgroup-4928

Notes             :

Datacenter        : Primary Site

PortBinding       : Static

NumPorts          : 8

VDSwitch          : TestVDS

IsUplink          : False

Id                : DistributedVirtualPortgroup-dvportgroup-4928

Uid               : /VIServer=lab\vmware@labvc01:443/DistributedPortgroup=

                    DistributedVirtualPortgroup-dvportgroup-4928/

Client            : VMware.VimAutomation.Vds.Impl.V1.VDClientImpl

VirtualSwitch     : TestVDS

AFTER (notice the mis-matched value between "Key" and "Id"):

VlanConfiguration : VLAN 123

Name              : TestServers123

ExtensionData     : VMware.Vim.DistributedVirtualPortgroup

Key               : dvportgroup-4928

Notes             :

Datacenter        : Primary Site

PortBinding       : Static

NumPorts          : 8

VDSwitch          : TestVDS

IsUplink          : False

Id                : DistributedVirtualPortgroup-dvportgroup-4932

Uid               : /VIServer=lab\vmware@labvc01:443/DistributedPortgroup=

                    DistributedVirtualPortgroup-dvportgroup-4932/

Client            : VMware.VimAutomation.Vds.Impl.V1.VDClientImpl

VirtualSwitch     : TestVDS

[virtwo]

I have recently used this feature, and it worked perfectly for me: I had to rebuild my vCenter (hostname naming convention requirement changed after initial deployment).

I exported my dvs config, I reinstalled the VCSA, added the hosts back, then imported the dvs config with "preserve identifiers". vCenter immediately stopped complaining about "unknown dvs child objects" on the hosts, and I did not have to reconfigure anything wrt virtual networking.

[Bleeder]

Did you ever find a fix for this?  Perhaps a script or something that can change the ID's to match?

I see that VMware finally acknowledged the mismatched ID's in https://kb.vmware.com/kb/2144159

[Bill_Oyler]

Hi Bleeder,

I did not find a fix per se, but my work-around was to simply create brand new DVPortGroups and migrate the VMs to the new DVPortGroups.  I then deleted the "bad" DVPortGroups.  This solved my problems with Citrix and SRM.  I was able to do it with zero downtime, but it was annoying because it was time-consuming and defeated the purpose of the "Export" / "Import" routine.  I suppose you could use PowerCLI to automate the process, but I get nervous automating such "drastic" changes so I just did it by hand.

Thanks for the link to the KB article.  It's nice to see that VMware has identified the issue.  It may not be a "bug" from VMware's perspective, but their own product (SRM) breaks when the "Export" / "Import" routine is used, so I would consider it a bug with either the SRM product or the DVS Export/Import routine.  That's just my opinion anyway. 

Bill

[dacuna16]

Hi Hill,

Which command/cmdlet/script did you use to pull that data out from the DVS's portgroup?

Thanks,

[Bill_Oyler]

In my case, what I did was simply create new port groups (with a new name) and dragged-and-dropped all of the VMs from the old port groups to the new port groups.  For example if the old port group was called "VLAN50", I created a new port group called "VLAN50_New" and moved all my VMs over to the new port group, which is a zero downtime event (does not even lose a ping).  Then I deleted the old port groups, and when I was all done, I renamed the new port groups to match the name of the old port groups, which is also a zero downtime change.  It was time-consuming, but it solved the problem entirely.  You could script it with PowerCLI, but that would have taken even longer and might have caused an outage if I were to have made a scripting mistake.