Yellow Bricks

by Duncan Epping

Logitech Brio Webcam issues with autofocus and not retaining settings on Mac OSX

· · 14 Comments

I have been using a Logitech Brio Webcam for the past year or so. It is a 4k Webcam which is very useful for webinars and meetings, especially as I run my Macbook with an external monitor and it is closed. Over the past 9 months or so I had a bunch of trouble with the Logitech Brio Webcam. This week I received a new Macbook and I had to reinstall all components, and immediately after I installed the Logitech software, all issues started popping up again. Auto Focus was just not working as expected, wide/standard view settings were not properly retained, and neither was the angle/width. I made sure I had the latest version of the software, the latest version of the firmware, but that didn’t solve any of the problems. Actually, it made things worse as now I had the camera randomly stopping as well, even had my Mac log me off randomly when using the camera. I solved all these issues by uninstalling ALL Logitech software. Yes, you read that correctly, I uninstalled all Logitech software and the Brio was usable again.

Unfortunately, this means that you can’t configure the Brio as you would wish, and it runs with the optimal/default settings, but at least it works. I was told that the Logitech G Hub software could potentially be a nice alternative. But after reading this thread on Reddit I decided I am going to skip that as well, as I don’t get a real comfortable feeling when reading all the comments. Unfortunately, I don’t have a way to configure the webcam right now, if I find a solution to this problem I will make sure to update this post. You may ask, what would you need to configure? Well in my case I would like to configure the Webcam to use PAL instead of NTSC for the refresh rate, which removes some of the flickering I would be able to spot other wise. Unfortunately, not possible just yet without the software to my knowledge, or maybe one of you knows the answer to this problem? To conclude, I think it is fair to say that the Logitech hardware is great, but unfortunately, the software is not.

VMs which are not stretched in a stretched cluster, which policy to use?

· · 2 Comments

I’ve seen this question popping up regularly. Which policy setting (“site disaster tolerance” and “failures to tolerate”) should I use when I do not want to stretch my VMs? Well, that is actually pretty straight forward, in my opinion, you really only have two options you should ever use:

  • None – Keep data on preferred (stretched cluster)
  • None – Keep data on non-preferred (stretched cluster)

Yes, there is another option. This option is called “None – Stretched Cluster” and then there’s also “None – Standard Cluster”. Why should you not use these? Well, let’s start with “None – Stretched Cluster”. In the case of “None – Stretched Cluster”, vSAN will per object decide where to place it. As you hopefully know, a VM consists of multiple objects. As you can imagine, this is not optimal from a performance point of view, as you could end up having a VMDK being placed in Site A and a VMDK being placed in Site B. Which means it would read and write from both locations from a storage point of view, while the VM would be sitting in a single location from a compute point of view. It is also not very optimal from an availability stance, as it would mean that when the intersite link is unavailable, some objects of the VM would also become inaccessible. Not a great situation. What would it look like? Well, potentially something like the below diagram!

Then there’s “None – Standard Cluster”, what happens in this case? When you use “None – Standard Cluster” with “RAID-1”, what is going to happen is that the VM is configured with FTT=1 and RAID-1, but in a stretched cluster “FTT” does not exist, and FTT automatically will become PFTT. This means that the VM is going to be mirrored across locations, and you will have SFTT=0, which means no resiliency locally. It is the same as “Dual Site Mirroring”+”No Data Redundancy”!

In summary, if you ask me, “none – standard cluster” and “none – stretched cluster” should not be used in a stretched cluster.

Sharing my vSAN 7.0 U1 webinar, watch it now!

· · 1 Comment

I recorded a webinar a while back. It was streamed last week, and I figured that as I have the recording here, I may as well share it with you. In this webinar I discuss many of the new features which were introduced as part of vSAN 7.0 U1, features like HCI Mesh, IO Insight, enhanced File Service capabilities, and much more. The session is about 40 minutes long, but of course, the great thing about youtube is that you can play it at a different speed. Hope you will enjoy it! Click on the video below, or simply follow this link to youtube. Make sure to like the video, and subscribe to my channel as well!

vSAN File Service SMB capability not showing up in the vSAN 7.0 U1 UI?

· · Leave a Comment

I had two customers who ran into this issue the last week. They ran into the situation where the UI did not show the SMB capabilities after upgrading to vSphere/vSAN 7.0 Update 1. You can solve this pretty quickly by upgrading vSAN File Service as well. Just go to the vSAN Services page, go to File Service and click “Check Upgrade”. After the validation, simply do the “Upgrade”. After the upgrade, the new options will appear!

 

After the upgrade has completed you can now click “Edit” on the service: File Service. This will then allow you to for instance configure the Active Directory integration etc. Pretty straight forward right?

vCLS VMs not powering on, insufficient resources error

· · 3 Comments

This week I had someone internally me asking about a situation where vCLS VMs (learn more about vSphere Cluster Service here.) were not powering on and an error was thrown stating “insufficient resources”. I had seen this issue before at some point and I knew it had something to do with the VM version and EVC. The details of the error messages seem to support that. The UI showed the following on the “power on virtual machine” task:

Insufficient resources

And then when you would look at the details of the error you could see the following:

The target host does not support the virtual machine's current hardware requirements.

Or you could see:

Feature 'MWAIT' was absent, but must be present.

So how do you solve this problem? First of all, this could be two different problems. We solved it the following way, please note that the second option was just us fiddling around to get the VMs provisioned and powered-on, and this is not the official VMware procedure to get it working. I have reported this to the engineers to figure out why this happens, and to get it fixed. There are two options, please use Option 1, as this is a requirement for EVC and the recommended method when you see the “MWAIT” error:

Option 1:

Verify if “Monitor/MWAIT” is set to Enabled in the BIOS. If it is set to Disabled, then this is why the power-on fails. vCLS has per-VM EVC enabled on the VM.

If you can’t enable Monitor/MWAIT, then below is the procedure for disabling “per VM EVC” for the provisioned vCLS VMs.

Option 2:

  1. Upgrade the VM’s “Compatibility” version to at least “VM version 14” (right-click the VM)
  2. Click on the VM, click on the Configure tab and click on “VMware EVC”
  3. Click on “Edit” and click on “Yes” when you are informed to not make changes to the VM
  4. Disable “EVC”
  5. Repeat for the other vCLS VMs

I want to mention cosmin.gq, as it seems the issue (and resolution with regards to disabling EVC) was also reported on that blog, and considering they reported it in October already it only seems fair to mention them here also.