Tag Archives: VMware
vMotion is pretty awesome am I right? Ever since I first saw my first VM migrate from one host to another without losing a beat I was pretty blown away – you always remember your first In my opinion it’s the vMotion feature that truly brought VMware to where they are today – laid the groundwork for all of the amazing features you see in the current release. It’s something I’ve taken for granted as of late – which is why I was a little perplexed when all of a sudden, for only a few VMs, it just stopped working…
You can see above one of my VMs that just didn’t seem to want to budge! Thankfully we get a very descriptive and helpful error message of “A general system error occurred: vim.faultNotFound” – you know, because that really helps a lot! With my Google-Fu turning up no results and coming up empty handed in forum scouring I decided to take a step back to the VCP days and look at what the actual requirements of vMotion are – surely, this VM is not meeting one of them! So with that, a simplified version of the requirements to vMotion…
- Proper vSphere licencing
- Compatible CPUs
- Shared Storage (for normal vMotion)
- vMotion portgroups on the hosts (min 1GB)
- Sufficient Resources on target hosts
- Same names for port groups
Licensing – check! vCloud Suite
CPU Compatibility – check! Cluster of blades all identical
Shared Storage – check! LUNs available on all hosts
vMotion interface – check! Other VMs moved no problem
Sufficient Resources – check! Lots of resources free!
Same names for port groups – check! Using a distributed switch.
So, yeah, huh?
Since I’d already moved a couple dozen other VMs and the fact that this single VM was failing no matter what host I tried to move it to I ruled out the fact that there was anything host related causing this and focussed my attention to the single VM. Firstly I thought maybe the VM was tied to the host somehow, using local resources of some sort – but the VM had no local storage attached to it, no CD ROMs mounted, nothing – it was the perfect candidate for vMotion but no matter what I tried I couldn’t get this VM to move! I then turned my attention to networking – maybe there was an issue with the ports on the distributed switch, possibly having none available.
After a quick glance, there was lots of ports available, but there was another abnormality that reared its ugly head! The VM was listed as being connected to the switch on the ‘VMs’ tab – however on the ‘Ports’ tab it was nowhere to be found! So what port was this VM connected to? Well, let’s ssh directly to the host to figure this one out…
To figure this out we need to run the “esxcli network vm port list” command and pass it the VMs worldID – to get that, we can simply execute the following
esxcli network vm list
From there, we can grab the world ID of our VM in question and run the following
esxcli network vm port list –w world_id
In my case, I came up with the following…
Port 317! Sounds normal right? Not in my case. In fact, I knew for certain from my documentation that the ports on this port group only went up to 309! So, I had a VM, connected to the port group, on a port that essentially didn’t exist!
How about a TL;DR version?
Problem stemmed from the VM being connected to essentially a non-existent port! Since I couldn’t have any downtime on this port my fix was to simply create a another port group on the dvSwitch, mimicking the settings from the first. After attaching the VM to the newly built port group, then re-attaching back to the existing one I was finally attached to what I saw as a valid port, Port #271.
After doing this guess what finally started working again – that’s right, the wonderful and amazing vMotion . I’m sure you could achieve the same result by simply disconnecting and connecting, however you will experience downtime with that method – so I went the duplicate port group route.
Where there is one there’s many
All of this got me thinking – this can’t be the only VM that’s experiencing this issue is it? I started looking around trying to find some PowerCLI scripts that I could piece together and as it turns out, knowing what the specific problem was certainly helps with the Google-Fu and I found a blog by Jason Coleman dealing with this exact same issue! Wish I could’ve found that earlier . Anyways, Jason has a great PowerCLI script attached to his post that peels through and detects which VMs in your environment are experiencing this exact problem! He even has automated the creation of the temporary port groups as well! Good work Jason! After running it my conclusions were correct – there were about a dozen VMs that needed fixing in my environment.
How or why this occurred I have no idea – I’m just glad I found a way around it and as always, thought I’d share with intention of maybe helping others! Also – it gave me a chance to throw in some Seinfeld action on the blog! Thanks for reading!
Recently I finally bit the bullet and decided to bring the vCenter portion of a vSphere environment up to version 6.5. Since the migration from a Windows based vCenter to the VCSA is now a supported path I thought it would also be a good time to migrate to the appliance as well. So with that I ran through a few blogs I found in regards to the migration, checked out the vSphere Upgrade Guide and peeled through a number KB’s looking for gotchya’s. With my knowledge in hand I headed into the migration.
At this point I had already migrated my external windows based PSC to version 6.5 and got started on the migration of the windows-based vCenter Server. Following the wizard I was prompted for the typical SSO information along with where I would like to place the appliance. The problem though came when I was prompted to select a deployment size for my new VCSA. My only options available were Large and X-Large. Might not be a big deal if in fact this environment required this amount of resources – Looking at the table below those deployment sizes are scoped to fit at a 1000 host and above mark.
Did this environment have 1000+ hosts and 10000+ VMs? Absolutely not! At its largest it contained maybe 70 hosts and a few hundred VMs running on them – a Small configuration at best, medium if you want to be conservative! At first I thought maybe I was over provisioned in terms of resources on my current vCenter Server – but again, it only had 8 vCPU’s and 16GB of RAM. With nothing out of the ordinary with vCenter itself I turned my attention to the database – and that’s where my attention stayed as it was currently sitting at a size of 200GB. Honestly, this seemed super big to me and knowing that it had been through a number of upgrades over the years I figured I would make it my goal to shrink this down as small as possible before trying again! TL;DR; version – The database was the culprit and I did end up with the “small” option – but I did a number of things after a frenzy of Google’s and searches – all listed below…
Reset the vpx provider
The vpx data provider basically supplies the object cache for vCenter – caching all inventory objects such as hosts, clusters, VMs, etc in order to provide that super-snappy response time in the vSphere Web Client 6.0 (Is this sarcasm?). Anyways, resetting this essentially will reduce the size of our Inventory Database. Now, the problem in versions prior to 5.5 Update 3 is that there was no way to reset individual data providers – in order to do one you had to do them all – and that meant losing all of your tags, storage profiles/policies, etc. Thankfully, 5.5 U3 and 6.0 allows us to simply reset just vpx, leaving the rest of our environment in-tact. In order to do so we must first get into the vSphere Inventory Managed Object Browser (MOB) and get the UUID of the vpx provider. **NOTE, this is different than the MOB you may be used to logging into, see below ***
First, log into the Inventory Service MOB by pointing your browser to https://vCenterIP/invsvc/mob1/ From there, simply click the ‘RetrieveAllProviderConfigs’ link within the Methods section as shown below
In the pop up dialog, click ‘Invoke Method’, then run a search for vpx
It’s the providerUuid string that we are looking for – go ahead and copy that string to your clipboard and return to https://vCenterIP/InvSvc/mob1/ – this time, clicking the ‘ResetProviderContent’ link under Methods. In the pop up dialog, paste in your copied UUID and click ‘Invoke Method’ as shown below…
After a little while the window should refresh and hopefully you see no errors! The process of resetting for myself took roughly 5 minutes to complete….
Getting rid of logs
Although vCenter does its own log rotation you may want to check out and see just how much space your logs are taking up on your current vCenter server before migrating as some of this data is processed during the migration/upgrade. I freed up around 30GB of disk by purging some old logs – not a lot, but 30GB that didn’t need to be copied across the wire during the migration. There is a great KB article here outlining the location and purpose of all of the vCenter Server log files – have a look at it and then peruse through your install and see what you may be able to get rid of. For the windows version of vCenter you can find all of the logs in the %ALLUSERSPROFILE%\VMware\vCenterServer\logs\ folder. I mostly purged anything that was gzipped and archived from most of the subfolders within this directory. Again, not a difference maker in terms of unlocking my “Small” deployment option – but certainly a time-saver during the migration! So what was culprit that was not allowing me to select “Small” – yeah, let’s get to that right now…
My Bloated vCenter Database
Yeah, 200GB is a little much right – even after resetting the vpx provider and shrinking the database files I was still sitting pretty high! So, since I had no intention of migrating historical events, tasks and performance data I thought I’d look at purging it before hand! Now if you have ever looked at the tables within your vCenter Server database you will find that VMware seems to create a lot of tables by appending a number to the VPX_HIST_STAT table. I had a lot of these – and going through them one by one wasn’t an option I felt like pursuing. Thankfully, there’s a KB that provides a script to clean all of this up – you can find that here! Go and get the MSSQL script in that KB and copy it over to your SQL Server. Once you stop the vCenter Service we can simply run the following command via the command prompt on our SQL Server to peel through and purge our data.
sqlcmd -S IP-address-or-FQDN-of-the-database-machine\instance_name -U vCenter-Server-database-user -P password -d database-name -v TaskMaxAgeInDays=task-days -v EventMaxAgeInDays=event-days -v StatMaxAgeInDays=stat-days -i download-path\2110031_MS_SQL_task_event_stat.sql
Obviously you will need to assign some values to the parameters passed (TaskMaxAgeInDays, EventMaxAgeInDays, & StatMaxAgeInDays). For these you have a few options.
- -1 – skips the respective parameter and deletes no data
- 1 or more – specifies that the data older than that amount of days will be purged
- 0 – deletes it all!
For instance, I went with the 0, making my command look like the following….
sqlcmd -S IP-address-or-FQDN-of-the-database-machine\instance_name -U vCenter-Server-database-user -P password -d database-name -v TaskMaxAgeInDays=0 -v EventMaxAgeInDays=0 -v StatMaxAgeInDays=0 -i download-path\2110031_MS_SQL_task_event_stat.sql
After purging this data, and running a shrink on both my data and log files I finally had my vCenter database reduced in size – but only to 30GB. Which, in all honesty still seemed a bit large to me – and after running the migration process again I still didn’t see my “Small” deployment option. So I went looking for other large tables within the database and…..
It’s not very nice to meet you at all!!! After finally getting down to this table – and running “sp_spaceused ‘VPX_TEXT_ARRAY’” I found that it was sitting a whopping 27GB. Again, a flurry of Google! What is VPX_TEXT_ARRAY and what data does it hold? Can I purge it? Well, yes….and no. VPX_TEXT_ARRAY, from what I can gather keeps track of VM/Host/Datastore information – including information in regards to snapshots being performed on your VMs. Also from what I can gather, from my environment anyways, is that this data exists within this table from, well, the beginning of time! So, think about backup/replication products which constantly perform snapshots on VMs in order to protect them – yeah, this could cause that table to grow. Also, if you are like me, and have a database that has been through a number of upgrades over the years you may end up having quite a bit of data and records within this table as it doesn’t seem to be processed in any sort of maintenance job. In my case, 7 million records resided within VPX_TEXT_ARRAY. Now, don’t just go and truncate that table as it most likely has current data residing in it – data vCenter needs in order to work – there’s a reason it tracks it all in the first place right? Instead, we have to parse through the table, comparing the records with those that are in the VPX_ENTITY table, ensuring we only delete items which do not exist. The SQL you can use to do so, below…
DELETE FROM VPX_TEXT_ARRAY
WHERE NOT EXISTS(SELECT 1 FROM VPX_ENTITY WHERE ID=VPX_TEXT_ARRAY.MO_ID)
A long and boring process – 18 hours later I was left with a mere 9000 records in my VPX_TEXT_ARRAY table. Almost 7 Million removed. Just a note, there is a KB outlining this information as well – in which it says to drop to SINGLE_USER mode – You can if you wish, but I simply just stopped my vCenter Server service and stayed in MULTI_USER so I could check in from time to time to ensure I was still actually removing records. an sp_spaceused ‘VPX_TEXT_ARRAY’ in another query window will let you track just that. Also, it might be easier, if you have the space, to set the initial size of your transaction logs something bigger than the amount of data in this table. This allows SQL to not have to worry about growing them as it deletes records – you can always go back in the end and reset the initial size of the tlogs to 0 to shrink them.
So – a dozen coffees and a few days later I finally ran another shrink on both the data and log files, setting their initial sizes to 0 and voila – a 3GB database. Another run at the migration and upgrade and there it was – the option to be “Small”! Again, this worked in my environment – it may not work in yours – but it might help get you pointed in the right direction! Do reach out if you have any questions and do ensure you have solid backups before you attempt any of this or anything you read on the net really Also, there’s always that Global Support Services thing that VMware provides if you want some help! Thanks for reading!
Dreams are important! Otherwise, sleep is just 8 hours of nothing. – MacGyver
vSphere 6.5 is here!
NDA’s have been lifted and the flood gates have opened in terms of bloggers around the world talking about vSphere 6.5! Now that the product has finally been declared GA we can all go ahead and download it today! Certainly the new HTML5 client, the addition of a more functional vCenter Server Appliance and built-in disk level encryption are enough to make me want to make the jump…eventually 🙂 That said there is a lot that is new with vCenter and ESXi – you can check it all out here.
Veeam Backup & Replication 9.5 is here!
And just as VMware releases it’s flagship hypervisor software to the masses Veeam follows behind one day later with the support and availability back it all up with their updated release of version 9.5 of Backup & Replication. There is a lot that’s new within this release – check it all out here! With Nimble support and a ton of integration with other Veeam products such as the Veeam Agents this release has a lot – but perhaps some of my favourite enhancements will be the ones that will probably not be written about the most and that’s all of the engine enhancements and things like the vSphere inventory cache. As with most Veeam releases I’m sure this one will be well adopted!
Tech Field Day 12 – that’s a wrap!
I’ve just returned home from Tech Field Day 12 in beautiful San Jose! I say beautiful but I was told it was cold by multiple people there – that said, I’m Canadian, and 18C in the middle of November is not my idea of cold 🙂 Either way I sat with 11 of my peers around the TFD table for a couple of days and got blasted by the fire hose. There was some great presenting companies there; think Dell-EMC, DriveScale, Rubrik, Cohesity, StorageOS, Docker, and Igneous. Expect more in this space about what these guys had to talk about but for now if you want to check out the videos you can do so – links are all over here.
Fancy some community recognition!
Ah, November – cooler air, the transition from Halloween to Christmas – and of course, a flurry of forms to fill out if you’d like to be included in any vendor/community recognition programs. Most of these things require you to nominate yourself – so suck up any pride as you may have to get a little self absorbed while you try and brag yourself up. Recognition programs are a funny thing – Some are great, some are so-so – I’m not going to go into the details of each. If you want a great spot to see a list of them all Jim Jones has a great post outlining everything here. And to get a glimpse into one of my favourties, the Veeam Vanguard program – check out Matt Crapes post here. I’ve also been invited to the KEMP VIP program – which is new to me so expect to see more about that as well in the future.
Beetlejuice, Beetlejuice, Docker
I feel like I can’t attend any presentation anymore without hearing the work Docker – honestly, containers and Docker is just popping up everywhere – with the oddest of technologies claiming they have support for Docker. So, with all this my problem is, What the eff is Docker – I’ve never had a use-case to even start looking at containers within my day job – therefore, I don’t really have that much knowledge around the challenges and benefits of them. After seeing them at TFD I can now say that I need to explore this further – and jump on this container bandwagon to learn what they are all about. First stop, Mr Stephen Foskett’s blog where he tells us just “What the deal with containers are“. If you are just learning, or just love containers – check it out!
Would it kill you not to be so funny all the time? That’s all I’m askin’. This woman thinks I’m very funny and now you’re gonna be funny, so what am I gonna be? I’m gonna be a short bald guy with glasses who suddenly doesn’t seem so funny. – George Costanza
VMworld is over – vSphere 6.5 is near
With VMworld EMEA sweeping up the remains of the solutions exchange the dawn of vSphere 6.5 is here! And with that comes a multitude – and I mean a crap load of multitudes of blogs talking about all of their favourite features of the release to come! With that said I can’t possible link to all of them that I have read – but what I will link to is to the linkmaster himself Eric Siebert! He’s got a great roundup post here of all of the features within vSphere 6.5. Now this post doesn’t have links, just quickly lists the features – but if you want to go deeper on a certain feature be sure to check out his ‘vSphere 6.5 Link-O-Rama’ page as well!
Renting vSphere on AWS
VMware and AWS announced a partnership – one which would allow vSphere to run on the Amazon cloud! What this means for customers is that they will get the familiarity of vSphere and all it has to offer, but on a cloud-like scale, running on bare-metal within Amazon’s datacenters. What’s in it for VMware – well, they get that global cloud they have been looking for, without having to actually build the datacenters behind it! And Amazon – well, who knows where they will take it but I can’t see them complaining too much about being able to pitch certain services and products to those who chose to run VMware on AWS! Anyways, Frank Denneman has a great article here taking a deeper look into everything – as well, a little bit of a preview on how the new service enables one pretty cool new feature – Elastic DRS.
Alastair teaches us to read!
Although this post is a couple months old I’m just getting around to sharing it now! I wanted to be sure as I’m always interested in how everyone in this community stays current with so much going on all the time! The amount of content getting created for and by the tech community is huge, and keeping track of it all is certainly becoming a skill! I read a lot, a lot of blogs so any way of figuring out ways to streamline my content consumption always sparks my interest! Alastair has already taken us through is process of creating content, but with this post he takes us through his process of consuming content! This is a great post with excellent tips on how to stay current!
More than simply writing a file
There’s a guest blog post on Michael White’s blog written by Michael Cade outlining the various backup methods used within Veeam Backup & Replication and how each one of them affects the capacity and performance on your backup repositories. If you are using VBR and you haven’t had an in-depth look at these backup methods I would suggest starting with this post – it does a great job at outlining just how each backup method works, what is actually contained within each VBR backup file type. It’s not just simply copying data here 🙂
#VDM30in30 30 posts, 30 days!
Think you have what it takes to pump out 30 posts in 30 days – I can say that I certainly thought I did at one point in time, but quickly realized after just a few days that I most certainly did not! But hey, kudos for trying right – and even though I have a lot going on this November I will most likely try again! Don’t have a clue what I’m talking about – well, the folks from the Virtual Design Master competition are once again challenging the blogging community to crank out 30 posts in 30 days throughout the month of November! Have a look at Eric Wright’s blog for a great description of what this is like! Now I know some people may think that the quality of posts may not be there, or that the content won’t be relevant, but honestly, my blogging isn’t about perfecting every single thing I do (I’m sure that’s apparent). It’s about sharing things I do, problems I run into, opinions I have – sometimes it may be relevant, sometimes it won’t – sometimes you may agree, sometimes you won’t – sometimes you may just not even understand why a post ends up on this blog! To me writing is about passion, and whether that passion be virtualization, technology, canadian folk music, maple syrup, hunting, whatever, it doesn’t matter! The point here is that when I write, I think – and when I think I learn – and nobody can argue that learning is invaluable! So heads up, you might see some odd posts here come this November!
Is it flowing? I like flowing, cascading hair. Thick lustrous hair is very important to me. Let me ask you this. If you stick your hand in the hair is it easy to get it out?
George Costanza – Seinfeld
Virtual Design Master 4 looking for sponsors
If you have never checked out the Virtual Design Master challenge I suggest you stop reading this and head over to their site and peruse the last 3 season, then com back here of course…. Anyways, the online, reality based challenge is back for Season 4 and they are looking for sponsors to help provide prizes, swag, infrastructure, etc for the upcoming season! So if you work for a vendor and want to get your brand attached to VDM4, follow this link to indicate your interest! They are looking to get everything firmed up to have a July/August competition.
New HTML5 vSphere Web Client!
Why VMware feels the need to change how the lightening fast, crazy responsive, highly reliable vSphere Web Client that is currently out there is beyond me, but they are… I hope you can detect the sarcasm in that last sentence. Anyways, they have been hard at work (re)developing the vSphere Web Client, removing it’s reliance on flash and flex and providing the same functionality through code based on HTML5. I’ve not yet had a chance to check this out, but from the reactions on the blogosphere and Twitter I’d say that they are on the right track! They are releasing the vSphere Web Client 6.5 as a Fling, allowing the product to get out into everyone’s hands before it’s integrated into a vSphere version. If you have a chance go and check it out – it’s simply a virtual appliance that integrates with your current environment.
Getting Linux ready for a vSphere Template!
Fellow VFD4 delegate Larry Smith recently posted in regards to cleaning up your Ubuntu templates! It’s a great post that covers off a lot of things than you can do to ensure you have a clean, prepped instance of Ubuntu to use a template within your vSphere environment. That said, he takes it one step further, scripting out the complete cleanup in bash – and in Ansible. If you deal with Linux/Ubuntu templates I would definitly recommend heading over to Larry’s blog and applying some of this scripty goodness.
vSphere.next – Beta Time!
VMware has announced that the next version of vSphere will enter a (limited) public beta. If you feel like you have the time and are ready to provide the effort in providing feedback, submitting bugs, etc to VMware in regards to the next release of vSphere then you can head here and indicate your interest in being a part of the beta. As far as I know not everyone will be accepted – careful consideration will be taken on who is chosen to participate as they want to ensure they are getting valuable feedback and discovering any gotchya’s in the product before releasing it to the masses!
ZertoCon – The Premier Business Continuity Conference
Zerto has been a long time sponsor of this blog so I thought I’d place a shoutout to them and what they have in the works this spring! You can join Zerto and many others from May 23-25 in beautiful Boston for ZertoCon. Lately we have seen a lot of these smaller vendors opting to have their own conferences – and honestly if you use their products they are a must for you to go! The VM/EMC Worlds are a great venue, but honestly, these smaller, laser focused conferences are absolutely fabulous if you are looking to gain more knowledge around certain vendors and their ecosystems! I encourage you to check it out and sign up if you have the chance to go!
As I’ve recently brought a HPE 3PAR 7200 into production with an ESXi 6.0 U2 cluster I thought what a better time than now to check out just how VVOLs are implemented by HPE.
Although the tasks to do so aren’t difficult by any means I find the documentation around doing so is a bit scattered in different KB’s and documents between VMware and HPE, especially if you have upgraded to their latest firmware (3.2.2 MU2).
As far as prerequisites go there really isn’t that many other than ensuring you are up to date on both your 3PAR firmware and ESXi versions. For the 3PAR you will need to ensure you are running at the very least 3.2.1. In terms of vSphere – 6.0 or higher. Also don’t forget to check your HBA’s on the VMware HCL and ensure that they are actually supported as well, and note the proper firmware/driver combinations recommenced by VMware.
After spending the day(s) updating firmware (ugh!) it’s finally time to get going.
Step 1 – Time
NTP is your friend for this step. Before proceeding any further you need to ensure that all of your hosts, vCenter Server and 3PAR are all synced in terms of time. If you have NTP setup and running then you are laughing here, but if you don’t, stop looking at VVOLs and set it up now! It should be noted that the 3PAR and the VMware infrastructure can be set to different time zones, however they must still be synced in terms of time!
Step 2 – Can we see the protocol endpoint?
At this stage we should actually check our ESXi hosts to ensure we can see the protocol endpoint on the 3PAR. To do so we will need to ensure that we see the same WWN after running a couple of different commands. First, as shown below, the ‘showport’ command on our 3PAR. Circled is the WWN of our 3PAR array. Make note of this!
With the WWN of our storage array in memory we can now head over to our ESXi hosts. SSH in and run the ‘esxcli storage core device list –pe-only‘ command. This command will return any Protocol Endpoints visible from the ESXi host. If all goes well we should see the same WWN that we did with showport, and the ”Is VVOL PE’ flag set to true – as shown below
As you can see, we have a match so at least we have some visibility from our hosts!
Step 3 – VASA
As we all know the whole concept of VVOLs requires the array to support VASA 2.0 and act as a storage provider for vCenter – this is what allows us to create our VM profiles and have the array automatically provision VVOLs depending on what profile is selected. On the 3PAR we can check the status of VASA by simply running the ‘showvasa’ command. In the case shown we can see that it is already enabled and functioning properly, however this wasn’t always the case for me. To enable the service I first tried the ‘startvasa’ command, however it was complaining about not having a certificate. The easiest way, if you plan on using self-signed certificates to generate one is to simply run the ‘setvasa -reset’ command. This will reset your VASA configuration and generate a self-signed cert. After this you can simply run ‘startvasa’ to get everything up and running…
Step 4 – Create the storage container
Now if you are following the HPE VVOL integration guide you won’t see this step, mainly because it was created around the 3.2.1 firmware, which would have already had a default, and only one storage container created for you. If you are running 3.2.2 though you have the option to create more than one storage container, and by default comes with, well, no storage containers. So before we go and register our vCenter with the VASA provider we first need to create a storage container to host our VVOL datastore. First, create a new Virtual Volume set with the following command
Then, let’s create our storage container and assign our newly created set to it
setvvolsc -create set:myvvolsetname
Again, these commands wouldn’t be required in 3.2.1 as far as I know, but are in 3.2.2
Step 5 – Register our VASA within vCenter
Now it’s time to head over the familiar, lightening fast interface we call the vSphere Web Client and register the 3PARs VASA implementation as a storage provider. Make note of the ‘VASA_API2_URL’ shown in step 3 – you will need this when registering. With your vCenter Server context selected, navigate to Manage->Storage Providers and click plus sign to add a new storage provider.
Enter your VASA URL from step 3, along with a name, username, and password and click ‘OK’. For this instance I’ve used 3paradm, but you may be better off investigating creating a new account with just the ‘service’ role within the 3PAR. Either way, get your new storage provider registered in vCenter and wait for the Status to show as Online and active.
Step 6 – The VVOL datastore
We are almost there I promise! Before we can deploy VMs within a VVOL or assign storage profiles to match certain CPG’s within the 3par we need to have our VVOL datastore setup within vCenter. I found the best spot to create this datastore is by right clicking the Cluster or ESXi host we want to have access to VVOLs and selecting Storage->New Datastore. Instead of selecting VMFS or NFS as we normally would, select VVOL as the type as shown below
On the next screen simply give your datastore a name and select the storage container (this is what we made available in step 4). Then, simply select the hosts you wish to have access to deploy VVOLs to and away you go!
Step 7 – Storage Profiles
At this point you could simply deploy VMs into your newly created VVOL datastore – the 3PAR will intelligently chose the best CPG to create the VVOL in, but the power really comes by being able to assign certain VM storage profiles to our disks, and having the VVOL go to the proper CPG depending on the array capabilities. Storage Profiles are created by clicking on the Home icon and navigating to Policies and Profiles within the web client. In the VM Storage Profiles section simply click the ‘Create new storage profile’ button. Give your new profile a name and continue on to the Rule-Set section.
The Rule sets of my “Silver” VM storage profile are shown above. As you can see, I’ve specified that I want this storage profile to place VM disks within my FastClass raid 5 CPG, and place their subsequent snapshots in the SSD tier CPG. When you click next you will presented with a list of the compatible and incompatible storage. Certainly select your compatible storage and click next. Once we have all of the profiles we need we can simply assign them to our VMs disk as shown below…
As you can see I’ve selected our newly created “Silver” policy for our new VM. What this states is that when this VM is created a new VVOL will be created on our FastClass disks on the 3PAR housing the VMs.
Step 8 – VVOL visibility
Although we are technically done with deploying VVOLs at this point I wanted to highlight the showvvvolvm command that we can utilize on the 3PAR in order to gain visibility into our VVOLs. The first being simply listing out all of our VMs that reside on VVOLs within the 3PAR.
As you can see by the Num_vv column we have 3 VVOLs associated with our VM (MyNewVM). But how do we get the information on those VVOLs individually – we can use the same command just with the -vv flag
showvvolvm -sc -vv
So now we can see that we have 1 VVOL dedicated for the config, 1 VVOL dedicated for the actual disk of the VM, and finally 1 VVOL hosting a snapshot that we have taken on the VM.
Anyways, that’s all I have for now – although I haven’t gone too deep into each step I hope this post helps someone along the way get their VVOLs deployed as I had a hard time finding all of this information in one spot. For now I like what I see between HP and VMware concerning VVOLs – certainly they have a long road ahead of them in terms of adoption – we are still dealing with a 1.0 product from VMware here and there are a lot of things that need to be worked out concerning array based replication, VASA high availability, functionality without VASA, GUI integration, etc – but that will come with time. Certainly VVOLs will change the way we manage our virtualized storage and I’m excited to see what happens – for now, it’s just fun to play with 🙂 Thanks for reading!