2 Replies Latest reply on Jul 22, 2019 8:24 AM by beezleinc

    Virtual Object Placement Details incorrect

    beezleinc Novice

      When I look at the Virtual Object Placement Details for a vsan cluster I have all of the objects belonging to one VM stashed under the VO folder of another VM even though when I look at the vsanDatastore FS itself, the objects are in their correct 'folders'.

       

      I am assuming this is a VC instrumentation database mixup and nothing wrong with the vsan itself.

       

      Is there a way to reset this so it shows the correct folder tree under this display?

       

      Also, I notice that VC does not always show 'vSAN Default Storage Policy' for some objects even though it shows correctly when I edit the VM properties.

       

      TIA!

        • 1. Re: Virtual Object Placement Details incorrect
          TheBobkin Virtuoso
          VMware EmployeesvExpert

          Hello beezleinc,

           

          I determined a likely cause for this issue today - if the VMs have the same uuid.bios parameters they will appear as per your screenshot as vSAN Health/Monitoring has dependencies on this variable and thinks that the Objects associated with all subsequent VMs with identical parameters belong to the initial VM.

          On vSAN or otherwise (unless some element strictly relies on it), best practice is to deploy/clone/create VMs with unique IDs - this can be configured based on the solution (e.g. vCloud Director), in the vmx configuration and other ways. But in your case if you just want this to display properly then manually change the uuid.bios parameters of the VMs vmx to be unique (or re-deploy/clone the VMs putting in place measures that they are deployed with unique uuid.bios).

          VMware Knowledge Base

           

          Bob

          • 2. Re: Virtual Object Placement Details incorrect
            beezleinc Novice

            Thank you Bob.  I just found this same answer out yesterday!  Yes, it was two VM's with duplicate bios.uuid's.

             

            In the process of deploying/testing Veeam Backup and Recovery, this issue came to light again as it barks if dup uuid's are present as well.

             

            Problem solved.  Thank you again.