I will be spending the next couple of months catching up on all the sessions I missed. Head over to virtuallyGhetto to see all the other awesome things William Lam posts.
I have been looking to automate more processes at work and patching ESXi hosts was definitely in my top 5 PowerCLI projects. I really like the simplicity of Ben Liebowitz’s script over at The Lowercase w. I will use this as a starting point for my own script. (Not that it needs too much tweaking. Good job Ben!)
Please follow the link below to see the script.
We’ve been discussing using the VCS to VCVA fling converter appliance. We spent a few days installing the lab and re-installing due to not reading all the requirements for the VMware Migration Fling. I built the test vCenter server with Windows 2012 Server which has specifically been shown to be buggy and does not work. I shouldn’t have done that anyway since our production vCenter servers are Windows 2008 R2.
After spending time re-reading all the caveats and known issues with the fling at William Lam’s virtuallyGhetto it was time to test and get comfortable with how the fling works. We scheduled some conference room time and went through the deployment of the migration appliance and just followed the instructions.
The only issue that we experienced is that the converter appliance would not accept my domain credentials to access the existing vCenter server. Our default administrator account on all of our Windows servers is renamed in our domain. It appeared that the converter appliance would only try the vCenter local account called Administrator. After several tries with domain\username, username, localusername, etc. we created a local account on the vCenter server called Administrator. Once that was done the conversion continued on smoothly. After looking around I didn’t see anyone else having this issue but I thought I’d mention it in case someone else experiences this issue as well.
We were very happy with the result in the lab and will be scheduling the conversion of one of our production vCenter servers to the VCSA soon.
Do you ever find that as a VMware admin that you have to defend your choices when it comes to virtual machine sizing? We’ve all been there when our customers (i.e. internal I.T. analysts) or even your co-workers on your team question why you didn’t give their vm as much cpu or memory as originally requested.
How do you deal with it? Often it is easy to just declare I am the VMware admin and I obviously know more than you so just accept what I am saying. Besides, you are just an ignorant newb when it comes to VMware. The other response is to elevate the conversation and educate the ignorati.
I like to think that I choose the latter but I sometimes fantasize about the former.
In that vein I choose to highlight some basic troubleshooting methods that VMware recommends to determine if indeed that vm is worthy of a bump in cpu, memory, or even diagnose storage or network issues. A great knowledge base article to start with is Troubleshooting ESX/ESXi virtual machine performance issues (2001003) .
Hopefully this is a good start in troubleshooting ESXI performance issues and hopefully your political and ignorance issues are few and far between. I’d love to hear from you about your experiences!
If you’ve ever managed a VMware View vdi environment for a period of time sooner or later you will have to manually delete orphaned virtual desktops. Although VMware provides KB 1008658 that explains this procedure. It is lacking in clarity especially for first time VMware View admins.
As we all know our friend Google provides if you only ask. I have found 2 other blogs that do very good job of taking KB 1008658 and parsing it down to a more concise version. My intention was to do this myself but why reinvent the wheel when you can just pay homage to it.
Here are the 2 blog post links:
The summarized steps for deleting an orphaned virtual desktop in VMware View is:
- Stop provisioning on the offending vdi pool (optional but my experience is that it is essential especially with very busy non-persistent pools with)
- Remove orphaned virtual desktop from ADAM database
- Remove all relevant entries for the orphaned vdi in the SQL Composer database
- Delete corresponding computer object out of Active Directory
- Enable provisioning once again on the pool
Please see the other blog posts for exact details.
Hopefully seeing more than one example really helps in understanding the necessary steps.
Note: Edited 9/29/17 to remove a broken link
Welcome to my new blog chronicling my adventures in virtualization specifically utilizing VMware technologies. I will be including tutorials, videos, and interesting articles regarding VMware virtualization mostly. I may occasionally include other things that interest me in technology and or photography. I hope you’ll enjoy and learn from my learning.
Feel free to contact me and give suggestions and feedback.