If you have been under a rock (like I was for a while!), Docker is a container technology and containers are very cool. Containers sparked my interest in the same way that virtualization did the first time I saw it. I really regret not getting into it sooner but better late than never. Seriously if you haven’t played with containers at all try it on a local system, VM, or use this really nifty site http://training.play-with-docker.com/
As you may be aware, vRealize Automation 7.3 just released a few days ago. I took some time to upgrade my lab and thought I would share my experience as well as a look at the new embedded health service.
First it goes without saying that this is a lab, not a production instance. Obviously you should take care before any upgrade with standard checks like ensuring compatibility with any extras you have, ensuring you have good functional backups, etc.
Also my lab is a simple deployment, not a distributed one. Again, do your homework to ensure that you are prepared for the entire upgrade scenario.
Ok let’s get to it!
You have the option of doing the upgrade by using an online repository. I am never a fan of doing a major upgrade this way. It is one thing to download minor patches but I would rather download the file and do my own checksum validation before applying it myself.
First, you will need to download the upgrade ISO from the VMware download site. It is the same location where you get the vRA OVA, just a different download. After the download completes, validate the checksum against the provided one to ensure that your download is good.
After it is downloaded, I uploaded it to a datastore I have for ISOs and then attached it to the vRA CDROM. Make sure you actually connect it! This still trips people up, including yours truly.
Next, login to the vRA VAMI (default :5480) as root. Under Update > Settings, select Use CDROM Updates and save.
Back on the Status page, hit Check Updates which should show the 7.3 update. If you don’t see it, you probably don’t have the CDROM connected. Then just hit Install Updates. Note that I’m actually jumping two versions here, 7.1 to 7.3. This is OK but if you have an older one than 7.1 you’ll need to check the release notes on how to get to 7.3.
You will see this message below for a while during the appliance update, but fear not – let it go and it will finish.
My only complaint about this process is I hate messages like this with no “update progress” messages (or even worse, progress bars that just constantly scroll and don’t actually indicate progress) but it is a minor fault. The IAAS updates actually do provide some good progress indicators.
Once it completes it will let you know and you can reboot the appliance.
After the appliance reboot you can check the update screen again as the IAAS server components get upgraded next.
Once the IAAS updates finish, you are good to go. Overall a very painless experience, so kudos to the vRA team for ensuring easier installs and upgrades!
Next after I logged into my tenant and took a quick look around to make sure nothing looked awry, I gave the new health check feature a whirl. As IAAS Admin, you’ll find the Health option under Administration. Note that you can also see this as Tenant Admin but you can only view results, not configure or run tests!
Click New Configuration to create a new test. Configuring the test is pretty straight forward aside from the fact that you will need to input vRA info as if the system doesn’t understand itself. This is because you are not limited to monitoring the vRA instance you are logged into…as long as you can reach it and have credentials you can do a health check.
The only thing that caught me up was the naming for my tenant admin who is a domain user. After trying domain\user in several iterations and failing miserably, I simply used user@domain and it worked like a charm. So be careful if you are using domain accounts here.
After the test is configured, simply run it.
Test results are all green, and green is good! If you click on the icon you’ll get a more detailed view of what tests were run and the results.
When I had the wrong user and some of the tests failed to run (the output was decidedly more yellowy-reddy than above), the detailed output actually did notify me of the problem and sometimes it will offer fixes as well. As far as I was able to determine from the guide and my poking around, you can’t configure notifications for the health check which is kind of a bummer. It would be great to be able to SMTP/SNMP if a health check issue arose. Hopefully this can be added in the future unless I’m just missing it.
Look for more on vRA 7.3 over the coming weeks!
That’s me blowing the cobwebs off of my blog. 🙂
Time marches on and things are always changing. I too have recently made several changes both in my personal and professional life. I am now a delivery engineer for CDI Southeast, though we are going through another transition period ourselves. I am also doing a bit of retooling, attempting to become a little less storage focused and branching out into other areas. Right now I’m trying to focus more on vSphere but also working with some DevOps stuff as well. I also released a course on Pluralsight last October which I am very proud of. If you are interested in hearing me talk to you about VNX for hours, I encourage you to check it out.
So, great things hopefully coming down the pipe for me in the future and I hope to continue to share with the community at large that has given so much to me.
In the meantime, here is a quick nugget that I turned up a couple of weeks ago. I was doing a pretty straightforward implementation of vSphere replication (and I hope to do a series on that soon), but ran into an oddity which I initially wrote off as a squirrel.
A squirrel is a situation where I walk into your building to do an implementation, and shortly thereafter you (or your co-worker, or your boss) comes up to me and says, “you know ever since you got here, the squirrels have been going crazy outside. What did you do?”
The squirrel can be anything really, but most of the time is comically unrelated to anything I’m actually working on. And sometimes it is just people messing around with me. “Hey you know Exchange is down? JUST KIDDING!”
Side note – I’ve been on site with a jokey client where something really did go down and it took us a minute or two to figure out that there was really a problem.
I’m used to squirrels now. Honestly they rarely have merit but I always take them seriously “just in case.”
In this case, in the midst of replicating VMs in the environment, an admin asked me if anything I was doing would mess with the clock on a guest server. I racked my brain for a moment and replied that I wouldn’t think so. The admin didn’t think so either so he went off to investigate more. I did some more thinking, and then went back and got some more information. What exactly was happening to the clock?
In this case the server had a purposefully mis-set clock. As in, it wasn’t supposed to read current time but it kept getting set to the current time. VMware tools dawned on me, because there is a clock sync built into tools that has to be disabled. We double checked but it was disabled. It made sense because we didn’t do anything with tools (no new or updated tools install).
So later that night I was playing around in my lab. I recreated the setup as best I could. Installed a guest with tools, disabled time sync, and set the clock back a year and some months. Then I started replication. And instantly, the clock was set forward.
So it turns out that even if you tell the guest “don’t sync the clock to the host,” it will STILL sync the clock to the host in certain situations.
While I understand the rationale (certain operations have the potential to skew the clock, ergo syncing the clock up after those will help prevent ongoing skew) I really feel like if time sync is disabled, it shouldn’t sync the clock. Ever. Or there should be another check box that says “No really, never sync the clock.” Nevertheless, I don’t work for VMware so I can’t tell them how to run their product.
In this case the fix is pretty simple though it does require downtime. Shutdown the guest and add some lines to the .vmx:
time.synchronize.continue = "0" time.synchronize.restore = "0" time.synchronize.resume.disk = "0" time.synchronize.shrink = "0" time.synchronize.tools.startup = "0" time.synchronize.tools.enable = "0" time.synchronize.resume.host = "0"
Now it will really, really never mess with the clock on the guest.
This might be common knowledge to VMware admins but I had no idea and I suppose I’ve never dealt with a purposefully skewed clock before.