IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
These days libvirt is pretty reliable and even remote connections
(not the default for libvirt-guests anyway) either work or fail but are
uncommon to be flaky.
On the other hand users might have disabled the service and while we are
After=libvirtd for ordering we are not Requiring it. Adding that or any
harder dependency might break our ordering. But if people have disabled
libvirt they will do a full retry loop until timeout.
Lets drop the loop to be much faster if a remote is not reachable.
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1854653
This reverts
commit 4e7fc8305a
Author: Michal Prívozník <mprivozn@redhat.com>
Date: Fri Feb 21 12:46:08 2014 +0100
libvirt-guests: Wait for libvirtd to initialize
The race described in that commit no longer exists using systemd as
we now have socket activation. If not using systemd, then it is also
safe if using the libvirtd --daemon flag, since the parent process
won't return to the caller until the child is accepting connections.
Reported-by: Doug Smythies <dsmythies@telus.net>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
If another event in background while running libvirt-guests.sh
completely undefines a guest it will no more be available for proper
reporting of its shutdown.
This appears in the log as:
Failed to determint state of guest: <UUID>. Not tracking it anymore
Shutdown of guest complete
The first message already reports that we are giving up on the guest
(per UUID which is all we have left at that point). To avoid the message
with an empty guest_name in such a case lets check what guest_name
returned and only print a report on valid content.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Dariusz Gadomski <dariusz.gadomski@canonical.com>
The recent fix to libvirt-guests.sh.in works for what it intended to fix
(variable scope) but failed to adapt the loop in check_guests_shutdown
correctly. Due to that it currently might detect all guests as "Failed to
determine state of guest" by bad var content or just assumes they are shut
down by picking up an empty variable.
This commit fixes loop to use the passed value and the call in the loop
to actually use the variable assigned in the iterated.
Fixes: 7e476356 "tools: fix variable scope in in check_guests_shutdown"
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1764668
Reviewed-by: Dariusz Gadomski <dariusz.gadomski@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
libvirt-guests.sh when run with more active guests than requested to
shut down in parallel will run until it times out only shutting down
the first set of guests.
This patch fixes parallel shutdown by fixing a variable scope issue
where check_guests_shutdown unintentionally reset $guests which
prevented further progress.
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1688508
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
While libvirt-guests.sh is running cases can let guest_is_on fail which
causes check_guests_shutdown to print output.
That output shall not spill into the users of function
check_guests_shutdown which is therefore now returning values in a
variable like guest_is_on already did.
Original-Author: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Modified-By: Jorge Niedbalski <niedbalski@ubuntu.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The list_guests function in libvirt-guests uses 'grep -v' to filter
Xen domain0 from a list of guests. If domain0 is the only item in
the list, 'grep -v' returns 1, causing the 'stop' operation to fail
when action is 'suspend'. Improve the filtering by using sed to remove
domain0 from the list of guests.
With newer versions of libvirt Domain-0 is again visible in the list of
running guests but it should not be considered as a guest for shutdown
or suspend.
Signed-off-by Stefan Bader <stefan.bader@canonical.com>
The list file expects all guest UUIDs on the same line as the URI
which the guests run on. This does not happen when the list is
echo'ed in quotes. When stripping the quotes, newlines get transformed
into spaces. Without this, only the first guest on the list is actually
handled.
Based on a fix by Omar Siam <simar@gmx.net>
Bug-Ubuntu: http://bugs.launchpad.net/bugs/1591695
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1191227
Since 0fa15b19 we have this variable SYNC_TIME which allows users to
synchronize time on domain resume. However, despite what documentation
says, it's by default on because it's never initialized. Fix this by
setting it to zero at the beginning of the libvirt-guests script.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Well, imagine domains were running, and as the host went down, they
were managesaved. Later, after some time, the host went up again and
domains got restored. But without correct time. And depending on how
long was the host shut off, it may take some time for ntp to sync the
time too. But hey, wait a minute. We have an API just for that! So:
1) Introduce SYNC_TIME variable in libvirt-guests.sysconf to allow
users control over the new functionality
2) Call 'virsh domtime --sync $dom' in the libvirt-guests script.
Unfortunately, this is all-or-nothing approach (just like anything
else with the script). Domains are required to have configured and
running qemu-ga inside.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
I've noticed that in some cases systemd was quick enough and even
if libvirt-guests.service is marked to be started after the
libvirtd.service my guests were not resumed as
libvirt-guests.sh failed to connect. This is because of a
simple fact: systemd correctly starts libvirt-guests after it
execs libvirtd. However, the daemon is not able to accept
connections right from the start. It's doing some
initialization which may take ages. This problem is not limited
to systemd only, indeed. Any init system that is able to startup
services in parallel (e.g. OpenRC) may run into this situation.
The fix is to try connecting not only once, but continuously a few
times with a small sleep in between tries.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Right now, libvirt-guests gives awkward output. It's possible to
force faster failure by setting /etc/sysconfig/libvirt-guests to use:
ON_SHUTDOWN=shutdown
PARALLEL_SHUTDOWN=0
SHUTDOWN_TIMEOUT=1
ON_BOOT=ignore
at which point, we see:
$ service libvirt-guests restart
Running guests on default URI: a, b, d, c
Shutting down guests on default URI...
Starting shutdown on guest: a
Shutdown of guest a failed to complete in time.Starting shutdown on guest: b
Shutdown of guest b failed to complete in time.Starting shutdown on guest: d
Shutdown of guest d failed to complete in time.Starting shutdown on guest: c
Shutdown of guest c failed to complete in time.libvirt-guests is configured not to start any guests on boot
* tools/libvirt-guests.sh.in (shutdown_guest): Add missing newline.
Reported by Xuesong Zhang.
Most of this deals with moving the libvirt-guests.sh script which
does all the work to /usr/libexec, so it can be shared by both
systemd and traditional init. Previously systemd depended on
the script being in /etc/init.d
Required to fix https://bugzilla.redhat.com/show_bug.cgi?id=789747
