Tag Archives: vSphere 5.5
All to often I find myself in the following situation – I’m in the midst of deploying a new service or project into our environment. I have gone through tons of user manuals and articles, went through weeks of training and technical tutorials, successfully completed proof of concepts and pilots, yet as I’m beginning the production deployment I sit at my desk puzzled, staring into space in deep thought, perplexed by the multitude of options running through my mind over what I am going to name this server. In the Windows world, those 15 simple characters allowed in the NetBIOS name puts my mind in such a tailspin – sure, we have our own naming conventions for servers, first three digits are dedicated to a location code, followed by a dash, then whatever, then ending in a “-01” and increment – so that leaves me now with 8 characters to describe the whatever part that I’m deploying, and in some instances, it’s those 8 simple characters that tend to be the most difficult decision in the project – even with somewhat of a server and endpoint naming convention in place.
But it goes beyond just servers and endpoints.
Sure, most companies have naming processes in place for their servers and workstations – and I’ll eventually come up with something for those 8 characters after a coffee and some arguments/advice from others. The most recent struggles I’ve had though, apply not to servers, but to inventory items within vSphere. There are a lot objects within vSphere that require names – Datastores, PortGroups, Switches, Folders, Resource Pools, Datacenters, Storage Profiles, Datastore Clusters…..I can go on for quite some time but you get the point. All of these things require some sort of a name, and with that name comes a great deal of importance in terms of support. For outsiders looking in on your environment and their understanding of what something is, as well as for your own “well-being” when troubleshooting issues – a name can definitely make or break your day.
So how do we come up with a naming convention?
This sucks but there is no right or wrong answer for your environment – it’s your environment and you need to do whatever makes sense for you! Unlike naming children we can’t simply pick up a book called “1001 names for vSphere Inventory Items” and say them out loud with our spouses till we find one that works – we need something descriptive, something we can use when troubleshooting to quickly identify what and where the object is.
Back to my recent struggle – it had to do with datastores. For a long time I’ve had datastores simply defined as arrayname-vmfs01 and increment. So, vnx-vmfs01, vnx-vmfs02, eva-vmfs01, etc… This has always been fine for us – we are small enough that I can pretty much remember what is what. That said, after adding more arrays and a mixture of disk types (FC, SAS, NLSAS, SATA) I began to see a problem. Does eva-vmfs01 sit on SAS or SATA disks? Is it on the 6400 or 4400? Is it in the primary or secondary datacenter? Is this production or test storage? Does it house VMs or backups? What is the LUN ID of eva-vmfs01? I know – most of the questions can be answered by running some CLI commands, clicking around within the vSphere client or performing a little more investigation – but why put ourselves through this when we can simply answer these questions within the objects name?
So I set out to Twitter, asking if anyone had any ideas in regards to naming conventions for datastores – and I got a ton of responses, all with some great suggestions, and all different! So to sum it all up, here are a few suggestions of what to include in a datastore name that I received.
- Array munufacturer/model/model number
- Disk Type (SAS, FC, NLSAS, SATA, SCSI)
- Lun Identifier/Volume Number
- Destination Type (Backups, VMs)
- Storage Tiers (Gold, Silver Bronze/Tier 1, Tier 2, Tier3)
- Transport type (iSCSI, NFS, FC, FCoE)
- Raid Levels
- vSphere Cluster the datastore belongs to
- Of course, Description
Yeah, that’s a crap-load of information to put in a name – and maybe it makes sense to you to use it all but in my case it’s just too much. That said, it’s all great information, the toughest part is just picking the pieces you need and arranging them in an order that you like. Having something named DC1-TOR-HP-EVA-6400-FIBRE-FC-R6-VM-GOLD-CLUSTER1-L15 is a little much.
And in the end
So what did I chose? Well, to tell you the truth I haven’t chose anything yet. I thought by writing this post I might spark some creative thinking and it would pop into my head – but no – I’m more confused than ever. Honestly, I’m leaning towards something like array-disktype-lunid, like EVA-FIBRE-L6 or VNX-NLSAS-L4, but I just don’t know. This stuff is certainly not a deal breaker, but I’m just trying to make my life a bit easier. If you think you have the end all be all of naming conventions feel free to leave a comment! I’m always open for suggestions!
Today I received a message from VMware Education Services introducing a new way for current VCP holders to refresh or re-certify before their VCP expires. Currently as it stands, anyone holding a VCP certification prior to March 10, 2013 has only until March 10, 2015 to re-certify using one of the following methods.
- Take the most current VCP exam in any of the available tracks (Datacenter Virtualization, Cloud and Desktop – not sure if Network Virtualization qualifies for this or not). No matter which track you held your VCP in, all will be refreshed with another two years.
- Take an advanced level exam, meaning the VCAP DCA or VCAP DCD. Not only will you advance to the next level, you will refresh your VCP expiration as well.
Prior to today, these were your options. Now however all you VCP holders have a third option, so long as you are currently hold the VCP5-DCV status.
What is a delta exam?
This is something new to VMware certifications. Basically, this exam is based only on the differences between vSphere 5.0/5.1 and the vSphere 5.5 exams. Also, instead of your normal 135 questions the delta exam will only have 65. The biggest difference is how the exam is delivered – you won’t need to drive to a testing center for this one, it is being offered online through Pearson Vue – and I’m assuming this will be a similar fashion to that of the VCA delivery. Another noticeable difference is price – this one, coming in at $120 USD instead of the normal $220 USD.
Is it worth it?
This is something I can’t answer for you – you will have to go through the scenarios in your head. Currently I have an expiry date of January 2016 for my VCP5 and honestly I’d rather sit a new version of the VCAP then do the VCP again. That said, can I expect a VCAP6-DCA to be available by Jan 2016? I have no idea! Do I want to risk the chance of losing my VCP due to no new VCAP exam coming out or possibly failing the VCAP when it does come out? It’s all a giant kerfuffle in my head right now! One note, the email I received said it was only available to those who need to renew their VCP before March 10, 2015. As noted above, mine was extended to Jan 2016 due the completion of my VCAP in January of this year. That said, I went through the process of being authorized for this delta exam and had no issues getting into the portion of the Pearson Vue site which allows me to schedule it. So, try for yourself I guess!
Time’s a wastin!
Oh yah, better hurry and make your mind up. This delta exam will only be available until November 30th, 2014! So you have just less than a couple of months to figure out what you are going to do! Honestly, this whole re-certification process just confuses and puts me in a bad mood Nonetheless, though I’d share the news! Oh, I tried to use the VMUG Advantage VCP discount code – didn’t work!
A colleague of mine, one whom was attempting to troubleshoot some issues with Dell support was asking about the possiblity of gathering a DSET report on one of our hosts. DSET, or the Dell Server E-Support Tool is used to gather hardware, storage, and OS support information which consolidates into a single zip file which is used by support to troubleshoot and inventory your Dell Poweredge servers. Needless to say, DSET was pretty similar in the Windows/Physical world – simply install on the local OS, run the command and you are done.
In ESXi this becomes a little trickier. In fact, after reading up on some documentation I was somewhat reluctant, as it requires that the Dell OpenManageServer Administration bundle be installed on your host. In the past I’ve found myself fighting with Dell OpenManage and Server Administrator bundles as well as their remote counterparts. Seeing that only certain versions work with certain ESXi releases, and having to match up versioning numbers exactly to make things function properly. That, and the fact that every time I seem to hit Dell’s support site there are new releases really make things, well, let’s say troublesome (or annoying).
Nonetheless I gave it a shot and after enough experimentation I found a combination that worked – so, in case you’re having the same issues maybe this will help.
First up, OpenManage
So, first we need to install the OpenManageServer Administrator Bundle version 7.4 – you can find that located here. Go ahead and download the zip file and extract to /var/log/vmware on your host. Yes, the package will look for that specific path so you will need to be sure it is in /var/log/vmware. From there we can simply install the vib with the following command
Next – DSET
The version of DSET that we will install is 3.6. The installation for DSET is the standard Next Next type of install – so I won’t go over much of that – just be sure to select both the CIM provider and the collector. You can find it here. Once done you are good to go. Launch a command shell (as administrator) and browse to c:\Program Files(x86)\Dell\AdvDiags\DSET\bin and run the DellSystemInfo.exe command with your desired parameters (example below)
There you go! Your Dell DSET log that you can now forward off to support to get your issues looked after. This certainly isn’t a very difficult thing to do but troublesome nonetheless trying to match up versions to make things work. Anyways, hope it helps with anyone having issues.
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!
Over the past couple of months I’ve been working on some vCO workflows to setup and configure a Dell VRTX as we are on the verge of deploying a handful of them. Now this isn’t going to be a big post about what VRTX can do nor is it how to use vCO to set it up – I’ll save them for later – this is simply one small quirk that I’ve found when installing ESXi 5.5 onto the blades inside of the VRTX.
Small is the new big.
I shouldn’t have said small quirk – it’s somewhat of a show stopper. If you simply throw on the vanilla ESXi 5.5 image, or even the Dell released image of ESXi 5.5 you will quickly notice that you have absolutely no storage available to you from the shared PERC controller that sits inside the VRTX. Kind of hard to use the box with no storage 🙂
Before I go into my Dell rant if you are just looking for the solution, just scroll down to the “Driver thang” section of this post. For the rest of us…
Since writing this Dell has released a supported version of ESXi 5.5 for the Dell VRTX blades. Head over to Dell.com and punch in your service tags to get the image. I’ve used and tested this and it work flawlessly 🙂 Thanks Dell!
Start-Rant -Type ‘Mini’
ESXi 5.5 is not certified on a Dell VRTX, so ultimately, you could say, it isn’t supported – not by Dell or not by VMware. What I don’t understand here is that how Dell can release a “converged” solution, promote the crap out of it stating how great it is to run VMware on, and not support the latest release of ESXi!?!?! I mean, this thing was released in the summer of 2014. ESXi 5.5 was announced at VMworld in August 2013! You would think that Dell would have the drive to hit the market with this thing supporting the latest and greatest software – but no – either way, I’m sure it will all be updated soon, and I’m sure they have their reasons – but for the meantime, here’s how to get it going…
Ain’t nuttin but a driver thang.
The fact that you don’t see storage isn’t the result of any major issue or complex problem. It’s simply a driver. The driver that the shared PERC uses included with the ESXi 5.5 image is just too new (?!?!?!). However the version you need, or the version that I’ve found to work is labelled megaraid_sas version 06.801.52.00. What the difference is between these two versions I have no idea, i just know you need 6.801.52 to make it work. You can grab that here.
Once you have the file you are just a vib install away from VRTXing all night long. Pick your poison when it comes to vib installs; update manager, vMA or esxcli – for the sake of not having to put too much effort into anything I’ll go over the esxcli way of installing the vib. First things, upload that VIB to one of your datastores or an accessible area on the host. From there, ssh in and install the vib using the following command.
esxcli software vib install -d /tmp/megaraid/megaraid_sas-06.801.52.00-offline_bundle.zip
The only thing that stands in between you and your VRTX storage now is a reboot, so go ahead and do that.
There you have it – storage!
This is only the way I’ve found to make storage work with the VRTX and 5.5 and hey, I could be crazy by doing all of this – so if you have any other suggestions, concerns, or comments I encourage them below or send me a message on Twitter – Like I said, I have a handful of these to configure so I’d rather not roll them out in some kind of crazy state 🙂
With Update 1 of vSphere 5.5 released to the masses I'm sure that there are a lot of IT environments finally making the jump to the latest version of the hypervisor. I've begun the task of upgrading my vSphere environment in hopes of getting it up to snuff with all of the latest features and bug fixes. 5 years ago, this 'vSphere environment' consisted of vCenter Server and some hosts, now, vSphere environment contains a whole lot more than just the core components of hypervisor and management. The following are just a few examples of the many reasons that I believe vSphere upgrades, while having gotten easier, take much much longer to complete – there is a lot to it!
My vCenter Server has put on some pounds
As I mentioned just a short 5 years ago I had no problems pealing through a vSphere upgrade in less than a day. A simple vCenter upgrade followed by update manager orchestrating a handfull of host updates and voila, up to date. Now, things have changed. Yes, we've definitly accepted virtualization as a viable option for our production workloads, thus we've grown substantially, so there are more hosts to update – but hosts aren't really the most time consuming task in the process. It's everything else. Have a look at vCenter for instance – it's no longer just vCenter – it's moved from a single service to a compilation of applications and services handling everything from host provisioning to authentication to syslogging. So really, when I look at upgrading my vCenter Server, I'm actually talking about upgrading SSO, vSphere Web Client, Inventory Service, vCenter Server, AutoDeploy, Update Manager, and the SysLog Collector – all of which take time and could easily require a half day in itself to be configured.
Don't forget about the value-add!
Value Add – you know, all of those VMware and third-party tools that you threw into the environment over the years to monitor, secure, backup, automate, and tweak the performance of vSphere! Aside from assuring that they are compatible with the new release, most of the time, especially in VMware's case, they themselves will require upgrades to support the new release. So things like vCenter Operations Manager, Site Recovery Manager, vSphere Replication and Data Protection, vCenter Orchestrator, vSphere Management Assistant, etc will all need to be updated. Thankfully VMware has done a great job over the last couple of years in terms of the timing of these releases, more so aligning them with the release of the hypervisor updates. In terms of compatibility you need to pay attention to what versions of vSphere your third-party applications support. Applications like Veeam Backup and Replication, VMware View – you will want to be sure that before you go ahead and venture on a vSphere upgrade that you have the support from your third party vendors.
When I was your age we didn't have all these Virtual Appliances.
It's no doubt that VMware sees value in releasing some of their products in the form of a virtual appliance. By bundling these applications in an ovf it simplifies the setup and configuration, allowing customers to get things up and running faster, essentially hitting the market quicker. On VMware's end, let's just hope that they reduce the support calls and resources they need to dedicate to maintain these products – although that's highly unlikely :). Either way, the virtual appliance route doesn't just help with your initial setup, it can also provide ease of use when upgrading as well. vCenter Orchestrator upgrades can be accomplished by attaching a new appliance to the old database and performing updates. The vCenter Operations Manager vApp can be updated by simply loading a .pak file you download from your myvmware portal. The vSphere Management Assistant can accomplish updates via the vima-update command. The vCenter Server Appliance handles this even better – 2 clicks – check for updates, apply updates. This will go ahead and update all of those components that make up vCenter Server (SSO, Inventory, AutoDeploy, Web Client, etc). It's nice to have an easier upgrade with these appliances, what would even be nicer is to have VMware standardize on how the appliances are upgraded – chose one method and go for it.
Are we done yet?
No, not really even close. Aside from the core component updates there are a number of items within your vSphere environment that also need to be updated. First off, do you use dvSwitches? Be sure that you circle back and see if they require an update. dvSwitches add new features and benefits in terms of versions – so if your initial upgrade was driven by a new networking feature that was included, you might not get access to this until you go and upgrade your switches to the new version. Same goes for vmfs and your storage. Any datastore formatted as vmfs will also be tied to a specific version or compatibility number – so be sure to upgrade all of your datastores as well. Thankfully these processes are non disruptive and can be done without affection our production workloads
Lastly, the reason we are all here, the VMs
More so the applications running on the VMs but none the less we have to update these as well. Firstly, every core release usually sparks an update for VMware Tools as well. By now we should all be used to updating VMware tools. Again, we now have the ability to do this without requiring a reboot of the virtual machine which certainly makes this process more scriptable and achievable. Secondly, to support newly published config maximums and engage in some new features the VM hardware needs to be updated. Unfortunately there is no way around downtime being required for this one as the VM compatibility as it's now called can only be upgraded while the VM is powered off. That said, VMware has made some strides and implemented some features within the Web Client that we can flag to upgrade VM compatibly during it's next normal reboot – so a bit of help there for us. Personally, I like to schedule the maintenance and just get it done – that way I know it's done and done right 🙂
Go have a beer!
Well, I think I've covered everything! Everything inside of my environment anyways. So pat yourself on the back and go have a beer – unless you have a DR environment – then you need to go and duplicate everything you have just done! So, I guess I'm going to have a beer at my DR site 🙂