Caution: this is not supported by VMware. This is ‘this is possible’ post, not a standard procedure. Take care if you go forward.
Within vCloud Director, you can dynamically add networks to vApps and virtual machines, just as within vSphere. Moving the network of a virtual machine from networkA to networkB within vCloud Director is also a non-disruptive operation, as it should be. But for some reason, the removal of a network from a vApp, requires the entire vApp to be shut down. Ever since I’ve started working with vCloud Director, I’ve been asking VMware why that is (as it’s just a logical database entry), but haven’t gotten a proper answer yet. Anyway!
I did a network migration last week where a a bunch of virtual machines needed to switch External Networks from the current network to a new network. The migration itself was pretty straight-forward; added a new External Network coupled to the new port group, then used New-CIVAppNetwork to add the network to all vApps that needed it and used Set-CINetworkAdapter to move all virtual machine network adapters over. So that’s the migration done, all virtual machines are assigned to the new network and traffic was a’ flowing.
The old network was still present in all vApps though, doing nothing. This looks a bit like this:
The inner neurotic in me cannot let that stand. Previously, I just advised the customer to shut down the vApp and remove the network after it’s shut down. But this time, I couldn’t get myself to tell the customer or even go through the procedure again (mostly because it’s lame). So I went looking for an alternative for removing the network without a shutdown vApp.
Dive into the database
Once I ran a database profiler during the removal of a network through to GUI, I found that the only relevant table that was modified was: vapp_logical_resource
This table contains resources that a vApp has to its disposal. Can be storages, can be networks. This seems to be the only logical connection that a network has to a vApp when the virtual machines aren’t using it. With that knowledge I opened up a query inside SQL Server Management Studio and did a search for the network I was looking for:
(production data, so I obfuscated some details)
This query looks in the vapp_logical_resource table for the network, but also uses the table called vm_container to match the vApp ID to a readable name, so you can see whether the results make sense. Adjust the ‘WHERE lr.name = ‘YOUR-NETWORK’ to the network name you’re looking for.
The results are the vApps that have the network. In this case there are two vApps. You can do a double check by looking at the vapp_id string and matching that with the vApp ID that you can se inside the URL when you’re looking at the vApp diagram tab in vCloud Director:
(Yes, these do not match. They’re just examples. :-))
Removing the vApp to Network link
Once you feel good about the results, you can go ahead and delete the actual link between the vApp and the network. Make a database back-up (just to be sure) and be absolutely sure that no virtual machine is still using the network (or you’ll create a mess which is not easy to clean up). Then execute this simple query:
The result will be how many records that were deleted, or how many networks you’ve just separated from the number of vApps. Just refresh the page in vCloud Director and the network is gone. After doing that query, you can delete the network from the External Networks in the System tab. Once that’s done, you’ve just removed a network from all vApps without shutting them down.
Just to reiterate, this is an unsupported procedure and you need to be fully conscious when doing this. Enjoy!
Leave a Reply