On 7/5/23 3:08 PM, Daniel P. Berrangé wrote:
On Wed, Jul 05, 2023 at 02:46:03PM +0200, Claudio Imbrenda wrote:
On Wed, 5 Jul 2023 13:26:32 +0100
Daniel P. Berrangé <berra...@redhat.com> wrote:
[...]
I rather think mgmt apps need to explicitly opt-in to async teardown,
so they're aware that they need to take account of delayed RAM
availablity in their accounting / guest placement logic.
what would you think about enabling it by default only for guests that
are capable to run in Secure Execution mode?
IIUC, that's basically /all/ guests if running on new enough hardware
with prot_virt=1 enabled on the host OS, so will still present challenges
to mgmt apps needing to be aware of this behaviour AFAICS.
I think there is some fencing still? I don't think it's automatic
IIUC, the following sequence is possible
1. Start QEMU with -m 500G
-> QEMU spawns async teardown helper process
2. Stop QEMU
-> Async teardown helper process remains running while
kernel releases RAM
3. Start QEMU with -m 500G
-> Fails with ENOMEM
...time passes...
4. Async teardown helper finally terminates
-> The full original 500G is only now released for use
Basically if you can't do
while true
do
virsh start $guest
virsh stop $guest
done
then it is a change in libvirt API semantics, as so will require
explicit opt-in from the mgmt app to use this feature.
What is your expectation if libvirt ["virsh stop $guest"] fails to wait
for qemu to terminate e.g. after 20+ minutes. I think that libvirt does
have a timeout trying to stop qemu and than gives up.
Wouldn't you encounter the same problem that way?
With regards,
Daniel
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
