On Mon, Jan 23, 2017 at 3:27 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
>
>
> On Jan 23, 2017 3:20 PM, "Nathanaël Blanchet" <blanchet@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@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.

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@abes.fr
>>
>> _______________________________________________
>> Users mailing list
>> Users@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@abes.fr
>
>
>
> _______________________________________________
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>