1:50 p.m.
On Mon, Jan 23, 2017 at 8:31 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
On Mon, Jan 23, 2017 at 7:07 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
>
> On Mon, Jan 23, 2017 at 3:27 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
> >
> >
> > On Jan 23, 2017 3:20 PM, "Nathanaël Blanchet" <blanchet(a)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(a)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?
Adding David.
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(a)abes.fr
> >>
> >> _______________________________________________
> >> Users mailing list
> >> Users(a)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(a)abes.fr
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >