[SOLVED] Get VM Disk Details

[awado]

This is a fresh installation with ZFS. I have successfully migrated a 2TB VM from VirtualBox into Proxmox. Afterwards I deleted many unneeded big files within this VM. How can I tell what physical disk space this VM's disk is taking? I'm completely unsure, if the VM's trim mechanism works correct and if it's a qcow2 disk.

 

[Neobin]

If the 2 TB-VM is also on ZFS (natively, meaning in a ZVOL): zfs list
What vdisk-type it is can you see on the hardware-tab of that VM. Otherwise post the output in code-tags of: qm config YourVMID (replace YourVMID with the actual numeric ID of that VM), as well as of: cat /etc/pve/storage.cfg here.

 

[awado]

The hardware tab doesn't show any type.

# qm config 100
agent: 1
boot: order=sata1;ide2;net0
cores: 8
ide2: none,media=cdrom
memory: 8192
meta: creation-qemu=6.2.0,ctime=1662923244
name: Debian
net0: virtio=08:00:27:8a:9e:87,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
sata1: local-zfs:vm-100-disk-1,size=2097151M
scsihw: virtio-scsi-pci
smbios1: uuid=abccb18b-7bf4-4d1b-81bf-e07f8f24aef2
sockets: 1
vmgenid: 59505cc0-57e3-4b1f-848a-f15e30f89297

and

# cat /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content backup,vztmpl,iso

zfspool: local-zfs
        pool rpool/data
        content images,rootdir
        sparse 1

 

[Neobin]

The hardware tab doesn't show any type.

It does:

sata1: local-zfs:vm-100-disk-1,size=2097151M

It is a ZVOL on the default rpool:

zfspool: local-zfs
         pool rpool/data
         content images,rootdir
         sparse 1

Execute: zfs list on the PVE-host and look for: vm-100-disk-1.

But you do not have discard enabled. (discard=on is missing on the vdisk.) Edit the vdisk in the hardware-tab of the VM and tick: "Discard".
I am not sure, if discard works (in the meantime) with the virtual disk-interface sata, but with scsi it does definitely [1]. Maybe you have to change it.
Perhaps you also need to tick: "SSD Emulation".

After those changes, run fstrim -Av or fstrim -av [2] inside the VM and check, if the fstrim.timer is enabled: systemctl status fstrim.timer for automatic weekly trimming.

[1] https://pve.proxmox.com/wiki/Shrink_Qcow2_Disk_Files#PVE_Configuration (Mainly for qcow2, but as mentioned there counts also for ZFS with thin-provision enabled (sparse 1).)
[2] https://manpages.debian.org/bullseye/util-linux/fstrim.8.en.html

 

[awado]

Thanks a lot for this. Interresting insights. Can changes at the vdisk settings be done without any risk? And how can I tell, if the disk is qcow2 or raw? I used trimming on other VMs before, but they were freshly installed VM, not migrated VMs like this one. You may ask, why i won't make a backup and just try. Well, that's the point. The current VM disk ist too large to make a backup in a reasonable time. Trimming it would make it reasonable.

 

[Dunuin]

Changing disard or SSD emulation shouldn't be a problem. And don't forget to shutdown that VM, otherwise these changes won't be applied.
If its a zvol then its always raw, as zvols are block devices and qcow2 just works on file level.

 

[Neobin]

In addition to what Dunuin said; if you want to see it black on white, have a look in your PVE there:


Changing from sata to scsi (on a powered off VM) should be no problem on a Linux-VM, as long as the whatever is used identifier in e.g. fstab stays the same; I assume. But to be honest, I never changed it afterwards. So you might want to recherche a bit and better test it on a Test-VM first.
On a Windows-VM, there would be some more steps needed: [1].

[1] https://forum.proxmox.com/threads/change-guest-hard-drive-from-sata-to-scsi.106788/#post-459726

 

[awado]

Tested it with another Debian VM, editing the conf file by hand. Switching from "scsi0" to "sata0" and vice versa doesn't harm the VM. Changing cache mode also not. Thanks a lot for all those clarifications.