From 1c8e6f8428dae1b67526d4636198413b708baa4c Mon Sep 17 00:00:00 2001 From: Cole Robinson Date: Wed, 9 Oct 2024 13:03:14 -0400 Subject: [PATCH] virt-install: Make --cloud-init reboot by default (again) This basically reverts this commit from virt-manager 4.0.0 ``` commit 825ec644b859b99d6f9f155b04ef3ac07eca1fc2 Author: Cole Robinson Date: Tue Mar 1 10:32:01 2022 -0500 installer: Do not force reboot with --cloud-init Resolves: https://github.com/virt-manager/virt-manager/issues/189 ``` After that commit, using `--cloud-init` or `--unattended` would basically imply `--noreboot` For some usage of `--cloud-init`, like in the initial report, this makes sense to do. virt-install will drop you into the cloud image, you mess without, run `poweroff`, and are surprised when virt-install reboots the VM. I agreed, and made the change But changing this was a bad idea. cloud-init and unattended VMs have 2 XML phases. First XML is booting off temporary media (the generated cloudinit iso), second XML is the permanent boot config (booting off disk). We need to force the VM to fully poweroff, so that the second XML config takes effect. We make that happen with `destroy`, which tells libvirt/qemu to poweroff the VM when it receives a guest reboot notification. virt-install then defaults to restarting the VM when it detects shutdown, to manually replicate the VM requested reboot, but still get the second XML config to take effect. The perennial problem with this is that, from outside the VM, we don't know if the user inside the VM requested `poweroff` or `reboot`. virt-install emulates the reboot behavior, and provides `--noreboot` to override it. It's still confusing if a user puts a `poweroff` command at the end of an anaconda kickstart file, and sees the VM reboot, but it's been that way forever. Except with that commit above, we flipped it for --cloud-init and --unattended. Now, users who do `poweroff` are getting expected behavior, but users who request `reboot` are not. We could go further and add a `--yesreboot` option or similar. But for consistency sake I think we should just revert that behavior, and tell users to use --noreboot like usual. Resolves: https://github.com/virt-manager/virt-manager/issues/497 Signed-off-by: Cole Robinson --- virtinst/install/installer.py | 2 ++ virtinst/virtinstall.py | 4 ---- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/virtinst/install/installer.py b/virtinst/install/installer.py index 706bdcff4..aa406fdb6 100644 --- a/virtinst/install/installer.py +++ b/virtinst/install/installer.py @@ -507,6 +507,8 @@ class Installer(object): into the guest. Things like LiveCDs, Import, or a manually specified bootorder do not have an install phase. """ + if self.has_cloudinit() or self.has_unattended(): + return True if self._no_install: return False return bool(self._cdrom or diff --git a/virtinst/virtinstall.py b/virtinst/virtinstall.py index 63760a6b0..748286f28 100644 --- a/virtinst/virtinstall.py +++ b/virtinst/virtinstall.py @@ -438,10 +438,6 @@ def build_installer(options, guest, installdata): no_install = True elif options.boot_was_set: no_install = True - elif options.cloud_init: - no_install = True - elif options.unattended: - no_install = True installer = virtinst.Installer(guest.conn, cdrom=cdrom,