Re: [Users] Joss fails to start ... Keystore was tampered.
Thanks. Unfortunately the keystore is the most important file in the PKI area. Please try to recall your actions, and try to look for the keystore in case you moved / change folders or anything alike. Currently, the only valid solution for a lost keystore is re-installation. On 19/04/12 22:40, snmis...@linux.vnet.ibm.com wrote: Quoting Doron Fediuck dfedi...@redhat.com: Please check again using ls -la on that folder. Yes, I did run ls -la :-) -Sharad Mishra Sent from my Android phone. Please ignore typos. -Original Message- From: snmis...@linux.vnet.ibm.com Received: Thursday, 19 Apr 2012, 20:38 To: Ofer Schreiber [oschr...@redhat.com] CC: users@ovirt.org Subject: Re: [Users] Joss fails to start ... Keystore was tampered. Quoting Ofer Schreiber oschr...@redhat.com: I'm trying to understand few things: 1. Did you used RPM for deployment? No, it was from source. (git clone) 2. Was it an UPGRADE for the engine? yes, I updated the source which was about a month old. 3. Do you have /etc/pki/ovirt-engine/.keystore available? did it changed recently? There is no .keystore in /etc/pki/ovirt-engine. But rest of the files in this directory were modified on 4/17 (certs, keys, private, requests). I was playing with kerberos for ldap on 17th so it is possible that I did something that messed up the server, and it was just coincidental that I upgraded the source next day and ran into this issue. Any help on how I can get out of it? -Sharad Mishra Ofer. - Original Message - I had jboss running on my rhel6.2 machine. This morning I fetched latest engine source, built and deployed it. I did not see any errors. But now when I start jboss-as service I see following errors in engine.log - 2012-04-18 13:57:48,051 INFO [org.ovirt.engine.core.bll.Backend] (MSC service thread 1-5) Start time: 4/18/12 1:57 PM 2012-04-18 13:57:48,204 ERROR [org.ovirt.engine.core.engineencryptutils.EncryptionUtils] (MSC service thread 1-5) Failed to decryptjava.io.IOException: Keystore was tampered with, or password was incorrect 2012-04-18 13:57:48,204 ERROR [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service thread 1-5) Failed to decrypt value for property LocalAdminPassword will be used encrypted value 2012-04-18 13:57:48,209 WARN [org.ovirt.engine.core.utils.ConfigUtilsBase] (MSC service thread 1-5) Could not find enum value for option: NetConsolePort 2012-04-18 13:57:48,212 ERROR [org.ovirt.engine.core.engineencryptutils.EncryptionUtils] (MSC service thread 1-5) Failed to decryptjava.io.IOException: Keystore was tampered with, or password was incorrect 2012-04-18 13:57:48,212 ERROR [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service thread 1-5) Failed to decrypt value for property CertificatePassword will be used encrypted value 2012-04-18 13:57:48,214 ERROR [org.ovirt.engine.core.engineencryptutils.EncryptionUtils] (MSC service thread 1-5) Failed to decryptjava.io.IOException: Keystore was tampered with, or password was incorrect Regards, Sharad Mishra IBM ___ 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 Sent from my Android phone. Please ignore typos. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] fedora qemu modern CPU recognition issues cause ovirt manged host to go non-operational
Seeing an issue wherein ovirt moves a managed host to non-operational state. This occurs with the currently released version of ovirt and the latest development builds. The ovirt host is loaded with Fedora core 16 and equipped with most current development version of the vdsm. *Editorial node* The latest vdsm to work on the FC16 host required building and adding newer versions of the sanlock, libvirt, lvm2 and device-mapper packages than what FC16 provides. Ultimately however none of the newer packages have any bearing on this failure mode. The failure mode is as follows. Upon successfully adding the host and setting the cluster CPU compatibility level oVirt will offline the host with the following message: -- Host ovirtnode moved to Non-Operational state as host does not meet the cluster's minimum CPU level. Missing CPU features : model_Nehalem Under the hood the actual cause of this failure is that qemu is not correctly able to identify the host CPU feature flags. This can be observed by doing: qemu-system-x86_64 -cpu Nehalem,check which fails with: warning: host cpuid _ lacks requested flag 'fpu' [0x0001] warning: host cpuid _ lacks requested flag 'de' [0x0004] and on and on... A simple check of cat /proc/cpuinfo | grep flags flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid Thus the CPU is more than capable of everything being asked of it via the cpudef for Nehalem in /etc/qemu/target-x86_64.conf. This is only an issue on Fedora hosts. RHEL/CentOS/SL hosts work fine. This was recognized as an issue RHEL and fixed there but has not been fixed in Fedora. See: http://wiki.qemu.org/Features/CPUModels#Examples and this: https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=689665 and this related discussion in qemu-devel: http://www.mail-archive.com/qemu-devel@nongnu.org/msg101360.html Thus is appears that the changes were made to the RHEL qemu (eg: cpu type rhel6) AKA the change one needs to make to the ovirt engine database to have ovirt manage a EL based host. Fedora hosts-- psql -U postgres engine -c update vdc_options set option_value='pc-0.14' where option_name='EmulatedMachine' and version='3.0'; EL hosts -- psql -U postgres engine -c update vdc_options set option_value='rhel6.2.0' where option_name='EmulatedMachine' and version='3.0'; Thus at the moment any host loaded with Fedora and manged by oVirt utilizing a Sandy Bridge, Nehalem or Westmere processor will be dead in the water. -DHC ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] high availability via fencing
- Original Message - From: Ian Levesque i...@crystal.harvard.edu To: users@ovirt.org Sent: Friday, April 20, 2012 6:36:16 PM Subject: [Users] high availability via fencing Hello, I'm testing ovirt for potential deployment and one of the metrics for its success relies on the high availability feature. In my research on this feature, I found scattered documentation indicating that fencing is a prerequisite. On my test hardware, I don't have any LOM/IPMI but I see that APC managed PDUs are supported, which I do have. The problem is when I try to configure Power Management to use the apc type, I get this error: Test Failed, Host Status is: unknown. The fence-agent script reported the following error: Failed: You have to enter plug number Please use '-h' for usage ovirt-engine/engine.log tells me: 2012-04-20 11:32:44,595 INFO [org.ovirt.engine.core.bll.FencingExecutor] (http--0.0.0.0-8443-5) Executing Status Power Management command, Proxy Host:heilig, Agent:apc, Target Host:, Management IP:134.174.x.x, User:ovirt, Options:port=22,secure=true,slot=1 2012-04-20 11:32:44,598 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (http--0.0.0.0-8443-5) START, FenceVdsVDSCommand(vdsId = 6de5e3fa-8a33-11e1-b3f9-003048c85226, targetVdsId = 60087c5e-8a3b-11e1-b15d-003048c85226, action = Status, ip = 134.174.x.x, port = , type = apc, user = ovirt, password = **, options = 'port=22,secure=true,slot=1'), log id: 57f86a56 2012-04-20 11:32:44,696 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (http--0.0.0.0-8443-5) FINISH, FenceVdsVDSCommand, return: Test Failed, Host Status is: unknown. The fence-agent script reported the following error: Failed: You have to enter plug number Please use '-h' for usage I've tried to add port=1 to the Options field but that seems to have no effect. Any ideas? Is there any way to configure a dumb power management / fencing configuration for testing? If you still have the problem, can you please put also the vdsm log (look for fenceNode ) Thanks Cheers, Ian ___ 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: [Users] fedora qemu modern CPU recognition issues cause ovirt manged host to go non-operational
Sounds like vdsm should just require a newer version of qemu-kvm as well? Have you tested with a newer qemu-kvm? - Original Message - Seeing an issue wherein ovirt moves a managed host to non-operational state. This occurs with the currently released version of ovirt and the latest development builds. The ovirt host is loaded with Fedora core 16 and equipped with most current development version of the vdsm. *Editorial node* The latest vdsm to work on the FC16 host required building and adding newer versions of the sanlock, libvirt, lvm2 and device-mapper packages than what FC16 provides. Ultimately however none of the newer packages have any bearing on this failure mode. The failure mode is as follows. Upon successfully adding the host and setting the cluster CPU compatibility level oVirt will offline the host with the following message: -- Host ovirtnode moved to Non-Operational state as host does not meet the cluster's minimum CPU level. Missing CPU features : model_Nehalem Under the hood the actual cause of this failure is that qemu is not correctly able to identify the host CPU feature flags. This can be observed by doing: qemu-system-x86_64 -cpu Nehalem,check which fails with: warning: host cpuid _ lacks requested flag 'fpu' [0x0001] warning: host cpuid _ lacks requested flag 'de' [0x0004] and on and on... A simple check of cat /proc/cpuinfo | grep flags flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid Thus the CPU is more than capable of everything being asked of it via the cpudef for Nehalem in /etc/qemu/target-x86_64.conf. This is only an issue on Fedora hosts. RHEL/CentOS/SL hosts work fine. This was recognized as an issue RHEL and fixed there but has not been fixed in Fedora. See: http://wiki.qemu.org/Features/CPUModels#Examples and this: https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=689665 and this related discussion in qemu-devel: http://www.mail-archive.com/qemu-devel@nongnu.org/msg101360.html Thus is appears that the changes were made to the RHEL qemu (eg: cpu type rhel6) AKA the change one needs to make to the ovirt engine database to have ovirt manage a EL based host. Fedora hosts-- psql -U postgres engine -c update vdc_options set option_value='pc-0.14' where option_name='EmulatedMachine' and version='3.0'; EL hosts -- psql -U postgres engine -c update vdc_options set option_value='rhel6.2.0' where option_name='EmulatedMachine' and version='3.0'; Thus at the moment any host loaded with Fedora and manged by oVirt utilizing a Sandy Bridge, Nehalem or Westmere processor will be dead in the water. -DHC ___ 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: [Users] Call for agenda topics -- Weekly Sync 2012-04-24
Some other topic to discuss: 1. Java 7 in oVirt Engine 2. ovirt-engine-jbossas vs. Fedora17-jbossas 3. Moving to Fedora 17 Ofer. - Original Message - Reminder: Meeting moved this week to Tuesday 2012-04-24 due to Israel Independence Day. This mail is a call for topics for the 2012-04-24 Weekly Sync meeting. Standing Agenda Topics: * Status of Next Release * Sub-project reports (engine, vdsm, node) Other topics that need to be covered this week: * Additional Hardware resources for Jenkins use If you have additional topics, please reply to this email with the topic(s) you want to cover. A final planned agenda will be sent out prior to the meeting. Thanks The oVirt Team ___ Board mailing list bo...@ovirt.org http://lists.ovirt.org/mailman/listinfo/board ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] locale en_AU
I just tried to run engine-setup and got the following error. [root@manager ~]# engine-setup Error: current locale (en_AU.UTF-8) is not supported. supported locales are: en_US.UTF-8,en_US.utf-8,en_US.utf8 Please check log file /var/log/ovirt-engine/engine-setup_2012_04_23_09_07_53.log for more information While I can easily change the locale settings on the box, I really think this is a bit of a crazy limitation as almost every other bit of software seems to assume en_AU = en_US as almost no software ends up creating an Australian localization for it. The character set is the same, the keyboards are the same, and I can't see any reason why en_AU (or say en_NZ) would cause a problem. The only differences I can think of are dates (DD/MM/ vs MM/DD/) and the metric system. What would need to be the process to fix this? Is this just because no one has been willing to test or it is a policy? Jason ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] locale en_AU
On 04/23/2012 03:00 AM, Jason Lawer wrote: I just tried to run engine-setup and got the following error. [root@manager ~]# engine-setup Error: current locale (en_AU.UTF-8) is not supported. supported locales are: en_US.UTF-8,en_US.utf-8,en_US.utf8 Please check log file /var/log/ovirt-engine/engine-setup_2012_04_23_09_07_53.log for more information While I can easily change the locale settings on the box, I really think this is a bit of a crazy limitation as almost every other bit of software seems to assume en_AU = en_US as almost no software ends up creating an Australian localization for it. The character set is the same, the keyboards are the same, and I can't see any reason why en_AU (or say en_NZ) would cause a problem. The only differences I can think of are dates (DD/MM/ vs MM/DD/) and the metric system. What would need to be the process to fix this? Is this just because no one has been willing to test or it is a policy? actually, this was blocked due to locale and timezone issues to minimize problems until further testing, but later opened to allow reporting of any such issues. so, I assume you are trying 3.0? as this should have been fixed for 3.1 already: commit 3f9b8085dec28b23f483058e8a416122e7be1a75 Author: Idan Mansano imans...@redhat.com Date: Thu Jan 26 11:26:53 2012 +0200 engine-setup won't validate locale in the system ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] locale en_AU
Yeah, I think I am (3.0 is stable isn't it?) Sorry, I did a search through bugzilla but wasn't able to find anything matching this. As I am a recent member on the list I didn't know about this. Is there somewhere I should look for information on things like this? Jason On 23/04/12 3:08 PM, Itamar Heim wrote: On 04/23/2012 03:00 AM, Jason Lawer wrote: I just tried to run engine-setup and got the following error. [root@manager ~]# engine-setup Error: current locale (en_AU.UTF-8) is not supported. supported locales are: en_US.UTF-8,en_US.utf-8,en_US.utf8 Please check log file /var/log/ovirt-engine/engine-setup_2012_04_23_09_07_53.log for more information While I can easily change the locale settings on the box, I really think this is a bit of a crazy limitation as almost every other bit of software seems to assume en_AU = en_US as almost no software ends up creating an Australian localization for it. The character set is the same, the keyboards are the same, and I can't see any reason why en_AU (or say en_NZ) would cause a problem. The only differences I can think of are dates (DD/MM/ vs MM/DD/) and the metric system. What would need to be the process to fix this? Is this just because no one has been willing to test or it is a policy? actually, this was blocked due to locale and timezone issues to minimize problems until further testing, but later opened to allow reporting of any such issues. so, I assume you are trying 3.0? as this should have been fixed for 3.1 already: commit 3f9b8085dec28b23f483058e8a416122e7be1a75 Author: Idan Mansano imans...@redhat.com Date: Thu Jan 26 11:26:53 2012 +0200 engine-setup won't validate locale in the system ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Call for agenda topics -- Weekly Sync 2012-04-24
On 04/22/2012 05:43 AM, Mike Burns wrote: Reminder: Meeting moved this week to Tuesday 2012-04-24 due to Israel Independence Day. This mail is a call for topics for the 2012-04-24 Weekly Sync meeting. Standing Agenda Topics: * Status of Next Release it seems some of the features which feature pages were sent are actively being worked on - coupled with the move to java 7, jboss rpm's in fedora and fedora 17 - let's discuss the target release date to see how to optimize around these. * Sub-project reports (engine, vdsm, node) Other topics that need to be covered this week: * Additional Hardware resources for Jenkins use If you have additional topics, please reply to this email with the topic(s) you want to cover. A final planned agenda will be sent out prior to the meeting. Thanks The oVirt Team ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] locale en_AU
On 04/23/2012 08:17 AM, Jason Lawer wrote: Yeah, I think I am (3.0 is stable isn't it?) yes, 3.1 still not out. Sorry, I did a search through bugzilla but wasn't able to find anything matching this. As I am a recent member on the list I didn't know about this. Is there somewhere I should look for information on things like this? well, the wiki, google and git log / gerrit patch queue google covers wiki and git/gerrit log: https://www.google.com/search?q=ovirt+locale+check Jason On 23/04/12 3:08 PM, Itamar Heim wrote: On 04/23/2012 03:00 AM, Jason Lawer wrote: I just tried to run engine-setup and got the following error. [root@manager ~]# engine-setup Error: current locale (en_AU.UTF-8) is not supported. supported locales are: en_US.UTF-8,en_US.utf-8,en_US.utf8 Please check log file /var/log/ovirt-engine/engine-setup_2012_04_23_09_07_53.log for more information While I can easily change the locale settings on the box, I really think this is a bit of a crazy limitation as almost every other bit of software seems to assume en_AU = en_US as almost no software ends up creating an Australian localization for it. The character set is the same, the keyboards are the same, and I can't see any reason why en_AU (or say en_NZ) would cause a problem. The only differences I can think of are dates (DD/MM/ vs MM/DD/) and the metric system. What would need to be the process to fix this? Is this just because no one has been willing to test or it is a policy? actually, this was blocked due to locale and timezone issues to minimize problems until further testing, but later opened to allow reporting of any such issues. so, I assume you are trying 3.0? as this should have been fixed for 3.1 already: commit 3f9b8085dec28b23f483058e8a416122e7be1a75 Author: Idan Mansano imans...@redhat.com Date: Thu Jan 26 11:26:53 2012 +0200 engine-setup won't validate locale in the system ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
