On 03/10/2015 12:19 AM, Dan Kenigsberg wrote:
On Mon, Mar 09, 2015 at 12:17:00PM -0500, Chris Adams wrote:
> Once upon a time, Dan Kenigsberg <danken(a)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
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
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.