Re: [ovirt-users] ?3.4: VDSM Memory consumption
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Daniel Helgenberger daniel.helgenber...@m-box.de, pklic...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 1:11:42 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption On Mon, Sep 29, 2014 at 09:02:19PM +, Daniel Helgenberger wrote: Hello Francesco, -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv On 29.09.2014, at 22:19, Francesco Romani from...@redhat.com wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Francesco Romani from...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, users@ovirt.org Sent: Monday, September 29, 2014 2:54:13 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Hello Francesco, On 29.09.2014 13:55, Francesco Romani wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Dan Kenigsberg dan...@redhat.com Cc: users@ovirt.org Sent: Monday, September 29, 2014 12:25:22 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Dan, I just reply to the list since I do not want to clutter BZ: While migrating VMs is easy (and the sampling is already running), can someone tell me the correct polling port to block with iptables? Thanks, Hi Daniel, there is indeed a memory profiling patch under discussion: http://gerrit.ovirt.org/#/c/32019/ but for your case we'll need a backport to 3.4.x and clearer install instructions, which I'll prepare as soon as possible. I updated the BZ (and are now blocking 54321/tcp on one of my hosts). and verified it is not reachable. As general info: This system I am using is my LAB / Test / eval setup for a final deployment for ovirt (then 3.5) in production; so it will go away some time in the future (a few weeks / months). If I am the only one experiencing this problem then you might be better of allocating resources elsewhere ;) Thanks for your understanding :) Unfortunately it is true that developer resources aren't so abundant, but it is also true that memleaks should never be discarded easily and without due investigation, considering the nature and the role of VDSM. So, I'm all in for further investigation regarding this issue. As for your question: if I understood correctly what you are asking (still catching up the thread), if you are trying to rule out the stats polling made by Engine to this bad leak, one simple way to test is just to shutdown Engine, and let VDSMs run unguarded on hypervisors. You'll be able to command these VDSMs using vdsClient or restarting Engine. As I said in my BZ comment this is not an option right now, but if understand the matter correctly IPTABLES reject should ultimately do the same? Definitely yes! Just do whatever it is more convenient for you. As you might have already seen in the BZ comment the leak stopped after blocking the port. Though this is clearly no permanent option - please let me know if I can be of any more assistance! The immediate suspect in this situation is M2Crypto. Could you verify that by re-opening the firewall and setting ssl=False in vdsm.conf? You should disable ssl on Engine side and restart both Engine and Vdsm (too bad I do not recall how that's done on Engine: Piotr, can you help?). In vdc_options table there is option EncryptHostCommunication. Please to set it to false and restart the engine. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] numa error after upgrading from 3.5rc2 to 3.5rc3
- Original Message -
From: Gianluca Cecchi gianluca.cec...@gmail.com
To: Martin Sivak msi...@redhat.com
Cc: Dan Kenigsberg dan...@redhat.com, users users@ovirt.org,
mpriv...@redhat.com, Gilad Chaplik
gchap...@redhat.com
Sent: Friday, September 26, 2014 12:11:09 PM
Subject: Re: [ovirt-users] numa error after upgrading from 3.5rc2 to 3.5rc3
On Fri, Sep 26, 2014 at 10:56 AM, Martin Sivak msi...@redhat.com wrote:
Hi,
I think the default was changed to INTERLEAVE, because that is the value I
see everywhere as preselected in the current 3.5 code.
This is the logic that governs if the select boxes are enabled:
if (getModel().getMigrationMode().getSelectedItem() !=
MigrationSupport.PINNED_TO_HOST ||
getModel().getIsAutoAssign().getEntity() ||
getModel().getDefaultHost().getSelectedItem() == null ||
!getModel().getDefaultHost().getSelectedItem().isNumaSupport()) {
enabled = false;
}
So it seems that the following conditions have to be satisfied for the
select boxes to be enabled:
The VM has to be pinned to a NUMA host (check that please, it might allow
you to update the values using UI).
Have the default host set (probably satisfied by the previous condition)
The host has to support NUMA
I am adding Gilad to CC as he knows the code. Unfortunately he will be
available some time next week as they have a holiday season in Israel atm.
The point here is:
If I am on oVirt 3.4.x environment, is this numa_tune_mode parameter
present in the VM definition?
I have not at hand now a 3.4 system so I cannot check.
If not present at all in pre-3.5 VMs and I upgrade my environment, what
would be done for my pre-existing VMs?
Because I verified (not from 3.5rc3 scratch installation but upgrading from
3.5rc2) that for new VMs indeed the parameter is set with interleave as
default.
I don't know if inside the sql upgrade scripts there is something like
if current 3.5 then add parameter and set to interleave
So in this case it would make the correct thing for 3.4 environments, but
as a corner effect it would do nothing for my 3.5.rc2 environment, that
still didn't have the parameter, causing the problem I'm experiencing
you're right, I'm changing default value to interleave.
for now run the query: update vm_static set numatune_mode ='interleave';
Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] ?3.4: VDSM Memory consumption
Hello Piotr, On 30.09.2014 08:37, Piotr Kliczewski wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Daniel Helgenberger daniel.helgenber...@m-box.de, pklic...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 1:11:42 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption On Mon, Sep 29, 2014 at 09:02:19PM +, Daniel Helgenberger wrote: Hello Francesco, -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv On 29.09.2014, at 22:19, Francesco Romani from...@redhat.com wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Francesco Romani from...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, users@ovirt.org Sent: Monday, September 29, 2014 2:54:13 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Hello Francesco, On 29.09.2014 13:55, Francesco Romani wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Dan Kenigsberg dan...@redhat.com Cc: users@ovirt.org Sent: Monday, September 29, 2014 12:25:22 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Dan, I just reply to the list since I do not want to clutter BZ: While migrating VMs is easy (and the sampling is already running), can someone tell me the correct polling port to block with iptables? Thanks, Hi Daniel, there is indeed a memory profiling patch under discussion: http://gerrit.ovirt.org/#/c/32019/ but for your case we'll need a backport to 3.4.x and clearer install instructions, which I'll prepare as soon as possible. I updated the BZ (and are now blocking 54321/tcp on one of my hosts). and verified it is not reachable. As general info: This system I am using is my LAB / Test / eval setup for a final deployment for ovirt (then 3.5) in production; so it will go away some time in the future (a few weeks / months). If I am the only one experiencing this problem then you might be better of allocating resources elsewhere ;) Thanks for your understanding :) Unfortunately it is true that developer resources aren't so abundant, but it is also true that memleaks should never be discarded easily and without due investigation, considering the nature and the role of VDSM. So, I'm all in for further investigation regarding this issue. As for your question: if I understood correctly what you are asking (still catching up the thread), if you are trying to rule out the stats polling made by Engine to this bad leak, one simple way to test is just to shutdown Engine, and let VDSMs run unguarded on hypervisors. You'll be able to command these VDSMs using vdsClient or restarting Engine. As I said in my BZ comment this is not an option right now, but if understand the matter correctly IPTABLES reject should ultimately do the same? Definitely yes! Just do whatever it is more convenient for you. As you might have already seen in the BZ comment the leak stopped after blocking the port. Though this is clearly no permanent option - please let me know if I can be of any more assistance! The immediate suspect in this situation is M2Crypto. Could you verify that by re-opening the firewall and setting ssl=False in vdsm.conf? You should disable ssl on Engine side and restart both Engine and Vdsm (too bad I do not recall how that's done on Engine: Piotr, can you help?). In vdc_options table there is option EncryptHostCommunication. Please confirm the following procedure is correct: 1. Change Postgres table value: # sudo -u postgres psql -U postgres engine -c update vdc_options set option_value = 'false' where option_name = 'EncryptHostCommunication'; engine=# SELECT * from vdc_options where option_name='EncryptHostCommunication'; option_id | option_name| option_value | version ---+--+--+- 335 | EncryptHostCommunication | false| general (1 row) 2. Restart engine 3. On the hosts; grep ssl /etc/vdsm/vdsm.conf #ssl = true ssl = false 4. restart VDSM I assume I have to set 'ssl = false' this on on all hosts? Please to set it to false and restart the engine. -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv Geschäftsführer: Martin Retschitzegger / Michaela Göllner Handeslregister: Amtsgericht Charlottenburg / HRB 112767 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] ?3.4: VDSM Memory consumption
- Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Piotr Kliczewski pklic...@redhat.com, Dan Kenigsberg dan...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 11:50:28 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption Hello Piotr, On 30.09.2014 08:37, Piotr Kliczewski wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Daniel Helgenberger daniel.helgenber...@m-box.de, pklic...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 1:11:42 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption On Mon, Sep 29, 2014 at 09:02:19PM +, Daniel Helgenberger wrote: Hello Francesco, -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv On 29.09.2014, at 22:19, Francesco Romani from...@redhat.com wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Francesco Romani from...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, users@ovirt.org Sent: Monday, September 29, 2014 2:54:13 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Hello Francesco, On 29.09.2014 13:55, Francesco Romani wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Dan Kenigsberg dan...@redhat.com Cc: users@ovirt.org Sent: Monday, September 29, 2014 12:25:22 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Dan, I just reply to the list since I do not want to clutter BZ: While migrating VMs is easy (and the sampling is already running), can someone tell me the correct polling port to block with iptables? Thanks, Hi Daniel, there is indeed a memory profiling patch under discussion: http://gerrit.ovirt.org/#/c/32019/ but for your case we'll need a backport to 3.4.x and clearer install instructions, which I'll prepare as soon as possible. I updated the BZ (and are now blocking 54321/tcp on one of my hosts). and verified it is not reachable. As general info: This system I am using is my LAB / Test / eval setup for a final deployment for ovirt (then 3.5) in production; so it will go away some time in the future (a few weeks / months). If I am the only one experiencing this problem then you might be better of allocating resources elsewhere ;) Thanks for your understanding :) Unfortunately it is true that developer resources aren't so abundant, but it is also true that memleaks should never be discarded easily and without due investigation, considering the nature and the role of VDSM. So, I'm all in for further investigation regarding this issue. As for your question: if I understood correctly what you are asking (still catching up the thread), if you are trying to rule out the stats polling made by Engine to this bad leak, one simple way to test is just to shutdown Engine, and let VDSMs run unguarded on hypervisors. You'll be able to command these VDSMs using vdsClient or restarting Engine. As I said in my BZ comment this is not an option right now, but if understand the matter correctly IPTABLES reject should ultimately do the same? Definitely yes! Just do whatever it is more convenient for you. As you might have already seen in the BZ comment the leak stopped after blocking the port. Though this is clearly no permanent option - please let me know if I can be of any more assistance! The immediate suspect in this situation is M2Crypto. Could you verify that by re-opening the firewall and setting ssl=False in vdsm.conf? You should disable ssl on Engine side and restart both Engine and Vdsm (too bad I do not recall how that's done on Engine: Piotr, can you help?). In vdc_options table there is option EncryptHostCommunication. Please confirm the following procedure is correct: 1. Change Postgres table value: # sudo -u postgres psql -U postgres engine -c update vdc_options set option_value = 'false' where option_name = 'EncryptHostCommunication'; engine=# SELECT * from vdc_options where option_name='EncryptHostCommunication'; option_id | option_name| option_value | version ---+--+--+- 335 | EncryptHostCommunication | false| general (1 row) 2. Restart engine 3. On the hosts; grep ssl /etc/vdsm/vdsm.conf #ssl = true ssl = false 4. restart VDSM I assume I have to set 'ssl = false' this on on all hosts? Please to set it to false and restart the engine. I believe that you need to update a bit more on vdsm side. Please follow [1] section Configure ovirt-engine and vdsm to work in non-secure mode There is wrong name of the option and it should be
Re: [ovirt-users] ?3.4: VDSM Memory consumption
On 30.09.2014 11:57, Piotr Kliczewski wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Piotr Kliczewski pklic...@redhat.com, Dan Kenigsberg dan...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 11:50:28 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption Hello Piotr, On 30.09.2014 08:37, Piotr Kliczewski wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Daniel Helgenberger daniel.helgenber...@m-box.de, pklic...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 1:11:42 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption On Mon, Sep 29, 2014 at 09:02:19PM +, Daniel Helgenberger wrote: Hello Francesco, -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv On 29.09.2014, at 22:19, Francesco Romani from...@redhat.com wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Francesco Romani from...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, users@ovirt.org Sent: Monday, September 29, 2014 2:54:13 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Hello Francesco, On 29.09.2014 13:55, Francesco Romani wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Dan Kenigsberg dan...@redhat.com Cc: users@ovirt.org Sent: Monday, September 29, 2014 12:25:22 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Dan, I just reply to the list since I do not want to clutter BZ: While migrating VMs is easy (and the sampling is already running), can someone tell me the correct polling port to block with iptables? Thanks, Hi Daniel, there is indeed a memory profiling patch under discussion: http://gerrit.ovirt.org/#/c/32019/ but for your case we'll need a backport to 3.4.x and clearer install instructions, which I'll prepare as soon as possible. I updated the BZ (and are now blocking 54321/tcp on one of my hosts). and verified it is not reachable. As general info: This system I am using is my LAB / Test / eval setup for a final deployment for ovirt (then 3.5) in production; so it will go away some time in the future (a few weeks / months). If I am the only one experiencing this problem then you might be better of allocating resources elsewhere ;) Thanks for your understanding :) Unfortunately it is true that developer resources aren't so abundant, but it is also true that memleaks should never be discarded easily and without due investigation, considering the nature and the role of VDSM. So, I'm all in for further investigation regarding this issue. As for your question: if I understood correctly what you are asking (still catching up the thread), if you are trying to rule out the stats polling made by Engine to this bad leak, one simple way to test is just to shutdown Engine, and let VDSMs run unguarded on hypervisors. You'll be able to command these VDSMs using vdsClient or restarting Engine. As I said in my BZ comment this is not an option right now, but if understand the matter correctly IPTABLES reject should ultimately do the same? Definitely yes! Just do whatever it is more convenient for you. As you might have already seen in the BZ comment the leak stopped after blocking the port. Though this is clearly no permanent option - please let me know if I can be of any more assistance! The immediate suspect in this situation is M2Crypto. Could you verify that by re-opening the firewall and setting ssl=False in vdsm.conf? You should disable ssl on Engine side and restart both Engine and Vdsm (too bad I do not recall how that's done on Engine: Piotr, can you help?). In vdc_options table there is option EncryptHostCommunication. Please confirm the following procedure is correct: 1. Change Postgres table value: # sudo -u postgres psql -U postgres engine -c update vdc_options set option_value = 'false' where option_name = 'EncryptHostCommunication'; engine=# SELECT * from vdc_options where option_name='EncryptHostCommunication'; option_id | option_name| option_value | version ---+--+--+- 335 | EncryptHostCommunication | false| general (1 row) 2. Restart engine 3. On the hosts; grep ssl /etc/vdsm/vdsm.conf #ssl = true ssl = false 4. restart VDSM I assume I have to set 'ssl = false' this on on all hosts? Please to set it to false and restart the engine. I believe that you need to update a bit more on vdsm side. Indeed your beliefs were true; I was already running in this error while starting vdsm: vdsm: Running validate_configuration FAILED: conflicting vdsm and libvirt-qemu tls configuration. vdsm.conf with ssl=False
Re: [ovirt-users] ?3.4: VDSM Memory consumption
On 30.09.2014 11:57, Piotr Kliczewski wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Piotr Kliczewski pklic...@redhat.com, Dan Kenigsberg dan...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 11:50:28 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption Hello Piotr, On 30.09.2014 08:37, Piotr Kliczewski wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Daniel Helgenberger daniel.helgenber...@m-box.de, pklic...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 1:11:42 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption On Mon, Sep 29, 2014 at 09:02:19PM +, Daniel Helgenberger wrote: Hello Francesco, -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv On 29.09.2014, at 22:19, Francesco Romani from...@redhat.com wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Francesco Romani from...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, users@ovirt.org Sent: Monday, September 29, 2014 2:54:13 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Hello Francesco, On 29.09.2014 13:55, Francesco Romani wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Dan Kenigsberg dan...@redhat.com Cc: users@ovirt.org Sent: Monday, September 29, 2014 12:25:22 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Dan, I just reply to the list since I do not want to clutter BZ: While migrating VMs is easy (and the sampling is already running), can someone tell me the correct polling port to block with iptables? Thanks, Hi Daniel, there is indeed a memory profiling patch under discussion: http://gerrit.ovirt.org/#/c/32019/ but for your case we'll need a backport to 3.4.x and clearer install instructions, which I'll prepare as soon as possible. I updated the BZ (and are now blocking 54321/tcp on one of my hosts). and verified it is not reachable. As general info: This system I am using is my LAB / Test / eval setup for a final deployment for ovirt (then 3.5) in production; so it will go away some time in the future (a few weeks / months). If I am the only one experiencing this problem then you might be better of allocating resources elsewhere ;) Thanks for your understanding :) Unfortunately it is true that developer resources aren't so abundant, but it is also true that memleaks should never be discarded easily and without due investigation, considering the nature and the role of VDSM. So, I'm all in for further investigation regarding this issue. As for your question: if I understood correctly what you are asking (still catching up the thread), if you are trying to rule out the stats polling made by Engine to this bad leak, one simple way to test is just to shutdown Engine, and let VDSMs run unguarded on hypervisors. You'll be able to command these VDSMs using vdsClient or restarting Engine. As I said in my BZ comment this is not an option right now, but if understand the matter correctly IPTABLES reject should ultimately do the same? Definitely yes! Just do whatever it is more convenient for you. As you might have already seen in the BZ comment the leak stopped after blocking the port. Though this is clearly no permanent option - please let me know if I can be of any more assistance! The immediate suspect in this situation is M2Crypto. Could you verify that by re-opening the firewall and setting ssl=False in vdsm.conf? You should disable ssl on Engine side and restart both Engine and Vdsm (too bad I do not recall how that's done on Engine: Piotr, can you help?). In vdc_options table there is option EncryptHostCommunication. Please confirm the following procedure is correct: 1. Change Postgres table value: # sudo -u postgres psql -U postgres engine -c update vdc_options set option_value = 'false' where option_name = 'EncryptHostCommunication'; engine=# SELECT * from vdc_options where option_name='EncryptHostCommunication'; option_id | option_name| option_value | version ---+--+--+- 335 | EncryptHostCommunication | false| general (1 row) 2. Restart engine 3. On the hosts; grep ssl /etc/vdsm/vdsm.conf #ssl = true ssl = false 4. restart VDSM I assume I have to set 'ssl = false' this on on all hosts? Please to set it to false and restart the engine. I believe that you need to update a bit more on vdsm side. Please follow [1] section Configure ovirt-engine and vdsm to work in non-secure mode There is wrong name of the option and it should be EncryptHostCommunication. [1] http://www.ovirt.org/Developers_All_In_One I
Re: [ovirt-users] Is it possible to add ISCSI over iser?
- Original Message - From: Trey Dockendorf treyd...@gmail.com To: Arman Khalatyan arm2...@gmail.com Cc: users users@ovirt.org Sent: Tuesday, September 30, 2014 5:24:27 AM Subject: Re: [ovirt-users] Is it possible to add ISCSI over iser? Arman, One of my storage domains is iSCSI using iSER. You need the following in vdsm.conf: [irs] iscsi_default_ifaces = iser,default I believe the proper way to set that so it's preserved during node updates is the following # cat /etc/ovirt-host-deploy.conf.d/40-custom-vdsm-config.conf [environment:enforce] VDSM_CONFIG/irs/iscsi_default_ifaces=str:iser,default The filename I believe can be changed, just requires .conf extension Once VDSM is configured to use iser you can add the domain in the GUI using the IPoIB IP address to initiate iSER. ovirtnode01 # iscsiadm -m session iser: [3] 192.168.211.245:3260,1 iqn.2014-04.DOMAIN.vmstore1:ovirt-data_iscsi - Trey On Wed, Sep 24, 2014 at 6:42 AM, Arman Khalatyan arm2...@gmail.com wrote: Hi, I am trying to attach my new storage domain over iser. My server always gets that request is tcp/ip not rdma. Simple work around is login from hosts over iser. Would be good to add a possibility to select the protocol of iscsi:tcp/iser/srp. Thanks, Arman PS for those who was struggling with same trouble: 1) on hosts: add lines in /etc/rdma/rdma.conf # Load iSER module ISER_LOAD=YES 2) service rdma restart (or modprobe ib_iser 3) iscsiadm -m discovery -t st -p 10.10.10.31 -I iser 4) iscsiadm -m node --login 5) check if disks are there iscsiadm -m session -o show lssci [1228:0:0:0] storage IET Controller 0001 - [1228:0:0:1] diskIET VIRTUAL-DISK 0001 /dev/sde lsblk /dev/sde NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sde8:64 0 36.4T 0 disk ââ100090001 (dm-8) 253:80 36.4T 0 mpath ââ18b70b0d--4944--4c73--970d--87a1af353b9f-metadata (dm-9) 253:90 512M 0 lvm ââ18b70b0d--4944--4c73--970d--87a1af353b9f-ids (dm-10) 253:10 0 128M 0 lvm ââ18b70b0d--4944--4c73--970d--87a1af353b9f-leases (dm-11) 253:11 0 2G 0 lvm ââ18b70b0d--4944--4c73--970d--87a1af353b9f-outbox (dm-12) 253:12 0 128M 0 lvm ââ18b70b0d--4944--4c73--970d--87a1af353b9f-inbox (dm-13) 253:13 0 128M 0 lvm ââ18b70b0d--4944--4c73--970d--87a1af353b9f-master (dm-14) 253:14 0 1G 0 lvm Thanks for the info, guys. Does any of you use hosted engine with iSER? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] ovirt-engine admin GUI
Is there a way to configure the pause button to prompt with a confirmation dialog box in the same way that the shutdown button does (Are you sure you want to Shut down the following Virtual Machines?) . VM's with large amounts of memory in use take a while to pause so could be out of action for a while if pause was clicked by mistake. I looked through the engine-config options but couldn't see anything. Thanks, Simon ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] How to increase detail in displayed reports
Hi Grzegorz, You can connect to the history database and use the sql api available history views for querying and generating reports, using the ireport or other reporting tools. You can also refer to the reports jrxml files to see the queries used for each available report. There is documentation for most of the available views at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.3/html/Administration_Guide/sect-Statistics_History_Views.html Note: This is for a older version and might not be fully updated. Best regards, --- Shirly Radco BI Software Engineer Red Hat Israel Ltd. - Original Message - From: Grzegorz Szypa grzegorz.sz...@gmail.com To: users@ovirt.org Sent: Friday, September 19, 2014 5:32:49 PM Subject: [ovirt-users] How to increase detail in displayed reports How to increase detail in displayed reports, for example. Network report? Can Defining your own reports, if yes, how to do it? -- G.Sz. ___ 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
Re: [ovirt-users] ovirt-engine admin GUI
- Original Message - From: Simon Barrett simon.barr...@tradingscreen.com To: users@ovirt.org Sent: Tuesday, September 30, 2014 3:37:37 PM Subject: [ovirt-users] ovirt-engine admin GUI Is there a way to configure the “pause” button to prompt with a confirmation dialog box in the same way that the “shutdown” button does (Are you sure you want to Shut down the following Virtual Machines?) . VM’s with large amounts of memory in use take a while to pause so could be out of action for a while if pause was clicked by mistake. I looked through the engine-config options but couldn’t see anything. Seems like it is not supported in 3.5 , you can open a RFE on oVirt https://bugzilla.redhat.com/enter_bug.cgi?product=oVirt Thanks, Simon ___ 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
Re: [ovirt-users] ovirt-engine admin GUI
- Original Message - From: Eli Mesika emes...@redhat.com To: Simon Barrett simon.barr...@tradingscreen.com Cc: users@ovirt.org Sent: Tuesday, September 30, 2014 5:31:00 PM Subject: Re: [ovirt-users] ovirt-engine admin GUI - Original Message - From: Simon Barrett simon.barr...@tradingscreen.com To: users@ovirt.org Sent: Tuesday, September 30, 2014 3:37:37 PM Subject: [ovirt-users] ovirt-engine admin GUI Is there a way to configure the “pause” button to prompt with a confirmation dialog box in the same way that the “shutdown” button does (Are you sure you want to Shut down the following Virtual Machines?) . VM’s with large amounts of memory in use take a while to pause so could be out of action for a while if pause was clicked by mistake. I looked through the engine-config options but couldn’t see anything. IMHO, I think the word configure is somewhat misleading, hence I would not expect this to be at engine-config, this should probably be pure UI stuff. Seems like it is not supported in 3.5 , you can open a RFE on oVirt https://bugzilla.redhat.com/enter_bug.cgi?product=oVirt +1 Thanks, Simon ___ 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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 status - Go / No Go
Il 29/09/2014 08:34, Sandro Bonazzola ha scritto: Hi, We were supposed to start composing oVirt 3.5.0 GA today 2014-09-29 but we still have 3 blockers. Maintainers: - Please be sure that 3.5 snapshot satisfy release criteria[9] - Please be sure that no pending patches are going to block the release - If any patch must block the GA release please raise the issue as soon as possible. - If any packages need a rebase please raise the issue as soon as possible. - Be aware that packages that doesn't need a rebase must be re-built with final release versioning from the RC3 tag. - Please provide ETA for new blockers for rescheduling an RC4 and a GA release. The bug tracker [1] shows 3 blockers: Bug IDWhiteboard Status Summary 1147085 storage POSTMemory volumes not deleted when removing a vm with snapshots 1146073 sla POSTFailing to Attach a Storage Domain without Disk Profiles to a Data Center 3.5 1127460 storage NEW VM abnormal stop after LV refreshing when using thin provisioning on block storage Today we have: Bug ID Whiteboard Status Summary 1127460 storage POSTVM abnormal stop after LV refreshing when using thin provisioning on block storage 1147971 storage NEW Snapshot locked after successful live storage migration ETA? The following bugs are keyworded as Regression and not marked as blockers[10] Bug IDWhiteboard Status Summary 1142647 gluster NEW supervdsm leaks memory when using glusterfs 1138144 storage NEW Failed to autorecover storage domain after unblocking connection with host 1147085 storage POSTMemory volumes not deleted when removing a vm with snapshots 1118349 storage NEW [vdsm] Creating DataCenter 3.5 using master domain V1 fails with InquireNotSupportedError Feature freeze is now effective, and branch has been created. All new patches must be backported to 3.5 branch too. Features completed are marked in green on Features Status Table [2] There are still 69 bugs [3] targeted to 3.5.0. Excluding node and documentation bugs we still have 46 bugs [4] targeted to 3.5.0. More in detail [5]: WhiteboardNEW ASSIGNEDPOSTTotal docs 13 1 0 14 gluster 4 0 2 6 i18n 0 0 1 1 infra 1 0 0 1 integration 0 0 1 1 node 9 4 0 13 ppc 2 0 4 6 sla 10 0 3 13 storage 2 1 3 6 virt 3 1 4 8 Total 44 7 18 69 Maintainers / Assignee: - Please ensure that completed features are marked in green on Features Status Table [2] - If you find a blocker bug please remember to add it to the tracker [1] - Please fill release notes, the page has been created here [6] - Please review results from Third Test Day on the etherpad [7] and on the mailing lists - Please update the target to 3.5.1 or later for bugs that won't be in 3.5.0: it will ease gathering the blocking bugs for next releases. Community: - You're welcome to join us testing last release candidate or nightly builds and getting involved in oVirt Quality Assurance[8] [1] http://bugzilla.redhat.com/1073943 [2] http://goo.gl/4SuYdE [3] http://red.ht/1pVEk7H [4] http://red.ht/1zT2mSq [5] http://red.ht/1q7SqNL [6] http://www.ovirt.org/OVirt_3.5_Release_Notes [7] http://etherpad.ovirt.org/p/3.5-testday-3 [8] http://www.ovirt.org/OVirt_Quality_Assurance [9] http://www.ovirt.org/OVirt_3.5_release-management#Release_Criteria_.28WIP.29 [10] http://goo.gl/uavikG Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] ovirt-engine admin GUI
Thanks. I submitted this: https://bugzilla.redhat.com/show_bug.cgi?id=1148034 -Original Message- From: Eli Mesika [mailto:emes...@redhat.com] Sent: 30 September 2014 15:31 To: Simon Barrett Cc: users@ovirt.org Subject: Re: [ovirt-users] ovirt-engine admin GUI - Original Message - From: Simon Barrett simon.barr...@tradingscreen.com To: users@ovirt.org Sent: Tuesday, September 30, 2014 3:37:37 PM Subject: [ovirt-users] ovirt-engine admin GUI Is there a way to configure the “pause” button to prompt with a confirmation dialog box in the same way that the “shutdown” button does (Are you sure you want to Shut down the following Virtual Machines?) . VM’s with large amounts of memory in use take a while to pause so could be out of action for a while if pause was clicked by mistake. I looked through the engine-config options but couldn’t see anything. Seems like it is not supported in 3.5 , you can open a RFE on oVirt https://bugzilla.redhat.com/enter_bug.cgi?product=oVirt Thanks, Simon ___ 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
Re: [ovirt-users] ?3.4: VDSM Memory consumption
On Tue, Sep 30, 2014 at 10:23:47AM +, Daniel Helgenberger wrote: On 30.09.2014 11:57, Piotr Kliczewski wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Piotr Kliczewski pklic...@redhat.com, Dan Kenigsberg dan...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 11:50:28 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption Hello Piotr, On 30.09.2014 08:37, Piotr Kliczewski wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Daniel Helgenberger daniel.helgenber...@m-box.de, pklic...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 1:11:42 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption On Mon, Sep 29, 2014 at 09:02:19PM +, Daniel Helgenberger wrote: Hello Francesco, -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv On 29.09.2014, at 22:19, Francesco Romani from...@redhat.com wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Francesco Romani from...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, users@ovirt.org Sent: Monday, September 29, 2014 2:54:13 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Hello Francesco, On 29.09.2014 13:55, Francesco Romani wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Dan Kenigsberg dan...@redhat.com Cc: users@ovirt.org Sent: Monday, September 29, 2014 12:25:22 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Dan, I just reply to the list since I do not want to clutter BZ: While migrating VMs is easy (and the sampling is already running), can someone tell me the correct polling port to block with iptables? Thanks, Hi Daniel, there is indeed a memory profiling patch under discussion: http://gerrit.ovirt.org/#/c/32019/ but for your case we'll need a backport to 3.4.x and clearer install instructions, which I'll prepare as soon as possible. I updated the BZ (and are now blocking 54321/tcp on one of my hosts). and verified it is not reachable. As general info: This system I am using is my LAB / Test / eval setup for a final deployment for ovirt (then 3.5) in production; so it will go away some time in the future (a few weeks / months). If I am the only one experiencing this problem then you might be better of allocating resources elsewhere ;) Thanks for your understanding :) Unfortunately it is true that developer resources aren't so abundant, but it is also true that memleaks should never be discarded easily and without due investigation, considering the nature and the role of VDSM. So, I'm all in for further investigation regarding this issue. As for your question: if I understood correctly what you are asking (still catching up the thread), if you are trying to rule out the stats polling made by Engine to this bad leak, one simple way to test is just to shutdown Engine, and let VDSMs run unguarded on hypervisors. You'll be able to command these VDSMs using vdsClient or restarting Engine. As I said in my BZ comment this is not an option right now, but if understand the matter correctly IPTABLES reject should ultimately do the same? Definitely yes! Just do whatever it is more convenient for you. As you might have already seen in the BZ comment the leak stopped after blocking the port. Though this is clearly no permanent option - please let me know if I can be of any more assistance! The immediate suspect in this situation is M2Crypto. Could you verify that by re-opening the firewall and setting ssl=False in vdsm.conf? You should disable ssl on Engine side and restart both Engine and Vdsm (too bad I do not recall how that's done on Engine: Piotr, can you help?). In vdc_options table there is option EncryptHostCommunication. Please confirm the following procedure is correct: 1. Change Postgres table value: # sudo -u postgres psql -U postgres engine -c update vdc_options set option_value = 'false' where option_name = 'EncryptHostCommunication'; engine=# SELECT * from vdc_options where option_name='EncryptHostCommunication'; option_id | option_name| option_value | version ---+--+--+- 335 | EncryptHostCommunication | false| general (1 row) 2. Restart engine 3. On the hosts; grep ssl /etc/vdsm/vdsm.conf #ssl = true ssl = false 4. restart VDSM I assume I have to set 'ssl = false' this on on all hosts? Please to set it to false and restart the engine. I believe that you need to update a bit more on vdsm side.
Re: [ovirt-users] ?3.4: VDSM Memory consumption
On Tue, Sep 30, 2014 at 10:17:59AM +, Daniel Helgenberger wrote: On 30.09.2014 11:57, Piotr Kliczewski wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Piotr Kliczewski pklic...@redhat.com, Dan Kenigsberg dan...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 11:50:28 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption Hello Piotr, On 30.09.2014 08:37, Piotr Kliczewski wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Daniel Helgenberger daniel.helgenber...@m-box.de, pklic...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 1:11:42 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption On Mon, Sep 29, 2014 at 09:02:19PM +, Daniel Helgenberger wrote: Hello Francesco, -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv On 29.09.2014, at 22:19, Francesco Romani from...@redhat.com wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Francesco Romani from...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, users@ovirt.org Sent: Monday, September 29, 2014 2:54:13 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Hello Francesco, On 29.09.2014 13:55, Francesco Romani wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Dan Kenigsberg dan...@redhat.com Cc: users@ovirt.org Sent: Monday, September 29, 2014 12:25:22 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Dan, I just reply to the list since I do not want to clutter BZ: While migrating VMs is easy (and the sampling is already running), can someone tell me the correct polling port to block with iptables? Thanks, Hi Daniel, there is indeed a memory profiling patch under discussion: http://gerrit.ovirt.org/#/c/32019/ but for your case we'll need a backport to 3.4.x and clearer install instructions, which I'll prepare as soon as possible. I updated the BZ (and are now blocking 54321/tcp on one of my hosts). and verified it is not reachable. As general info: This system I am using is my LAB / Test / eval setup for a final deployment for ovirt (then 3.5) in production; so it will go away some time in the future (a few weeks / months). If I am the only one experiencing this problem then you might be better of allocating resources elsewhere ;) Thanks for your understanding :) Unfortunately it is true that developer resources aren't so abundant, but it is also true that memleaks should never be discarded easily and without due investigation, considering the nature and the role of VDSM. So, I'm all in for further investigation regarding this issue. As for your question: if I understood correctly what you are asking (still catching up the thread), if you are trying to rule out the stats polling made by Engine to this bad leak, one simple way to test is just to shutdown Engine, and let VDSMs run unguarded on hypervisors. You'll be able to command these VDSMs using vdsClient or restarting Engine. As I said in my BZ comment this is not an option right now, but if understand the matter correctly IPTABLES reject should ultimately do the same? Definitely yes! Just do whatever it is more convenient for you. As you might have already seen in the BZ comment the leak stopped after blocking the port. Though this is clearly no permanent option - please let me know if I can be of any more assistance! The immediate suspect in this situation is M2Crypto. Could you verify that by re-opening the firewall and setting ssl=False in vdsm.conf? You should disable ssl on Engine side and restart both Engine and Vdsm (too bad I do not recall how that's done on Engine: Piotr, can you help?). In vdc_options table there is option EncryptHostCommunication. Please confirm the following procedure is correct: 1. Change Postgres table value: # sudo -u postgres psql -U postgres engine -c update vdc_options set option_value = 'false' where option_name = 'EncryptHostCommunication'; engine=# SELECT * from vdc_options where option_name='EncryptHostCommunication'; option_id | option_name| option_value | version ---+--+--+- 335 | EncryptHostCommunication | false| general (1 row) 2. Restart engine 3. On the hosts; grep ssl /etc/vdsm/vdsm.conf #ssl = true ssl = false 4. restart VDSM I assume I have to set 'ssl = false' this on on all hosts? Please to set it to false and restart the engine. I believe that you need to update a bit more on vdsm side.
Re: [ovirt-users] ?3.4: VDSM Memory consumption
Il 30/09/2014 17:03, Dan Kenigsberg ha scritto: On Tue, Sep 30, 2014 at 10:23:47AM +, Daniel Helgenberger wrote: On 30.09.2014 11:57, Piotr Kliczewski wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Piotr Kliczewski pklic...@redhat.com, Dan Kenigsberg dan...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 11:50:28 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption Hello Piotr, On 30.09.2014 08:37, Piotr Kliczewski wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Daniel Helgenberger daniel.helgenber...@m-box.de, pklic...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 1:11:42 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption On Mon, Sep 29, 2014 at 09:02:19PM +, Daniel Helgenberger wrote: Hello Francesco, -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv On 29.09.2014, at 22:19, Francesco Romani from...@redhat.com wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Francesco Romani from...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, users@ovirt.org Sent: Monday, September 29, 2014 2:54:13 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Hello Francesco, On 29.09.2014 13:55, Francesco Romani wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Dan Kenigsberg dan...@redhat.com Cc: users@ovirt.org Sent: Monday, September 29, 2014 12:25:22 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Dan, I just reply to the list since I do not want to clutter BZ: While migrating VMs is easy (and the sampling is already running), can someone tell me the correct polling port to block with iptables? Thanks, Hi Daniel, there is indeed a memory profiling patch under discussion: http://gerrit.ovirt.org/#/c/32019/ but for your case we'll need a backport to 3.4.x and clearer install instructions, which I'll prepare as soon as possible. I updated the BZ (and are now blocking 54321/tcp on one of my hosts). and verified it is not reachable. As general info: This system I am using is my LAB / Test / eval setup for a final deployment for ovirt (then 3.5) in production; so it will go away some time in the future (a few weeks / months). If I am the only one experiencing this problem then you might be better of allocating resources elsewhere ;) Thanks for your understanding :) Unfortunately it is true that developer resources aren't so abundant, but it is also true that memleaks should never be discarded easily and without due investigation, considering the nature and the role of VDSM. So, I'm all in for further investigation regarding this issue. As for your question: if I understood correctly what you are asking (still catching up the thread), if you are trying to rule out the stats polling made by Engine to this bad leak, one simple way to test is just to shutdown Engine, and let VDSMs run unguarded on hypervisors. You'll be able to command these VDSMs using vdsClient or restarting Engine. As I said in my BZ comment this is not an option right now, but if understand the matter correctly IPTABLES reject should ultimately do the same? Definitely yes! Just do whatever it is more convenient for you. As you might have already seen in the BZ comment the leak stopped after blocking the port. Though this is clearly no permanent option - please let me know if I can be of any more assistance! The immediate suspect in this situation is M2Crypto. Could you verify that by re-opening the firewall and setting ssl=False in vdsm.conf? You should disable ssl on Engine side and restart both Engine and Vdsm (too bad I do not recall how that's done on Engine: Piotr, can you help?). In vdc_options table there is option EncryptHostCommunication. Please confirm the following procedure is correct: 1. Change Postgres table value: # sudo -u postgres psql -U postgres engine -c update vdc_options set option_value = 'false' where option_name = 'EncryptHostCommunication'; engine=# SELECT * from vdc_options where option_name='EncryptHostCommunication'; option_id | option_name| option_value | version ---+--+--+- 335 | EncryptHostCommunication | false| general (1 row) 2. Restart engine 3. On the hosts; grep ssl /etc/vdsm/vdsm.conf #ssl = true ssl = false 4. restart VDSM I assume I have to set 'ssl = false' this on on all hosts? Please to set it to false and restart the engine. I believe that you need to update a bit more on vdsm side. Please follow [1] section Configure ovirt-engine and vdsm to work in non-secure mode
Re: [ovirt-users] ?3.4: VDSM Memory consumption
On Di, 2014-09-30 at 16:04 +0100, Dan Kenigsberg wrote: On Tue, Sep 30, 2014 at 10:17:59AM +, Daniel Helgenberger wrote: On 30.09.2014 11:57, Piotr Kliczewski wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Piotr Kliczewski pklic...@redhat.com, Dan Kenigsberg dan...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 11:50:28 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption Hello Piotr, On 30.09.2014 08:37, Piotr Kliczewski wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Daniel Helgenberger daniel.helgenber...@m-box.de, pklic...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 1:11:42 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption On Mon, Sep 29, 2014 at 09:02:19PM +, Daniel Helgenberger wrote: Hello Francesco, -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv On 29.09.2014, at 22:19, Francesco Romani from...@redhat.com wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Francesco Romani from...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, users@ovirt.org Sent: Monday, September 29, 2014 2:54:13 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Hello Francesco, On 29.09.2014 13:55, Francesco Romani wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Dan Kenigsberg dan...@redhat.com Cc: users@ovirt.org Sent: Monday, September 29, 2014 12:25:22 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Dan, I just reply to the list since I do not want to clutter BZ: While migrating VMs is easy (and the sampling is already running), can someone tell me the correct polling port to block with iptables? Thanks, Hi Daniel, there is indeed a memory profiling patch under discussion: http://gerrit.ovirt.org/#/c/32019/ but for your case we'll need a backport to 3.4.x and clearer install instructions, which I'll prepare as soon as possible. I updated the BZ (and are now blocking 54321/tcp on one of my hosts). and verified it is not reachable. As general info: This system I am using is my LAB / Test / eval setup for a final deployment for ovirt (then 3.5) in production; so it will go away some time in the future (a few weeks / months). If I am the only one experiencing this problem then you might be better of allocating resources elsewhere ;) Thanks for your understanding :) Unfortunately it is true that developer resources aren't so abundant, but it is also true that memleaks should never be discarded easily and without due investigation, considering the nature and the role of VDSM. So, I'm all in for further investigation regarding this issue. As for your question: if I understood correctly what you are asking (still catching up the thread), if you are trying to rule out the stats polling made by Engine to this bad leak, one simple way to test is just to shutdown Engine, and let VDSMs run unguarded on hypervisors. You'll be able to command these VDSMs using vdsClient or restarting Engine. As I said in my BZ comment this is not an option right now, but if understand the matter correctly IPTABLES reject should ultimately do the same? Definitely yes! Just do whatever it is more convenient for you. As you might have already seen in the BZ comment the leak stopped after blocking the port. Though this is clearly no permanent option - please let me know if I can be of any more assistance! The immediate suspect in this situation is M2Crypto. Could you verify that by re-opening the firewall and setting ssl=False in vdsm.conf? You should disable ssl on Engine side and restart both Engine and Vdsm (too bad I do not recall how that's done on Engine: Piotr, can you help?). In vdc_options table there is option EncryptHostCommunication. Please confirm the following procedure is correct: 1. Change Postgres table value: # sudo -u postgres psql -U postgres engine -c update vdc_options set option_value = 'false' where option_name = 'EncryptHostCommunication'; engine=# SELECT * from vdc_options where option_name='EncryptHostCommunication'; option_id | option_name| option_value | version ---+--+--+- 335 | EncryptHostCommunication | false| general (1 row) 2. Restart engine 3. On the hosts; grep ssl /etc/vdsm/vdsm.conf #ssl = true
Re: [ovirt-users] ?3.4: VDSM Memory consumption
Hello Sandro, On Di, 2014-09-30 at 17:09 +0200, Sandro Bonazzola wrote: Il 30/09/2014 17:03, Dan Kenigsberg ha scritto: On Tue, Sep 30, 2014 at 10:23:47AM +, Daniel Helgenberger wrote: On 30.09.2014 11:57, Piotr Kliczewski wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Piotr Kliczewski pklic...@redhat.com, Dan Kenigsberg dan...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 11:50:28 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption Hello Piotr, On 30.09.2014 08:37, Piotr Kliczewski wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Daniel Helgenberger daniel.helgenber...@m-box.de, pklic...@redhat.com Cc: Francesco Romani from...@redhat.com, users@ovirt.org Sent: Tuesday, September 30, 2014 1:11:42 AM Subject: Re: [ovirt-users]?3.4: VDSM Memory consumption On Mon, Sep 29, 2014 at 09:02:19PM +, Daniel Helgenberger wrote: Hello Francesco, -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv On 29.09.2014, at 22:19, Francesco Romani from...@redhat.com wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Francesco Romani from...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, users@ovirt.org Sent: Monday, September 29, 2014 2:54:13 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Hello Francesco, On 29.09.2014 13:55, Francesco Romani wrote: - Original Message - From: Daniel Helgenberger daniel.helgenber...@m-box.de To: Dan Kenigsberg dan...@redhat.com Cc: users@ovirt.org Sent: Monday, September 29, 2014 12:25:22 PM Subject: Re: [ovirt-users]3.4: VDSM Memory consumption Dan, I just reply to the list since I do not want to clutter BZ: While migrating VMs is easy (and the sampling is already running), can someone tell me the correct polling port to block with iptables? Thanks, Hi Daniel, there is indeed a memory profiling patch under discussion: http://gerrit.ovirt.org/#/c/32019/ but for your case we'll need a backport to 3.4.x and clearer install instructions, which I'll prepare as soon as possible. I updated the BZ (and are now blocking 54321/tcp on one of my hosts). and verified it is not reachable. As general info: This system I am using is my LAB / Test / eval setup for a final deployment for ovirt (then 3.5) in production; so it will go away some time in the future (a few weeks / months). If I am the only one experiencing this problem then you might be better of allocating resources elsewhere ;) Thanks for your understanding :) Unfortunately it is true that developer resources aren't so abundant, but it is also true that memleaks should never be discarded easily and without due investigation, considering the nature and the role of VDSM. So, I'm all in for further investigation regarding this issue. As for your question: if I understood correctly what you are asking (still catching up the thread), if you are trying to rule out the stats polling made by Engine to this bad leak, one simple way to test is just to shutdown Engine, and let VDSMs run unguarded on hypervisors. You'll be able to command these VDSMs using vdsClient or restarting Engine. As I said in my BZ comment this is not an option right now, but if understand the matter correctly IPTABLES reject should ultimately do the same? Definitely yes! Just do whatever it is more convenient for you. As you might have already seen in the BZ comment the leak stopped after blocking the port. Though this is clearly no permanent option - please let me know if I can be of any more assistance! The immediate suspect in this situation is M2Crypto. Could you verify that by re-opening the firewall and setting ssl=False in vdsm.conf? You should disable ssl on Engine side and restart both Engine and Vdsm (too bad I do not recall how that's done on Engine: Piotr, can you help?). In vdc_options table there is option EncryptHostCommunication. Please confirm the following procedure is correct: 1. Change Postgres table value: # sudo -u postgres psql -U postgres engine -c update vdc_options set option_value = 'false' where option_name = 'EncryptHostCommunication'; engine=# SELECT * from vdc_options where option_name='EncryptHostCommunication'; option_id | option_name| option_value | version ---+--+--+- 335 | EncryptHostCommunication | false| general (1 row) 2. Restart engine 3. On the hosts; grep ssl /etc/vdsm/vdsm.conf #ssl = true ssl = false 4. restart VDSM I assume I have to set 'ssl =
Re: [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 status - Go / No Go
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: Users@ovirt.org, de...@ovirt.org Sent: Tuesday, September 30, 2014 5:46:15 PM Subject: Re: [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 status - Go / No Go Il 29/09/2014 08:34, Sandro Bonazzola ha scritto: Hi, We were supposed to start composing oVirt 3.5.0 GA today 2014-09-29 but we still have 3 blockers. Maintainers: - Please be sure that 3.5 snapshot satisfy release criteria[9] - Please be sure that no pending patches are going to block the release - If any patch must block the GA release please raise the issue as soon as possible. - If any packages need a rebase please raise the issue as soon as possible. - Be aware that packages that doesn't need a rebase must be re-built with final release versioning from the RC3 tag. - Please provide ETA for new blockers for rescheduling an RC4 and a GA release. The bug tracker [1] shows 3 blockers: Bug ID Whiteboard Status Summary 1147085 storage POSTMemory volumes not deleted when removing a vm with snapshots 1146073 sla POSTFailing to Attach a Storage Domain without Disk Profiles to a Data Center 3.5 1127460 storage NEW VM abnormal stop after LV refreshing when using thin provisioning on block storage Today we have: Bug IDWhiteboard Status Summary 1127460 storage POSTVM abnormal stop after LV refreshing when using thin provisioning on block storage Basically this is an issue with systemd, not with ovirt. However we have a workaround that we can consume in the short term. Patch for RHEL7: http://gerrit.ovirt.org/33492 We believe that we can get the real fix for the underlying component for Fedora quickly. If not, we have a patch ready for enabling the workaround on Fedora. Patch for Fedora: http://http://gerrit.ovirt.org/33555 1147971 storage NEW Snapshot locked after successful live storage migration This is an ifra issue, handled by Ravi. ETA? Dan? Nir ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] [New Documentation] oVirt Administrator's Guide (Please Review!)
After several weeks of conversion and updating, I would like to announce the posting of a new page on the oVirt site: the oVirt Administrator's Guide[1]. This guide, adapted to MediaWiki form with the help of Red Hat's Content Services team, should be up to date as of oVirt 3.4. Given the impending release of oVirt 3.5, I invite everyone to take start poking at this documentation once oVirt 3.5 is released and people get familiar with the new release to identify procedures that have changed, and new features that must be added. Please use Bugzilla to assign bugs in this document to me. Up next: an oVirt User's Guide that focuses on the User Portal, followed by a revised Quick Start Guide. Eventually, we hope to have more dedicated resources devoted to oVirt's documentation, and this new set of documents will be a good starting point. [1] http://www.ovirt.org/OVirt_Administration_Guide Peace, Brian -- Brian Proffitt Community Liaison oVirt Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
