[ovirt-users] Re: CEPH - Opinions and ROI
On 2020-10-01 04:33, Jeremey Wise wrote: > > I have for many years used gluster because..well. 3 nodes.. and so > long as I can pull a drive out.. I can get my data.. and with three > copies.. I have much higher chance of getting it. > > Downsides to gluster: Slower (its my home..meh... and I have SSD to > avoid MTBF issues ) and with VDO.. and thin provisioning.. not had issue. > > BUT gluster seems to be falling out of favor. Especially as I > move towards OCP. > > So.. CEPH. I have one SSD in each of the three servers. so I have > some space to play. > > I googled around.. and find no clean deployment notes and guides on > CEPH + oVirt. > Greetings, First, the legalese...the below is all personal view/experiences...I am not speaking on my employers behalf on any of it, I just happen to have most of the experience from my work for them...yadda yadda yadda...blah blah blah...and so on and so forth. This is all just me and my thoughts/opinions. :-D *sigh* It sucks we are in a world where that garbage has to be said when talking about work-related experiencesAnyway... We've been running CephFS since Firefly in 2014. Yeah, I know. We were crazy, but the risk of data loss vs speed was within threshold of what we were trying to do. Fast-forward six years and we've got two CephFS clusters as primary storage for High Performance Clusters where we very much care about performance AND the risk of data loss. We've also got two deployments of oVirt with CephFS as the filesystem. In other words, I've got some experience with this setup and we are /very/ happy with it. :-) I'm so happy with it, that it is easier/faster for me to list the bad than to list the good. 1. Red Hat (our OS to satisfy the "enterprise" check-box for the audit-heads) and I have gone round and round multiple times over the years. In short, don't expect excellent support out of oVirt for Ceph. Want to use Ceph via iSCSI or Cinder? Whooo boy do I have some horror stories for you! One of the many reasons we prefer CephFS. But say that to them and you get blank looks until they've escalated the ticket sufficiently high up the chain, and even then it's not reassuring... However, if you pass CephFS to oVirt as NFS it works...but you don't get the high-availability nor high-performance aspect of scaling your metadata nodes when coming from oVirt. You _SHOULD_ scale your metadata nodes (as with everything in Ceph, scaling in three's is best), but oVirt won't let you mount "cephmds01,cephmds02,cephmds03". It will gladly tell you that it works, but the moment you start a VM on it oVirt freaks out and it has since I reported it years ago (I recently confirmed this again on 4.4 with CentOS8). But if you just mount "cephmds01" and then hack around on your IP routes in your switch to handle the distribution of the data, it's fine. Honestly, even if you just mount a single host and you /know/ that and you _plan_ upgrades/fails/ect around that, it's still fine. It just really sucks that RH pushes Ceph and claims it's a valued FS, but then doesn't really support anything but their cloud variations of Ceph and if you step out of their very narrow definitions you get a *shrug*. Sigh...anyway...digressing from that as this isn't the time/place for my rants. :-D Point being, if you are going RH don't expect to use any of their helper scripts or minimal install builds or anything like that. Minimal OS install, add CephFS drivers, then install oVirt (or...I forget what they call it..) and configure Ceph like you would NFS. Should be fine afterwards. But I've rarely found significant differences between the community version of oVirt and the RH version (when comparing same/similar versions) including the support for Ceph. 2. We get incredible performance out of Ceph, but it does require tuning. Ceph crushes the pre-packaged vendors we ran tests against. But part of the reason is because it is flexible enough that we can swap out the bits that we need to scale - and we can do that FAR cheaper than the pre-packaged solutions allow. Yes, in three's for the servers. Three metadata's, three monitors (we double those two services on the same servers), and storage in blocks of three. If your SSD's are fast enough, 1 SSD per every two spinning disks is a great ratio. And rebuild times across the cluster are only as fast as your back-plane so you should have a dedicated back-plane network in addition to your primary network. Everyone wants their primary network fast, but your backplane should be equally fast if not faster (and no, don't add just one "fast" network - it should be two). So you are going to need to plan and tweak your install. Just throwing parts at Ceph and expecting it to work will get you mixed results at best. 3. I'd never run it at my home. My home oVirt system mounts NFS to a ZFS filesystem. Nothing fancy either. Stripped mirrors ensure good read/write speed with good fault tolerance. I threw two cheap SSD's as a log drive and a
[ovirt-users] Re: LDAP setup fails on 4.4 reading PEM file
On 2020-06-11 20:55, Stack Korora wrote: > Well made one discovery. While named with an 's' in EL7, in EL8 that 's' > is missing. ovirt-engine-extensions-aaa-ldap is now > ovirt-engine-extension-aaa-ldap. > > However, even after fixing that in the properties it still gives the > same error message (just missing the 's' now). I do have the packages > installed and I do have > /usr/share/java/ovirt-engine-extension-aaa-ldap/ovirt-engine-extension-aaa-ldap.jar > (and the symlinks that point there). Still throws errors. :-( I finally cracked it. There's a bunch of small minor changes that don't allow for the config file from 4.3 to work with 4.4. Things like dropping the 's' or exchanging the '-' for '.'. Also had a heck of a time with the ugly verbosity of the output from ovirt-engine-extension-aaa-ldap tool. Not nearly as clean as it was under 4.3. But, as I said, I cracked the issue and I've got it working. Thanks to all on the list. I found a lot of good info in searching the archive. Thanks! ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/7AMQAQKPUQGI3MDGQV5KT3CN3HOBJKZZ/
[ovirt-users] Re: LDAP setup fails on 4.4 reading PEM file
On 2020-06-11 20:32, Stack Korora wrote: > [snip] >> Since I wasn't getting anywhere with this, I decided to try a few >> things. I copied the following files from a working 4.3 on RHEL 7 >> (again, this setup is CentOS8 with 4.4): >> /etc/ovirt-engine/aaa/ldap.jks >> /etc/ovirt-engine/aaa/ldap.properties >> /etc/ovirt-engine/extensions.d/ldap-authn.properties >> /etc/ovirt-engine/extensions.d/ldap-authz.properties >> >> I verified permissions were all good (including SELinux). I restarted a >> few services but wasn't getting anything at all of value telling me what >> was wrong...so I rebooted. That did the trick! Now I get an error, >> though nothing of use is turning up from the internet searches. >> >> # ovirt-engine-extensions-tool info list-extensions >> [snip] >> SEVERE: Extension 'ldap-authn.properties' load failed (ignored): Error >> loading 'ldap-authn': The module 'org.ovirt.engine-extensions.aaa.ldap' >> cannot be loaded: org.ovirt.engine-extensions.aaa.ldap >> SEVERE: Extension 'ldap-authn.properties' load failed (ignored): Error >> loading 'ldap-authz': The module 'org.ovirt.engine-extensions.aaa.ldap' >> cannot be loaded: org.ovirt.engine-extensions.aaa.ldap >> [snip] >> >> I do have these packages installed: >> ovirt-engine-extensions-aaa-ldap >> ovirt-engine-extensions-aaa-ldap-setup Well made one discovery. While named with an 's' in EL7, in EL8 that 's' is missing. ovirt-engine-extensions-aaa-ldap is now ovirt-engine-extension-aaa-ldap. However, even after fixing that in the properties it still gives the same error message (just missing the 's' now). I do have the packages installed and I do have /usr/share/java/ovirt-engine-extension-aaa-ldap/ovirt-engine-extension-aaa-ldap.jar (and the symlinks that point there). Still throws errors. :-( Thoughts? Thanks! ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/HUVCIP4KVLMPI3GBGVZTMFUNHRMHRSBW/
[ovirt-users] Re: LDAP setup fails on 4.4 reading PEM file
Bottom posted update:
On 2020-06-11 17:35, Stack Korora wrote:
> Greetings,
> I'm having some issues getting LDAP working on CentOS 8 with oVirt 4.4.
> I would appreciate some help please.
>
> When I run ovirt-engine-extension-aaa-ldap-setup I choose "11 - RFC-2307
> Schema (Generic)" because that's what my LDAP guy said I should do. :-)
>
> Next I select the default Yes for "Use DNS".
>
> I select 4 for "Failover between multiple hosts".
>
> I put in my two hosts "svr1.my.domain srv2.my.domain".
>
> To select the protocol I type "ldaps".
>
> To select the method to obtain the PEM I type "File".
>
> Then the "File path". A full path to the file. Not quoted. Yes, I
> checked that I typed it correct. I can copy-paste into "ls" and it's
> fine with the correct read permissions and everything. (I can't copy
> paste into the script but that's another issue.)
>
> It immediately fails with:
> [ ERROR ] Failed to execute stage 'Environment customization': a
> byte-like object is required, not 'str'
>
> There is a log file, here is the snippet at the point it goes wrong.
>
> 2020-06-11 11:35:49,915-0500 DEBUG otopi.plugins.otopi.dialog.human
> dialog.__logString:204 DIALOG:SEND File path:
> 2020-06-11 11:36:24,373-0500 DEBUG otopi.plugins.otopi.dialog.human
> dialog.__logString:204 DIALOG:RECEIVE
> /etc/pki/ca-trust/source/anchors/Infrastructure.pem
> 2020-06-11 11:36:24,375-0500 DEBUG otopi.context
> context._executeMethod:145 method exception
> Traceback (most recent call last):
> File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132, in
> _executeMethod
> method['method']()
> File
> "/usr/share/ovirt-engine-extension-aaa-ldap/setup/bin/../plugins/ovirt-engine-extension-aaa-ldap/ldap/common.py",
> line 781, in _customization_late
> cacert, cacertfile, insecure = self._getCACert()
> File
> "/usr/share/ovirt-engine-extension-aaa-ldap/setup/bin/../plugins/ovirt-engine-extension-aaa-ldap/ldap/common.py",
> line 357, in _getCACert
> _cacertfile.write('\n'.join(cacert) + '\n')
> File "/usr/lib64/python3.6/tempfile.py", line 485, in func_wrapper
> return func(*args, **kwargs)
> TypeError: a bytes-like object is required, not 'str'
> 2020-06-11 11:36:24,376-0500 ERROR otopi.context
> context._executeMethod:154 Failed to execute stage 'Environment
> customization': a bytes-like object is required, not 'str'
> 2020-06-11 11:36:24,376-0500 DEBUG otopi.context
> context.dumpEnvironment:765 ENVIRONMENT DUMP - BEGIN
> 2020-06-11 11:36:24,376-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV BASE/error=bool:'True'
> 2020-06-11 11:36:24,376-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV BASE/exceptionInfo=list:'[( 'TypeError'>, TypeError("a bytes-like object is required, not 'str'",),
> )]'
> 2020-06-11 11:36:24,377-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/hosts=str:'svr1.my.domain
> srv2.my.domain'
> 2020-06-11 11:36:24,377-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/protocol=str:'ldaps'
> 2020-06-11 11:36:24,377-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/serverset=str:'failover'
> 2020-06-11 11:36:24,377-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/useDNS=bool:'True'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV
> QUESTION/1/OVAAALDAP_LDAP_CACERT_FILE=str:'/etc/pki/ca-trust/source/anchors/Infrastructure.pem'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV
> QUESTION/1/OVAAALDAP_LDAP_CACERT_METHOD=str:'file'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV
> QUESTION/1/OVAAALDAP_LDAP_PROTOCOL=str:'ldaps'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV QUESTION/1/OVAAALDAP_LDAP_SERVERSET=str:'4'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV QUESTION/1/OVAAALDAP_LDAP_USE_DNS=str:'yes'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV
> QUESTION/2/OVAAALDAP_LDAP_SERVERSET=str:'svr1.my.domain srv2.my.domain'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:779 ENVIRONMENT DUMP - END
>
Since I wasn't getting anywhere with this, I decided to try a few
things. I copied the following files from a working 4.3 on RHEL 7
(again, this setup is CentOS8 with 4.4):
/etc/ovirt-engine/aaa/ldap.jks
/etc/ovirt-engine/aaa/ldap.properties
/etc/ovirt-engine/extensions.d/ldap-authn.properties
/etc/ovirt-engin
[ovirt-users] LDAP setup fails on 4.4 reading PEM file
Greetings,
I'm having some issues getting LDAP working on CentOS 8 with oVirt 4.4.
I would appreciate some help please.
When I run ovirt-engine-extension-aaa-ldap-setup I choose "11 - RFC-2307
Schema (Generic)" because that's what my LDAP guy said I should do. :-)
Next I select the default Yes for "Use DNS".
I select 4 for "Failover between multiple hosts".
I put in my two hosts "svr1.my.domain srv2.my.domain".
To select the protocol I type "ldaps".
To select the method to obtain the PEM I type "File".
Then the "File path". A full path to the file. Not quoted. Yes, I
checked that I typed it correct. I can copy-paste into "ls" and it's
fine with the correct read permissions and everything. (I can't copy
paste into the script but that's another issue.)
It immediately fails with:
[ ERROR ] Failed to execute stage 'Environment customization': a
byte-like object is required, not 'str'
There is a log file, here is the snippet at the point it goes wrong.
2020-06-11 11:35:49,915-0500 DEBUG otopi.plugins.otopi.dialog.human
dialog.__logString:204 DIALOG:SEND File path:
2020-06-11 11:36:24,373-0500 DEBUG otopi.plugins.otopi.dialog.human
dialog.__logString:204 DIALOG:RECEIVE
/etc/pki/ca-trust/source/anchors/Infrastructure.pem
2020-06-11 11:36:24,375-0500 DEBUG otopi.context
context._executeMethod:145 method exception
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132, in
_executeMethod
method['method']()
File
"/usr/share/ovirt-engine-extension-aaa-ldap/setup/bin/../plugins/ovirt-engine-extension-aaa-ldap/ldap/common.py",
line 781, in _customization_late
cacert, cacertfile, insecure = self._getCACert()
File
"/usr/share/ovirt-engine-extension-aaa-ldap/setup/bin/../plugins/ovirt-engine-extension-aaa-ldap/ldap/common.py",
line 357, in _getCACert
_cacertfile.write('\n'.join(cacert) + '\n')
File "/usr/lib64/python3.6/tempfile.py", line 485, in func_wrapper
return func(*args, **kwargs)
TypeError: a bytes-like object is required, not 'str'
2020-06-11 11:36:24,376-0500 ERROR otopi.context
context._executeMethod:154 Failed to execute stage 'Environment
customization': a bytes-like object is required, not 'str'
2020-06-11 11:36:24,376-0500 DEBUG otopi.context
context.dumpEnvironment:765 ENVIRONMENT DUMP - BEGIN
2020-06-11 11:36:24,376-0500 DEBUG otopi.context
context.dumpEnvironment:775 ENV BASE/error=bool:'True'
2020-06-11 11:36:24,376-0500 DEBUG otopi.context
context.dumpEnvironment:775 ENV BASE/exceptionInfo=list:'[(, TypeError("a bytes-like object is required, not 'str'",),
)]'
2020-06-11 11:36:24,377-0500 DEBUG otopi.context
context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/hosts=str:'svr1.my.domain
srv2.my.domain'
2020-06-11 11:36:24,377-0500 DEBUG otopi.context
context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/protocol=str:'ldaps'
2020-06-11 11:36:24,377-0500 DEBUG otopi.context
context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/serverset=str:'failover'
2020-06-11 11:36:24,377-0500 DEBUG otopi.context
context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/useDNS=bool:'True'
2020-06-11 11:36:24,378-0500 DEBUG otopi.context
context.dumpEnvironment:775 ENV
QUESTION/1/OVAAALDAP_LDAP_CACERT_FILE=str:'/etc/pki/ca-trust/source/anchors/Infrastructure.pem'
2020-06-11 11:36:24,378-0500 DEBUG otopi.context
context.dumpEnvironment:775 ENV
QUESTION/1/OVAAALDAP_LDAP_CACERT_METHOD=str:'file'
2020-06-11 11:36:24,378-0500 DEBUG otopi.context
context.dumpEnvironment:775 ENV
QUESTION/1/OVAAALDAP_LDAP_PROTOCOL=str:'ldaps'
2020-06-11 11:36:24,378-0500 DEBUG otopi.context
context.dumpEnvironment:775 ENV QUESTION/1/OVAAALDAP_LDAP_SERVERSET=str:'4'
2020-06-11 11:36:24,378-0500 DEBUG otopi.context
context.dumpEnvironment:775 ENV QUESTION/1/OVAAALDAP_LDAP_USE_DNS=str:'yes'
2020-06-11 11:36:24,378-0500 DEBUG otopi.context
context.dumpEnvironment:775 ENV
QUESTION/2/OVAAALDAP_LDAP_SERVERSET=str:'svr1.my.domain srv2.my.domain'
2020-06-11 11:36:24,378-0500 DEBUG otopi.context
context.dumpEnvironment:779 ENVIRONMENT DUMP - END
Can someone help please?
Thanks!
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MHBAPSJOFLAWFMBT4HPJAZUYB3ODL7BX/
[ovirt-users] Re: PKIX path error
On 2020-06-02 06:16, Martin Perina wrote: > Hi, > > could you please restart ovirt-engine service and share server.log and > engine.log from /var/log/ovirt-engine ? Greetings Martin, Thank you for the response. Sorry it took a while, I had a family issue come up and had to road-trip 10hours away for a few days. An update on the status, we were also struggling with an unrelated hardware problem. The new NVMe drives were giving my coworkers and myself issues on 7. My coworker tried CentOS8 just to see what happened, and it worked flawlessly. So we _just_ rebuilt the whole thing: CentOS8 + oVirt 4.4. We figured we might as well attempt to future-proof this install a little bit while it is still in the "build" stage. :-) One of my goals today is to get SSL and LDAP working on the fresh install. If I have issues, I will post back. Thank you again! ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/3X2KFSZBY337N56T2YBWSHA7YDG3UXKU/
[ovirt-users] Re: Mixing OS versions
On 2020-06-01 16:31, Sandro Bonazzola wrote: > > > Il giorno lun 1 giu 2020 alle ore 17:52 Stack Korora > mailto:stackkor...@disroot.org>> ha scritto: > > Greetings, > We've been using Scientific Linux 7 quite successfully with oVirt for > years now. However, since there will not be a SL8 we are transitioning > new servers to CentOS8. I would like to add a new oVirt hypervisor > node. > > How bad of an idea is it to have a 8 system when the rest are 7 even > though the version of oVirt will be the same? > > > Please note the oVirt version can't be the same on el7 and el8 because > hosts on el8 are supported only by oVirt 4.4 and oVirt 4.4 is not > available on el7. > You can upgrade the engine to 4.4 and then add el8 hosts while still > keeping el7 hosts until you finish the upgrade. Thank you for the clarification! I appreciate it. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KIXLZWRJDRKAND2AZSQZYW6TYB2CUHXZ/
[ovirt-users] Mixing OS versions
Greetings, We've been using Scientific Linux 7 quite successfully with oVirt for years now. However, since there will not be a SL7 we are transitioning new servers to CentOS8. I would like to add a new oVirt hypervisor node. How bad of an idea is it to have a 8 system when the rest are 7 even though the version of oVirt will be the same? Thanks! ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KH5JK3CVNVTNUHRII2KO2VM6LAUHOBTJ/
[ovirt-users] Re: PKIX path error
On 2020-05-29 07:03, Strahil Nikolov via Users wrote: > You mentioned that your certificates were different. Did you try converting > them to the type used in the example ? Yeah. So I will walk through the steps. Since I don't have a p12 format, the directions say "proceed to Replacing the Red Hat Virtualization Manager Apache SSL Certificate". Well, that isn't right. :-) Instead I skipped to "Replacing the oVirt Engine Apache SSL Certificate" I converted mine to PEM and did step #1 and I included not just my cert but the full chain. No issues there. I replaced the PEM per #2 and #3. Then backed up per #4. Step #5 & #6 require steps from the first section I skipped above. So I did those. If I do those steps exactly, I will get SSL errors about untrusted cert. However, if I add (>> vs >) to the original (which I backed up) then all the SSL errors go away. That was with apache.key.nopass and apache.cer. The rest of the steps I followed exactly. Not sure if that helps point out what I did wrong. Thanks for replying! ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/5G27DGSCSFUJSQ7233WQ4ETH4EM32GLA/
[ovirt-users] Re: PKIX path error
On 2020-05-29 08:08, Martin Perina wrote: > Hi Stack, > > if I understand correctly your custom SSL certificates are working > correctly and you are able to login to webadmin using admin@internal, > right? Correct. > If the problem is, that your aaa-ldap profile is not visible in the > login dialog, then there is some issue with aaa-ldap configuration. > You have mentioned that you used ovirt-engine-extension-aaa-ldap-setup > tool to create you aaa-ldap profile, have you executed login and > search operation at the end of setup tool? If so, were they successful? I did and yes they were. > > Anyway right you can use following command to debug your aaa > extensions setup: > > # ovirt-engine-extensions-tool info list-extensions > > Using above command, could you see authn and authz instance of your > aaa-ldap profile? I do see both authz and authn. > If so, please try below tests: > > 1. Checking is user search is working: > > # ovirt-engine-extensions-tool aaa search --extension-name= PROFILE AUTHZ NAME> --entity-name= It does work and it returns valid information. > 2. Checking if login is working > > # ovirt-engine-extensions-tool aaa login-user --profile= NAME> --user-name= > A result=SUCCESS on that too! However, I still don't see a second profile option on the web login. Thanks for responding and giving me some help! ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/C2QPG6OPMUHW2IQJO2QDA3GB74DPWVYZ/
[ovirt-users] Re: PKIX path error
On 2020-05-28 16:07, Strahil Nikolov wrote: > Can you check > https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL.html just > in case you missed a step ? > > Best Regards, > Strahil Nikolov Greetings, Thanks for replying. I was going to argue a bit since the way my certs come are in different formats so my commands are a bit different then the directions. But I went through step by step. Got to the end, and the internal authentication was working with the right SSL cert! My LDAP authentication was missing though...it looks correct. So I redid all the steps for adding LDAP. At the end of the ovirt-engine-extension-aaa-ldap-setup script, I can test accounts and search so I know that is correct. My cert is in the right .jks file. Still nothing I do shows anything but internal. So I scrapped the changes and started over. Round three on a fresh reboot (just in case I missed a service) with the SSL certs and configuring LDAP. SSL works, internal works, ldap doesn't show up as a drop-down option for the profile. Grr...Reboot just in case I missed a service again...nope. SSL and internal work, ldap still not shown in the profile. Tried a different browser, same thing. Double Grr... Any suggestions on where I might be going wrong? Thanks! ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/A4BKWITWPNPYYVLDVRN4XOSDTN4LPNB3/
[ovirt-users] PKIX path error
Greetings, I have a running oVirt install that's been working for almost 2 years. I'm building a _completely_ new install. I mention it because it is useful for me to compare configurations when I run into issues like this one. Right now there are three physical hosts: 1x management where I run the engine and db 2x hypervisor nodes. I had it up and installed and running smooth this morning on 4.3.9.4-1.el7 on Scientific Linux 7.8 (fully patched). I copied over our 3rd party certs from the running system and restarted httpd. Perfect. SSL is running! /etc/pki/ovirt-engine/apache-ca.pem /etc/pki/ovirt-engine/certs/apache.cer /etc/pki/ovirt-engine/keys/apache.key.nopass Next I used ovirt-engine-extension-aaa-ldap-setup to point to our ldap server. I did the login and search test and both passed on the command line! Horray! Then I went to the web interface... sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target I'm digging through logs and I don't see anything close to this error except nearly the identical message in engine.log. ERROR [org.ovirt.engine.core.aaa.servlet.SslPostLoginServlet] (default task-2) [] server_error: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target I can't log in via the web at all, I only get that message (so I can't even test out the local admin). The aaa ldap configuration it generated is darn near perfectly identical (just a name change). The certs are the same. Even when I look in the keystore, the sha1 hashes are the same between the two environments! After over an hour poking at this, I'm completely stumped. Can someone please give me a pointer on what I should try next? Thanks! ~Stack~ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YOR3ATLII3LYIBEYVOKTEE4RIYZGJR76/
[ovirt-users] Re: Multiple CephFS Monitors cause issues with oVirt
On 08/29/2018 10:44 AM, Stack Korora wrote: > On 08/29/2018 10:14 AM, Markus Stockhausen wrote: >> Hi, >> >> maybe a foolish guess: Did you try this >> >> https://www.spinics.net/lists/ceph-devel/msg30958.html >> >> Mit freundlichen Grüßen, >> >> Markus Stockhausen >> Head of Software Technology > Thanks, I thought about that but I have not tried it. I will add it to > my list to check today and will report back if it works (though I don't > see why it wouldn't). It is good to know that someone else has at least > had success with having a DNS entry for the multiple CephFS monitor hosts. A single DNS entry did not work. Red Hat's oVirt did not like mounting it even though it works fine via command line. :-/ I now have a Red Hat ticket open so we will see what happens on that front. Thanks! ~Stack~ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/4RFPEUFOIGHKA6MD2JPC72SBD6GHIZPZ/
[ovirt-users] Re: Multiple CephFS Monitors cause issues with oVirt
On 08/29/2018 10:14 AM, Markus Stockhausen wrote: > Hi, > > maybe a foolish guess: Did you try this > > https://www.spinics.net/lists/ceph-devel/msg30958.html > > Mit freundlichen Grüßen, > > Markus Stockhausen > Head of Software Technology Thanks, I thought about that but I have not tried it. I will add it to my list to check today and will report back if it works (though I don't see why it wouldn't). It is good to know that someone else has at least had success with having a DNS entry for the multiple CephFS monitor hosts. ~Stack~ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/3VJO3TMKB6WVOPORFDLC6D6OFWJDQGZS/
[ovirt-users] Re: Multiple CephFS Monitors cause issues with oVirt
On 08/29/2018 09:28 AM, Nir Soffer wrote: > > > On Wed, 29 Aug 2018, 15:48 Stack Korora, <mailto:stackkor...@disroot.org>> wrote: > > Greetings, > > My setup is a complete Red Hat install. > Manager OS: RHEL 7.5 > Hypervisors OS: RHEL 7.5 > Running Red Hat CephFS (with their Ceph repos on all of the systems) > with Red Hat Virtualization (aka oVirt). > Everything is fully patched and updated as of yesterday morning. > > Yes, I have valid Red Hat support but I figured this was an odd enough > problem that the community (and the Red-Hat-ers who hang out on this > list) might have a better idea of where to start. (Although I > might open > a ticket anyway just because that is what support is for, right? :) > > Quick background: > > Your /etc/fstab when you mount a nfs should probably look > something like > this: > :/path/ /mount/point nfs 0 0 > > Just one IP is needed. Since part of the redundancy for Ceph is in the > monitors, to mount CephFS the fstab should look something like this: > > ,,:/path/ > /mount/point ceph 0 0 > > Both the Ceph community and Red Hat recommend the comma separator for > mounting multiple CephFS monitor nodes. (See section 4.2 point 3) > > https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/2/html/ceph_file_system_guide_technology_preview/mounting_and_unmounting_ceph_file_systems > > > Now to oVirt/RHV. > > When I mount my Data Domain path as a Posix file system with a path of > ":/path/" it works splendidly well (especially > after > the last Red Hat kernel update!). I've done a bunch of stuff to it and > it seems to work every time. However, I don't have the redundancy of > multiple Ceph Monitors. > > When I mount my Data Domain path as a Posix file system with a path of > ",,:/path/" > most things seem to work. But I noticed a higher rate of failures. The > only failure that I can trigger 100% of the time though is to mount a > second data import domain and attempt to copy a vm disk from the > import > into the CephFS Data domain. Then I get an error like this: > > would > VDSM ovirt01 command HSMGetAllTasksStatusesVDS failed: > low level Image copy failed: > (u'Destination volume 7c1bb510-9f35-4456-8d51-0955f788ac3e error: > ParamsList: sep , in > > /rhev/data-center/mnt/,,:_ovirt_data/70fb34ad-e66d-43e6-8412-5e020baa34df/images/23991a68-0c43-433f-b1f9-48b1533da54a',) > > Uh, oh. It seems that the commas in the mount path are causing the > problems. So I went looking through the logs for "sep , in" and > found a > bunch more hits which makes me think that this is actually the problem > message. > > I've switched back to just one IP address for the time being but I > obviously want the Ceph redundancy back. While running on just one IP, > the vm disk that refused to copy before had no problem copying. The > _only_ change I made was dropping two of the three IP's from the Data > Domain path option. > > Is this a bug, or did I do something wrong? > > > > Looks like a bug,aybe vdsm is not parsing the mount spec correctly. > > Please file vdsm bug and attach vdsm logs showing the entire flow. > > Regardless, I'm not sure how well oVirt with cephfs is tested, or > recommended. > > Adding Yaniv t9 add more info on this. > > Nir Thank you. I can file a report today. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/AJKZDJGU5TSF2HQXK3F6C6QPO5IQDWQ3/
[ovirt-users] Multiple CephFS Monitors cause issues with oVirt
Greetings, My setup is a complete Red Hat install. Manager OS: RHEL 7.5 Hypervisors OS: RHEL 7.5 Running Red Hat CephFS (with their Ceph repos on all of the systems) with Red Hat Virtualization (aka oVirt). Everything is fully patched and updated as of yesterday morning. Yes, I have valid Red Hat support but I figured this was an odd enough problem that the community (and the Red-Hat-ers who hang out on this list) might have a better idea of where to start. (Although I might open a ticket anyway just because that is what support is for, right? :) Quick background: Your /etc/fstab when you mount a nfs should probably look something like this: :/path/ /mount/point nfs 0 0 Just one IP is needed. Since part of the redundancy for Ceph is in the monitors, to mount CephFS the fstab should look something like this: ,,:/path/ /mount/point ceph 0 0 Both the Ceph community and Red Hat recommend the comma separator for mounting multiple CephFS monitor nodes. (See section 4.2 point 3) https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/2/html/ceph_file_system_guide_technology_preview/mounting_and_unmounting_ceph_file_systems Now to oVirt/RHV. When I mount my Data Domain path as a Posix file system with a path of ":/path/" it works splendidly well (especially after the last Red Hat kernel update!). I've done a bunch of stuff to it and it seems to work every time. However, I don't have the redundancy of multiple Ceph Monitors. When I mount my Data Domain path as a Posix file system with a path of ",,:/path/" most things seem to work. But I noticed a higher rate of failures. The only failure that I can trigger 100% of the time though is to mount a second data import domain and attempt to copy a vm disk from the import into the CephFS Data domain. Then I get an error like this: would VDSM ovirt01 command HSMGetAllTasksStatusesVDS failed: low level Image copy failed: (u'Destination volume 7c1bb510-9f35-4456-8d51-0955f788ac3e error: ParamsList: sep , in /rhev/data-center/mnt/,,:_ovirt_data/70fb34ad-e66d-43e6-8412-5e020baa34df/images/23991a68-0c43-433f-b1f9-48b1533da54a',) Uh, oh. It seems that the commas in the mount path are causing the problems. So I went looking through the logs for "sep , in" and found a bunch more hits which makes me think that this is actually the problem message. I've switched back to just one IP address for the time being but I obviously want the Ceph redundancy back. While running on just one IP, the vm disk that refused to copy before had no problem copying. The _only_ change I made was dropping two of the three IP's from the Data Domain path option. Is this a bug, or did I do something wrong? Does anyone have a suggestion for me to try? Thank you! ~Stack~ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/6VVKOIQIDEH5ZV5XPVO3ZTJKFZPVF2GG/
