Uncategorized

Something I have learned over my career as a consultant is to back up everything before performing an upgrade, and then back it up again another way 🙂 There’s nothing worse than an upgrade going sideways and having no way to back out. Also, if you’re doing any sort of work in an enterprise setting, furnishing a back-out plan before you begin may well be a requirement. This is to ward off extended downtime and potential financial loss as a result. As deploying the vCenter Server Appliance (or whatever we’re calling it now…) becomes the de facto method of deploying vCenter, a Windows admin can sometimes no longer pop into SSMS and fire off a quick backup of the database. Especially as of version 6.0, the embedded vPostgres database is capable of handling quite a large environment, so more folks are opting to use it. As such, I’m going to go over how to grab a backup of it. It’s good practice to do this regularly if you aren’t getting a backup of it another way, and I also recommend doing this before any sort of upgrade (as I’m doing now). Here we go!

[Read more…]

Quick Tip: Cannot delete ISO on VMware datastore

There’s a VMware KB article that talks about trying to delete a file from a VMFS datastore, only to find that it’s locked by a particular ESXi host. The article walks through identifying which host as the file locked via a message in the vmkernel log file. By parsing the log message, one can deduce the MAC address of the host locking the file. From there the lock can be removed and the file deleted. The message in the logs looks something like this:

cpu6:5455056)FS3: 1393: vol ‘datastore_name‘, lock at 173475840: [Req mode: 1] Not free:

cpu6:5455056)[type 10c00004 offset 173475840 v 158, hb offset 3338752gen 4307, mode 1, owner 51b23791-f35c96e9-44ed-3c4a92f61680 mtime 2278287

cpu6:5455056)Res3: 5696: Rank violation threshold reached: cid 0xc1d0000c, resType 3, cnum 1410

The bolded section is a MAC address and will help chase down the host in question. But there’s something I’ve run into a number of times when trying to get a file deleted that I thought I’d share. When trying to delete an ISO (specifically an ISO) from a datastore, you’ll get the same error message about the file being locked. You search for the error you’re having and the KB article I referenced turns up. So you go look at vmkernel.log and find this:

2015-08-12T13:19:21.219Z cpu4:3476013)[type 10c00001 offset 201531392 v 18641, hb offset 3956736

gen 1051, mode 2, owner 00000000-00000000-0000-000000000000 mtime 44516

Now, what in the world does one do when the MAC address portion is empty? Well, after banging my head against my desk for about 5 minutes more times than I care to admit, I usually figure it out. I hope that after posting this I’ll remember that this means the ISO is mounted to a VM somewhere! Duh. If I can get this post to rank well in search engine results, maybe I’ll save someone from 4 minutes of those 5 minutes of head/desk banging agony. 🙂

Backing up vPostgres Database

Quick Tip: Cannot delete ISO on VMware datastore

2017 Reading Challenge