Data Protector - Support Tip - VMware fails to select SAN, using NBD instead
The backup did run over SAN and after a VEAgent problem some VM backup’s are now passing over NBD instead.
Typical message in the session report:
Virtual Machine 'VM': Backup disk scsiX:X using transport method NBD
The most probable reason is the SAN lock from VMware was not released.
Manual cleaning up the data is the only solution.
Note: If only a NBD transport mode exits, the backup will fail since no other transport mode is then available.
Virtual Machine 'VM': Could not backup disk scsi0:0 ...
When no backups are running have a look on the VEAgent backup host.
The place where VMware sets its lock files is C:\Windows\Temp\vmware-SYSTEM
This folder should be free of any uuid#-vm-XXXX folders, for example:
10/01/2012 07:56 PM <DIR> 420e8db6-5146-8aaf-5596-1dc7c738c1a1-vm-27
Directory of C:\Windows\Temp\vmware-SYSTEM\420e8db6-5146-8aaf-5596-1dc7c738c1a1-vm-27
10/01/2012 07:56 PM <DIR> .
10/01/2012 07:56 PM <DIR> ..
10/01/2012 07:56 PM <DIR> LOCK.lck
10/01/2012 07:56 PM <DIR> nbd
10/01/2012 07:56 PM <DIR> san
When the folder is deleted, the file LOCK.lck is removed
Quick question for you, you state that the locks are containted in the c:\windows\temp\vmware-system\ folder. In my structure, Data Protector 7.1 (various levels of updates applied), my locks seem to be in folders like c:\windows\temp\vmware-system-xxx\ and I have multiples of these folders. Is there a reason for this? Why are my SAN .lck files located differently than what you have listed as the lock directory?
I am pretty sure that these files are created by VMware, and are not a function of Data Protector. When I am working a VMware problem, I am, like you, finding these files in different places, although always in
This is why I said 'for example', and the best way to find these files is probably be doing a search for '.lck'