Wednesday, May 28, 2014

A fix to Windows 2008 R2 and Solaris 10 BSOD and Kernel Panic on Intel E5 v2 Series

Few months back there were reports of Windows 2008 R2 and Solaris 10 running 64-bit experiencing BSOD or kernel panic running vSphere 5.x.  Some of my customers were also impacted by this issues.  With VMware Support, they identified that there are experiencing servers that are on Intel E5 v2 series processors.

VMware was fast and release a temporary fix to use Software MMU however this is not beneficial as this increase the CPU and memory requirements on certain applications.

So the server vendors with VMware and Intel must have gone through lots of testing and have release the updated KB2073791.  The temporary fix will still applies if your server vendors does not have an updated BIOS upgrade to make some changes to resolve this issues.

If you refer to page 50 in the document stated in the KB2703791, CA135 is the known issue as a release document from Intel.  Since a processor cannot be altered, a fixed is provided via the server vendors BIOS.

Interesting with virtualization, although we may plan and design for lots of redundancy, there is still one single point of failure we cannot avoid the main core of the hardware which is the CPU which holds the heart to all the workload.  The most important thing that we are unable to plan for a redundancy.  Good thing on x86, we are still able to use other type of CPU.  Imagine you are not on a x86 platform, such incident can still happens especially if you are in a situation where you do not even have a choice of CPU to choose from.

Glad that now all is now resolved.

Friday, May 23, 2014

What is OEM and Open License?

Before I started Presales role, I do not know the difference between OEM and Open (some call it volume license) License means.  It was something I never bother as I was doing professional service I just implement and license was not something I need to understand as long my customer bought them and hand me the serial keys to setup.  Doesn't matter is it Microsoft, VMware, Symantec or whatsoever software.

After being a Presales consultant for a while now.  I have to understand licensing and able to explain when asked and one of the most talked and confused topics is always on OEM and Open licenses.  Been able to understand them more easily helps me to advise my customer not just in solution but also in terms of compliance not to violate any licensing agreements they have.

Here I must state the disclaimer, purpose of this post is to clarify all the doubts on what have you got confused with and as well as the references from the various vendors so none of this is NOT driven from assumptions.  This post will purely refer to all articles stated from official statement and references.  This post does not provide any recommendation or advice on what is to choose but provide you an understanding and clarification to choose the correct type of licensing yourself.  You should consult your respective consultant on the right type of license to use.

I did some search and here is a document from Microsoft on OEM licenses terms.  I would like only highlight two statements which I thought worth taking note of. 

OEM Software may NOT be transferred to another machine. Even if the original laptop, PC or Server is no longer in use, or if the software is removed from the original hardware, OEM licenses are tied to the device on which the software is first installed.  

Transferring Licenses


OEM Software may NOT be transferred to another machine.
  • Even if the original laptop, PC or server is no longer in use, or if the software is removed from the original hardware, the OEM licenses are tied to the device on which the software is first installed.
  • As long as the license and device remain together, there is no limit to the number of times they may be transferred from one user to another.  
  • When transferring a PC to a new end user, the software media, manuals (if applicable), and Certificate of Authenticity label should be included. It is also advisable to include the original purchase invoice or receipt. The original end user cannot keep any copies of the software.
When OEM licenses have Software Assurance (SA) coverage:
  • If an OEM license has SA coverage, although the SA coverage may be transferred the underlying OEM license may not. 
  • If any upgrades have been applied as part of the SA coverage, those upgrades must be removed before reassignment of SA to a new device.
Those I have underlined are very specific while the rest of the document just mainly describe the meaning.  In short, device and license must always stay together regardless of the situation while the user to that device can be transferred to anyone with the license always tagged along with the device.

Next, I try to look for VMware licensing document like the one from Microsoft. Instead, I found it uploaded by someone else here (the link is date and updated with my copy) and could not find any directly from VMware. Reading this document which was dated back at 2009, I have highlighted the below:

VMware customers buying through OEMs will find that VMware licenses come without the restrictions they may be familiar with in other OEM‐sourced applications or operating system...

3) Can VMware's OEM partners support a VMware license they sold if the license is moved to a server from a different vendor?
Yes, should a customer purchase VMware with a server from one OEM and later decide to move the license to another server from a different hardware vendor, the customer may continue to receive its VMware support from the original OEM.  The hardware vendor is able to provide support for VMware on other hardware, as the support purchased is for the VMware license and not the hardware.

The above illustrated the difference in OEM licensing from Microsoft or other software licensing from other vendors.  If a VMware license is purchased with a server from one OEM, the customer can eventually apply for the license on any make and model which may not be the server from the same OEM where they got the license from and still be getting the VMware support from the OEM.  E.g. Customer buy VMware license from OEM vendor A and later use that license on OEM vendor B server is still able to log a VMware support call to OEM vendor A which they bought the VMware OEM license support from.  One thing to note here, only VMware support.  If this is due to hardware issues related, the customer would also need to involve the OEM vendor B support.

This is something very interesting I find.  Often, OEM license is normally tagged to the physical OEM hardware and not transferable unless the hardware that is transferring to is from the same OEM vendor.

OEM licenses normally are a lot cheaper than the Open (or Volume License) License in general across all types of software.  For VMware, if the license is purchased from OEM, the support will come from OEM vendor.  How the OEM support works are documented here.  Some may ask what if the OEM vendor require Level 3 support from VMware, the OEM vendor would go through TSANET where all major software vendors are connected to provide support for each other.

As referring to the OEM document page 8, Level 1 and Level 2 support will be handled by OEM support and only Level 3 is handled by VMware Support.  In short, the customer will log a case with OEM vendor support to support Level 1 and 2 issues and OEM Support will log a case with VMware support for Level 3 issue via TSANET and they will revert back to OEM vendor who will respond back to the customer.  The OEM vendor will be fronting the customer and VMware support will revert only to OEM vendor support.  Whereas Open (Volume License) License would contain support directly from Original Vendor e.g. customer will log a support case with VMware Support directly however Open (Volume License) are normally higher in cost due to the direct support connection.

I have seen a customer on OEM license try to log a support case directly or request for escalation with VMware or Original license vendors' support.  As the support is provided by OEM support, customer CAN ONLY log case or perform escalation ONLY directly with the OEM support channel.  The cost of OEM license is attractive as the cost of support is direct OEM support.  With OEM license, the customer can bring down the Total Cost of Ownership using OEM licenses and often environment in Test and Dev, Testing, Development, Disaster Recovery site are very good used cases.

Open (Volume License) license on the other hand are more costly and are sold with direct support.  This is very useful where support resolution time need to be fast.  Often Open license are used for more important workloadx or production environment whereby direct of support from VMware where a shorter SLA is required.

With all this clarified, I hope you have a clearer picture now on what is the advantage of OEM licenses in cost as well as for Open license for direct support without any in between delay interaction.

Any comments are welcome.


FAQ

Can I switch from OEM to Open license?
Ye, there is a conversion fee.

Can I switch from Open license to OEM?
Yes, you can.

Can I purchase OEM license but purchase direct VMware support?
No this is not possible.  Support is tagged with the actual type of license.

With "A" OEM license, can I buy support from "B" OEM vendor?
This cannot be done.  Specific OEM vendor license is tagged to their respective support.

How do VMware OEM Support work?
Refer to this post.


Update 2nd Sept 2015
Update FAQ question.

Update 2nd April 2015
Added FAQ section.

Updated 3rd Mar 2015
Replaced the link to VMware Licensing Benefits document which the referring site is no longer valid.

Saturday, May 3, 2014

Upgrading vSphere Distributed Switch (vDS)

Someone who is attending the vSphere Install, Configure and Manage course asked me this question.  Will upgrading a virtual distributed switch cause a downtime or require a downtime?

After performing an upgrade to vSphere to a later version, there is a upgrade button on the Distributed Switch both on the web client as well as the C# client.  You can view some of the screenshots below:

Pictures reference from http://www.vmwarearena.com/2014/01/vsphere-distributed-switch-part-12.html.

There is no downtime required when upgrading the virtual distributed switch (vDS), the upgrade process only enables additional functionality of the switch which was release in the later version of vSphere.  E.g. Network I/O control on vSphere 5.0 on port level, Network I/O control on VM Level in vSphere 5.1, etc.  You can read this from the documentation center here which mention this bit that it is a "non-disruptive operation".  The vSphere 5.5 Networking guide also mention on this in page 26.

In all operations process, it is always important to make sure before doing anything in a production environment make sure proper backup procedures are performed.  In this case, you might just want to ensure you have backup your vDS setting before doing anything live.

With so much solution now, you tends to forget the most basic part.  So this keep a record in check and remind myself once again.

vMotion Between CPUs

With the release of vSphere 6.7, and the ability to have EVC on a per VM level instead of a per cluster level raise some questions. Before...