@pilow : thanks for let me know your experience.

I was afraid someone would say that.

Unfortunately for us going out of XOSTOR is not so simple because we really need VM mobility to allow for host maintenance which otherwise we would not be able to perform and budgeting for a redundant external storage is not an option either.

The annoying thing is that before start this journey with Vates we did engage with them and made them aware of our environment ( it is a migration from vmware) and no one has ever mention that could have been a problem to store so many VMs into xostor so I am really hope that support can shed some light and provide some fix to the situation.

Overall is not a bad experience but waiting for 3 / 4 minutes for a VM to start when you are in hurry is not really great.

Hi, you are not the only one to have the problem.

We do as well and with a smaller environment in terms of physical hosts ( only 3).

I did not engage with support yet because the size has gone back under 90% on its own but it keep popping up any other day.

We have constanst sr.scan as well which in our case last for a long time and we have other issues as well at running task like starting or stopping VM but we haven't figured why yet.

Hello, we have a pool of 3 hosts with XOSTOR and we are having various performance issues related to tasks like start/stop VMs, VM migrations or similar which according to Vates support are down to the task waiting for Sr.scan to be completed.

I can see sr.scan running all the time and some of them takes around 4 / 5 minutes...

the XOSTOR storage is around 27Tb and store about 107 VMs base disk + same amount of snapshots + what I think is the current changes for each of them for a total of 348 disks.

What your environments look likes? how long your sr.scans takes and most importantly do you have problems at start/stopping and migrating VMs?

For instance when we migrate VMs, the VMs freeze for about 3 / 4 minutes just before re-attaching the VDI on the target host and according to support is due to the sr.scan.