On Mon, Jan 23, 2017 at 7:07 PM, Nir Soffer <[email protected]> wrote:
> On Mon, Jan 23, 2017 at 3:27 PM, Yaniv Kaul <[email protected]> wrote: > > > > > > On Jan 23, 2017 3:20 PM, "Nathanaël Blanchet" <[email protected]> wrote: > > > > > > > > Le 23/01/2017 à 13:08, Yaniv Kaul a écrit : > > > > > > > > On Mon, Jan 23, 2017 at 1:38 PM, Nathanaël Blanchet <[email protected]> > > 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? 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 > >> [email protected] > >> > >> _______________________________________________ > >> Users mailing list > >> [email protected] > >> 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 > > [email protected] > > > > > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/users > > >
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
