This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
vmware:troubleshooting [2018/04/23 09:47] – lunetikk | vmware:troubleshooting [2022/09/03 16:27] (current) – lunetikk | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ===== VMware Troubleshooting ===== | + | ====== VMware Troubleshooting |
==== Cant apply or remediate a host profile ==== | ==== Cant apply or remediate a host profile ==== | ||
Line 38: | Line 38: | ||
__Fix:__ \\ | __Fix:__ \\ | ||
- | |||
At first, if you dont want to get VMs migrated right away, activate maintenance before executing something from below.\\ | At first, if you dont want to get VMs migrated right away, activate maintenance before executing something from below.\\ | ||
Line 53: | Line 52: | ||
If it still doesnt, [[http:// | If it still doesnt, [[http:// | ||
+ | |||
+ | |||
+ | ==== Search in vSphere Client doesnt work ==== | ||
+ | |||
+ | Trying to search a system fails with the following message: \\ | ||
+ | < | ||
+ | Login to the query service failed. | ||
+ | |||
+ | |||
+ | The server could not interpret the communication from the client. (The remote server returned an error: (500) Internal Server Error.) | ||
+ | </ | ||
+ | |||
+ | __Reason:__ \\ | ||
+ | VMware says that this is "//an expected behavior//" | ||
+ | |||
+ | //Searching for Inventory objects when logged in to the vSphere Client using the Use Windows session credentials option is not supported.// | ||
+ | |||
+ | For sure this is expected... why would you let lazy people search in your vCenter? m( | ||
+ | |||
+ | __Fix:__ \\ | ||
+ | At the login screen deselect "Use Windows session credentials" | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | ==== Cant connect a VMDK backup because of duplicated UUIDs ==== | ||
+ | |||
+ | Connecting a backed up VMDK to the same machine results in a duplicated UUID \\ | ||
+ | < | ||
+ | msg.disk.duplicateUUID: | ||
+ | |||
+ | "/ | ||
+ | </ | ||
+ | |||
+ | __Reason:__ \\ | ||
+ | Well... Duplicated UUIDs... | ||
+ | |||
+ | __Fix:__ \\ | ||
+ | Login on the ESX host to change the UUID of the VMDK.\\ | ||
+ | Check the current and set a new one afterwards. | ||
+ | < | ||
+ | vmkfstools -J getuuid < | ||
+ | vmkfstools -J setuuid < | ||
+ | </ | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | ==== Snapshot Manager fails with the error: Operation not allowed in current state ==== | ||
+ | |||
+ | Creating / removing a snapshot fails with the following message | ||
+ | < | ||
+ | Cannot create snapshot | ||
+ | Operation not allowed in current state | ||
+ | </ | ||
+ | |||
+ | On the ESX itself you may find the following error in / | ||
+ | < | ||
+ | 2019-10-08T07: | ||
+ | </ | ||
+ | or | ||
+ | < | ||
+ | [07: | ||
+ | </ | ||
+ | |||
+ | __Reason:__ \\ | ||
+ | |||
+ | This issue occurs if the vCenter Server management agents have stopped causing the snapshot attempt to move in to the ON_SHUTTING_DOWN state. | ||
+ | |||
+ | __Fix:__ \\ | ||
+ | |||
+ | Connect to your ESX host via SSH and restart the management agents | ||
+ | < | ||
+ | / | ||
+ | / | ||
+ | </ | ||
+ | |||
+ | You should be able to create or remove the snapshot afterwards | ||
+ | |||
+ | [[https:// | ||
+ | [[https:// | ||
+ | [[https:// | ||
+ | |||
+ | ==== No coredump target has been configured ==== | ||
+ | |||
+ | You see a yellow warning on your ESX hosts with the following message | ||
+ | < | ||
+ | No coredump target has been configured. Host core dumps cannot be saved | ||
+ | </ | ||
+ | {{: | ||
+ | |||
+ | __Reason:__ \\ | ||
+ | |||
+ | Just like the warning says, there is no coredump target configured. | ||
+ | |||
+ | __Fix:__ \\ | ||
+ | |||
+ | Solution 1:\\ | ||
+ | Create the target -> [[https:// | ||
+ | |||
+ | Solution 2:\\ | ||
+ | Suppress the warning (WARNING: this will " | ||
+ | |||
+ | Go to your " | ||
+ | < | ||
+ | Host > Configuration > Advanced Settings > UserVars > SuppressCoredumpWarning > 1 | ||
+ | </ | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | |||
+ | ==== Lost connectivity to the device naa.60xxxx backing the boot filesystem ==== | ||
+ | |||
+ | You see a yellow warning on your ESX hosts with the following message | ||
+ | < | ||
+ | Error: Lost connectivity to the device naa.60xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx backing the boot filesystem / | ||
+ | </ | ||
+ | |||
+ | __Reason:__ \\ | ||
+ | |||
+ | Your ESX lost connection to its bootdevice, maybe because of a network outage (switch reboot, cable disconnect, | ||
+ | |||
+ | __Fix:__ \\ | ||
+ | |||
+ | Solution 1:\\ | ||
+ | Put the host into maintenance mode to migrate all VMs to another host and reboot. | ||
+ | |||
+ | Solution 2:\\ | ||
+ | Access your ESX via SSH and restart the managementagent | ||
+ | |||
+ | < | ||
+ | / | ||
+ | </ | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | ==== No space left on device (vCenter) ==== | ||
+ | |||
+ | * vCenter AD Login doesnt work | ||
+ | * “shell.set –enabled True” shows the error “Unknown command: `shell.set' | ||
+ | * creating files will show “No space left on device” | ||
+ | |||
+ | You can also check this by connecting via SSH and entering the following commands | ||
+ | < | ||
+ | com.vmware.vimtop | ||
+ | |||
+ | com.vmware.rvc | ||
+ | |||
+ | >Host to connect to (user@host): | ||
+ | >Are you sure you want to continue connecting (y/n)? y | ||
+ | |||
+ | Warning: Permanently added ' | ||
+ | Failed to connect to localhost: No space left on device @ dir_s_mkdir - /root/.rvc | ||
+ | </ | ||
+ | |||
+ | __Reason:__ \\ | ||
+ | You have no space left on your device, mostly /var/log/ and mostly because of audit.log | ||
+ | |||
+ | __Fix:__ \\ | ||
+ | |||
+ | Because you cant use PuTTY to operate the shell, you need to open the shell with a kernelparameter in the GRUB bootloader. You need to reboot your vCenter (DOWNTIME!). Before starting your VM, set the "Power On Boot Delay" to 10 seconds. | ||
+ | |||
+ | Fatclient: | ||
+ | {{: | ||
+ | |||
+ | Webclient: | ||
+ | {{: | ||
+ | |||
+ | After starting the VM, check the VMware console and wait for the bootloader. You can stop the autostart by hitting " | ||
+ | |||
+ | Select the vCenter appliance and hit " | ||
+ | Then select the right kernel and hit " | ||
+ | Add " | ||
+ | You should now be in the shell. Check the drives with "df -h"\\ | ||
+ | If audit.log is the problem, empty it with | ||
+ | < | ||
+ | echo "" | ||
+ | </ | ||
+ | |||
+ | To fix the logrotate/ | ||
+ | |||
+ | ==== Restore from different datastore ==== | ||
+ | |||
+ | A VM is broken and needs to be restored. To do so you need to copy the VM from the backup datastore to your productive one \\ | ||
+ | |||
+ | __Reason:__ \\ | ||
+ | You dont want to run VMs from your backup datastore \\ | ||
+ | |||
+ | __Fix:__ \\ | ||
+ | Connect to your esx host via ssh and copy the files with " | ||
+ | Make sure you either rename your old .vmdk + flatfile to .old or your restore to something different (rename flat in .vmdk) | ||
+ | <code bash> | ||
+ | cp -a myvm.vmdk / | ||
+ | cp -a myvm-flat.vmdk / | ||
+ | </ | ||
+ | |||
+ | With vmkfstools you dont need to edit the flat name inside .vmdk, the tool does this for you if you choose another name | ||
+ | <code bash> | ||
+ | vmkfstools -i myvm.vmdk / | ||
+ | </ | ||
+ | |||
+ | \\ |