I just had to do a Zoom presentation (on a Macbook by the way) and one thing which always bugs me is that I need to run the presentation in full screen and can’t see the chat or Q&A. I like to address questions as I go during the presentation. I was going through the Powerpoint interface and noticed an option I had not noticed before. If you click on “Slideshow” and then “Set Up Slide Show” you can select “Browsed by an individual (window)”, this allows you to run the presentation within a window and have your chat and Q&A open next to the window. Very useful if you ask me. Figured I would share as it doesn’t seem common knowledge
MS Office autoupdate in constant loop on OSX / Mac
Oh man, this was driving me insane. I found myself in a situation where MS Office Autoupdate was in a loop, I think it ran about once an hour at least for 2 days. Each time, of course, it would tell me there were no updates. Frustrating for sure. I place it in to “Manual” mode but it would still open up every hour. This Autoupdate loop started to begin after an upgrade to MS Office 16.24 for Mac. I ended up doing the following to solve the problem. So far I have not seen the Autoupdate window anymore, so let’s hope it indeed solved it:
Open a terminal window and do the following:
cd ~/Library/Preferences rm -rf com.microsoft.autoupdate*.plist
After the files have been deleted, manually run Autoupdate once. This solved the problem for me. One of my colleagues solved the problem by simply downloading the autoupdater for Mac from the MS website and manually update it. Just sharing this in case others are hitting the same problem.
I want vSphere HA to use a specific Management VMkernel interface
This comes up occasionally, customers have multiple Management VMkernel interfaces and see vSphere HA traffic on both of the interfaces, or on the incorrect interface. In some cases, customers use the IP address of the first management VMkernel interface to connect the host to vCenter and then set an isolation address that is on the network of the second management VMkernel so that HA uses that network. This is unfortunately not how it works. I wrote about this 6 years ago, but it never hurts to reiterate as it came up twice over the past couple of weeks. The “management” tickbox is all about HA traffic. Whether “Management” is enabled or not makes no difference for vCenter or SSH for instance. If you create a VMkernel interface without the Management tickbox enabled you can still connect to it over SSH and you can still use the IP to add it to vCenter Server. Yes, it is confusing, but that is how it works.
If you want the interface to not be used by vSphere HA, make sure to untick “Management”. Note, this is not the case for vSAN, with vSAN automatically the vSAN network is used by HA. This only pertains to traditional, non-vSAN based, infrastructures.
Want to play around with Kubernetes? Try MicroK8s!
Two weeks ago I wanted to play around with Kubernetes for a day or two. I found this training course internally at VMware that allowed me to go through some labs. I asked around if anyone had some tips on getting Kubernetes up and running fast. I couldn’t be bothered with creating a multi node kubernetes cluster. I wanted to play around with some of the commands and YAML files. I tried Atomic as suggested by the lab manual, but there were way too many steps involved to install/configure Kubernetes if you ask me. Next option would be some version hosted in a cloud of choice, but I didn’t want to incur the cost. After digging around I stumbled on MicroK8s. It sounded easy, so I figured I would give it a try. When it comes to Linux my preference is Ubuntu/Debian, it is just what I am most familiar with, and as MicroK8s comes from Canonical I figured I would give it a try. As Kelsey Hightower suggested on twitter yesterday (which triggered this article), it is just one command away:
I think @Canonical might have assembled the easiest way to provision a single node Kubernetes cluster:
$ snap install microk8s –classichttps://t.co/Px9UZVrv01
— Kelsey Hightower (@kelseyhightower) April 23, 2019
I downloaded the latest Ubuntu Server ISO and I created a VMware Fusion VM. I stepped through the installation wizard of Ubuntu Server and then noticed it already provided the option even to install “microk8s”, I selected the package, and some additional packages I figured I would need, and clicked done. Literally within minutes, I had a fresh single node Kubernetes configuration, which for me worked straight out of the box!
After it is done configuring, click reboot and login. I created an alias for kubectl, as I didn’t want to type “microk8s.kubectl
” every time or install a different version:
sudo snap alias microk8s.kubectl kubectl
I also enabled the Kubernetes dashboard from the get-go, which can be done by running the command “microk8s.enable dashboard
“. There are a whole bunch of articles out there that can take you through the steps of deploying your first container, making it highly available by specifying the number of instances so I am not going to do that. I don’t want to pretend to be an expert, as I am far from that. Also, check the MicroK8s documentation, it is pretty decent. My colleague Myles Gray has a very good tutorial on why containers, very good read which I also recommend for people who just want to know a bit more about it like myself.
Mixing versions of ESXi in the same vSphere / vSAN cluster?
I have seen this question being asked a couple of times in the past months, and to be honest I was a bit surprised people asked about this. Various customers were wondering if it is supported to mix versions of ESXi in the same vSphere or vSAN Cluster? I can be short whether this is support or not, yes it is but only for short periods of time (72hrs max). Would I recommend it? No, I would not!
Why not? Well mainly for operational reasons, it just makes life more complex. Just think about a troubleshooting scenario, you now need to remember which version you are running on which host and understand the “known issues” for each version. Also, for vSAN things are even more complex as you could have “components” running on a different version of ESXi. On top of that, it could even be the case that a certain command or esxcli namespace is not available on a particular version of ESXi.
Another concern is when doing upgrades or updates, you need to take the current version into account when updating, or more importantly when upgrading! Also, remember that firmware/driver combination may be different for a particular version of vSphere/vSAN as well, this could also make life more complex and definitely increases the chances of making mistakes!
Is this documented anywhere? Yes, check out the following KB: