[ovirt-users] packages that can be updated without maintening hosts

[Yaniv Kaul]

On Mon, Jan 23, 2017 at 7:07 PM, Nir Soffer <nsoffer at redhat.com> wrote:

> On Mon, Jan 23, 2017 at 3:27 PM, Yaniv Kaul <ykaul at redhat.com> wrote:
> >
> >
> > On Jan 23, 2017 3:20 PM, "Nathanaël Blanchet" <blanchet at abes.fr> wrote:
> >
> >
> >
> > Le 23/01/2017 à 13:08, Yaniv Kaul a écrit :
> >
> >
> >
> > On Mon, Jan 23, 2017 at 1:38 PM, Nathanaël Blanchet <blanchet at abes.fr>
> > wrote:
> >>
> >> Hi
> >>
> >> The update notifier in the webadmin was originally designed to alert for
> >> new vdsm* packages. Now, I noticed that available update of virt
> packages
> >> and more are notified. I know that hot updating qemu-kvm package does
> break
> >> vms that are running on concerned hosts, but what about other one like
> >> libvirt-client? I know it is recommended to put in maintenance while
> >> updating, but can we update some minor packages without waiting for
> >> migration?
> >
> >
> > Hot-updating any package should not break any running VMs. If it does,
> it's
> > a bug.
>
> Updating vdsm is not supported when the host is not in maintenance.
>
> The major issue is sanlock, if it is maintaining a lease on storage,
> updating
> sanlock will cause the host to reboot. Sanlock is not petting the host
> watchdog
> because you killed sanlock during the upgrade, the watchdog will
> reboot the host.
>

Is the sanlock RPM preventing an upgrade (in the pre-upgrade script) if it
has a lock?
Y.


> Updating vdms while file based storage domain are mounted is also not
> supported, since the local mount path may change between versions, for
> example because of fixed bugs. If the local mount path changed, the domain
> will not be considered mounted, and some flows may fail.
>
> Nir
>
> > The last time I did a qemu-kvm upgrade, my host became down and the vms
> on
> > it with a question mark and no possibility to interact with them. My only
> > solution was to use the "confirm host has rebooted" to fence the vms, and
> > then the nightmare began : the high
> >
> >
> > Was the host indeed rebooted?
> >
> > availaible vms rebooted on an other host while they were still active on
> the
> > first one, so they were up on two hosts at the same time. Their disk
> began
> > to be written by two vms at the same time and I had to fscsk them to make
> > them up on the next boot. Some database vms were completely unusabled!
> >
> >
> > On 4.1 we are going to introduce a feature that will protect against this
> > situation, by taking a lock on the storage.
> > Y.
> >
> >
> > So I'm very surprised to hear that it is possible to do  hot-updating on
> > these kind of upgrade, and I won't do it anymore!
> >
> > I personally agree it's not the best habit to do it nevertheless, and I
> > expect users to put hosts to maintenance before performing any upgrade.
> >
> > We cannot tell which update requires maintenance and which doesn't (or
> for
> > that matter - requires a reboot or a service restart) - there's no
> metadata
> > available to do attached to the packages that can tell us that.
> > Y.
> >
> >>
> >>
> >>
> >> --
> >> Nathanaël Blanchet
> >>
> >> Supervision réseau
> >> Pôle Infrastrutures Informatiques
> >> 227 avenue Professeur-Jean-Louis-Viala
> >> 34193 MONTPELLIER CEDEX 5
> >> Tél. 33 (0)4 67 54 84 55
> >> Fax  33 (0)4 67 54 84 14
> >> blanchet at abes.fr
> >>
> >> _______________________________________________
> >> Users mailing list
> >> Users at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/users
> >
> >
> >
> > --
> > Nathanaël Blanchet
> >
> > Supervision réseau
> > Pôle Infrastrutures Informatiques
> > 227 avenue Professeur-Jean-Louis-Viala
> > 34193 MONTPELLIER CEDEX 5
> > Tél. 33 (0)4 67 54 84 55
> > Fax  33 (0)4 67 54 84 14
> > blanchet at abes.fr
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170123/48005740/attachment.html>