Handling of Fault Tolerance

[Sneddo]

Currently fault tolerant VMs will essentially show up as two VMs with the same information. This causes a few duplicates whenever these VMs show up on report, as well as causing false positives for things like the VM tools not running on secondary VMs.

How do you think this would be best handled?

1. Leave it as-is
2. Filter out Secondary VMs at a global level (though perhaps add another field to aid identifying these VMs?)
3. Add filters in the plugins where they cause confusion.
4. Something else?

[monahancj]

I like #2. We don't have any so I don't know what conditions an FT secondary VM might have that would cause it to show in a plugin where the primary wouldn't, but I'd like to know if it did happen someday.

Maybe rename the secondary VM "Name" object in the $VM and $FullVM variables by appending "-FT2nd" or something.

[haripetrov]

I think that option 2 will cover this case in the best way.

[Sneddo]

Yeah, the only issue with this is that we need to create a copy of the object as this property is read-only. Not really sure what- if anything- this will break. Or, we add a property to hold the display name, but this would mean changing all plugins as well...

[vScripter]

Yea, I think the proper way to handle is to take a look at the properties of the guest and identify it as FT, the question/issue that remains it how do we return additional meta-data about FT (primay/secondary, etc.). Similar scenarios seem to creep up in other places; maybe it makes sense to have some type of 'General' or 'MetaData' property that exists on all objects of a certain type, or all objects returned, globally, that can be used to append 'scope' based information. This would give us flexibility without having to create a whole bunch of properties and maintain those as we pass info around internal functions and output.