Memory query RPC service

[ben-grande]

What I don't like about the script: it infinitely waits for a running qube to respond for the qubes.VMShell service call, which I don't know how to indirectly timeout the subprocess created by run_service_for_stdio.

Also the table formatting is "OKayish".

Just the bare minium info qui-domains format, not enough info to justify command-line options and it is not as great as xentop, but more useful for Qubes.

I assume the Qubes license is GPL-2.0-only, not or-later because I didn't find this info.

[marmarek]

which I don't know how to indirectly timeout the subprocess created by run_service_for_stdio.

run_service_for_stdio can't do that for you, but run_service can - it returns subprocess instance on which you can wait yourself, including own timeout handling (like proc.communicate(timeout=...)).

[marmarek]

There is already meminfo-writer that reports more or less the same info for the qmemman use. It writes it into xenstore under memory/meminfo key. And since that's what is getting used by qmemman, it's probably more useful value.

OTOH, having a service that needs to be called into all VMs by qvm-top is going to be quite heavy.

Maybe a better idea is to extend admin.vm.Stats method to include also this value in the reported events? Then qvm-top can make a single call to get stats of all VMs, and periodical updates of it.

[ben-grande]

There is already meminfo-writer that reports more or less the same info for the qmemman use. It writes it into xenstore under memory/meminfo key. And since that's what is getting used by qmemman, it's probably more useful value.

I see that the memory/meminfo has a delay, posibly only written too once at each qmemman loop, so not real time data. Also reading meminfo is not possible when meminfo-writer is off (PCI qubes and other).

P.S.: I understood how to query it with xen.lowlevel.xc.xc().domain_getinfo().

OTOH, having a service that needs to be called into all VMs by qvm-top is going to be quite heavy.

Yes... it takes 3 seconds for the whole qvm-top loop with 10 qubes running.

Maybe a better idea is to extend admin.vm.Stats method to include also this value in the reported events? Then qvm-top can make a single call to get stats of all VMs, and periodical updates of it.

It is a better idea, I didn't knew about admin.vm.Stats.

I presume a new setting avail_memory_kb should be added to https://github.com/QubesOS/qubes-core-admin/blob/c1cdf38da6cd5f1cfdf54afb203da371d56b177b/qubes/api/admin.py#L1985-1992

For another day to understand how to a write a new value to xenstore and then query it with xc.domain_getinfo() and which script should actually call the writing to xenstore in the qube, considering that meminfo-writer may be disabled in the qube.

[marmarek]

I see that the memory/meminfo has a delay, posibly only written too once at each qmemman loop, so not real time data.

It is written every meminfo-writer iteration, whenever there is a significant enough change (first arg to meminfo-writer, by default 30MB). And meminfo-writer checks that every 100ms (the second arg), which is likely faster than your qrexec service.

Also reading meminfo is not possible when meminfo-writer is off (PCI qubes and other).

That is true, but also I'd argue it's less relevant then too. Because those qubes won't take/give memory to others.

P.S.: I understood how to query it with xen.lowlevel.xc.xc().domain_getinfo().

Nope. This returns only info about assigned memory (what qmemman decided to assign, based on the info given by meminfo-writer and available amount). the memory/meminfo needs to be read via xs.read().

I presume a new setting avail_memory_kb should be added to https://github.com/QubesOS/qubes-core-admin/blob/c1cdf38da6cd5f1cfdf54afb203da371d56b177b/qubes/api/admin.py#L1985-1992

Yes. But note that meminfo-writer tells how much memory is used in the VM (which may be more than assigned when you run into swap), not how much is free.