(SOLVED) max Size of vdisk.img

[cracksilver]

Hi there

 

I have tried a lot to make timemachine backups directly in an unraid share. Unfortunately all attempts failed sometime. Sometimes it didn't work, sometimes it didn't work after 2 days. It just wasn't supposed to be.

 

Because I also know Rockstor and know the timemachine backups works there out of the box and absolutely reliable I was looking for a solution. But I don't want to run an extra server with rockstor. 

 

Now I have rockstor running successfully in a VM. The start partition in vdisk1.img and the data disk in vdisk2.img. The vdisk2 has a size of over 600 GB. Is that basically ok or will I have problems due to the size at some point? If that's not ok, can I solve it in unraid by creating multiple vdisks which are then combined in rockstor as stripe?

 

What do you think about this topic, has someone solved it similarly?

 

thank you in advance.
greg

 

[JorgeB]

1 hour ago, cracksilver said:

The vdisk2 has a size of over 600 GB. Is that basically ok or will I have problems due to the size at some point?

It's OK as long as it fits on the disk it currently is, since on Unraid a file can't span more than one disk, depending on the VM config it might also be limited to 2TB max.

[cracksilver]

Thanks. Good to know. It is on a 1.5 TB Disk.


Gesendet von meinem ONEPLUS A5000 mit Tapatalk

[itimpi]

One thing to be aware of with vdisks is that normally they are set up as ‘sparse’ files.    This means that disk space is not actually given to the file on the physical drive for parts that are not used.  This means the space used on disk can be less than the the notional size of the vdisk file.    As the VM runs it can write to unused parts of the vdisk that will cause extra space on the physical drive to be used.   If the physical disk runs out of space during this process the VM can stop running correctly.

[cracksilver]

Timemachine manages the backups by its own, it means that tm deletes the oldest backups if there is no space on vdisk2.img anymore. So I hope it works. At least it does it in a "normal" environment.

[Warrentheo]

16 hours ago, itimpi said:

One thing to be aware of with vdisks is that normally they are set up as ‘sparse’ files.    This means that disk space is not actually given to the file on the physical drive for parts that are not used.  This means the space used on disk can be less than the the notional size of the vdisk file.    As the VM runs it can write to unused parts of the vdisk that will cause extra space on the physical drive to be used.   If the physical disk runs out of space during this process the VM can stop running correctly.

While you can manually sparse-ify these files with this command:

fallocate -d <filenamegoeshere>

which lets you "Dig" all the zeros out of a file... A better option would be to change the driver KVM/Qemu uses to be the SCSI driver, then set the the "Discard" option for the drive manually in the VM XML like this:

    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' discard='unmap'/>
      <source file='/mnt/user/domains/<imagefilenamegoeshere>'/>
      <target dev='sda' bus='scsi'/>
    </disk>

This lets the VM's TRIM command get passed to the host, and therefor make it all the way down to the real drive...  This lets KVM/Qemu automatically manage the image file sparseness for you...  Obviously much more useful if you are storing it on an SSD, since constantly changing the VM's image file size would murder speed on an HDD...

 

If you are running on a HDD, it is recommended that you leave these files fully allocated so that things like defrag continue to work correctly...

 

Edit: changing the driver that Windows uses to talk to the boot drive can be problematic, and is best set during windows install...  It is possible to change afterward, but make sure to do backups of both the image file, and the VM XML before you try it...

Edited February 7, 2019 by Warrentheo

[cracksilver]

On 2/7/2019 at 9:59 PM, Warrentheo said:

While you can manually sparse-ify these files with this command:

fallocate -d <filenamegoeshere>

which lets you "Dig" all the zeros out of a file... A better option would be to change the driver KVM/Qemu uses to be the SCSI driver, then set the the "Discard" option for the drive manually in the VM XML like this:

    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' discard='unmap'/>
      <source file='/mnt/user/domains/<imagefilenamegoeshere>'/>
      <target dev='sda' bus='scsi'/>
    </disk>

This lets the VM's TRIM command get passed to the host, and therefor make it all the way down to the real drive...  This lets KVM/Qemu automatically manage the image file sparseness for you...  Obviously much more useful if you are storing it on an SSD, since constantly changing the VM's image file size would murder speed on an HDD...

 

If you are running on a HDD, it is recommended that you leave these files fully allocated so that things like defrag continue to work correctly...

 

Edit: changing the driver that Windows uses to talk to the boot drive can be problematic, and is best set during windows install...  It is possible to change afterward, but make sure to do backups of both the image file, and the VM XML before you try it...

thx for this input. greg

[casperse]

Hi Everyone

 

I know this is a older thread, but my questions is related to this problem

So far I have been using the pass through disc to a VM, but then I loose a drive in the array to only this VM

So would the best solution be to create a vdisk.img on a UAD drive? 2-3 TB in size? (Already have 1 UAD)

Would I need to change anything in the VM config to get a size above 2TB?

Is there anyway to create it as a fixed size taking up the space when creating the vdisk file?