<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">&lt;<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>&gt;</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 &lt;<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Jan 23, 2017 3:20 PM, &quot;Nathanaël Blanchet&quot; &lt;<a href="mailto:blanchet@abes.fr">blanchet@abes.fr</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Le 23/01/2017 à 13:08, Yaniv Kaul a écrit :<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Jan 23, 2017 at 1:38 PM, Nathanaël Blanchet &lt;<a href="mailto:blanchet@abes.fr">blanchet@abes.fr</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi<br>
&gt;&gt;<br>
&gt;&gt; The update notifier in the webadmin was originally designed to alert for<br>
&gt;&gt; new vdsm* packages. Now, I noticed that available update of virt packages<br>
&gt;&gt; and more are notified. I know that hot updating qemu-kvm package does break<br>
&gt;&gt; vms that are running on concerned hosts, but what about other one like<br>
&gt;&gt; libvirt-client? I know it is recommended to put in maintenance while<br>
&gt;&gt; updating, but can we update some minor packages without waiting for<br>
&gt;&gt; migration?<br>
&gt;<br>
&gt;<br>
&gt; Hot-updating any package should not break any running VMs. If it does, it&#39;s<br>
&gt; 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>
&gt; The last time I did a qemu-kvm upgrade, my host became down and the vms on<br>
&gt; it with a question mark and no possibility to interact with them. My only<br>
&gt; solution was to use the &quot;confirm host has rebooted&quot; to fence the vms, and<br>
&gt; then the nightmare began : the high<br>
&gt;<br>
&gt;<br>
&gt; Was the host indeed rebooted?<br>
&gt;<br>
&gt; availaible vms rebooted on an other host while they were still active on the<br>
&gt; first one, so they were up on two hosts at the same time. Their disk began<br>
&gt; to be written by two vms at the same time and I had to fscsk them to make<br>
&gt; them up on the next boot. Some database vms were completely unusabled!<br>
&gt;<br>
&gt;<br>
&gt; On 4.1 we are going to introduce a feature that will protect against this<br>
&gt; situation, by taking a lock on the storage.<br>
&gt; Y.<br>
&gt;<br>
&gt;<br>
&gt; So I&#39;m very surprised to hear that it is possible to do  hot-updating on<br>
&gt; these kind of upgrade, and I won&#39;t do it anymore!<br>
&gt;<br>
&gt; I personally agree it&#39;s not the best habit to do it nevertheless, and I<br>
&gt; expect users to put hosts to maintenance before performing any upgrade.<br>
&gt;<br>
&gt; We cannot tell which update requires maintenance and which doesn&#39;t (or for<br>
&gt; that matter - requires a reboot or a service restart) - there&#39;s no metadata<br>
&gt; available to do attached to the packages that can tell us that.<br>
&gt; Y.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Nathanaël Blanchet<br>
&gt;&gt;<br>
&gt;&gt; Supervision réseau<br>
&gt;&gt; Pôle Infrastrutures Informatiques<br>
&gt;&gt; 227 avenue Professeur-Jean-Louis-Viala<br>
&gt;&gt; 34193 MONTPELLIER CEDEX 5<br>
&gt;&gt; Tél. 33 (0)4 67 54 84 55<br>
&gt;&gt; Fax  33 (0)4 67 54 84 14<br>
&gt;&gt; <a href="mailto:blanchet@abes.fr">blanchet@abes.fr</a><br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; Users mailing list<br>
&gt;&gt; <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
&gt;&gt; <a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Nathanaël Blanchet<br>
&gt;<br>
&gt; Supervision réseau<br>
&gt; Pôle Infrastrutures Informatiques<br>
&gt; 227 avenue Professeur-Jean-Louis-Viala<br>
&gt; 34193 MONTPELLIER CEDEX 5<br>
&gt; Tél. 33 (0)4 67 54 84 55<br>
&gt; Fax  33 (0)4 67 54 84 14<br>
&gt; <a href="mailto:blanchet@abes.fr">blanchet@abes.fr</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Users mailing list<br>
&gt; <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
&gt;<br>
</div></div></blockquote></div><br></div></div>