On Mon, Mar 09, 2015 at 12:17:00PM -0500, Chris Adams wrote:
Once upon a time, Dan Kenigsberg <danken@redhat.com> said:
I'm afraid that we are yet to find a solution for this issue, which is completly different from the horrible leak of supervdsm < 4.16.7.
Could you corroborate the claim of Bug 1147148 - M2Crypto usage in vdsm leaks memory ? Does the leak disappear once you start using plaintext transport?
So, to confirm, it looks like to do that, the steps would be:
- In the [vars] section of /etc/vdsm/vdsm.conf, set "ssl = false". - Restart the vdsmd service.
Is that all that is needed?
No. You'd have to reconfigure libvirtd to work in plaintext
vdsm-tool congfigure --force
and also set you Engine to work in plaintext (unfortunately, I don't recall how's that done. surely Yaniv does) if the host already managed by the engine you can move it to
On 03/10/2015 12:19 AM, Dan Kenigsberg wrote: maintenance, set directly in vdc_options table by psql client to your db- update to False in vdc_options the value of 'EncryptHostCommunication' 'SSLEnabled' options, then restart ovirt-engine. expect the engine side, run also the changes on host (ssl=False and configure --force as Dan mentions above) and reactivate the host.
Is it safe to restart vdsmd on a node with active VMs?
It's safe in the sense that I have not heard of a single failure to reconnected to already-running VMs in years. However, this is still not recommended for production environment, and particularly not if one of the VMs is defined as highly-available. This can end up with your host being fenced and all your VMs dead.
Dan.
-- Yaniv Bronhaim.