Comment 11 for bug 1738834

Hmm, maybe another package of that upgrade pack restarts it which it should not do.

I prepared an upgrade from Xenial to the Cloud Archive versions as initially reported.
This comes down to the critical section being:
The following NEW packages will be installed:
  libvirt-clients libvirt-daemon libvirt-daemon-driver-storage-rbd libvirt-daemon-system
The following packages will be upgraded:
  libvirt-bin libvirt0

Experimenting with that I see similar (but no failure):
Jul 18 11:01:49 x-uca systemd[1]: Started Virtual machine log manager.
Jul 18 11:22:28 x-uca systemd[1]: Reloading Virtual machine log manager.
Jul 18 11:22:28 x-uca systemd[1]: Reloaded Virtual machine log manager.
Jul 18 11:22:29 x-uca systemd[1]: Started Virtual machine log manager.

Splitting this apart with dpkg --force-depends -i instead of apt I found that libvirt-daemon-system triggers a reload (ok as it has the new files).
None of the other packages do (of course in the past when libvirt-bin had the service this would trigger the reload).

That said it reloads just fine, and I'd in fact assume that this is no "extra" restart.
It is triggering the reload and after it is complete it will report "started" having taken over the file descriptors and keeping the PID.
To test that I was just running "systemctl reload virtlogd.service" but that only gave me
  Jul 18 11:54:53 x-uca systemd[1]: Reloading Virtual machine log manager.
  Jul 18 11:54:53 x-uca systemd[1]: Reloaded Virtual machine log manager.

Hmm, running start gives me the start message.
But since this is not a re-start it is safe.
The service retains PID and FD's and actually nothing happens.
 $ systemctl start virtlogd.service
 Log:
   Jul 18 11:55:56 x-uca systemd[1]: Started Virtual machine log manager.

In fact what triggers this is the SYSV compat code.
It still has (for backports and people still insisting to run without systemd) /etc/init.d/virtlogd
If that exists the postinst will call
  $ invoke-rc.d virtlogd start
That is the start action we see as with systemd installed the old calls are mapped to systemd.

But again, it is no REstart so nothing changes.
The question is why the START action in your case fails.

If you just run "systemctl start virtlogd.service":
- does it work or fail as in your upgrade case?
- does it change the PID?
We need to find why the "start" action in your cases fail.