[virt-tools-list] [virt-manager gui feature request] check box for "locked" memory backing

[Joachim Wagner]

Thanks for looking into this.

> it's 1) difficult to explain in
> the UI, 2)
+
> 2) has tricky operational caveats (see
> https://libvirt.org/formatdomain.html#elementsMemoryBacking),

Ok, I wasn't aware one needs to use hard_limit to make this safe for the host 
and that guests' memory usage on the host can grow arbitrarily. However, there 
should be values h0 and h1 such that hard_limit = h0 + h1 * maxMemory only 
waste a small amount of memory acceptable to normal users, maybe h0=256 MB and 
h1=1.05, and results in a low probability of hitting the limit. This extra 
memory usage could then be mentioned in the "locked" check box.

For myself, I think I will simply remove "locked" again as I also moved to 
using huge pages and I understand the SUSE documentation that huge pages are 
never swapped out.

> 3) has a
> limited audience who are already power users.

Given the simple, reproducible, non-power user situations in which my VMs have 
been swapped out so much that they became unusable (unresponsive to mouse 
clicks) over the last years, I'd expect that the majority of users would need 
this "locked" option. I only need to do something mundane as copying a large 
file from disk/SSD to a low-speed memory stick and from one minute to the next 
99% of my VM is no longer in RAM (without "locked"). With swap on spinning 
disks, swap out is fast because it's sequential but swap in is super slow 
because it's mostly random access. Before I learned about "locked", my best 
course of action was to "force off" the VM and start it again. (In some cases, 
swap usage went back to exactly 0, indicating that only the VM was swapped 
out. I guess that the kernel picks the largest idle process when it wants to 
make available some extra RAM for I/O.) 

What puzzles me is that experts and power users do not seem to have ever 
encountered such problems. On serverfault, the experts say it is perfectly 
fine that the VM is swapped out, arguing that the kernel's swap heuristics are 
carefully tuned and if the kernel decides to do so there must be a good reason 
and it must be for the better of overall performance. 

> virt-xml $VMNAME --edit --memorybacking locked=on
Thanks. I tested this and updated my serverfault answer accordingly.

> I'm thinking virt-manager really needs a raw XML editing
> mode.
If my own learning experience is representative, I'd say a tab "Advanced 
Settings" does not need an editor but just pointers to virt-xml (+ virsh edit 
if virt-xml cannot do all) and online resources / step-by-step examples / 
community wiki.

Joachim