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 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
