Idea ID: 2685309

Population of VMware storage topology (mapping between Drive C: -> VMware Datastore)

Status : Accepted
over 2 years ago

Dear all,

We would like to see population of VMware storage topology that will include population of mapping between Drive C: down to VMware datastore. 

The change should most probably touch both VMware Topology by VIM as well as Resources by Shell/WMI.

Thanks,

Dmitry

Labels:

Discovery-Content
Parents
  •  We do not have clustered virtual servers sharing the same VMDK in our infrastructure, so I would not be able to tell the behavior. However, our add-on do not modify the out-of-the-box discovery of the VMware virtual disk. So, if the Vmware virtual disk discovered as "Logical volume" is currently merged into a single object in uCMDB, it will stay the same and we should see two Disk devices (\\PHYSICALDRIVEx) pointing to the same Logical volume (Hard disk x+1) . I am just unsure how our module "OS storage by Shell" would react if the VMware virtual disk is not at the same position on each virtual machine (ex: 3rd disk on the first VM and 4th disk on the second VM), but if I remember correctly, that kind of configuration is a bad practice for building a virtual cluster...

    FYI, we already had a few meetings with MF R&D about this idea. We have sent them our improved discovery code.

Comment
  •  We do not have clustered virtual servers sharing the same VMDK in our infrastructure, so I would not be able to tell the behavior. However, our add-on do not modify the out-of-the-box discovery of the VMware virtual disk. So, if the Vmware virtual disk discovered as "Logical volume" is currently merged into a single object in uCMDB, it will stay the same and we should see two Disk devices (\\PHYSICALDRIVEx) pointing to the same Logical volume (Hard disk x+1) . I am just unsure how our module "OS storage by Shell" would react if the VMware virtual disk is not at the same position on each virtual machine (ex: 3rd disk on the first VM and 4th disk on the second VM), but if I remember correctly, that kind of configuration is a bad practice for building a virtual cluster...

    FYI, we already had a few meetings with MF R&D about this idea. We have sent them our improved discovery code.

Children
No Data