List VMs in datastore that is not in inventory

[MHegelund]

Hi Guys

PowerCLI rookie here, so sorry for stupid questions.

I’m trying to clean up a bunch of singehost with local datastores. So I need a script that can output a list of virtual machine files on a datastore that is not being used by VMs in the inventory. One of the problem is that the files on the datastore, is not all ways named exactly the same as the VM’s in the inventory.

Been looking at this, but I think the term “orphaned” is ‘sent what I think it is:

https://communities.vmware.com/thread/266913

Also there is this one, which I think I should be able to modify to do what I want:

http://www.wooditwork.com/2011/08/11/adding-vmx-files-to-vcenter-inventory-with-powercli-gets-even-e...

Any hints or clues to push me in the right direction would be appreciated.

[LucD]

In the script in Orphaned files and folders – Spring cleaning you can specify specific datastores to check.

[MHegelund]

Wow Luc - you do answer the threads in here as fast as Alan said you would, in Barcelona

Your script works great on shared datastores, however I can't get it to pick up orphaned files on singlehosts with local datastores.

I removed the you line 42 : if($ds.Type -eq "VMFS" -and $ds.ExtensionData.Summary.MultipleHostAccess), but still nothing.

[ccalvetTCC]

By "singlehosts" do you mean standalone host not connected to any vCenter?

[LucD]

You have to remove the condition that checks for shared datastores, so change that line to

if($ds.Type -eq "VMFS")

[MHegelund]

Thanks Luc, but I already tried that, still doesn't pick up the orphaned vmdk file.

By singlehosts, I mean hosts that is not joined to a cluster, but are added to a VCenter.

Heres the environment, and a test VM on the datastore that is not in inventory.

[LucD]

Can you check what the DisplayName in the VMX file says ?

It could be that these files are attached to a VM that is registered under another DisplayName than mhetest.

[MHegelund]

That does not seem to be the issue.

displayName = "mhetest"

[LucD]

Ok, just trying to find out why the files are not listed as orphaned.

The script uses the following logic:

1. it gets the VMs on that datastore from vCenter
2. it gets all the files on the datastore
3. it compares the files from 1) with the files from 2). The difference are the orphaned files

Does

Get-VM -Datastore 'MyDS'

return the VM ?

[ccalvetTCC]

I have  created some scripts based on the logic provided by LucD with some modification to fit my needs.

The difference is that there is one script per step in the logic.

One script extract the files attached to all VMs

One script extract all files located in a specific datastore(s).

...

So it you use the two scripts above you can then compare the results of the step 1 and step 2 manually instead of letting the script doing it in the step 3.

http://thecrazyconsultant.com/find-orphaned-vmdk-files-workflow/

[MHegelund]

Yup that what been trying to figure out.

If the VM is in the inventory the command Get-VM -Datastore 'MyDS' lists the mhetest vm on the datastore, if i remove it from the inventory and leave it on the datastore it does not show up when running Get-VM -Datastore 'MyDS'

Note, the ESXi host is named the exactly same as the datastore, could that be part of the problem?

[LucD]

No, the same name for the datastore and the ESX host shouldn't be a problem.

Does the VM still show when you do a

Get-VM -Name mhetest

after removing it from the inventory

[MHegelund]

If the mhetest VM is not in the inventory and I do a it do a Get-VM -Name mhetest it does not show up.

[ccalvetTCC · Accepted solution]

Please try:

$AllFilesLocalDatastore = Get-datastore "localdatastorename" | get-fileindatastore

$FilesIdentifiedAsAssociatedToAllVMs = Get-FilesIdentifiedAsAssociatedToAllVMs

#The two functions above are available there http://thecrazyconsultant.com/find-orphaned-vmdk-files-workflow/

Check the content of the two variables for example with ogv or export-csv

$AllFilesInESX01LocalDatastore | ogv

Then try:

$FilesNotIdentifiedAsAssociatedToAnyVM = $AllFilesLocalDatastore  | foreach-object{

          $FullPath = $_.FullPath

            If ($FilesIdentifiedAsAssociatedToAllVMs.FileName -notcontains $FullPath){

            Return $_

            }

}

$FilesNotIdentifiedAsAssociatedToAnyVM | ogv

#The above one will contain all files not identified as associated to any VM

$ProbablyOrphanedFiles = $FilesNotIdentifiedAsAssociatedToAnyVM | where{ $_.FileTypeFullName -match "VMware.Vim.Vm*" -OR ($_.FileTypeFullName -eq "VMware.Vim.FileInfo" -AND ($_.Fullpath -match ".vmsd" -OR $_.Fullpath -match ".vmxf" -OR $_.Fullpath -match "aux.xml" -OR $_.Fullpath -match ".vswp" -OR ($_.Fullpath -match ".vmdk" -AND $_.Fullpath -notmatch "ctk.vmdk") -OR ($_.Fullpath -match ".vmx" -AND $_.Fullpath -notmatch ".vmx~" -AND $_.Fullpath -notmatch ".vmx.lck") ))}

$ProbablyOrphanedFiles | ogv

Edit:

Edited the datastore name, it seems that it was not supposed to be in the initial screenshot.

Edit2:
Switch order of the first command, more details in the last post in this thread

[MHegelund]

Christophe - That's awesome, I owe you a beer man

I believe that's gives me the result I was looking for.

Again - Thanks Luc and Christophe!

[ccalvetTCC]

Edit2:
It is much better to run the first commands in this order:

$AllFilesLocalDatastore = Get-datastore "localdatastorename" | get-fileindatastore

$FilesIdentifiedAsAssociatedToAllVMs = Get-FilesIdentifiedAsAssociatedToAllVMs

If the same script is launched accross many large datastore for example in a datastore cluster it will be common to see a storage vmotion or any others activies happening between the completion of the two commands.

In that case it is better to have the latest pictures of the files associated to the VMs at the end.

Worst case scenario, in case of a storage vMotion for example, it will end up with:
Probably orphaned files will be the path of the "virtual machine in production" files "before" the storage VMotion...so it will not point to anything.

In the other order, the probably orphaned files will be the path of "virtual machine in production" files "after" the storage VMotion....so in fact files that are not orphaned at all.

[MHegelund]

I'm just reading it all making sure I understand everything. (still a rookie ) So what do I gain by switching in the two lines?

Regarding large datastores and vMotion.

I get what you are saying, but as I said this part of the environment are single hosts with local storage so I'm not worried that's going to be an issue.

[Phillip_K]

First off, many thanks!

I tested your Register-VMX function on one of our Engineering clusters. It did the job, but it probably needs an update.

It would search the datastores and register the vmx, however you can't specify where to register it at. So instead of ending up back on my engineering cluster it went to one of my production clusters. Additionally registering a vmx file by cluster or datacenter just closed my ISE session.

I'll take a look at it and see what I come up with. In the meantime if you have any updates please share them.

Thanks again.

[LucD]

Thanks.

That is indeed a good idea, an option to specify where it should register the VM.

Now it registers the VM in the parent Datacenter, and the VM will appear on the host or in the cluster where they were before, if I'm not mistaken.

What would you prefer when that destination is not fit to register the VM, for example datastore not mapped to a cluster?

[Phillip_K]

I can test some more, but initially my VM's that I unregistered in my engineering cluster were coming back on a separate production cluster in the same datacenter.

As for the error message, whatever you deem acceptable. I'm just happy you put this out there. It still gets the job done either way. We've done work previously where our VM's get unregistered and we didn't know which datastore it was on.

That's a headache, so again, many thanks.