After creating some virtual machines on ExtremIO storage, I noticed virtual machines would blue screen after booting up. This did not happen on any other attached array. It turns out this is a long standing problem, dating back to 2014. Being new to the ExtremIO space, our VAR did not give us a heads up that some tuning needs to be done on the host side.
“The default DiskMaxIOSize in ESXi is 32767 (32 MB). Even if the storage array reports a different block size to the host, ESXi continues to use the default DiskMaxIOSize of 32 MB. Because of this, block transfers between the virtual machine and the storage array may be interrupted or incomplete. The result is that the Windows Virtual machine may fail to boot using EFI.”
I have not seen this come up for any other block array. The issues is only with EFI enabled virtual machines. So if you have this type of issue with a new block array, check the best practices on VMware.
There is still time! Make sure to apply for the VMware vExpert 2018 program! The application window closes 1/19/2018
vExpert 2018 Applications are Now Open
I had an interesting question posed to me last week regarding the Spectre Vulnerability and virtual machines. “If I patch the hypervisor, does that mean I do not need to patch the guest operating systems”?
The answer to that is no. According the VMware Security & Compliance Blog “For these patches to be fully functional in a guest OS additional ESXi and vCenter Server updates will be required”. This would include all guest OS on the host.
Here is a link to a good post on how to create a baseline in VUM to do the patch.
If you need to do an individual install of the patch, you can run a search for it on the product patch site. https://my.vmware.com/group/vmware/patch#search The patch itself is around 500MB.
ESXi 6.5 – ESXi650-201712101-SG
ESXi 6.0 – ESXi600-201711101-SG
ESXi 5.5 – ESXi550-201709101-SG
https://kb.vmware.com/s/article/2151132 Has all the info about the patch and instruction on how to run it locally.
To understand what performance impacts you may have: https://access.redhat.com/articles/3307751
Simply sign up for a new letter and win a free book.
Sign up for our newsletter
You can also head over to yellow bricks and read up on HA, but Franks’ book promotion will get you a hard copy.
The end will come sooner than you think. Don’t forget to plan ahead and upgrade to the latest version.
The End of General Support for vSphere 5.5 is September 19, 2018. To maintain your full level of support and subscription, VMware recommends upgrading to vSphere 6.5, or newer. VMware has extended the general support for vSphere 6.5 to a full five years from date of release, which means the general support for vSphere 6.5 will end November 15, 2021. For more information on the benefits of upgrading and how to upgrade, visit the VMware vSphere Upgrade Center.
If you would like assistance in moving to a newer version of vSphere, VMware’s vSphere Upgrade Service is available. This service delivers a comprehensive guide to upgrading your virtual infrastructure. It includes recommendations for planning and testing the upgrade, the actual upgrade itself, validation guidance and rollback procedures. For more information contact your Technical Account Manager or visit VMware Professional Services.
In the event you are unable to upgrade before the End of General Support (EOGS) and are active on Support and Subscription, you have the option to purchase extended support in one year increments for up to two years beyond the EOGS date. The price of Extended Support is $300,000 per product per year. Visit VMware Extended Support for more information.
Technical Guidance for vSphere 5.5 is available until September 19, 2020 primarily through the self-help portal. During the Technical Guidance phase, VMware does not offer new hardware support, server/client/guest OS updates, new security patches or bug fixes unless otherwise noted. For more information, visit VMware Lifecycle Support Phases.
The option to download a calendar with your sessions is now available on the VMworld 2017 sessions page. I have been checking for this option for weeks. The site had instructions for downloading these, but was never visible. It looks like they finally got around to reorganizing some of the pages. Now if we can just get the app on our phones.
You also have the option to print a CSV. Thanks VMworld.
If you run iDRAC updates on your VMware hosts you might run in to this error with the Dell Management plug-in for VMware vCenter. “Fail – Unable to contact iDRAC. Check iDRAC credentials and network connectivity”.
I ran in to this when upgrading the iDRAC from 2.30.30 to 2.40.40. I was able to log in to the iDRAC directly and ping the iDRAC from the Dell virtual appliance. The Dell vCenter plugin was the only thing that could not log on to the host iDRAC. The issue turned out to be located in the iDRAC settings under network/services. The web server needs to be set to TLS 1.0.
Unfortunately the Dell OMI only works with 1.0, but they hope to have it upgraded in the future.
So your option is to change the TLS settings in the iDRAC or leave your iDRAC firmware lower than 2.40.40.
Is it support? That is an interesting question if you ask a Microsoft consulting company. You might just get a mixed bag of answers. The goal of a Microsoft consulting company is to push HyperV. Lync and Skype for Business are absolutely supported on VMware hypervisors. It falls under the “Server Virtualization Validation Program” from Microsoft. UC products like Skype and Lync do not fall under the same restrictions as Exchange when it comes to the storage platform. Microsoft will not support Exchange if it is on NFS storage (even though the same conditions for the restrictions exist in SMB3). There is no known restrictions on storage platform for Lync or Skype.
The design considerations in the “Planning a Lync Server 2013 Deployment on Virtual Servers” guide are all geared towards HyperV. VMware took up issues with this article (detailed here) and asked why Microsoft never created a validation document for VMware (clearly a market leader). To date, there still has not been a document published by Microsoft, and I do not expect them to publish a favorable article for a competing product. As far as designing your environment, do use the guidelines listed by Microsoft, but pay not attention to the restrictions on HyperThreading and memory sharing. There is not a good technical justification from Microsoft to disable these options when using VMware products.
I work in an environment where I have a multi pool global Skype deployment for 5,000 users and a US pool for 5,000 users all running on vSphere. I have not had any hypervisor related issues and I’ve never had issues with Microsoft support when it comes to having the platform on VMware products.
Don’t be persuaded that vSphere is not the best platform for Skype or Lync. I’ve heard comments like “so you’ve chosen the most expensive and complex product for your environment” or “you are not guaranteed to get support from Microsoft if you have issues in your environment”. That last statement would be somewhat true if the environment was poorly designed. Just make sure your design considerations fall within Microsoft guidelines.