If you’re using nfs mounts (even if they are gluster based), it’s safe to restart vdsmd, you’ll see it change status in ovirt, but your VMs will continue running. If you’re mounting gluster based storage as glusterfs shares directly (not over nfs), there’s another issue that will cause all your VMs to pause and the only way to recover is to stop them and restart them, but that’s going to happen to them anyway when vdsmd runs out of ram and crashes… Best solution is to migrate them yourself in this case, then restart and migrate back. Or live migrate them to NFS mounted storage so when vdsm crashes they don’t lock up, and clean up after you’ve had an opportunity to upgrade or patch.
Upgrade to 3.5.3 or later at your earliest opportunity, the mem leak is resolved there. Sounds like you already found the patch you can apply if upgrading isn’t an option, but it will still require you to restart your vdsms. -Darrell > On Sep 10, 2015, at 1:45 PM, Michael Kleinpaste > <michael.kleinpa...@sharperlending.com> wrote: > > Hi everybody. > > So I ran into that high mem usage thing. The problem I have with patching is > that this is a live system so I can't do it mid day. Can anybody tell me if > it is possible to just restart the vdsm service or does the host have to be > in "maintenance mode" before restarting it? It is using gluster storage, if > that makes a difference as well. > > Thanks, > > -- > Michael Kleinpaste > Senior Systems Administrator > SharperLending, LLC. > www.SharperLending.com <> > michael.kleinpa...@sharperlending.com > (509) 324-1230 Fax: (509) 324-1234 > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
