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

[Nir Soffer]

On Mon, Jan 23, 2017 at 8:31 PM, Yaniv Kaul <ykaul at redhat.com> wrote:
>
>
> 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?

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 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
>> >
>
>