Monthly Archives: May 2014
Last month I published a post in regards to the Dell VRTX, ESXi 5.5, and storage – or the lack thereof. Well shortly after publishing that article Dell announced full support for ESXi 5.5 and released an ESXi 5.5 image on their website for those looking to upgrade or install. In the chance that my little driver work around might affect support I decided I’d better pull the image down and get it installed on the few VRTX’s I had already deployed.
That said, looking at the build numbers and attempting to not have to redo all of the configuration I had already applied, I decided to take the upgrade route – even though the only difference was most likely the storage driver. The upgrade process itself went smooth – no issues, no problems. But after it was complete guess what was missing? Yup, the datastore was gone again!
Now this wasn’t the same issue of missing storage that I described the last post. Previously I couldn’t see the storage at all, this time, when looking at my Storage Adapters I could actually see the device that hosted my datastore listed. So it was off to the CLI to see if I could get a little more information about what was going on.
To the CLI Batman!
After doing some poking around I discovered that the volume was being detected as a snapshot/replica. Why did this happen? I have no idea – maybe its the fact that I was messing around with the storage drivers 🙂 I guess that’s why they say things are supported and unsupported 🙂 Either way, how I found this out was with the following command.
esxcli storage vmfs snapshot list
This command actually displayed the volume that I was looking for, and more specifically showed that it was mountable. So my next step was to actually mount that volume again. Take caution here if you are doing the same. I know for sure that this volume is the actual volume I’m looking for – but if you have an environment with lots of lun snapshots/replica’s you will want to ensure that you never mount duplicate volumes with the same signature – strange things can happen. Anyways, to mount the volume, take note of the VMFS UUID and we can use the following command.
esxcli storage vmfs snapshot mount -u 5315e865-0263a58f-413a-18a99b8c1ace
And with that you should now have your Dell VRTX storage back online – everyone is happy and getting along once again – Thanks for reading!
Every year VMware takes the thousands of session abstracts submitted by community members and puts them out there to the masses so YOU can have your say, whether it be a yay or nay! This year is no different so if you haven’t already cast your votes for the session you want to see you’d better hurry as voting ends this weekend, Sunday, May 18th @ 11:59 PDT.
Now there are a ton of great sessions available and by no means am I going to tell you which ones to vote on (wait, yes I am and I’m going to do it right now!) If you are having trouble wading through them all or just want to get that clicking finger warmed up why not just search for Session 1683 and give that one a vote.
For real though I have some high hopes for this session – I’ve teamed up with a couple of the brightest and smartest guys I know when it comes to vCO (James Bowling [blog/twitter] and Joerg Lew[blog/twitter]) to bring an informative panel session revolving around best practices, pitfalls, tips and tricks when it comes to vCenter Orchestrator. We are hoping to turn this session into a real discussion with a lot of interaction from the audience. So, if that sounds appealing to you then go ahead and give us the ‘Thumbs Up’. If not, then leave unchecked – actually, don’t, just Thumbs up it anyway 🙂
Either way, VMworld 2014 is quickly approaching and I hope to see you there!
Ever have an issue that no matter what you do you can’t seem to get rid of an old vCenter Orchestrator server that’s registered with vCenter? No? Well, you might want to just stop reading then! Either way, I have and no matter how many times I un-configured the vCenter plug-in, removed the vCenter plug-in, reloaded the vCenter plug-in the entry would just not seem to go away. After a slew of curse words and a half dozen restarts of vCO and SSO I finally prevailed – and this is how I did so.
Take the “mob” approach and “dispose” of the vCO server.
Don’t worry, there’s no illegal activity here – I’m not talking about taking Soprano action but what we will do is get a little Al Capone on the vSphere MOB (Managed Object Browser). The MOB is basically a graphical representation or hierarchy of our vSphere objects which allows us to view properties and invoke and perform different methods on different objects to achieve the respective results. That’s about the best way I can explain it – anyways, let’s cut to the point and get rid of that registered vCO server.
Access the mob by opening up your favorite browser and navigating to https://IP_OF_VCENTER/mob/
Once authenticated let’s click our way to our vCenter extensions by hitting ‘content’, then ‘Extension Manager’
Here we can see all of the extensions that are currently registered with our vCenter Server, including our vCenter Orchestrator extension.
Before we can go ahead and unregister this extension we need to obtain the extension key or unique identifier. To do so, you guessed it, click on it
If you have more than one vCO extension and can’t figure out which one is which try drilling further down into the object by clicking ‘server’ in order to get the URL associated with the object. That should help you figure out which object key you need.
Copy that object key and head back to the ‘Extension List’ screen. Here, we need to invoke a method located in the bottom section called ‘Unregister Extension’. Simply paste in your extension key you obtained above and click ‘Invoke Method’.
Booyah! All should be well in the world again! Hope someone finds this short, but to the point post helpful! As always, comments, concerns and threats are all welcome through the outlets provided in the comments section. Happy Friday and #GOHABSGO.