Today one post about things I see sometimes in the field.
Today I want to show you how to fix the issue when you get servers and clients with the same SMBIOS ID. Normally that would be an issue but as soon as you try to management them with System Center Virtual Machine Manager or Configuration Manager it will become one. Both tools use the SMBIOS ID to create a primary key in their databases to identify the system.
Currently I only know the following trick to fix the issue and that one would be extremly annoying on many clients or servers but it actually work.
First you need two tools.
1: Rufus – To create a bootable USB Stick
2: AMIDMI – With that tool you can overright the SMBIOS ID
Now create the Bootstick with Rufus and copy the AMIDMI file on the stick.
Reboot your from the stick.
Navigate to the folder with your AMIDMI file and run the command amidmi /u
Afterwards you can reboot the system and start Windows again.
When you are working with Virtual Machine Manager, you need to remove the host from your management consolte and add it again. After the host is discovered again, you can see the new SMBIOS ID.
I currently saw these issues with following motherboard vendors:
- ASRock (Client & Rack)
- ASUS (Client)
- SuperMicro (Server & ARM)
- Fujisu (Server)
today another story I see most of the days when I do Healthcheck on customer site.
One of the first things I found was a new VMM installation on top of a new Microsoft Hyper-V Cluster. The issue was, that the cluster was installed first and every thing was running on Hyper-V converged network and standard Hyper-V Switches. There was no VMM network configured or the host made compliant within VMM.
Why is that so bad? It’s bad because VMM uses it’s own kind of switches (logical switches) and needs some additional configurations to manage the hosts in the best possible way.
When I ask guy’s why they do it in that way, I normally get the answer “how should I configure the host when no VMM is in place before he install the cluster?”.
So now my answer and how you can do it in the right way.
- Install a Hyper-V Host as Standalone host
- Configure and install the VMs for VMM and SQL Server (if needed) on the standalone host
- Performe the ful VMM configuration
- Install the other Hyper-V Hosts and roll out the VMM configuration to that hosts
- Cluster the Hyper-V Hosts
- Migrate your SQL DB and VMM with shared nothing livemigration to the new Hyper-V Cluster
- Reconfigure the standalone Hyper-V Host with VMM and add it to the cluster
- Run the cluster validation again
That’s all and it will cost you the same amount of time.
Today I had an issue with virtual machine converter during migration of a VM from VMware to Hyper-V. The screenshot below shows the issue.
The issue shows an configuration missmatch which stopped the convert of the VM.
The solution of the issue is pretty easy. You need to check and change the virtual machine configuration in VMware vCenter.
First you need to check the SCSI Bus logic. There you need to configure LSI Logic.
Second and more likely the reason for the issue is that one or more of your disks are configured as independed. Just uncheck the box and your fine. 🙂
This week I had a very strange issue with a Hyper-V Cluster managed by Virtual Machine Manager.
Completely randomly different cluster nodes failed and I weren’t able to start failover cluster manager on one of the cluster nodes. On the infected node it self, I wasn’t able to open the hyper-v manager or server manager.
After a lot of research I found a solution from the windows server core team which pointed me to the solution.
Unable to launch Cluster Failover Manager on any node of a 2012/2012R2 Cluster
When Failover Cluster Manager is opened to manage a Cluster, it will contact all the nodes and retrieve Cluster configuration information using WMI calls. If any one of the nodes in the Cluster does not have the cluster namespace “root\mscluster” in WMI, Failover Cluster Manager will fail and give one of the below errors:
Unfortunately, it does not give any indication of which node is missing the WMI namespace. One of the ways you can check to see which one has it missing is to run the below command on each node of the Cluster.
Get-WmiObject -namespace "root\mscluster" -class MSCluster_Resource
It can be a bit tedious and time consuming if you have quite a few nodes, say like 64 of them. The below script can be run on one of the nodes that will connect to all the other nodes and check to see if the namespace is present. If it is, it will succeed. If the namespace does not exist, it will fail.
Write-Host "Imported Cluster module"
Write-Host "Getting the cluster nodes..." -NoNewline
$nodes = Get-ClusterNode
Write-host "Found the below nodes "
Write-host " "
Write-host "Running the WMI query...."
Write-host " "
ForEach ($Node in $nodes)
Write-Host -NoNewline $node
if($Node.State -eq "Down")
Write-Host -ForegroundColor White " : Node down skipping"
$result = (get-wmiobject -class "MSCluster_CLUSTER" -namespace "root\MSCluster" -authentication PacketPrivacy -computername $Node -erroraction stop).__SERVER
Write-host -ForegroundColor Green " : WMI query succeeded "
Write-host -ForegroundColor Red -NoNewline " : WMI Query failed "
In the below example, you can see that one of the nodes failed.
To correct the problem, you would need to run the below from an administrative command prompt on the “failed” node(s).
Once the Cluster WMI has been added back, you can successfully open Failover Cluster Management. There is no restart of the machine or the Cluster Service needed.
Quote: Microsoft Ask the Core Team Blog
In my case I wasn’t able to fix it so easy because the server vendor implemented the WMI Provider directly in his BMC via Agent (for the interested ones Fujitsu). during the process of recompiling the WMI for the Cluster the whole Server Network interfaces and BMC fail.
so my fix:
- shutdown the server
- make it powerless
- start it
- check cluster (everything fine)
- uninstall the (fucking) agent
Since than it worked.
Sometimes when I’m invited to visit a customer to “optimize their high available virtual machine manager”, I normally see following configuration.
When I ask why they say it is high available, they normally tell me that they can move the machine from one host to another. Normally i ask now “And what happens when you need to patch the SQL DB, VMM or Windows Server or the storage fail?”
Here comes the point where most people realize that high availability means other things than moving services from A to B.
So now let us think what we need to get our VMM Server high available.
On the VMM Site we need following parts:
- two VMM Management Servers running in a Cluster
- two Database Servers running in a Cluster
- two Fileserver running in a Cluster as Library server
- two Hyper-V Hosts for VM Placement
- two Storages with Storage Replication
When it comes to a very big Hyper-V and VMM Environment, I would suggest to run you Management Systems in a separated Hyper-V Cluster. That helps you to keep your VM workload running even when you need to take down your fabric cluster in maintenance mode.