[libvirt] libvirt-guests.sh without or with failing ACPI support
Hi all, the systemd shutdown scripts work sequentially with a 300s timeout (seen on Debian). If a VM does not have ACPI support, or the ACPI support failed for some reason, you are looking at a 300s timeout per instance for a host shutdown/reboot. i.e. 10 instances without working ACPI = 3000s to shut down I think the systemd scripting should be parallel instead of sequentially. So if you have many VMs without working ACPI you just have to wait 300s in total for the host to shut down. Steps to reproduce: - star a VM that does not support ACPI - reboot the host and wait 300s for the VM to be shut down - now start it multiple times - wait multiples of 300s for the shutdown Expected behaviour: - no matter how many instances do not support ACPI, make it 300s max because we shut them down in parallel regards, Henning
On Tue, Dec 10, 2019 at 10:46 AM Henning Schild <henning.schild@siemens.com> wrote:
Hi all,
the systemd shutdown scripts work sequentially with a 300s timeout (seen on Debian). If a VM does not have ACPI support, or the ACPI support failed for some reason, you are looking at a 300s timeout per instance for a host shutdown/reboot. i.e. 10 instances without working ACPI = 3000s to shut down
I think the systemd scripting should be parallel instead of sequentially. So if you have many VMs without working ACPI you just have to wait 300s in total for the host to shut down.
Hi Henning, this is configurable in /etc/default/libvirt-guests For example Ubuntu (otherwise using the same bits) changes that to run PARALLEL_SHUTDOWN=10 SHUTDOWN_TIMEOUT=120 I never got bugs about that config being too aggressive. The change is old and as easy as: https://git.launchpad.net/ubuntu/+source/libvirt/tree/debian/patches/ubuntu/... Maybe you just want to open a bug with Debian to change the default config there as well? Steps to reproduce:
- star a VM that does not support ACPI - reboot the host and wait 300s for the VM to be shut down - now start it multiple times - wait multiples of 300s for the shutdown
Expected behaviour: - no matter how many instances do not support ACPI, make it 300s max because we shut them down in parallel
regards, Henning
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Am Tue, 10 Dec 2019 12:01:24 +0100 schrieb Christian Ehrhardt <christian.ehrhardt@canonical.com>:
On Tue, Dec 10, 2019 at 10:46 AM Henning Schild <henning.schild@siemens.com> wrote:
Hi all,
the systemd shutdown scripts work sequentially with a 300s timeout (seen on Debian). If a VM does not have ACPI support, or the ACPI support failed for some reason, you are looking at a 300s timeout per instance for a host shutdown/reboot. i.e. 10 instances without working ACPI = 3000s to shut down
I think the systemd scripting should be parallel instead of sequentially. So if you have many VMs without working ACPI you just have to wait 300s in total for the host to shut down.
Hi Henning, this is configurable in /etc/default/libvirt-guests For example Ubuntu (otherwise using the same bits) changes that to run PARALLEL_SHUTDOWN=10 SHUTDOWN_TIMEOUT=120
Sweet. I went for the PARALLEL_SHUTDOWN=10 and left the 300. Maybe the default PARALLEL_SHUTDOWN value should not be 0 ?
I never got bugs about that config being too aggressive. The change is old and as easy as: https://git.launchpad.net/ubuntu/+source/libvirt/tree/debian/patches/ubuntu/... Maybe you just want to open a bug with Debian to change the default config there as well?
No it is a bug in libvirt having the "wrong" defaults. And a bug in ubuntu not fixing it upstream ;). Thanks, Henning
Steps to reproduce:
- star a VM that does not support ACPI - reboot the host and wait 300s for the VM to be shut down - now start it multiple times - wait multiples of 300s for the shutdown
Expected behaviour: - no matter how many instances do not support ACPI, make it 300s max because we shut them down in parallel
regards, Henning
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Dec 10, 2019 at 12:41 PM Henning Schild <henning.schild@siemens.com> wrote:
Am Tue, 10 Dec 2019 12:01:24 +0100 schrieb Christian Ehrhardt <christian.ehrhardt@canonical.com>:
On Tue, Dec 10, 2019 at 10:46 AM Henning Schild <henning.schild@siemens.com> wrote:
Hi all,
the systemd shutdown scripts work sequentially with a 300s timeout (seen on Debian). If a VM does not have ACPI support, or the ACPI support failed for some reason, you are looking at a 300s timeout per instance for a host shutdown/reboot. i.e. 10 instances without working ACPI = 3000s to shut down
I think the systemd scripting should be parallel instead of sequentially. So if you have many VMs without working ACPI you just have to wait 300s in total for the host to shut down.
Hi Henning, this is configurable in /etc/default/libvirt-guests For example Ubuntu (otherwise using the same bits) changes that to run PARALLEL_SHUTDOWN=10 SHUTDOWN_TIMEOUT=120
Sweet. I went for the PARALLEL_SHUTDOWN=10 and left the 300. Maybe the default PARALLEL_SHUTDOWN value should not be 0 ?
I never got bugs about that config being too aggressive. The change is old and as easy as:
https://git.launchpad.net/ubuntu/+source/libvirt/tree/debian/patches/ubuntu/...
Maybe you just want to open a bug with Debian to change the default config there as well?
No it is a bug in libvirt having the "wrong" defaults. And a bug in ubuntu not fixing it upstream ;).
No it isn't as it was discussed and nacked (years ago)
Thanks, Henning
Steps to reproduce:
- star a VM that does not support ACPI - reboot the host and wait 300s for the VM to be shut down - now start it multiple times - wait multiples of 300s for the shutdown
Expected behaviour: - no matter how many instances do not support ACPI, make it 300s max because we shut them down in parallel
regards, Henning
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
participants (2)
-
Christian Ehrhardt -
Henning Schild