Processing Error: Failed to open VDDK disk [[.vmdk] ( is read-only mode - [true] )
Failed to open virtual disk [.vmdk (flags: 4)
Logon attempt with parameters [VC/ESX: [vc.domain.local];Port: 443;Login: [];VMX Spec: [moref=vm-];Snapshot mor: [snapshot-443];Transports: [nbd];Read Only: [true]] failed because of the following errors:
Failed to open disk for read.
Failed to upload disk.
Anyone else see this error when using SAN transport mode? We've been fighting with it for a while and have been sort of working around it but would love to see VMWare resolve. Working with Veeam tier 2 support now on case 01954128. Ken has been superb to work with. Just looking for feedback for what others may have seen and how you've worked around or possibly resolved.
Interesting find and it does show the same error but doesn't seem to apply to our environment. We're on 5.5 build 4345813 and have not found a case where console access was interrupted. We only see this when attempting to utilize SAN transport mode on our backups and somewhat intermittently. Hotadd and NBD work without issue.
hi
have a customer that experinecing the same error on [san] mode and only see this when doing snapshots of virtual desktops (win7 and win10) all servers seems to work fine. The failed VM's is two or three in a job out of 40 and when the job is retried with [nbd] the failed VM's work fine.
Did you find any solution or good workaround for it?
Our "fix" was to use virtual proxies (hot add) in place of SAN mode. Not ideal, but it works for now. Support seemed to think once we moved to vSphere 6.5 we wouldn't have this issue. Recently installed the Cisco c3260 as our backup repository so really hoping we can use SAN mode with this.
We just ran into this too, however in our case it was because the job was trying to use a DirectSAN proxy that wasn't connected to that datastore (it was in another site). Some drives were backed up fine by the correct DirectSAN proxy and some failed with this because it tried to use a DirectSAN proxy from another site.
In our case we're still on 6U2 for vCenter and ESXi. We did upgrade some of our hosts from build 4192238 to 4600944 on our DR site to test it and I'm now wondering if that might be the cause, although I wasn't aware the ESX hosts themselves were part of the DirectSAN LUN detection at all
We are having this same issue. When we rolled veeam out we were on vsphere 5.5 u3 and we were told all problems would go away once we updated to vpshere/vcenter 6 u2. Well that upgrade was performed a few months back and I just went to try moving the backup job that experiences this issue over to the direct access proxy. Same exact error occurred. This particular job happens to be 3 separate windows 2008 r2 file servers. The largest being almost 2.7TB. It never works with the large file server, we always receive this error, and it will work sporadically with the other 2.
We are having this same issue with Vsphere 5.5u3
is there any update about this error ?
yes, support was contacted but they haven't found any solution yet
I had this error and found that the problem was time sync on the Veeam server. The Veeam server was more than five minutes out of sync with the correct time. I resolved this by correcting the time sync configuration on the Veam server.
