Should not stop if there are active clients

Is that considered a generally-ok thing to do? It seems like it
could cause severe problems if the libvirt daemon kept running
while configuration bits might be updated by package upgrade. I'm
obviously open to guidance to the contrary.

Note that you can always directly access the VM - I.e. using
vncviewer or spicy by hand. The VM doesn't actually get stopped,
it's only your virt-manager connection to libvirtd which goes
away.

On 22 August 2013 22:12, Serge Hallyn <email address hidden> wrote:
> Is that considered a generally-ok thing to do? It seems like it
> could cause severe problems if the libvirt daemon kept running
> while configuration bits might be updated by package upgrade. I'm
> obviously open to guidance to the contrary.
>

Some critical daemons that must not loose connections do that.
E.g. openssh doesn't close connections and in postinstall does a
configuration reload.
But openssh upstream allows for such scenarios.

> Note that you can always directly access the VM - I.e. using
> vncviewer or spicy by hand. The VM doesn't actually get stopped,
> it's only your virt-manager connection to libvirtd which goes
> away.
>

Still annoying, for those of us who do use virt-manager =)
(i work mostly on graphical install in the VM, thus directly on the
live-cd before anything is installed, so virt-manager is actually a
very nice way to flip between cds etc.)

If you'd like to file a bug against virt-manager that might be appropriate, but libvirt absolutely should not stay running.

You can connect over vnc/spice and those connections do not go away just bc libvirt stops. So virt-manager should be able to show that it can't show machine details (bc libvit is down) bu tit can still keep up the active graphics connections.

You can however minimise the downtime:

Currently this happens:

prerm libvirt-bin -> stop libvirt
...
upgrade hundreds of packages
...
postinst libvirt-bin -> start libvirt

However using --restart-after-upgrade option should be feasible:
       -R, --restart-after-upgrade
           Do not stop the init script until after the package upgrade has been completed. This is different than the default behavior, which stops the script in the prerm, and starts it again in the
           postinst.

           This can be useful for daemons that should not have a possibly long downtime during upgrade. But you should make sure that the daemon will not get confused by the package being upgraded
           while it's running before using this option.

That way:
prerm libvirt-bin -> old libvirt continious to run
....
postinst libvirt-bin -> stop; start libvirt-bin (restarted into new libvirt)

Thanks, xnox, where should that be specified?

Given it looks like it's using cdbs something like:

DEB_DH_INSTALLINIT_ARGS=--restart-after-upgrade

should work.

This bug was fixed in the package libvirt - 1.2.8-0ubuntu20

---------------
libvirt (1.2.8-0ubuntu20) vivid; urgency=medium

  * debian/rules:
    - use --with-esx (LP: #565771)
    - specify restart-after-upgrade (LP: #1215617)
  * debian/control: add libcurl4-gnutls-dev for esx support
 -- Serge Hallyn <email address hidden> Wed, 21 Jan 2015 13:01:59 -0600