Demi Marie Obenour writes: > On 7/16/26 04:29, Alyssa Ross wrote: >> Demi Marie Obenour writes: >> >>> The networking test runs run-vmm twice with the same VM ID. >>> If it waits for the previous cgroup to be empty, the second >>> call waits forever. >>> >>> Is this expected? I would expect that run-vmm is only called >>> once. >> >> Assuming you mean run twice in sequence, rather than run twice at the >> same time, then yes, it is expected. >> >> The way it works at the moment is that imported VMs have a VM ID >> assigned when they're imported, and they can then be started any number >> of times. When the VM shuts down, the VMM exits, so if the VM is >> started again after that, run-vmm will be run again with the same VM ID. >> If this were not the case, VM IDs could not be assigned at import time, >> and stay the same between successive boots of the same VM. >> >> If your cgroup is not being emptied as expected, that is a bug, >> regardless of whether it ends up being used again, because there >> shouldn't be lingering processes or cgroups hanging around forever. >> It sounds like we should have a test that confirms that this doesn't >> happen, if it's hard to get right. >> >> The networking test does do something slightly unusual, which is that it >> restarts the VMM with s6-svc -Wr -r, rather than e.g. via the Cloud >> Hypervisor API. I would expect that this runs the finish script, but >> might be worth confirming. > > What should happen if run-vmm is run more than once for the same VM? At the same time? That shouldn't happen. That can either be ensured outside of run-vmm or inside it — I don't think that every time we factor out a common script it needs to add a new check that it's being used correctly, or the codebase will end up all usage checks.