Yellow Bricks

by Duncan Epping

esxi

VMworld Reveals: Armed and Ready (ESXi on ARM, #OCTO2944BU)

· ·

At VMworld, various cool new technologies were previewed. In this series of articles, I will write about some of those previewed technologies. Unfortunately, I can’t cover them all as there are simply too many. This article is about ESXi on ARM, which was session OCTO2944BU. For those who want to see the session, you can find it here. This session was presented by Andrei Warkentin and Daniel Beveridge. Please note that this is a summary of a session which is discussing a tech preview, these features may never be released, and this preview does not represent a commitment of any kind, and this feature (or it’s functionality) is subject to change. Now let’s dive into it, what is VMware doing with ARM?

First of all, what caught my interest in this session was the fact that Hivecell was mentioned. Hivecell is a rather unique solution which allows you to stack ARM hosts. What is unique about that? Well when I say stack, I mean stack in the physical sense. The interesting part here is that only the first node will need to have power and networking cables, and the rest will receive power and networking through a magnetic link. William wrote about it extensively, so go here to read more about these guys. Really cool solution if you ask me.

The session started with an intro to ARM and the various use cases. I wrote about that extensively when Chris Wolf and Daniel discussed that at VMworld 2018. So I am not going to reiterate that either, just click the link to figure out why ARM could be interesting. What was new in this session then compared to last year? Well they showed a couple of things which I have not seen shown in public before.

First thing that was discussed was the fact that VMware is looking to support the AWS ARM instances (A1 instance) which were introduced a while ago. The plan is to not only support ARM, but also support Elastic Network Interfaces(ENI) and Elastic Block Storage(EBS). All of it managed through vCenter Server of course. VMware is now looking for early validation customers and partners.

[Read more…] about VMworld Reveals: Armed and Ready (ESXi on ARM, #OCTO2944BU)

ESXi on ARM/Raspberry Pi for vSAN Witness purposes or for?

· ·

I was just catching up on a couple of VMworld sessions. One session that stood out to me was most definitely once again the session by Chris Wolf and Daniel Beveridge. I am not going to write up a full coverage of it, as it is mostly very similar to the session they did in the US which I posted about here.

However, what is interesting in the European edition is that Regis Duchesne comes up on stage after about 38 minutes in and he starts discussing and demoing ESXi on ARM, but more impressively ESXi on top of a Raspberry Pi. Note that these machines have very limited memory (1GB) and little CPU (64-bit SoC @ 1.4GHz) resources, and are low powered! Gotta love an intro as well that includes “been at VMware for about 20 years”.

Very interesting to see that Regis and the team managed to get ESXi booting on an RPI 3b, but also that it only uses about 500MB of the memory, which would leave room to boot one VM as Regis points out if you are lucky. One example of a use case is to use this machine as a physical vSAN Witness host for 2 host configurations. This was the immediate use case I had in mind as well for this! (Although preferably a configuration with a bit more CPU power and memory would be preferred!)

Regis also mentions the option to run 1 VM on an RPi3, but you could, of course, have multiple RPi’s running and connect them using a 1GbE switch so the VMs can communicate with each other, you could even create a cluster and move VMs between RPi’s when you are doing maintenance at the edge. Or even more VMs could potentially run on an RPi and you could use it as an IoT gateway. As Regis points out, what is great about ESXi is that it already provides isolation and QoS for VMs, which ensures that all apps running on an IoT gateway would get their fair share of resources. (Eliminate the noisy neighbor problems) Note that this is a project and very much at an alpha stage, nowhere close to being available for customers or partners, but as Regis points out… if you are a customer or partner doing things at the edge and interesting in this please let us know. The team is looking for design partners to better understand the different use case, to ensure they build something which can be useful for customers! (You can leave a comment here, let us know what you are looking to do with it and I will connect you with the right folks.)

Module MonitorLoop power on failed error when powering on VM on vSphere

· ·

I was playing in the lab for our upcoming vSphere Clustering Deepdive book and I ran in to this error when powering on a VM. I had never seen it before myself, so I was kind of surprised when I figured out what it was referring to. The error message is the following:

Module MonitorLoop power on failed when powering on VM

Think about that for a second, if you have never seen it I bet you don’t know what it is about? Not strange as the message doesn’t give a clue.

f you go to the event however there’s a big clue right there, and that is that the swap file can’t be extended from 0KB to whatever it needs to be. In other words, you are probably running out of disk space on the device the VM is stored on. In this case I removed some obsolete VMs and then powered on the VM that had the issue without any problems. So if you see this “Module MonitorLoop power on failed when powering on VM” error, check your free capacity on the datastore the VM sits on!

More details:

Strange error message, for a simple problem. Yes, I will file a request to get this changed.



Where did ESXi 6.5.0 build 7526125 go?

· ·

I had two customers asking today what happened to ESXi 6.5 build 7526125. They downloaded patches and installed them in their test environment. Ready to patch some of their clusters they did a validation and found out that the patch (ESXi650-201801001.zip) has disappeared from the face of the earth. This patch included microcode for Intel processors, and Intel informed VMware that there was potentially an issue with their microcode. As such VMware decided to pull the patch as noted in the KB article. Those who had already downloaded the patches and are manually updating, make sure to delete these. Those who use VUM, make sure to exclude them from your baseline as mentioned in the KB:

Any baseline (including VMware Pre-defined Baseline), that includes one or more of  the bulletins that  correspond to patch VMSA-2018-0004, would experience the above listed error and hence, will not be able to proceed with the remediation process. For such customers, it is recommended to create dynamic or static baseline excluding the bulletins ESXi650-201801401-BG, ESXi650-201801402-BG,  ESXi600-201801401-BG,  ESXi600-201801402-BG ,ESXi550-201801401-BG and continue with the remediation process. For more information on Create and Edit Patch or Extension Baselines see vSphere 6.5 document.

Normally I don’t share these types of things anymore, but as I had two people asking on the same day I figured I would as it seems not everyone had seen that the patches were pulled and replaced. If you haven’t downloaded the patches yet, or haven’t patched your systems but want to, read this advisory first and use the patches mentioned it.

VMkernel Observations (VOBs)

· ·

I never really looked at VOBs but as this came up last week during a customer meeting I decided to look in to it a bit. I hadn’t realized there was such a large number of them in the first place. My conversation was in the context of vSAN, but there are many different VOBs. For those who don’t know VOBs are system events. These events are logged and you can create different alarms for when they are being logged.

You can check the full list of VOBs on ESXi, SSH in to it and then look at this file:

  • /usr/lib/vmware/hostd/extensions/hostdiag/locale/en/event.vmsg

When they are triggered you will see them here:

  •  /var/log/vobd.log

And as stated when you want to do something with them you can create a customer alarm. Select “specific event occuring on this object” and click next:

Now you add an event, simply click the “+” and remove the current value and simply copy/paste the VOB string in, the string will look something like this: “esx.problem.vob.vsan.pdl.offline”. Hit enter when you added it and then click “Next” and “Finish”.

I find the following useful myself:

  • esx.problem.vsan.net.redundancy.reduced
  • esx.problem.vob.vsan.lsom.componentthreshold
  • esx.problem.vob.vsan.lsom.diskerror
  • esx.problem.vob.vsan.pdl.offline
  • esx.problem.vsan.lsom.congestionthreshold
  • esx.problem.vob.vsan.dom.nospaceduringresync

There are many more, and I just listed those I found useful for vSAN, for more detail check the following links: