qm suspend <vmid> [OPTIONS]
Suspend virtual machine.
qm resume <vmid> [OPTIONS]
Resume virtual machine.
qm suspend --todisk 1
also work if the pve node is rebooted afterwards? So: suspend VM, reboot node, resume VM. I found this bug report https://bugzilla.proxmox.com/show_bug.cgi?id=426 where it looks like this would work, but I am not completley sure if it really applies to this case.State storage selection
If no target storage for the memory is given, it will be automatically chosen, the first of:
- The storage vmstatestorage from the VM config.
- The first shared storage from any VM disk.
- The first non-shared storage from any VM disk.
- The storage local as a fallback.
Seems to me like a job for the Agent. Would be really nice to have an option whereWell… the quest could probably hibernate itself after flushing the caches, if one would let it use the PVE api to hibernate itself. Otherwise, the qm command would have to be issued from the PVE host and that one has of course no knowledge as of when or if the cashes have been flushed out.
qm suspend
would flush the cache from within the guest. The command is blocking. It means it will not return before it's complete. If you have a lot of ram (100+GB etc.) then you can actually see it decreasing from proxmox webui under status. Depending on the machine the flushing can occur on ranges of 5-30GB/s.@Jannoke Interesting approach! Do you issue it on the host machine or inside the VMs? Do you need to wait for a certain time after the 'echo' command?
Can you please detail this a bit? Thank youYes I tested that out also. Got an extra file in my zfs pool. Also it seems it wil dump only needed memory and size of the "hibernate" file depends on the current ram usage. So for faster standby/resume echo 3 >/proc/sys/vm/drop_caches is one way to go. I use it also to make migrations faster between nodes.