VMName - Virtual Machine swap object : Physical disk placement

[suhag79]

Hi All,

Recently we have deployed one vSAN setup. All went well except one error on vSAN  virtual object tab as below. Can anyone help to fix this.

Thanks,

Suhag

[TheBobkin]

Hello Suhag,

How many inaccessible .vswp Objects are there and have you determined that all other data is healthy and accessible?

If all other data is accessible (e.g. you can register and power on all VMs) then you can use RVC to remove the inaccessible .vswp Object(s) that should have by now been recreated by powering on the VM that the original .vswp belonged to:

> vsan.purge_inaccessible_vswap_objects <pathToCluster>

https://www.virten.net/2017/07/vsan-6-6-rvc-guide-part-6-troubleshooting/#vsan-purge_inaccessible_vs... https://www.virten.net/2017/07/vsan-6-6-rvc-guide-part-6-troubleshooting/#vsan-purge_inaccessible_vs...

Do note that this is capable of removing inaccessible non-vswap Objects so if you cannot determine the type and/or use of inaccessible Objects it is assisting with deleting then stop and evaluate what you are deleting as opposed to pressing Y.

Bob

[suhag79]

Hello Bob,

"How many inaccessible .vswp Objects are there and have you determined that all other data is healthy and accessible"

This .vswp object is inaccessible only for one VM. For the same VM, other disk objects are healthy.

Should i try with rebooting the VM or i can directly remove the inaccessible object.

Thanks,

[TheBobkin]

Hello Suhag,

"Should i try with rebooting the VM or i can directly remove the inaccessible object."

If the VM is powered on and functional then it is not using the inaccessible .vswp and has generated a new Object the last time it was powered on - this can be validated by checking the vSAN Object that the current .vswp is pointing to e.g.

# cat /vmfs/volumes/vsanDatastore/VMName/VMName.vswp | grep vsan

(Note the .vswp you are looking at here is the one that is bytes in size (just a descriptor) - not the BIOS/vmx .vswp which is usually ~120MB in size)

The UUID of the Object this points to will be a different UUID than the inaccessible Object.

The UUID of the inaccessible Object should be determinable via one of the following (depending if it is a state 12 or 13 inaccessible Object):

# cmmds-tool find -f python | grep CONFIG_STATUS -B 4 -A 6 | grep 'uuid\|content' | grep 'state\\\": 12' -B 1 | grep uuid

# cmmds-tool find -f python | grep CONFIG_STATUS -B 4 -A 6 | grep 'uuid\|content' | grep 'state\\\": 13' -B 1 | grep uuid

Once verified that it is a different Object in use then it is safe to remove the old inaccessible one - realistically though, if a VM was pointing to an inaccessible .vswp Object then it wouldn't be functional nor would removing the inaccessible Object change the state of it.

Bob