Copyright © SEP AG 1999-2022. All rights reserved.
Any form of reproduction of the contents or parts of this manual is allowed only with the express written permission from SEP AG. When compiling and designing user documentation SEP AG uses great diligence and attempts to deliver accurate and correct information. However, SEP AG cannot issue a guarantee for the contents of this manual.
- 1 VMware vStorage API
- 1.1 SEP sesam version > 18.104.22.168
- 1.1.1 Backup
- 22.214.171.124 Virtual machines residing on NFS storage are unresponsive during a backup
- 126.96.36.199 VMware vSphere backup on Linux fails due to VDDK error
- 188.8.131.52 VMware backup or browsing of VMware vCenter fails with an error due to a Java VM security restriction
- 184.108.40.206 Segmentation fault during VMware backup on Linux-based data movers
- 220.127.116.11 VMware slow backup performance via NBD. OR: Backups are failing in SAN transport mode with VMs residing on VMFS 6.0
- 18.104.22.168 VMware backup fails with error due to unrecognized extended LUN connected to a Linux data mover
- 1.1.2 Single file restore
- 22.214.171.124 Mounting VMware saveset on Linux fails with error
- 126.96.36.199 Single file restore is not working with VMware 6.0
- 188.8.131.52 When restoring a single file, SEP sesam cannot access storage on a VM that is configured with the SCSI LSI Logic SAS adapter
- 184.108.40.206 After updating an existing SEP sesam structure with a new VDDK version, it is no longer possible to mount a VMDK
- 1.1.1 Backup
- 1.1 SEP sesam version > 220.127.116.11
- 2 See also
VMware vStorage API
SEP sesam version > 18.104.22.168
Virtual machines residing on NFS storage are unresponsive during a backup
- When using NFSv3 to mount NFS data stores and performing VMware backup in HotAdd transport mode, the VM that is backed up is not reachable for approx. 30 seconds when the HotAdd data mover detaches the VMDK.
- This issue occurs when the target VM and the data mover are running on two different hosts (ESXi), and the NFSv3 protocol is used to mount NFS data stores.
- To avoid this problem, the VMware data mover and VM have to run on the same ESXi.
- Use the NFSv4 protocol to mount NFS data stores.
VMware vSphere backup on Linux fails due to VDDK error
- A VMware vSphere backup (on the SEP sesam Server or RDS) on Linux fails with the following error:
Load VDDK library failed: Cannot load: libvixDiskLib.so
- The VMware Virtual Disk Development Kit (VDDK) is not installed.
VMware backup or browsing of VMware vCenter fails with an error due to a Java VM security restriction
- VMware backup or browsing of VMware vCenter might fail with the following error:
Error: VM Exception: [VI SDK invoke exception:javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints].
- Due to advanced security settings, the Java virtual machine does not allow connection to VMware vCenter.
- To avoid the Java virtual machine security restriction, proceed as follows:
- On your SEP sesam Server, locate the following file in the Java installation directory:
- Once done, restart the SEP sesam service.
Then change the line
jdk.certpath.disabledAlgorithms=MD2, RSA > 1024
Segmentation fault during VMware backup on Linux-based data movers
- VM backup on Linux-based data mover completed successfully, however a segfault event is recorded.
- This is the VMware library issue caused by the missing /sys/class/scsi_disk directory on the Linux system.
- Before executing the VMware backups on Linux-based data movers, use the modprobe command
modprobe sd_modto load the sd_mod kernel module and make the /sys/class/scsi_disk directory available.
VMware slow backup performance via NBD. OR: Backups are failing in SAN transport mode with VMs residing on VMFS 6.0
- Slow backup performance via NBD. Another problem is that backups might fail in SAN transport mode.
- vSphere 6.5 and 6.7 may have slow backup performance via NBD with VDDK 6.0.x due to the VMware policy concerning backward and forward compatibility for VDDK to support N-2 and N+1 releases.
- With vSphere 6.5 neither of VDDK 6.0.x versions provides SAN transport support when using datastores formatted with new VMFS 6.0 filesystem. Consequently, the backup will fail.
- On Windows, VDDK is installed automatically during the SEP sesam installation. However, if you use a new vSphere version you should check the VDDK Compatibility Matrix to find its corresponding VDDK version and install it manually, if required.
- On Linux, you have to install the required VDDK version manually. Note that every new release of vSphere has a corresponding VDDK version; typically, the version number of VDDK matches the version number of vSphere.
For details on the required version, see VDDK Compatibility Matrix.
VMware backup fails with error due to unrecognized extended LUN connected to a Linux data mover
- VMware backup fails with error, such as:
Error while reading data. Error: VixDiskLib: VixDiskLib_Read: Read 2048 sectors at 0 failed. Error 16000 (One of the parameters supplied is invalid) (DiskLib error 4096062: One of the parameters supplied is invalid) at 5024.
- On the Linux data mover in VMware environments, when you extend LUN while online (without restarting your Linux system), the extended LUN will not be instantly visible from the Linux operating system. The extended disk is automatically adjusted on Windows, while on Linux you need to rescan SCSI bus manually. Consequently, the backup will fail.
- To rescan SCSI bus on Linux without restarting it, use the following command when adding a new disc (X is the number of SCSI host to scan):
echo “- – -” > /sys/class/scsi_host/hostX/scan
- Use the following command when expanding an existing disc:
echo 1 > /sys/class/scsi_device/device/rescan
Single file restore
Mounting VMware saveset on Linux fails with error
- Mounting VMware saveset (on the SEP sesam Server or RDS) on Linux fails with an error, for example:
Client mount tools not installed
- The guestmount tool is not installed on the Linux host.
- To be able to access and mount the file system of an image on Linux, you have to use use the guestfs-tools. Install the guestfs-tools package as described in Installing guestfs-tools on Linux.
Single file restore is not working with VMware 6.0
- When restoring single files on VMware 6.0, the restore fails with: Cannot open Thin/TBZ disks in a multiwriter mode.
This log is also shown in the vCenter events.
- This error appears if the SCSI bus sharing type on the proxy machine is set to Physical.
- Shut down the proxy machine and change the type of SCSI bus sharing to None, so the virtual disks cannot be shared by other virtual machines.
When restoring a single file, SEP sesam cannot access storage on a VM that is configured with the SCSI LSI Logic SAS adapter
- In SEP sesam version ≥ 22.214.171.124 in combination with a Linux proxy VM, when trying to select the restore source in the restore wizard (step 4: Select Files), no items are displayed in the browser.
- This issue seems to be related to the SCSI controller of the proxy VM. When trying to restore a single file from a virtual machine, SEP sesam cannot access storage on a virtual machine that is configured with the SCSI LSI Logic SAS adapter.
- Open the properties of the proxy VM in your vCenter and change the controller on the VM from the LSI Logic SAS controller (on some VMs, this is selected by default) to an LSI Logic Parallel controller.
For more information, see VMware Docs article Change the SCSI Controller Type in the vSphere Client.
- Restart the restore wizard. If there are still no items displayed in the restore browser, reboot the proxy VM and then click the Update button.
After updating an existing SEP sesam structure with a new VDDK version, it is no longer possible to mount a VMDK
- After VDDK ≥ 6.5.x has been manually installed on Windows, it is no longer possible to mount a VMDK saveset on this host.
- If another VDDK version, for example VDDK ≥ 6.5.x, is manually installed on Windows, the host requires a reboot after the update if you want to mount a VMDK on this host.
- Reboot the host after the VDDK update, then run the following script from the command line:
vstor2install.bat in directory C:\Program Files\VMware\VMware Virtual Disk Development Kit\bin
Hard reset (offline via CLI)
Depending on SEP sesam version, use a relevant command for hard reset via CLI:
- For SEP sesam v. < 4.4.1.x, if a soft reset does not work or it is not available, use the following command for hard reset.
sbc_vadp -b -a "action=resetcbt,server=ws2008x64,username=Administrator,password=secret"
sm_cmd resetcbt -S qsbox1 -d "SEP Cloud" -V "cosinus (SEP)" -m hard
The virtual machine must be powered off for this action.
CBT reset via the vSphere client
- Alternatively, a CBT-reset can be performed via the vSphere client:
- The virtual machine does not need to be shut down to reset CBT:
- Open the properties of the affected virtual machine from Tasks > By Clients.
- Uncheck Enable Change Block Tracking (CBT) and save the task.
- Create a snapshot via vSphere Client of the affected virtual machine (none of the ticks needs to be selected).
- Delete the snapshot that was created before.
- In SEP sesam, activate the CBT option in the VM client settings and start the VM backup.
- This step needs to be performed if a reset of CBT in online mode does not work. The virtual machine must be turned off for this step:
- Shut down the VM.
- Open the VMware Snapshot-Manager and delete all snapshots.
- Right-click VM -> Edit settings -> Options tab -> General -> Configuration Parameters.
- Set the value "ctkEnabled" to false.
- Set the value "scsi0:0.ctkEnabled" to false (NOTE: set the value to false for each disk).
- Open the folder where the VM *.VMDK files exists and delete all *-CTK.VMDK files
- Start the VM.
- Shut down the VM (this is required for the CTK table update).
- Start the VM again.
- In SEP sesam, activate the CBT option in the VM client settings and start the VM backup.-->