You can concede that virtual machines need a cold start to utilise updated software, right? And that users needing to do so manually is suboptimal? It's a problem that I think needs addressing but your response seems a little dismissive. Michal Prívozník wrote:
There is an inherent problem with bundling two or more operations under a single command (and you point it out at the end): what to do when one operation in sequence fails?
These are two separate problems, the "at the end" one is discussed at the bottom of this message. With the first, I don't believe it is inherent to bundling operations together. The same challenge exists with the current tooling, and virsh makes it the user's responsibility, but it could assist instead. If either operation fails, the single command should fail. I don't see how it could be any other way. Furthermore, bundled operations would solve the case where a VM is configured to restart in `on_shutdown`, where running a shutdown command alone never results in a 'cold' state. A cold reboot option, would allow virsh to fully shut down the VM, knowing that the config obligation will be met by starting it again afterwards.
And specifically for powering off/rebooting a VM - that requires guest cooperation. What to do, when guest (silently) refuses poweroff/reboot request (e.g. acpid is not running)?
Then the command would wait indefinitely (unless interrupted) or fail after the timeout, as stated previously. This is no different from a user script polling in a loop without a break, or a loop with a limit with the current version of virsh. Is there a better way? This is what I've seen in real-world use, e.g.: https://github.com/crc-org/snc/blob/2f4fb10767b7733d69946490c93820cd5ec3c9f4... The other alternative I can think of is first running an event monitoring command in one shell, like: (d=bazquux; LC_ALL=C LANG=C virsh event --domain "$d" --event lifecycle --loop | grep -qF ': Shutdown Finished' && virsh start --domain "$d") then running the shutdown command in another. Both this and the example in my previous message are quite convoluted for automation. They're also fragile because they rely on parsing output intended for humans, which may change in future. In cases where virsh could determine it would never succeed, even if it knew it was supposed to start the machine again, then it could return this failure immediately, without attempting to modify the VM's state. With this feature, it would still be up to the user to deal with, which is no worse than the situation now. There are plenty of ways to write shell commands that will never complete. Some are built not to, like `yes`. That's not virsh's problem.
The moment virsh introduces a timeout there's going to be a user for whom the timeout is short.
In this scenario, virsh doesn't introduce the timeout, the user does, and its up to them to set its length. If it's too short, that's their fault. The default would be no timeout.
if the shutdown portion was not completed quickly enough, they would fail and exit with a non-zero status, and the former would not start the VM again.
A timeout would only need apply to the shutdown operation. In a cold reboot, the machine would request the shutdown and return failure if it did not happen in time. If it did complete in time, it would return success if the start operation also succeeded. It could only cause the command to deliberately fail, not dictate whether or not the VM eventually shuts down.
I'm not sure of a good way to handle this where `on_poweroff` is set to something that doesn't result in the machine being shut off.
The second problem you reference above is this one, with a shutdown command like: virsh shutdown --domain bazquux --synchronous It may succeed but result in the VM being active afterwards, due to config, though what the user really wants is to wait until the machine is off. Given virsh could not know from that command whether the user intends to wait until it's completely off or just restarted, it might need a second option, like: virsh shutdown --domain bazquux --synchronous --cold Then the command could fail immediately (with an explanation) if config would prevent a 'cold' state, or wait indefinitely until it does. This feature request is about improving a common use case, not changing current or default command behaviour, nor covering every possible edge case, which virsh does not do now, anyway.