I would be confirming what the vmware storage and the underlaying physical storage (SAN?) is saying about it.  It is one of those cases where a full power cycle of those systems may help or give you more clues.   More details on that front would be useful for us to assist further.

If those layers all check out and restarts of the storage don't resolve it, we may have a Maxim 41 situation "Do you have a backup?" means "I can't fix this."   So checking your backup status might be a valuable parallel task (that should be periodically performed anyways)

The pool is on virtual vmdk disk.

The customer's administrator has a backup, but some small part has not by chance backuped, so it would be welcomed to manage rebuilding the pool.

Under that vmdk is a datastore, that is provisioned on some actual physical drives in some fashion, a SAN with redundancy, hopefully.  The health of those needs to be looked at. I have seen issues happen there that look like what you are seeing, and finding and fixing those issues has helped me before.  At least once, a full power shutdown (convenient power outage beyond UPS) resolved this.

Location of the vm, such as what host it is on, vs the datastore has been an issue before. Once, just bringing up the vm on a different host made a big difference.  While that "shouldn't" make a difference, reality likes laughing at and thumbing its noses at the "shoulds"

The virtual server was copied to a synology environment and a clone was created on the VMware environment. The same problem with the pool was identify on the both migrated servers. So I think, that a hw problem is not probable.

Ah,  that is a good elimination.

The only other thought would be to bring the volume up on a different version of OES in case it is just a code issue. Even just updating the server after a good snapshot of it off.

Yes, on Monday (I must consult it with the customer's administrator) I am going to install a new OES 24.4 server and try to connect the problematic pool, at first outside of the product tree to investigate if the problem is or is not a problem of a progam code.

I know such a situation with NSS. In any case, you need to look deep into the logs of the VMware hosts in question. I had iSCSI and SAN Multipath issues that caused problems in the virtual volumes in the layers above, which then affected the application.

One issue concerned certain NAS systems that were used for VMware. Block allocation errors were caused by incorrect SCSI block commands at low level. What can also happen from time to time in the iSCSI environment is that packets (UDP packet loss) lead to problems in the upper layers.

To be able to make a concrete statement, I would have to have logs from the Vmware and use a sniffer to look into SAN or iSCSI or whatever is connected to it. One last thing that comes to mind. I also had a misconfigured VSAN that caused errors in the devices

George

The problem was resolved:
nssstart.cfg:
/PoolAutoDeactivate=all
reboot

Then /PoolMaintenance=DATA1 was successful and "ravsui rebuild" repaired the pool.