Category Archives: Server

Unable to remove a datastore from vCenter Server Inventory

Posted on by

I recently had an issue where I was unable to remove a datastore from the vCenter Server Inventory.  The datastore was grayed out and when right-clicking, had no options.  After some digging and some research in SQL, I found a way to manually do this in the vCenter database.  Every datastore is given a unique ID and can be found and removed inside of the database.

Warning: Always make a SQL backup before attempting any manual database changes.  You never know when things might break and you need to restore.

So here we go:

  1. Stop the vCenter Server Service
  2. Open SQL Management Studio
  3. Run the following against your vCenter Server database (This will give you the datastore ID):

select ID from VPX_ENTITY where name = ‘datastore_name’

  1. Now we have the ID and can remove it from the database
  2. Run the following 3 queries individually (Using the ID we got from the previous query):

delete from VPX_DS_ASSIGNMENT where DS_ID=ID;
delete from VPX_VM_DS_SPACE where DS_ID=ID;
delete from VPX_DATASTORE where ID=ID;

  1. Finally, run the following:

delete from VPX_ENTITY where ID=ID;

If you want to verify that everything went correctly, you can run the following:

select * from VPX_DS_ASSIGNMENT where DS_ID=ID;
select * from VPX_VM_DS_SPACE where DS_ID=ID;
select * from VPX_DATASTORE where ID=ID;
select * from VPX_ENTITY where ID=ID;

Now you’ve removed the datastore from the database and can start the vCenter Server Service again. If you don’t see that it has been removed, a reboot may help. I rebooted my server just to be on the safe side.

You can check out this VMware KB for more info.

vNUMA: A VMware Admin’s Guide

Posted on by

Since I’ve been discussing this recently at work with developers and managers due to some SQL Server issues we have been having, I decided it was time to write about it.  vNUMA was introduced along with vSphere 5 back in the day and is related to NUMA (Non Uniform Memory Architecture). In a nutshell, vNUMA allows you to divide your CPU and Memory resources into different nodes and allows for faster memory access.

vNUMAThe image above shows how NUMA breaks up the resources to create the nodes.  This is also a setting that can be controlled within VMware.  vNUMA is typically used for your “Monster VMs”, where your virtual CPUs span multiple physical CPUs. For example, if your virtual machine has 12 CPUs and your physical host has 8 cores, you are spanning multiple CPUs.  vNUMA is also recommended when using more than 8 vCPUs.  To change the NUMA setting (Keep in mind that the VM must be powered off to make this change):

  1. Select your VM
  2. Choose Edit Settings…
  3. Go to the Options tab
  4. Go to Advanced -> General
  5. Click the button “Configuration Parameters”
  6. Add the following “numa.vcpu.min” and set to the number of CPUs you want used in the NUMA node.

One thing to keep in mind with NUMA is that you want to size the NUMA nodes according to the number of cores in your physical host.  For example, my physical hosts have a six core processor, so my NUMA node on the SQL Server is set to 6.  This gives my 12 processor SQL Server 2 NUMA nodes with 6 CPUs each.  By default, when you create a VM with more than 8 vCPUs, vNUMA is enabled by default.  Using the instructions above, you can change the vNUMA value or set it on VMs with less than 8 vCPUs.

vNUMA is very specific to certain use cases and should be used with caution.  Incorrectly configuring NUMA can cause more problems than leaving it at the default.  Be sure to test your settings on a non production server and see if the results were as expected.  One final thought and last thing to keep in mind, ensure that the hosts in your cluster when vNUMA is being used have similar NUMA configurations to avoid issues when the VM decides to vMotion to a different host.

Image courtesy of brentozar.com