Update ESXi 6.5 to ESXi 6.5.0d

Put the host into maintenance mode, ssh to the host, and then run below command:

Then reboot the host after installation finished:)

Do not rename the only domain controller… And how to fix it if you have already done so..

Even though MS provide the document about how to rename domain controller, the thing is, if you only have one domain controller, the “rename” will break the AD service and you are not able to roll back.

The issue you will get is that after you rename domain controller, the AD DS services are still using the old hostname because you didn’t transfer the FSMO roles from the old name to the new name. And if you want to start any domain management tools you’ll get error said that domain is unavailable. And if you want to change domain controller name back you will get the same error because dc is not available and your renaming will failed too. And this issue won’t happen if your domain get two or more domain controllers.

Ok, how to fix this issue if you have already done so? What we can do now is to update registry and change the computer name back to the old one. Below are the four registry keys you need to update:

HKLM\System\CCS\Control\Computername "Computername"
HKLM\System\CCS\Control\Computername "ActiveComputername"
HKLM\System\CCS\Services\Tcpip\Parameters "Hostname"
HKLM\System\CCS\Services\Tcpip\Parameters "NVHostname"

Vmware NSX for vSphere 6.2.2 bugs — lost network connection

We are using VMware NSX in our production environment for a long time.
And recently we got some problem with NSX, the symptoms is

Some VMs will lose network connection after migrated to another VM;
New firewall rules are not able to apply on some of the VMs.

After engaged VMware, VMware confirmed that it’s a bug in NSX.

VMware assigned about 1.6G heap memory for NSX firewall on each of the ESX hosts. If you applied too much rules or you have too many VMs and you’ll reach the memory limit. Then you’ll get this issue…

Current fix is to upgrade to 6.2.3…

Reading a memory.dmp or other .dmp file

This can be accomplished with 7 easy steps:

Step 1. Obtain and install the debugging tools.

Debugging Tools Windows

All you need to install is the “Install Debugging Tools for Windows as a Standalone Component (from Windows SDK)” and during the install only select “Debugging Tools for Windows”. Everything else is used for more advanced troubleshooting or development, and isn’t needed here. Today I followed the link to “Install Debugging Tools for Windows as a Standalone Component (from Windows SDK)” although for a different OS you may need to follow a different link.

Step 2. From an elevated command prompt navigate to the debugging folder. For me with the latest tools on Windows Server 2012 it was at C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\. You can specify the path during the install.

Step 3. Type the following:

kd –z C:\Windows\memory.dmp (or the path to your .dmp file)

Step 4. Type the following:

.logopen c:\debuglog.txt

Step 5. Type the following:

.sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols

If you computer can’t connect to internet, you can download the symbols from below link:

https://developer.microsoft.com/en-us/windows/hardware/download-symbols

Step 6. Type the following:

.reload;!analyze -v;r;kv;lmnt;.logclose;q

Step 7. Review the results by opening c:\debuglog.txt in your favorite text editor. Searching for PROCESS_NAME: will show which process had the fault. You can use the process name and other information from the dump to find clues and find answers in a web search. Usually the fault is with a hardware drivers of some sort, but there are many things that can cause crashes so the actual analyzing of the dump may take some research.

Often times a driver update will fix the issue. If the summary information doesn’t offer enough information then you’ll need to dig further into the debugging tools or open a CSS case with Microsoft. The steps above will provide you with a summary mostly-human-readable report from the dump. There is much more information available in the memory dump although it gets exponentially more difficult to track down the details the further you get into windows debugging.

Hopefully these quick steps are helpful for you as you troubleshoot the unwelcome BSOD.

FreeBSD: use mrsas driver to replace mfi driver

My server got a Dell PERC H330 raid card, and I made it’s working in HBA mode to make sure that it can get best performance under FreeBSD with zfs.
But every time when I boot the server, I’ll get below error message and it take a long time to pass the disk check stage.

1

After research, it seems this timeout error was caused by the old mfi driver.
And LSI has released a new mrsas driver for FreeBSD. So It’s better to switch the driver from mfi to mrsas.

First, add below line into /boot/loader.conf

And then add below device hint into /boot/device.hints . This line is very important. Without this device hint, FreeBSD will use the old mfi driver for raid card even though you enabled maras drvier.

And then, add below line into /boot/loader.conf to disable disk id identity.

Without above two line, after you switch from mfi to mrsas, all the disks will be shown as diskid-*****************。

And don’t forget to update /etc/fstab to change the swap partition from mfi*p* to da*p*. Otherwise you’ll lose your swap partition.

Then, reboot your server, and enjoy.

Fix VCSA 6.0 disk issue — “unknow command shell.set”

In my home lab I’m using Lenovo M900 tiny to run ESX 6.0 and using Synology DS1813+ to provide the ISCSI LUN.
And I’m using VCSA as my vCenter server and put it on the iSCSI lun.

Today I updated my DS1813+ to DSM 6.0 update 1, during the update, I reboot my synology nas. And it seems ESX lost connecting to the iSCSI LUN and my VCSA was dead.

Tried to restart VCSA, it always failed and asked my to run fsck.
1

At first, I want to run fsck in VCSA shell. But the wired thing is that when I run command “shell.set –enable True”, it told me this command doesn’t exist..
2

It seems that the volumes are in read-only and the shell is dead.
Don’t worry, let’s fix it.
Please follow below steps:

  1. stop VCSA machine
  2. add the iso of RHEL7 installation CD to the (actually as CD/DVD of the machine and modified boot order to start from the CD
  3. boot from CD
  4. enter shell of LiveCD
  5. issue the following commands (to see that logical volumes are OK)
  6. repeat step 5 to check all the volumes

3

After finished, remove the ISO and reboot the VM.
You will find VCSA is back:)