XenServer NFS Storage Repo in the SMB

olivier

@johnhooks If you are on a XenServer pre-Dundee, that's normal: LVM is not thin provisioned in this case.

Dashrender

@DustinB3403 Even classical backup: for a running VM we need to export the snapshot. So if all your VMs are running and you are backuping everything at once, you'll need to double your space usage (at least during the VM export process).

That's why it's important to use thin provisioned storage as possible.

HUH? Creating a Snap doesn't instantly create a double of your current in use storage. Assuming a 2 TB VM, you snap it, As I understand it, what happens is the current 2 TB file is no longer written to, and a new additional file is created where all of the changes are written to. If that VM isn't very change heavy, the Snap file most likely will remain small. Of course there are times when the system might be changing data like crazy - out with the old, in with the new - so total usage doesn't change, but actual changes could be epic.

olivier

@Dashrender It's not exactly like that on a thick storage. It's a little bit more complicated in fact.

It depends of the current disk content. XenServer will try to deflate as possible. Let's take for example, only one VDI with the total size of the disk space provisioned (let's say on a LVMoiSCSI):

Then, if you do a snapshot, you'll have 3 disks:

the original one will become the parent
the new created active VDI will be remapped to be current VM disk
the snapshot

Doubling size is the worst case, when deflate won't free some space (or very little). In this case, the initial snapshot mechanism will double the space used.

But any extra snapshot (after the initial one) won't consume a lot of space.

olivier

By the way, you can spot the difference with a thin provisioned SR, like NFS in this case:

Far better...

Dashrender

Interesting. What happens when you take a second snap? When it is deleted, is the there two or three files now?

olivier

@Dashrender Okay let's retake a clean example: one VM in a SR, with one 4GB VDI:

# lvscan 
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/MGT' [4.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-770ceeac-e97e-4e05-b9c5-892b97b9d16e' [4.02 GiB] inherit

After first snapshot:

# lvscan 
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/MGT' [4.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-38e2156f-da74-4edb-ac83-56fda54cfe55' [1.75 GiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-770ceeac-e97e-4e05-b9c5-892b97b9d16e' [4.02 GiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-f18856a5-039b-4d84-bf6c-a259d0f49a9e' [8.00 MiB] inherit

After second snapshot:

# lvscan 
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/MGT' [4.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-38e2156f-da74-4edb-ac83-56fda54cfe55' [1.75 GiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-f18856a5-039b-4d84-bf6c-a259d0f49a9e' [8.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-770ceeac-e97e-4e05-b9c5-892b97b9d16e' [4.02 GiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-68408f33-5a69-4b3b-afdd-a2cfabcad9ba' [8.00 MiB] inherit

As you can see, we got a second 8 MiB logical volume, nothing more (base parent and active VDI doesn't change).

Let's remove the latest snapshot:

# lvscan 
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/MGT' [4.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-38e2156f-da74-4edb-ac83-56fda54cfe55' [1.75 GiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-f18856a5-039b-4d84-bf6c-a259d0f49a9e' [8.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-770ceeac-e97e-4e05-b9c5-892b97b9d16e' [4.02 GiB] inherit

It removes the previously created volume, as expected. Now, let's remove the initial snapshot. Durin few seconds, we'll have this:

lvscan 
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/MGT' [4.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-38e2156f-da74-4edb-ac83-56fda54cfe55' [1.75 GiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-770ceeac-e97e-4e05-b9c5-892b97b9d16e' [8.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/leaf_770ceeac-e97e-4e05-b9c5-892b97b9d16e_38e2156f-da74-4edb-ac83-56fda54cfe55' [4.00 MiB] inherit

But it will be automatically "garbage collected" when the system will see than the chain doesn't have any snapshot in it (after few seconds in this case):

# lvscan 
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/MGT' [4.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-770ceeac-e97e-4e05-b9c5-892b97b9d16e' [4.02 GiB] inherit

We are back to the initial situation.