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.

Ahh, that is excellent. I didn't find that, and the version I'm working with pre-dates that feature. If I'm correct in thinking this does not cover the case where `on_poweroff` is set to restart, which cannot be altered on a running VM, so the await can never see an inactive state... then a cold reboot option could still be worthwhile. Otherwise, I guess one must run something like: virsh destroy <domain> --graceful && virsh await <domain> --condition domain-inactive && virsh start <domain>

So, to clarify, the best way to power-cycle a (persistent) VM and minimise downtime is: virsh set-lifecycle-action $DOM poweroff destroy --live && virsh await $DOM --condition domain-inactive && virsh start $DOM I still think this would be nicer: virsh reboot $DOM --cold

On Fri, Mar 13, 2026 at 09:06:58AM +0100, Peter Krempa via Devel wrote:

On Fri, Mar 13, 2026 at 07:46:30 -0000, Roy Orbitson via Devel wrote:

...

So, to clarify, the best way to power-cycle a (persistent) VM and minimise downtime is:

virsh set-lifecycle-action $DOM poweroff destroy --live && virsh await $DOM --condition domain-inactive && virsh start $DOM

'virsh set-lifecycle-action' just changes the setting of <on_poweroff>. You still need to initiate the shutdown via virsh shutdown.

...

I still think this would be nicer:

virsh reboot $DOM --cold

Compounding too many operations into one is brittle and may cause that some assumptions are baked in which may not make sense in other scenarios.

E.g. the above case could wait an unbounded amount of time if the guest os ignores graceful shutdown. What to do when such thing happens is a policy decision, as in some cases you might not want to just 'virsh destroy' the VM and potentialy lose data.

'virsh await' has --timeout but what to do when the timeout is reached isn't IMO for us to decide. Same would apply if we were to compound everything into what you propose.

I would highly recommend not trying todo this in shell using virsh. This is far better suited to writing a short python script using the libvirt-python API, where thereis much more flexibility and easier control to get the behaviour desired. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|