Arnaud:
> Dear Tails,
>
> I'd like to propose a little improvement to the Tails Builder VM.
>
> My use-case is that I build Tails locally on my laptop. My concern is a
> little lack of convenience: if ever I forget to close the Tails Builder
> VM (using `rake vm:halt`) after I'm done, the laptop gets stuck at
> shutdown. I can see these log messages:
>
> libvirt-guests.sh: Waiting for guest xxx to shut down, 300 seconds left
> libvirt-guests.sh: Waiting for guest xxx to shut down, 295 seconds left
> ...
Another way to work around this is to set `SHUTDOWN_TIMEOUT=0` in `/etc/default/libvirt-guests`.
> So basically, what happens is that systemd tries to stop libvirt guests,
> by invoking `/etc/init.d/libvirt-guests stop`. This script ends up in
> invoking `virsh shutdown tails-builder-...`. And this command fails.
>
> This is something you can verify by yourself easily. Launch the VM
> (`rake vm:up`), then try various ways to stop it. Commands that allow to
> stop the VM, from the higher-level to the lower-level, are:
> - OK: rake vm:halt
> - OK: vagrant halt <vm-id>
> - KO: virsh -c qemu:///system shutdown <name>
>
> At the libvirt level, stopping the VM doesn't work. To start with,
> anyone can confirm that, or am I the only one having this behavior ?
>
> After a bit of digging and experimenting, it turns out that this is not
> a bug, just the expected behavior. It seems that libvirt tries to
> shutdown the VM by speaking to the QEmu Guest Agent, which is not
> installed on the VM. So nothing happens, and the libvirt shutdown script
> gets stuck there, and my laptop doesn't shutdown.
>
> So !
>
> I did just that, installed the QEmu guest agent on the VM, enabled it in
> the Vagrantfile, and since then my life is so much better, and my laptop
> shuts down reliably and peacefully. It's a real improvement to me.
>
> Are you guys interested in enabling that upstream ? Should I open a
> ticket along with the patch ? Or is there some reasons why you didn't
> enable the QEmu guest agent in the first place ?
If the fix I proposed above isn't good enough for you, I suggest you wait and return to this issue in a few months -- there's an ongoing rework of how we use Vagrant which moves in the direction where each build will start with a completely fresh (first boot) builder VM, and whenever a build finishes (success or not) the VM is immediately destroyed and undefined. So I think your problem will just go away once this work is merged into our main branches. Fair enough?
Cheers!