在 2021-07-29 02:46，Cole Robinson 写道：
On 7/15/21 9:17 AM, Michal Prívozník wrote:
On 7/7/21 3:31 PM, Cole Robinson wrote:
On 7/7/21 4:50 AM, Michal Prívozník wrote:
On 7/5/21 5:20 AM, lma wrote:
在 2021-07-01 08:39，Michal Prívozník 写道：
On 7/1/21 12:52 AM, Cole Robinson wrote:
(ccing mprivozn with a domaincapabilities design question below)
<snip/>
IMO just source type= is enough.
FYI, I just merged patches that implement this in libvirt:
133d05a15e qemu: capabilities: fill in domcaps <memoryBacking>
e27e22585a conf: domcaps: Report <memoryBacking>
# virsh domcapabilities | xmllint --xpath
/domainCapabilities/memoryBacking -
<memoryBacking supported="yes">
<enum name="sourceType">
<value>file</value>
<value>anonymous</value>
<value>memfd</value>
</enum>
</memoryBacking>
Thanks Michal!
We had some internal discussion about using memfd by default, but
there's some caveats: memfd implies shared memory, and shared memory
does things like prevent KSM from working, add some hiccups to memory
ballooning, and causes VM to appear to own all its memory after
save/restore. So I'm not sure we should set this as the default any
time
soon.
So this puts us back at the beginning. Do we make addhardware try to
transparently set up shared memory when virtiofs is requested? That
still makes me leery TBH.
IMO transparently setting up shared memory in this case is not a good
idea.
I'm thinking we should add a UI checkbox in the memory screen for
enabling/disabling shared memory. This way the logic is testable for an
existing VM outside of the addhardware wizard. If our logic is
incorrect
and screws up their VM like making it unbootable, there's an explicit
way to back out that change. We should prefer memfd over file shm
memory
if memfd is available in domcaps.
Then when adding virtiofs device in addhardware, we try to make the
default behavior work, but let the user opt out. So in the standard
case, where VM has no shared memory config, when selecting virtio-fs,
we
show a new checkbox 'Enable shared memory for the whole VM' with an
info
icon + tooltip explaining this is necessary for virtio-fs. We still
show
it even when the host already has shared memory configured, but disable
the checkbox and add a tooltip saying 'VM is already configured with
shared memory'. I think that should be enough to make this safe to
maintain, and more informative to the user about what is happening
Based on the above valuable information, What I intend to do are:
- If virtiofs is available in domcaps: Add a UI checkbox in the memory
screen
of details for enabling/disabling shared memory, meanwhile set 'memfd'
as
backend if memfd is available in domcaps, otherwise set 'file' as
backend.
- This UI checkbox will be invisible if virtiofs is unavailable in
domcaps.
- This UI checkbox will be disabled in the memory screen if existing
virtio-fs
device(s) are detected in VM config.
- Don't add such UI checkbox in new VM wizard.
- Add a checkbox "Enable shared memory for the whole VM" with an info
icon +
tooltip when selecting virtio-fs in the addhardware wizard or in the
details.
- Still show this checkbox even when the VM already has shared memory
configured,
but disable the checkbox and add a tooltip saying 'VM is already
configured with shared memory'
BTW, About the "Are there qemu versions that support virtiofs but aren't
new
enough for libvirt's defaultRAMid determination?":
We know that qemu exposes default_ram_id through 'query-machines' since
v5.2.
Libvirt uses memory-backend-* for regular VM memory if default RAM ID is
detected.
If the default RAM ID isn't detected, Libvirt falls back to the
deprecated -mem-path,
(Unfortunately, default RAM ID isn't exposed in domcapabilities)
So it's harmless setting shared memory via the above checkbox in VM
memory
screen even if the underlying qemu is v5.0 or v5.1.
Thanks Michal!
Thanks Cole!
Lin
