On Thu, Aug 15, 2019 at 10:35 AM Evelina Shames <eshames@redhat.com> wrote:

Hey Kevin, By design, when creating a snapshot, the new volume is created with 'sparse' allocation policy. I suggest you to open a bug since this operation should not crash the VM. Add this description and please add all relevant logs and any relevant information of your environment.

Regards, Evelina

On Tue, Aug 13, 2019 at 4:10 PM Kevin Doyle <kevin.doyle@manchester.ac.uk> wrote:

...

Hi I have linux VM with 2 disks one for OS is sparse the other is for a Database and is Preallocated. When I take a snapshot of the VM both disks change to sparse policy but the disks in the snapshot are 1 sparse and 1 allocated. Before the snapshot the VM was running fine, now it crashes when data is written to the database. When I delete the snapshot the disks go back to 1 sparse and 1 allocated. Has anyone else seen this happen. Ovirt is 4.3.2.1-1.el7 and it is running on a hostedEngine

Many thanks Kevin _______________________________________________

Hi, some clarifications needed: what kind of storage are you using? If block based (iSCSI or FC-SAN) I verified problems on sparse allocated disks and databases (Oracle in my case) during high I/O on datafiles. So, as you did, I used preallocated for data based disks. For fine tuning of automatic LVM extensions in case of block based storage domains, see also this 2017 thread: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/S3LXEJV3V4CIOTQ... not currently using it tohugh with recent versions of oVirt, so I have no "fresh" information about efficiency, depending on I/O load amount HIH anyway, Gianluca

On Fri, Aug 16, 2019 at 12:37 AM Nir Soffer <nsoffer@redhat.com> wrote: [snip]

Hi,

...

some clarifications needed: what kind of storage are you using? If block based (iSCSI or FC-SAN) I verified problems on sparse allocated disks and databases (Oracle in my case) during high I/O on datafiles.

What kind of problems did you have? do we have a bug for this?

The problems I described in the referred thread of my previous answer: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/S3LXEJV3V4CIOTQ... VM has been paused due to storage I/O problem Managing the vdsm related parameters: volume_utilization_percent and volume_utilization_chunk_mb mitigated the probability of occurrence but didn't solve definitely. I didn't open a bugzilla for that

...

So, as you did, I used preallocated for data based disks.

For best performance, we always recommended preallocated disks. I think you will get best results with direct LUN for applications that needs best performance.

And I did it, as you recommended, despite not optimized storage allocation, but solving the VM paused error. And this was also the reason why I didn't open a bugzilla, supposing the answer would have been to use preallocated and with thin provisioning not to be used in this use case scenario... Thanks, Gianluca