We run a very large VMware environment and have a large number of orphaned or Phantom VMDK files... ones that are left over after another team deletes a virtual machine...
Have heard that Orchestrator has a way to deal with cleaning these 'Phantom' files up .. can anyone confirm this or direct me to a doc. for usage examples?
Thank you, - John Middleton
There is a workflow called "Find orphaned virtual machines" in the vCenter library. There is an option to send the results by mail.
Christophe.
Chris,
Pardon my ignorance as I am very new to Orchestrator... but is this workflow and its process explaned in a specific VMware document.. if so, could you tell me its name so I can start my learning curve..?
Apprecite your help very much, - John M.
Thinking this through again.. the better question is .. can this Workflow perform clean up of these orphaned VMDK files..? Can we use Orchestrator to help clean up or recover our LUN space..?
Thank you, - John M.
This is a workflow part of the standard library found in the vCenter category
I am not sure if this is documented in the vCO doc guides but the workflow description says:
So this workflow only list the files so you can clean them up manualy. Now I have found other workflows that may help delete these:
You can test using the log ones and use the delete if it does what you need.
Christophe.
Christophe,
Your book looks like a great resource so I have ordered it.. hopefully it will enable a Noobie like me to figure this usage out. Will let you know.
Thank you for all your help.
Regards, - John M.
Hi,
Thank you. The book is not from me. It is from Cody Bunch and I think it is a very good way to start wirh vCO.
Christophe.
Christophe,
Ok, so I am working my way through the book which does indeed help (Chapter 7, Smoothies Inc.
.. but have a question...
When looking at the Workflow you mentioned "Delete all unused datastore Files" ... how can I find which files or file types it will delete? We just want certain VMDK files...
Trying to understand it before I pull the trigger to be sure ONLY the file types we want are removed..? Maybe in over my head or getting ahaed of myself but this is the most outstanding question in my mind right now... thank you !
Best regards, - John M.
"Log unused datastore files" will list the file and not delete them. It uses a subworkflow called "Find unused files in datastores". This one has the following description:
"Searches vCenter Server for all unused disks (*.vmdk), virtual machines (*.vmx), and template (*.vmtx) files that are not associated to any vCenter Server instances that are registered with Orchestrator."
I have not used these workflows myself so I cannot comment more than what is documented. If anyone else did feel free to comment on your experiences with these.
Christophe.
to remove "phantom" or orphaned disk without cheking is not a goog idea.
i check such things with powershell - that uses the same technics.
Sometime the script found orphaned disks that are not orphaned. Mostly thats snapshot delta disks.
If such a VM is not running and delete delta vmdk of snapshot stack than you get a corrupt VM...
Best way ist to start with logging as suggested by Joerg.
best regards,
Mike
So, the answer to the question of can Orchestrator clean up orphaned VMDK files is clearly... no.
vCO has the workflow to do this job but no one uses it ... or no one knows how to control it to be safely used... and since we already use PowerCLI to locate these files and 'manually' delete them.. back to PowerCLI methods we go.
Too bad... seemed like a good idea at the time.
Thank you everyone for clarifying this question, - John M.
Hi John,
please don't get it wrong: You CAN do the deletion of phantom vmdk-files with vCO! (Luc's PowerCLI-script also uses the same vSphere API of vCenter as the vCO-server)
There is just no ready-to-use workflow for exactly your use case in the library...
The workflow in Cody's book MIGHT do exactely what you want, but I recommend:
Whatever solution you use: When you use an automatic way to delete files, you absolutely should understand what the script/workflow does!
So you anyway have to dig into a vCO Workflow as well as into a PowerCLI-script you might have found in the communties.
Best way: Build your own custom workflow, then you absolutely will control what it does
.
Cheers,
Joerg
You can do the Task in Orchestrator or in PowerShell or PowerShell in Orchestrator. The results are the same.
(But a vCO Workflow is much more readable)
But i would dig you to a possible faulty result. So be careful with the "automatic remove" of vmdk - it can be destroy your VMs in case of
false positiv.....
best regards,
Mike
Which workflow? VM Decomissioning? Or the one from the "Other VM things" chapter?
Assuming you're talking about "Find Orphaned VMs" from the "other VM tasks" chapter, I used the built in vCO workflow. However, you can certainly customise it to move from just listing orphaned VM files to removing them.
-C
just curious ... how do you define a phantom vmdk ?
is a phantom.vmdk a vmdk that is not referenced in any vmx-file ?
or
is a phantom.vmdk a vmdk that is not referenced in any vmx-file AND not referenced in any other vmdk-file ?
I would at least use the second definition before I would allow a script to delete it
Hi Ulli!
Welcome to this section of the VMTN :smileygrin:!
And. good to have you onboard in this early stage of planning, rather than usual when you have to fix what such an automation broke :smileysilly:
Cheers,
Joerg
> Welcome to this section of the VMTN :smileygrin:
Lol - I really rarely visit the red-light district :smileylaugh:
I could imagine a shell script that first lists all vmx- and vmdk-files and writes this list into file A.
Then it would it would list all vmdks into file B..
Then it would have to take first entry of file B and take it as the argument for a grep command against all files in file A.
If it does not find at least a single occurence it would be safe to delete the vmdk
Continue with second entry of file B ....
and so on
The gist of the latest replies seems to be "Best way: Build your own custom workflow, then you absolutely will control what it does".
Suppose if we were intending to manage a large portion of our 8000 VM's with vCO then investing in serious vCO training would make sense. But right now it just seems easier to use PowerCLI than to invest so much effort learning a new language like vCO JavaScripting to build a single workflow..?
Or... am I seeing this wrong.. can a PowerCLI script be written and then run via vCO .. is that an option?
Curious, - John M.
> can a PowerCLI script be written and then run via vCO .. is that an option?
Well, not exactly run in vCO but PowerCLI script could be called from vCO. You might want to look at these links to get an idea about the Powershell plugin:
http://blogs.vmware.com/orchestrator/2011/12/vco-powershell-plug-in.html
However, you may also read Christophe's blog about javascript:
"The specific value of a scripting language versus another is, in my opinion, irrelevant as long as you can get to the same result with a similar effort. It took me a few days to go from Perl to a JavaScript level good enough to do what I needed."
John,
you're right of course: If you just plan to automate this single problem, and you already have PowerCLI experience in your team, go for a PowerCLI solution.
But in an environment with 8000 VMs I guess there is MUCH more to automate, and therefore it would be absolutely worth to invest in vCO Know-How!
In my opinion vCO is a more reliable and "Enterprise" style for automation (not to mention all the great integration possibilities with all other systems besides vSphere). You have to spend some time to learn (with PowerCLI you might get "solutions" quicker, if you call copy-and-past from scripts found via google a "solution"), but once you got started with vCO, the possiblities are endless.
Cheers,
Joerg
