Yellow Bricks

by Duncan Epping

Audio stops working on MAC / OSX

Leave a Comment

I have this issue where my sound / audio just stops working on my Mac / OSX. Very annoying, and as I find myself searching for the command every time I have this issue I figured I would simply drop it on my blog as a reminder, much easier to find, at least for me. How do I get my audio working again? Well I simply open a terminal and kill the service responsible for it. It is then auto restarted and it starts working again (you can also kill it through the UI):

sudo killall coreaudiod

I have this problem in OSX 10.14.1, but also had it in 10.14 and 10.13.x. if anyone knows how to solve the problem please leave a comment!

(My) VMworld Europe sessions online

Leave a Comment

The VMworld Europe sessions have all been posted. Of course William scraped the VMworld website and placed the links on github. Very useful! For those who were not at VMworld I wanted to share the links to the sessions I participated in. I had 4 sessions scheduled, of which 1 was a repeat, so I have 3 links to share. I hope you enjoy the sessions

 

VIN1249BER vSphere Clustering Deep Dive, Part 1: vSphere HA and DRS STREAM
HCI1270BE The Power of Storage Policy-Based Management STREAM
HCI3728KE Innovating Beyond HCI: How VMware is Driving the Next Data Center Revolution STREAM

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

7 Comments

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!

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.)

HA Futures: Per VM Admission Control – Part 4 of 4 – (Please comment!)

1 Comment

As admission control hasn’t evolved in the past years, we figured we would include another potential Admission Control change. Right now when you define admission control you do this cluster-wide. You can define you want to tolerate 1 failure for instance, but some VMs simply may be more important than other VMs. What do you do in that case?

Well if that is the case then with today’s implementation you are stuck. This became very clear when customers started using the vSAN policies and defined different “failures to tolerate” for different workloads, it just makes sense. But as mentioned, HA does not allow you to do this. So our proposal is the following: Per VM FTT Admission Control.

In this case you would be able to define Host Failures To Tolerate on a per VM basis. This would provide a couple of benefits in my opinion:

  • You can set a higher Host Failures To Tolerate for critical workloads, increasing the chances of being to restart them when a failure has occurred
  • Aligning the HA Host Failures To Tolerate with the vSAN Host Failures To Tolerate, resulting in similar availability from a compute and storage point of view
  • Lower resource fragmentation by providing on a per VM basis Admission Control, even when using “slot based algorithm”
  • Of course you can use the new admission control types as mentioned in my earlier post.

Hopefully that is clear, and hopefully, it is a proposal you appreciate. Please leave a comment if you find this useful, or if you don’t find this useful. Please help shape the future of HA!

HA Futures: VMCP for Networking – Part 3 of 4 – (Please comment!)

13 Comments

VMCP, or VM Component Protection, has been around for a while. Many of you are probably using this to mitigate storage issues. However, what if the VM network fails? Well, that is a problem right now… if the VM network fails then there’s no response from HA. This by many customers is considered to be a problem. So what would we like to propose? VM Component Protection for Networking!

How would this work? Well the plan would be to allow you to enable VM Component Protection for Networking for any network on your host. This could be the vMotion network, different VM networks etc. On this network HA would need to have an IP address it could check “liveness” against of course, very similar to how it used the default gateway to verify “host isolation”.

On top of that, besides validating liveness through an IP address, of course, HA should also monitor the physical NIC. If either of the two would not work, well then HA should take action immediately. What this action will be will depend on the type of failure that has occurred. We are considering the following two types of responses to a failure:

  1. If vMotion still works, migrate the VM from impacted host to a healthy host
  2. If vMotion doesn’t work, restart the impacted VM on a healthy host

In addition to monitoring the health of the physical NIC, HA can also use in guest/VM monitoring techniques to monitor the network route from within the VM to a certain address/gateway. Would this technique be useful?

What do you think? Please provide feedback/comments below, even if it is just a “yes, please!” Please help shape the future of HA!