Yellow Bricks

by Duncan Epping

Server

Thanks for your support!

· ·

About 7-8 months ago I shared with you that I would be participating in the ROPA RUN for charity. As explained, the ROPA RUN is a charity relay running event where you start near Paris and run back to Rotterdam. Each team that participates has 8 runners which are divided in 2 groups, and each group runs 4-5 hrs in a relay fashion.

Last weekend I participated in the event, and what an experience that was. From a running perspective, it definitely was something I had never experienced before. The relay mechanism is what made things more challenging than expected, after every 1-2KM you switch runners and you get ~15 minutes of rest, however, this also means you cool down. Although I didn’t run a huge number of KMs, between 17k and 22k per “shift” of 4-5 hrs, when you have to sit down after every 1-2KM it will get more challenging to get started every single time it is your turn.

What probably was the biggest challenge though for me was the lack of sleep. As we had to travel between locations while the other group was running, and we also had to freshen up, eat, and hydrate, it resulted in around 1.5 hrs of sleep combined over 2 nights. Unfortunately for me, I also had a bad night of sleep on Friday (3hrs), which definitely didn’t help either. This was the most challenging aspect of the whole event… My body appreciates sleep. But I already knew that I guess. I knew I would get a splitting headache if I were sleep-deprived, and I knew that running would be very unpleasant with a headache as a result of lack of sleep.

Why did I sign up knowing that it would be unpleasant? Well first and foremost because it is a charity event, I feel everyone should aim to give back in some shape or form when they can. The other reason of course is because I like to challenge myself, sometimes you need to do things that are far out of your comfort zone, things you may not enjoy when you are in the moment. The third reason was because I would be able to hang out with friends for three days straight. Anyway, that wasn’t why I wanted to write this post, I simply wanted to thank everyone who supported me by reposting my request for donations, and especially those who donated. I personally raised over 2700 euros, and every single cent of that went to charity! Thanks everyone, I truly appreciate it!

How to stop vCLS VMs from running on a vSphere HA Failover Host?

· ·

I’ve had this question twice in about a week, which means that it is time to write a quick post. How do you stop vCLS VMs from running on a vSphere HA Failover Host? For those who don’t know, a vSphere HA Failover Host is a host which is used when a failure has occurred and vSphere HA needs to restart VMs. In some cases customers (but usually Cloud partners) want to prevent the use of these hosts by any workload as it could impact the cost of usage of the platform.

Unfortunately within the UI you cannot specify that vCLS VMs cannot run on specific hosts, you can limit the vCLS VMs from running next to other VMs, but not hosts. There is however an option to specify which datastores the VMs can be stored on, and this is a potential way of limiting which hosts the VMs can run on as well. How? Well if you create a datastore that is not presented to the designated vSphere HA Failover Host then the vCLS VM cannot run on that host as the host cannot access the datastore. It is a workaround for the problem, you can find out more about the datastore placement mechanism for vCLS in this document here. Do note, as stated, those vCLS VMs won’t be able to run on those hosts, so if the rest of the cluster fails and only the Failover Host is left the vCLS VMs will not be powered on. This means that DRS will not function while those VMs are unavailable.

I’ve contacted vSphere HA/vCLS product management to see if we can get this fixed somehow more elegantly in the product, and it is being worked on.

Happy Holidays: vSAN 8.0 U1 Book Discounted to less than 5 USD for the ebook!

· ·

Holidays are coming, so we figured it was time to lower the price of the vSAN ESA 8.0 U1 book! Haven’t bought it yet? The paper edition is around $ 19.99 and the ebook is $ 4.99 (or less, depending on where you live).

It’s a lot of great content for a really low price, and as said we made sure the ebook is priced extremely aggressively as we prefer for technical books not to be printed. Pick it up, the price will return to normal (29.99 and 9.99) after the holiday season!

Of course, we also have the links to other major Amazon stores:

Doing network/ISL maintenance in a vSAN stretched cluster configuration!

· ·

I got a question earlier about the maintenance of an ISL in a vSAN Stretched Cluster configuration which had me thinking for a while. The question was what would you do with your workload during maintenance. I guess the easiest of course is to power off all VMs and simply shutdown the cluster, for which vSAN has a UI option, and there’s a KB you can follow. Now, of course, there could also be a situation where the VMs need to remain running. But how does this work when you end up losing the connection between all three locations? Normally this would lead to a situation where all VMs will become “inaccessible” as you will end up losing quorum.

As said, this had me thinking, you could take advantage of the “vSAN Witness Resiliency” mechanism which was introduced in vSAN 7.0 U3. How would this work?

Well, it is actually pretty straight forward, if all hosts of 1 site are in maintenance mode, failed, or powered off, the votes of the witness object for each VM/Object will be recalculated within 3 minutes. When this recalculation has completed the witness can go down without having any impact on the VM. We introduced this capability to increase resiliency in a double-failure scenario, but we can (ab)use this functionality also during maintenance. Of course I had to test this, so the first step I took was placing all hosts in 1 location into maintenance mode (no data evac). This resulted in all my VMs being vMotioned to the other site.

Now next I checked with RVC if my votes were recalculated or not. As stated, depending on the number of VMs this can take around 3 minutes in total, but usually will probably be quicker. After the recalculation had been completed I powered off the Witness, and this was the result as shown below, all VMs were still running.

Of course, I had to double check on the commandline using RVC (you can use the command “vsan.vm_object_info” to check a particular object for instance) to ensure that indeed the components of those VMs were still “ACTIVE” instead of “ABSENT”, and there you go!

Now when maintenance has been completed, you simply do the reverse, you power on the witness, and then you power on the hosts in the other location. After the “resync” has been completed the VMs will be rebalanced again by DRS. Note, DRS rebalancing (or should rules being applied) will only happen when the resync of the VM has been completed.

What does Datastore Sharing/HCI Mesh/vSAN Max support when stretched?

· ·

This question has come up a few times now, what does Datastore Sharing/HCI Mesh/vSAN Max support when stretched? It is a question which keeps coming up somehow, and I personally had some challenges to find the statements in our documentation as well. I just found the statement and I wanted to first of all point people to it, and then also clarify it so there is no question. If I am using Datastore Sharing / HCI Mesh, or will be using vSAN Max, and my vSAN Datastore is stretched, what does VMware (or does not) support?

We have multiple potential combinations, let me list them and add whether it is supported or not, not that this is at the time of writing with the current available version (vSAN 8.0 U2).

  • vSAN Stretched Cluster datastore shared with vSAN Stretched Cluster –> Supported
  • vSAN Stretched Cluster datastore shared with vSAN Cluster (not stretched) –> Supported
  • vSAN Stretched Cluster datastore shared with Compute Only Cluster (not stretched) –> Supported
  • vSAN Stretched Cluster datastore shared with Compute Only Cluster (stretched, symmetric) –> Supported
  • vSAN Stretched Cluster datastore shared with Compute Only Cluster (stretched, asymmetric) –> Not Supported

So what is the difference between symmetric and asymmetric? The below image, which comes from the vSAN Stretched Configuration, explains it best. I think Asymmetric in this case is most likely, so if you are running Stretched vSAN and a Stretched Compute Only, it most likely is not supported.

This also applies to vSAN Max by the way. I hope that helps. Oh and before anyone asks, if the “server side” is not stretched it can be connected to a stretched environment and is supported.