Unsolved
This post is more than 5 years old
6 Posts
0
133990
June 7th, 2012 16:00
vFoglight with linked-mode
In our environment we have 3 virtual centers. 1 for test VM’s, 1 for production VM’s and another at a different location that is used for both test and production. They are configured as linked-mode. We have 3 virtual fglam servers for each virtual center. When a server is initially created they are deemed test. Some of the servers will change status from test to production. At which time the server is shutdown, removed from inventory, then added to one of the production virtual centers.
The issue is now you have 2 VM’s listed in vFoglight, 1 which is stale and the other which is active. Granted you can go into data management and delete the stale object.
The bigger issue is any dashboards that were created while the VM was on the test virtual center are now stale and must be recreated from scratch using the vFoglight VM object that is now on the production environment.
Does vFoglight support a virtual center linked mode environment to avoid this issue? Are there any workarounds or other solutions to avoid these issues?
DELL-Thomas B
171 Posts
0
June 7th, 2012 20:00
We support linked mode being on, but we do not leverage it for inventory or such. That being said, what you really want to do is use a parameterized input if you are making custom dashboards and such. That will allow you to create a single view and change the VM related the view vs. recreating it every time. This video shows how to use such an input http://www.quest.com/tv/All-Videos/1107695895001/Customizing-Foglight-Reports-with-Parameterized-Inputs/Video/
valstrubhar
6 Posts
0
June 7th, 2012 23:00
If you have a number of VM's spread across different ESXi hosts and different vCenters on your dashboard then using parameterized input would not work since all of the object will use the same page input, correct?
I would like to have a dashboard that shows more than 1 VM along with its pertinent information but should one or more of the VM's move to a different vCenter I don't want to have to recreate each VM object again.
DELL-Thomas B
171 Posts
0
June 8th, 2012 00:00
You are correct if there are then multiples it will not work with the parameterized input with VMWVirtualMachine. You can hard code it in that way, or if you wanted to take it a step further you could create a view for a single VM like what you have in WCF and interate that for all the VMs in a List OR even better that are part of a service within Foglight and then use that as the parameterized input. I tend to use services for this a lot, that way it's easy to make views off of.
john_s_main
132 Posts
0
June 15th, 2012 18:00
Have to say, not seeing the advantage of moving ESX Hosts between Virtual Centers, since the Virtual Center Name is the base 'key' on the vFoglight data collection process. Moving an ESX Host to a new virtual center is guaranteed to create a TON of duplicate (and leave a ton of eventually stale) objects in the database, just as renaming a Virtual Center server creates all new objects with the root key of the new VC name.
In fact, it's likely not a great idea to move VMs between Virtual Centers, since they will create, on a lesser level, the same issue.
We have around 13,000 VMs in our environment, and use the name of the VM to designate Dev, Test, Stage, or Prod. They currently reside on separate clusters, but we are moving to deploying them all on the same clusters in the future, given that there isn't any difference between a deployed ESX host running dev/test/stage or prod VMs.
When some app is ready to move to the next level, there are good options available, such as copying the VM to a new, correct name and putting it on the correct type cluster.
You can still differentiate between VM types, using folders, for example, or custom attributes.
All that being said, as long as all 3 VCs are being collected on a single FMS, and as long as you don't have a huge environment, you can probably write a custom functions to accept a VM name, search the topology for matching VM objects, consolidate the specific desired metrics into a single values, and return that list of values as additional context. Not for the faint of heart, but possible. Not usable in Drag and Drop, either.