my 1TB vdisk continues to grow even when the OS is reporting a much smaller size. 

 

disk 3 continues to grow while on my ubuntu VM the disk is a fraction of the size (36%)

 

Ubuntu VM:

 

This is the only file/vdisk on the disk

 

 

I thought originally maybe some snapshot feature was causing this, I uninstalled snapd from ubuntu but the issue persists. 

That's how sparse vdisks work, unless you configure both the host and guest to allow the space to be reclaimed. By default the guest treats the entire virtual capacity of the allocated image as writeable, and unless the host and guest can agree on what bits are no longer in use, the host has no choice but to keep every write the guest makes, even if the guest goes back and "deletes" the data.

 

Here is a post that describes the process for Windows based VM's, you should be able to adapt to linux based guests as well.

https://forums.unraid.net/topic/51703-vm-faq/?tab=comments#comment-557606

 

Sounds if the logical size of the vdisk is larger than the available space to store it?    If so the VM will pause when the physical space used by the vdisk file uses up all the free space on the drive where it is located.    It is not good practice to ‘over-commit’ the vdisk file although there are Use Cases where it can make sense.   Was it deliberate to put it on a drive that was smaller than the logical size of the drive?

The over allocation shouldn't be the issue, the used capacity on the volume never gets that close. 

 

I tried the solution mentioned in the link provided by @jonathanm 

    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='writeback' discard='unmap'/>
      <source file='/mnt/user/domains/Ubuntu/vdisk2.img' index='1'/>
      <backingStore/>
      <target dev='hdd' bus='scsi'/>
      <alias name='scsi0-0-3'/>
      <address type='drive' controller='0' bus='0' target='0' unit='3'/>

This didnt seem to make a difference. 

 

I know this is probably not the best solution, but currently i am trying a cronjob that runs fstrim periodically. this appears to be working 

Just now, BirdUp said:

The over allocation shouldn't be the issue, the used capacity on the volume never gets that close. 

You missed the point. What the guest shows as used, vs. what the host sees as used are two different things unless you can get the two to communicate. The "unused" space inside the image still has data written, it's just that the guest has marked the files in those spaces as deleted and available for writing. The bits are still there, and allocated as far as the host is concerned.

 

Your guest shows an address space of 964G available for storage, and the host only actually has 932G available. When the guest tries to write to an address that can't be allocated, the host pauses it instead of crashing.