<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 23, 2017 at 7:07 PM, Nir Soffer <span dir="ltr"><<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jan 23, 2017 at 3:27 PM, Yaniv Kaul <<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>> wrote:<br>
><br>
><br>
> On Jan 23, 2017 3:20 PM, "Nathanaël Blanchet" <<a href="mailto:blanchet@abes.fr">blanchet@abes.fr</a>> wrote:<br>
><br>
><br>
><br>
> Le 23/01/2017 à 13:08, Yaniv Kaul a écrit :<br>
><br>
><br>
><br>
> On Mon, Jan 23, 2017 at 1:38 PM, Nathanaël Blanchet <<a href="mailto:blanchet@abes.fr">blanchet@abes.fr</a>><br>
> wrote:<br>
>><br>
>> Hi<br>
>><br>
>> The update notifier in the webadmin was originally designed to alert for<br>
>> new vdsm* packages. Now, I noticed that available update of virt packages<br>
>> and more are notified. I know that hot updating qemu-kvm package does break<br>
>> vms that are running on concerned hosts, but what about other one like<br>
>> libvirt-client? I know it is recommended to put in maintenance while<br>
>> updating, but can we update some minor packages without waiting for<br>
>> migration?<br>
><br>
><br>
> Hot-updating any package should not break any running VMs. If it does, it's<br>
> a bug.<br>
<br>
</span>Updating vdsm is not supported when the host is not in maintenance.<br>
<br>
The major issue is sanlock, if it is maintaining a lease on storage, updating<br>
sanlock will cause the host to reboot. Sanlock is not petting the host watchdog<br>
because you killed sanlock during the upgrade, the watchdog will<br>
reboot the host.<br></blockquote><div><br></div><div>Is the sanlock RPM preventing an upgrade (in the pre-upgrade script) if it has a lock?</div><div>Y.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Updating vdms while file based storage domain are mounted is also not<br>
supported, since the local mount path may change between versions, for<br>
example because of fixed bugs. If the local mount path changed, the domain<br>
will not be considered mounted, and some flows may fail.<br>
<span class="HOEnZb"><font color="#888888"><br>
Nir<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> The last time I did a qemu-kvm upgrade, my host became down and the vms on<br>
> it with a question mark and no possibility to interact with them. My only<br>
> solution was to use the "confirm host has rebooted" to fence the vms, and<br>
> then the nightmare began : the high<br>
><br>
><br>
> Was the host indeed rebooted?<br>
><br>
> availaible vms rebooted on an other host while they were still active on the<br>
> first one, so they were up on two hosts at the same time. Their disk began<br>
> to be written by two vms at the same time and I had to fscsk them to make<br>
> them up on the next boot. Some database vms were completely unusabled!<br>
><br>
><br>
> On 4.1 we are going to introduce a feature that will protect against this<br>
> situation, by taking a lock on the storage.<br>
> Y.<br>
><br>
><br>
> So I'm very surprised to hear that it is possible to do hot-updating on<br>
> these kind of upgrade, and I won't do it anymore!<br>
><br>
> I personally agree it's not the best habit to do it nevertheless, and I<br>
> expect users to put hosts to maintenance before performing any upgrade.<br>
><br>
> We cannot tell which update requires maintenance and which doesn't (or for<br>
> that matter - requires a reboot or a service restart) - there's no metadata<br>
> available to do attached to the packages that can tell us that.<br>
> Y.<br>
><br>
>><br>
>><br>
>><br>
>> --<br>
>> Nathanaël Blanchet<br>
>><br>
>> Supervision réseau<br>
>> Pôle Infrastrutures Informatiques<br>
>> 227 avenue Professeur-Jean-Louis-Viala<br>
>> 34193 MONTPELLIER CEDEX 5<br>
>> Tél. 33 (0)4 67 54 84 55<br>
>> Fax 33 (0)4 67 54 84 14<br>
>> <a href="mailto:blanchet@abes.fr">blanchet@abes.fr</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Users mailing list<br>
>> <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
>> <a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
><br>
><br>
><br>
> --<br>
> Nathanaël Blanchet<br>
><br>
> Supervision réseau<br>
> Pôle Infrastrutures Informatiques<br>
> 227 avenue Professeur-Jean-Louis-Viala<br>
> 34193 MONTPELLIER CEDEX 5<br>
> Tél. 33 (0)4 67 54 84 55<br>
> Fax 33 (0)4 67 54 84 14<br>
> <a href="mailto:blanchet@abes.fr">blanchet@abes.fr</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Users mailing list<br>
> <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
> <a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
><br>
</div></div></blockquote></div><br></div></div>