The hits just keep on coming here at VMworld 2017. Lots of big announcements and great sessions today. VMware Cloud on AWS is a big focus this year and you can expect to see continued integration points between VMware and Amazon (as well as other cloud providers). Continue reading
My first session at VMworld 2017 was “What’s New and What’s Next for VMware Cloud Management Platform.” There are a ton of great sessions and overlap at this conference, but I thought this would be a good one to attend (and blog on) as they touched on a lot of things VMware is doing outside of itself.
A big issue in the tech field today is that the world is moving “open.” Open source, open APIs, commodity hardware, etc. Customers are very wary of vendor lock-in that prevents them from either using new solutions or moving to other solutions later.
VMware has clearly recognized this, as a primary focus of late is cloud and product interoperability. This is huge for a massive company like VMware who has TONS of proprietary stuff. Continue reading
vRealize Automation 7.3 was just released and there is a lot to unpack. I haven’t had the chance yet to play with the new version (hope to soon!), but I wanted to take a brief moment to call out some cool things I noticed. Here are the release notes (link) if you want to check the whole thing out.
If you’ve been following along, whew! Last post in this series and likely the easiest. Let’s do a quick recap.
In our first post we basically went through the process of determining “how do I do what I want to do?” In our case that was making a REST call to UCSD and kicking off a workflow. We used the Postman utility to help accomplish this.
In the second post we went through the process of “how do I get vRealize Orchestrator to do what I want to do?” Here we used some existing sample workflows and made some modifications to do what we wanted, how we wanted.
In this final post we need to expose that workflow to vRealize Automation so that it can be consumed in a catalog.
OK this is definitely the meatiest part of this series, but bear with me and we’ll get through it. Before we get started, it is important to note there are a million different ways to skin this cat in vRO. This is just one that I find to be fairly straightforward.
I will also fully disclose that this is not easy and at times very frustrating. Some of the vRO stuff is well documented, but some of it is behind curtains and seems to be (on some level or another) different than some of the provided API documentation. I say that just to say, if you are getting your angryface on while working through some of this, you are not alone. Hopefully this series will help alleviate some of that frustration! Continue reading
You might ask yourself, “self, why do I care so much about automation? Why so much fuss over APIs?” The truth is the world is changing – this is true everywhere, and especially true in IT. Automation and APIs are changing the game, allowing you to answer the question, “what can we do?” with “pretty much anything.”
There are a lot of references to VMware vRealize Automation/Orchestration (vRA/vRO) and Cisco UCS Director (UCSD) REST APIs from the vendors, but I thought I would post some findings and methodologies around rolling your own integrated solution. I’m specifically going to work through calling a UCSD workflow with a vRA XaaS (a.k.a. vRO workflow) blueprint, but you can use this methodology to add any REST functionality through vRA for most anything. APIs allow us the opportunity for endlessly integrated solutions…as long as you’ve got the time and patience to develop them! Continue reading
In case you haven’t heard the news, VMware announced vSphere 6.5 at VMworld Europe this year. As usual I wouldn’t recommend anyone jumps on the bandwagon at the .0 release (unless you have test environments). Nobody wants to be that first gazelle across the river!
Make no mistake, there are a TON of new features and enhancements in this version, which you should be checking out on VMware’s press releases. I don’t want to cover them all, as you’d need a gallon of coffee to make it through, but I did want to talk about a few of them that I’m personally excited about. Continue reading
I’ve noticed over the years that while VMware admins tend to really understand maintenance mode, a lot of others in adjacent spaces (storage, network, etc.) have a very murky perspective on it. In fact, I’d bet that if you sat down a storage person at vCenter and told them to evacuate a host with MM, odds are they would be really confused when the task hung or failed. I know I was the first time I tried it. Continue reading
Or, more accurate than the title, a black area on the border of the console window.
I got a new laptop running Windows 10 and when I brought up the console in my home lab, this is what I’d get.
It actually ended up being worse even than it looks as the mouse is pretty much unusable on the screen and a huge chunk of the screen (bottom and right side) is cut off. It is virtually impossible to do anything with VMs including installations of operating systems.
I tried several fixes like compatibility mode, update drivers, etc. without success. Then I stumbled upon this scaling setting which is mentioned on several sites dealing with mouse usage in the VDI space.
Browse to C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\ and right click on VpxClient.exe and select Properties.
On this screen, select the Disable Display Scaling box indicated. Then restart your client.
As a annoying side effect, now some of the text isn’t scaled right so some things in the client look wrong. But it is still usable and the console is usable.
Weirdly, the vCenter console from the web client has no such issue that I noticed. But if you are being pestered by this “feature” try this setting and see if it helps.
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.