This is meant to be a very short post about the importance of vCenter Managed Object References with vCloud Director. In the past folks have heard David Hill and I talk about the vCloud Eco-System and how vCenter is pretty much in the middle of the universe for many things. Today a lot of products, least of all vCloud Director and vShield Manager interface with vCenter Server for information. It is no secret to anyone that vCenter uses what it calls Managed Object references, or MoREF to identify the different objects. Almost everything in vCenter gets a MoREF including things like:
- Virtual Machines (I have been told vCD can re-connect the dots here)
- Network Port Groups
- Resource Pools
These are just a few examples of items in the vCenter inventory that use some kind of MoREF identification. So how do things like vCloud Director and vShield Manager use them? Simple just take a look at your vCloud Director Database and you will see in some tables the MoREF ID’s. Below is an example of one table (dbo.vm) from vCloud Director’s SQL Database
You will notice as you scroll over to the right there is a moref column. That vm-### equates to the MoREF ID, as indicated by the column, of the virtual machines in vCenter. You will see this repeated on other tables, and in fact the same is true for vShield Manager. The local MySQL database tracks the vShield Edge Devices my their vCenter MoREF ID.
So why is Understanding This so Important?
Previously I wrote about a specific condition of Disabling DRS with vCloud Director, and how it can adversely affect your vCloud Director installation. Well the real reason that was an issue is that when you remove an object from vCenter and re-create it, even with the same name, the MoREF will be different. This is like changing the area code to your phone number and not telling anyone. How in the world would people be able to reach you until the new phone book is printed, or you TELL them about the change? The same holds true with products like vCloud Director that interface with vCenter and it’s MoREF identifications.
We have said for some time to not make changes to vCenter when vCloud Director is deployed mainly because if you do, you cannot tell all the tables in vCD’s database where to find the re-numbered object. Above is just one table with a reference to those Virtual Machines. vCloud Director pulls that data in from vCenter, stores it in its own database, and unless it issues the change it has no idea you modified the zip code so to speak. Therefore you will be stuck with all kinds of headaches trying to re-connect the dots.
So imagine disconnecting, removing, and re-connecting a host with virtual machines running? Assuming you could not evacuate them all to get the host in Maintenance Mode. It happens I have had to do it myself. The remaining virtual machines will get flushed from the vCenter database. When you reconnect the host they will be re-registered and paced in the “Discovered Virtual Machines” folder and the clusters “root” resource pool. Hence they will not be where they started, and the Virtual Machine itself will no longer be “Managed By” vCloud Director. I have confirmed you can get vCloud Director to reconnect to the Virtual Machine’s with a “Refresh” command, but it will not move them back to their folders and resource pools for you. You can see some screen shots below.
Refresh command must be issued through vCloud Director UI or API at this point, however the inventory is still not properly organized.
The Moral of the Story
The moral here is simple. I have said before and I will continue to say, PLEASE do not make changes to vCenter directly especially if it involves removing objects from the vCenter inventory. Above is just one example of what you can do in vCenter to make your life pretty miserable. Personally I like doing this kind of testing, because it means I am also able to work with Engineering on figuring out solutions to scenarios like this. If you do make vCenter changes with vCloud Director, vShield Manager, or other products are integrated you could make your life a little bit miserable. Lock down the vCenter that is being used by vCloud Director from access to general folks so you can control the changes. Also, this is a great example of why vCAT suggests a separate vCenter server for vCloud Director. Although you can try to control object based access in many cases it is easier to lock out the whole vCenter from universal access.