Since the sanlock IPC id have changed between version 2.6 and 2.8 (see bug 1054902) it is required to restart vdsm, libvirt and sanlock daemons when upgrading to version 2.8. According to the current RHEV 3.3 documentation the rhel host should be in maintenance mode when upgrading and the command to issue is: # yum update If the documentation steps are followed correctly and the host is really in maintenance no problem should arise. It is strongly suggested to check that vdsm, libvirt and sanlock daemons are restarted after the yum update command finished (check the pids before and after the command). If a new kernel was installed and for extra-safety rebooting the machine is strongly suggested (already mentioned in the current documentation). Sanlock 2.8 was not enforced in RHEV 3.3 so if the documentation was not followed and the update command used was: # yum update vdsm then the same issue may potentially arise in RHEV 3.4 as well. Anyway following again the documentation will prevent any problem. Note: hypervisors are not affected by this issue.
This is a doc-only bug. Action items: 1. docs team should provide the doc-text as per the flag. 2. QA should verify the procedure in comment 1 works correctly.
After upgrading sanlock from 2.6 to 2.8 using 'yum update' command, I restarted sanlock, libvirtd and vdsmd (while host was in maintenance) and activate the host in RHEVM, it went fine Tested using a RHEL host with: vdsm-4.13.2-0.7.el6ev.x86_64 (RHEV3.3-is33) libvirt-0.10.2-29.el6_5.7.x86_64 Upgraded sanlock from sanlock-2.6-2.el6.x86_64 to sanlock-2.8-1.el6.x86_64
Allon, we need to change the documentation: Restart order is important, need to perform the following: - put host to maintenance in RHEVM - yum update - restart sanlock - restart libvirtd - restart vdsmd - activate the host in RHEVM
Jodi, I've update the suggested doctext as per Elad's comment 5. Please advise if this is doable for 3.4, or if you need any additional information.
Hi Allon The doc text field is for the inclusion of release notes and errata. I've raised a separate bug against the guides component for your request. https://bugzilla.redhat.com/show_bug.cgi?id=1091762 I've fixed it - I went with your suggestion of just changing it to tell customers to restart after updating. Much simpler.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-0504.html