August 2016 - Users - Ovirt List Archives

by Doron Fediuck

----_com.android.email_640187878761650 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgS3lsZSzCoApXZSBtYXkgaGF2ZSBzZWVuIHNvbWV0aGluZyBzaW1pbGFyIGluIHRoZSBwYXN0 IGJ1dCBJIHRoaW5rIHRoZXJlIHdlcmUgdmxhbnMgaW52b2x2ZWQuwqAKSXMgaXQgdGhlIHNhbWUg Zm9yIHlvdT/CoApUb255IC8gRGFuLCBkb2VzIGl0IHJpbmcgYSBiZWxsP8Kg ----_com.android.email_640187878761650 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5IaSBLeWxlLCZuYnNwOzwv ZGl2PjxkaXY+V2UgbWF5IGhhdmUgc2VlbiBzb21ldGhpbmcgc2ltaWxhciBpbiB0aGUgcGFzdCBi dXQgSSB0aGluayB0aGVyZSB3ZXJlIHZsYW5zIGludm9sdmVkLiZuYnNwOzwvZGl2PjxkaXY+SXMg aXQgdGhlIHNhbWUgZm9yIHlvdT8mbmJzcDs8L2Rpdj48ZGl2PlRvbnkgLyBEYW4sIGRvZXMgaXQg cmluZyBhIGJlbGw/Jm5ic3A7PC9kaXY+PC9ib2R5PjwvaHRtbD4= ----_com.android.email_640187878761650--

6 years, 4 months

2
1
0 / 0

Unable to backend oVirt with Cinder

by Logan Kuhn

------=_Part_51316288_608143832.1472587678781 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I've got Cinder configured and pointed at Ceph for it's back end storage. I can run ceph commands on the cinder machine and cinder is configured for noauth and I've also tried it with Keystone for auth. I can run various cinder commands and it'll return as expected. When I configure it in oVirt it'll add the external provider fine, but when I go to create a disk it doesn't populate the volume type field, it's just empty. The corresponding command for cinder: cinder type-list and cinder type-show <name> returns fine and it is public. Ovirt and Cinder are on the same host so it isn't a firewall issue. Cinder config: [DEFAULT] rpc_backend = rabbit #auth_strategy = keystone auth_strategy = noauth enabled_backends = ceph #glance_api_servers = http://10.128.7.252:9292 #glance_api_version = 2 #[keystone_authtoken] #auth_uri = http://10.128.7.252:5000/v3 #auth_url = http://10.128.7.252:35357/v3 #auth_type = password #memcached_servers = localhost:11211 #project_domain_name = default #user_domain_name = default #project_name = services #username = user #password = pass [ceph] volume_driver = cinder.volume.drivers.rbd.RBDDriver volume_backend_name = ceph rbd_pool = ovirt-images rbd_user = cinder rbd_secret_uuid = <secret> rbd_ceph_conf = /etc/ceph/ceph.conf rbd_flatten_volume_from_snapshot = true rbd_max_clone_depth = 5 rbd_store_chunk_size = 4 rados_connect_timeout = -1 #glance_api_version = 2 [database] connection = postgresql://user:pass@10.128.2.33/cinder [oslo_concurrency] lock_path = /var/lib/cinder/tmp [oslo_messaging_rabbit] rabbit_host = localhost rabbit_port = 5672 rabbit_userid = user rabbit_password = pass Regards, Logan ------=_Part_51316288_608143832.1472587678781 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: Arial; font-size: 12pt; color: #0000= 00"><div>I've got Cinder configured and pointed at Ceph for it's back end s= torage.  I can run ceph commands on the cinder machine and cinder is c= onfigured for noauth and I've also tried it with Keystone for auth.  I= can run various cinder commands and it'll return as expected. </= div><div> </div><div>When I configure it in oVirt i= t'll add the external provider fine, but when I go to create a disk it does= n't populate the volume type field, it's just empty.  The correspondin= g command for cinder: cinder type-list and cinder type-show <name> re= turns fine and it is public. </div><div> </div= ><div>Ovirt and Cinder are on the same host so it isn't a firewall issue.</= div><div> </div><div>Cinder config:</div><div>[DEFA= ULT] rpc_backend =3D rabbit #auth_strategy =3D keystone auth_strat= egy =3D noauth enabled_backends =3D ceph #glance_api_servers =3D http= ://10.128.7.252:9292 #glance_api_version =3D 2 #[keystone_authtok= en] #auth_uri =3D http://10.128.7.252:5000/v3 #auth_url =3D http://10= .128.7.252:35357/v3 #auth_type =3D password #memcached_servers =3D lo= calhost:11211 #project_domain_name =3D default #user_domain_name =3D = default #project_name =3D services #username =3D user #passwo= rd =3D pass [ceph] volume_driver =3D cinder.volume.drivers.rbd.RB= DDriver volume_backend_name =3D ceph rbd_pool =3D ovirt-images rbd= _user =3D cinder rbd_secret_uuid =3D <secret> rbd_ceph_con= f =3D /etc/ceph/ceph.conf rbd_flatten_volume_from_snapshot =3D true r= bd_max_clone_depth =3D 5 rbd_store_chunk_size =3D 4 rados_connect_tim= eout =3D -1 #glance_api_version =3D 2 [database] connection = =3D postgresql://user:pass@10.128.2.33/cinder [oslo_concurrency] = lock_path =3D /var/lib/cinder/tmp [oslo_messaging_rabbit] rabbit_= host =3D localhost rabbit_port =3D 5672 rabbit_userid =3D <span = style=3D"color: #000000; font-family: Arial; font-size: 16px; font-style: n= ormal; font-variant-ligatures: normal; font-variant-caps: normal; font-weig= ht: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-a= lign: start; text-indent: 0px; text-transform: none; white-space: normal; w= idows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inlin= e !important; float: none; background-color: #ffffff;" data-mce-style=3D"co= lor: #000000; font-family: Arial; font-size: 16px; font-style: normal; font= -variant-ligatures: normal; font-variant-caps: normal; font-weight: normal;= letter-spacing: normal; line-height: normal; orphans: 2; text-align: start= ; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; w= ord-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !importan= t; float: none; background-color: #ffffff;">user rabbit_password = =3D <span style=3D"color: #000000; font-family: Arial; font-size: 16px= ; font-style: normal; font-variant-ligatures: normal; font-variant-caps: no= rmal; font-weight: normal; letter-spacing: normal; line-height: normal; orp= hans: 2; text-align: start; text-indent: 0px; text-transform: none; white-s= pace: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;= display: inline !important; float: none; background-color: #ffffff;" data-= mce-style=3D"color: #000000; font-family: Arial; font-size: 16px; font-styl= e: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-= weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; te= xt-align: start; text-indent: 0px; text-transform: none; white-space: norma= l; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: i= nline !important; float: none; background-color: #ffffff;">pass</div= ><div> </div><div data-marker=3D"__SIG_PRE__">Regards, Logan</div></d= iv></body></html> ------=_Part_51316288_608143832.1472587678781--

7 years

4
4
0 / 0

HostedEngine with HA

by Carlos Rodrigues

Hello, I have one cluster with two hosts with power management correctly configured and one virtual machine with HostedEngine over shared storage with FiberChannel. When i shutdown the network of host with HostedEngine VM, it should be possible the HostedEngine VM migrate automatically to another host? What is the expected behaviour on this HA scenario? Regards, -- Carlos Rodrigues Engenheiro de Software Sénior Eurotux Informática, S.A. | www.eurotux.com (t) +351 253 680 300 (m) +351 911 926 110

7 years, 3 months

4
30
0 / 0

ovirt-ha-agent cpu usage

by Gianluca Cecchi

Hello, I have a test machine that is a nuc6 with an i5 and 32G of ram and SSD disks. It is configured as a single host environment with Self Hosted Engine VM. Both host and SHE are CentOS 7.2 and oVirt version is 3.6.6.2-1.el7 I notice that having 3 VMs powered on and making nothing special (engine VM, a CentOS 7 VM and a Fedora 24 VM) the ovirt-ha-agent process on host often spikes its cpu usage. See for example this quick video with top command running on host that reflects what happens continuously. https://drive.google.com/file/d/0BwoPbcrMv8mvYUVRMFlLVmxRdXM/view?usp=sha... Is it normal that ovirt-ha-agent consumes all this amount of cpu? Going into /var/log/ovirt-hosted-engine-ha/agent.log I see nothing special, only messages of type "INFO". The same for broker.log Thanks, Gianluca

8 years, 2 months

8
29
0 / 0

Hosted engine Single Sign-On to VM with freeIPA not working

by Paul

This is a multipart message in MIME format. ------=_NextPart_000_0050_01D18069.35C995E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am having an issue with getting SSO to work when a standard user(UserRole) logs in to the UserPortal. The user has permission to use only this VM, so after login the console is automatically opened for that VM. Problem is that it doesn't login on the VM system with the provided credentials. Manual login at the console works without any issues. HBAC-rule check on IPA shows access is granted. Client has SELINUX in permissive mode and a disabled firewalld. On the client side I do see some PAM related errors in the logs (see details below). Extensive Google search on error 17 "Failure setting user credentials" didn't show helpful information :-( AFAIK this is did a pretty standard set-up, all working with RH-family products. I would expect others to encounter this issue as well. If someone knows any solution or has some directions to fix this it would be greatly appreciated. Thanks, Paul ------------------------------------------------------ System setup: I have 3 systems The connection between the Engine and IPA is working fine. (I can log in with IPA users etc.) Connection is made according to this document: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualizat ion/3.6/html-single/Administration_Guide/index.html#sect-Configuring_an_Exte rnal_LDAP_Provider Configuration of the client is done according to this document: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualizat ion/3.6/html/Virtual_Machine_Management_Guide/chap-Additional_Configuration. html#sect-Configuring_Single_Sign-On_for_Virtual_Machines --- Hosted Engine: [root@engine ~]# cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) [root@engine ~]# uname -a Linux engine.DOMAIN.COM 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@engine ~]# rpm -qa | grep ovirt ovirt-vmconsole-1.0.0-1.el7.centos.noarch ovirt-engine-restapi-3.6.2.6-1.el7.centos.noarch ovirt-setup-lib-1.0.1-1.el7.centos.noarch ovirt-engine-setup-plugin-ovirt-engine-common-3.6.3.4-1.el7.centos.noarch ovirt-engine-setup-3.6.3.4-1.el7.centos.noarch ovirt-image-uploader-3.6.0-1.el7.centos.noarch ovirt-engine-extension-aaa-jdbc-1.0.5-1.el7.noarch ovirt-host-deploy-1.4.1-1.el7.centos.noarch ovirt-engine-extension-aaa-ldap-setup-1.1.2-1.el7.centos.noarch ovirt-engine-wildfly-overlay-8.0.4-1.el7.noarch ovirt-engine-wildfly-8.2.1-1.el7.x86_64 ovirt-vmconsole-proxy-1.0.0-1.el7.centos.noarch ovirt-engine-tools-3.6.2.6-1.el7.centos.noarch ovirt-engine-dbscripts-3.6.2.6-1.el7.centos.noarch ovirt-engine-backend-3.6.2.6-1.el7.centos.noarch ovirt-engine-3.6.2.6-1.el7.centos.noarch ovirt-engine-extension-aaa-ldap-1.1.2-1.el7.centos.noarch ovirt-engine-setup-base-3.6.3.4-1.el7.centos.noarch ovirt-engine-setup-plugin-ovirt-engine-3.6.3.4-1.el7.centos.noarch ovirt-engine-setup-plugin-websocket-proxy-3.6.3.4-1.el7.centos.noarch ovirt-engine-vmconsole-proxy-helper-3.6.3.4-1.el7.centos.noarch ovirt-engine-cli-3.6.2.0-1.el7.centos.noarch ovirt-host-deploy-java-1.4.1-1.el7.centos.noarch ovirt-engine-userportal-3.6.2.6-1.el7.centos.noarch ovirt-engine-webadmin-portal-3.6.2.6-1.el7.centos.noarch ovirt-guest-agent-common-1.0.11-1.el7.noarch ovirt-release36-003-1.noarch ovirt-iso-uploader-3.6.0-1.el7.centos.noarch ovirt-engine-lib-3.6.3.4-1.el7.centos.noarch ovirt-engine-sdk-python-3.6.3.0-1.el7.centos.noarch ovirt-engine-setup-plugin-vmconsole-proxy-helper-3.6.3.4-1.el7.centos.noarch ovirt-engine-websocket-proxy-3.6.3.4-1.el7.centos.noarch ovirt-log-collector-3.6.1-1.el7.centos.noarch ovirt-engine-extensions-api-impl-3.6.3.4-1.el7.centos.noarch --- FreeIPA: [root@ipa01 ~]# cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) [root@ipa01 ~]# uname -a Linux ipa01.DOMAIN.COM 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@ipa01 ~]# rpm -qa | grep ipa ipa-python-4.2.0-15.el7_2.6.x86_64 ipa-client-4.2.0-15.el7_2.6.x86_64 python-libipa_hbac-1.13.0-40.el7_2.1.x86_64 python-iniparse-0.4-9.el7.noarch libipa_hbac-1.13.0-40.el7_2.1.x86_64 sssd-ipa-1.13.0-40.el7_2.1.x86_64 ipa-admintools-4.2.0-15.el7_2.6.x86_64 ipa-server-4.2.0-15.el7_2.6.x86_64 ipa-server-dns-4.2.0-15.el7_2.6.x86_64 --- Client: [root@test06 ~]# cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) [root@test06 ~]# uname -a Linux test06.DOMAIN.COM 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@test06 ~]# rpm -qa | grep ipa python-libipa_hbac-1.13.0-40.el7_2.1.x86_64 python-iniparse-0.4-9.el7.noarch sssd-ipa-1.13.0-40.el7_2.1.x86_64 ipa-client-4.2.0-15.0.1.el7.centos.6.x86_64 libipa_hbac-1.13.0-40.el7_2.1.x86_64 ipa-python-4.2.0-15.0.1.el7.centos.6.x86_64 device-mapper-multipath-0.4.9-85.el7.x86_64 device-mapper-multipath-libs-0.4.9-85.el7.x86_64 [root@test06 ~]# rpm -qa | grep guest-agent qemu-guest-agent-2.3.0-4.el7.x86_64 ovirt-guest-agent-pam-module-1.0.11-1.el7.x86_64 ovirt-guest-agent-gdm-plugin-1.0.11-1.el7.noarch ovirt-guest-agent-common-1.0.11-1.el7.noarch --------------------------------------------------- Relevant logs: --- Engine: //var/log/ovirt-engine/engine 2016-03-17 15:22:10,516 INFO [org.ovirt.engine.core.bll.aaa.LoginUserCommand] (default task-22) [] Running command: LoginUserCommand internal: false. 2016-03-17 15:22:10,568 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-22) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User test6@DOMAIN logged in. 2016-03-17 15:22:13,795 WARN [org.ovirt.engine.core.dal.job.ExecutionMessageDirector] (default task-6) [7400ae46] The message key 'VmLogon' is missing from 'bundles/ExecutionMessages' 2016-03-17 15:22:13,839 INFO [org.ovirt.engine.core.bll.VmLogonCommand] (default task-6) [7400ae46] Running command: VmLogonCommand internal: false. Entities affected : ID: 64a84b40-6050-4a96-a59d-d557a317c38c Type: VMAction group CONNECT_TO_VM with role type USER 2016-03-17 15:22:13,842 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.VmLogonVDSCommand] (default task-6) [7400ae46] START, VmLogonVDSCommand(HostName = host01, VmLogonVDSCommandParameters:{runAsync='true', hostId='225157c0-224b-4aa6-9210-db4de7c7fc30', vmId='64a84b40-6050-4a96-a59d-d557a317c38c', domain='DOMAIN-authz', password='***', userName='test6@DOMAIN'}), log id: 2015a1e0 2016-03-17 15:22:14,848 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.VmLogonVDSCommand] (default task-6) [7400ae46] FINISH, VmLogonVDSCommand, log id: 2015a1e0 2016-03-17 15:22:15,317 INFO [org.ovirt.engine.core.bll.SetVmTicketCommand] (default task-18) [10dad788] Running command: SetVmTicketCommand internal: true. Entities affected : ID: 64a84b40-6050-4a96-a59d-d557a317c38c Type: VMAction group CONNECT_TO_VM with role type USER 2016-03-17 15:22:15,322 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (default task-18) [10dad788] START, SetVmTicketVDSCommand(HostName = host01, SetVmTicketVDSCommandParameters:{runAsync='true', hostId='225157c0-224b-4aa6-9210-db4de7c7fc30', vmId='64a84b40-6050-4a96-a59d-d557a317c38c', protocol='SPICE', ticket='rd8avqvdBnRl', validTime='120', userName='test6', userId='10b2da3e-6401-4a09-a330-c0780bc0faef', disconnectAction='LOCK_SCREEN'}), log id: 72efb73b 2016-03-17 15:22:16,340 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (default task-18) [10dad788] FINISH, SetVmTicketVDSCommand, log id: 72efb73b 2016-03-17 15:22:16,377 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-18) [10dad788] Correlation ID: 10dad788, Call Stack: null, Custom Event ID: -1, Message: User test6@DOMAIN initiated console session for VM test06 2016-03-17 15:22:19,418 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-53) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User test6@DOMAIN-authz is connected to VM test06. --- Client: /var/log/ovirt-guest-agent/ovirt-guest-agent.log MainThread::INFO::2016-03-17 15:20:58,145::ovirt-guest-agent::57::root::Starting oVirt guest agent CredServer::INFO::2016-03-17 15:20:58,214::CredServer::257::root::CredServer is running... Dummy-1::INFO::2016-03-17 15:20:58,216::OVirtAgentLogic::294::root::Received an external command: lock-screen... Dummy-1::INFO::2016-03-17 15:22:13,104::OVirtAgentLogic::294::root::Received an external command: login... Dummy-1::INFO::2016-03-17 15:22:13,104::CredServer::207::root::The following users are allowed to connect: [0] Dummy-1::INFO::2016-03-17 15:22:13,104::CredServer::273::root::Opening credentials channel... Dummy-1::INFO::2016-03-17 15:22:13,105::CredServer::132::root::Emitting user authenticated signal (651416). CredChannel::INFO::2016-03-17 15:22:13,188::CredServer::225::root::Incomming connection from user: 0 process: 2570 CredChannel::INFO::2016-03-17 15:22:13,188::CredServer::232::root::Sending user's credential (token: 651416) Dummy-1::INFO::2016-03-17 15:22:13,189::CredServer::277::root::Credentials channel was closed. /var/log/secure Mar 17 15:21:07 test06 gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0) Mar 17 15:21:10 test06 polkitd[749]: Registered Authentication Agent for unix-session:c1 (system bus name :1.34 [gnome-shell --mode=gdm], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Mar 17 15:22:13 test06 gdm-ovirtcred]: pam_sss(gdm-ovirtcred:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=test6 Mar 17 15:22:13 test06 gdm-ovirtcred]: pam_sss(gdm-ovirtcred:auth): received for user test6: 17 (Failure setting user credentials) /var/log/sssd/krb5_child.log (debug-level 10) (Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [get_and_save_tgt] (0x0020): 1234: [-1765328360][Preauthentication failed] (Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [map_krb5_error] (0x0020): 1303: [-1765328360][Preauthentication failed] (Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [k5c_send_data] (0x0200): Received error code 1432158215 (Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [pack_response_packet] (0x2000): response packet size: [4] (Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [k5c_send_data] (0x4000): Response sent. (Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [main] (0x0400): krb5_child completed successfully /var/log/sssd/sssd_DOMAIN.COM.log (debug-level 10) (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_pam_handler] (0x0100): Got request with the following data (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): domain: DOMAIN.COM (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): user: test6 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): service: gdm-ovirtcred (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): tty: (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): ruser: (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): rhost: (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): authtok type: 1 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): priv: 1 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): cli_pid: 2570 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): logon name: not set (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [krb5_auth_queue_send] (0x1000): Wait queue of user [test6] is empty, running request [0x7fe30df03cc0] immediately. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [krb5_setup] (0x4000): No mapping for: test6 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7fe30df07120 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7fe30df16590 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Running timer event 0x7fe30df07120 "ltdb_callback" (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Destroying timer event 0x7fe30df16590 "ltdb_timeout" (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Ending timer event 0x7fe30df07120 "ltdb_callback" (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [get_server_status] (0x1000): Status of server 'ipa01.DOMAIN.COM' is 'working' (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [get_port_status] (0x1000): Port status of port 389 for server 'ipa01.DOMAIN.COM' is 'working' (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [get_server_status] (0x1000): Status of server 'ipa01.DOMAIN.COM' is 'working' (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_resolve_server_process] (0x0200): Found address for server ipa01.DOMAIN.COM: [10.0.1.21] TTL 1200 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://ipa01.DOMAIN.COM' (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sss_krb5_realm_has_proxy] (0x0040): profile_get_values failed. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2575] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2575] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [write_pipe_handler] (0x0400): All data has been sent! (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [child_sig_handler] (0x1000): Waiting for child [2575]. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [child_sig_handler] (0x0100): child [2575] finished successfully. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [read_pipe_handler] (0x0400): EOF received, client finished (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [check_wait_queue] (0x1000): Wait queue for user [test6] is empty. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [krb5_auth_queue_done] (0x1000): krb5_auth_queue request [0x7fe30df03cc0] done. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_print_server] (0x2000): Searching 10.0.1.21 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(cn=ipaConfig)(objectClass=ipaGuiConfig))][cn=etc,dc=DOMAIN,dc=com]. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaMigrationEnabled] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUserMapDefault] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUserMapOrder] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 122 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_op_add] (0x2000): New operation 122 timeout 60 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: sh[0x7fe30deef090], connected[1], ops[0x7fe30df094a0], ldap[0x7fe30def2920] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn=ipaConfig,cn=etc,dc=DOMAIN,dc=com]. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaMigrationEnabled] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSELinuxUserMapDefault] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSELinuxUserMapOrder] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: sh[0x7fe30deef090], connected[1], ops[0x7fe30df094a0], ldap[0x7fe30def2920] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_op_destructor] (0x2000): Operation 122 finished (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ipa_get_migration_flag_done] (0x0100): Password migration is not enabled. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 17, <NULL>) [Success (Failure setting user credentials)] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_pam_handler_callback] (0x0100): Sending result [17][DOMAIN.COM] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_pam_handler_callback] (0x0100): Sent result [17][DOMAIN.COM] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: sh[0x7fe30deef090], connected[1], ops[(nil)], ldap[0x7fe30def2920] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! ------=_NextPart_000_0050_01D18069.35C995E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 15 = (filtered medium)"><style></style></head><body lang=3DEN-US = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1>Hi,<o:p></o:p><o:p> </o:p>I am having = an issue with getting SSO to work when a standard user(UserRole) logs in = to the UserPortal.<o:p></o:p>The user has = permission to use only this VM, so after login the console is = automatically opened for that VM.<o:p></o:p>Problem is that it doesn't login on the VM system with = the provided credentials. Manual login at the console works without any = issues. <o:p></o:p>HBAC-rule check on IPA shows = access is granted. Client has SELINUX in permissive mode and a disabled = firewalld. <o:p></o:p><o:p> </o:p>On the client side I do see some PAM related errors in = the logs (see details below). Extensive Google search on error 17 = "Failure setting user credentials" didn't show helpful = information :-(<o:p></o:p><o:p> </o:p>AFAIK this = is did a pretty standard set-up, all working with RH-family products. I = would expect others to encounter this issue as well. <o:p></o:p>If someone knows any solution or has some directions = to fix this it would be greatly appreciated.<o:p></o:p><o:p> </o:p>Thanks,<o:p></o:p><o:p> </o:p>Paul<o:p></o:p><o:p> </o:p>------------------------------------------------------<= o:p></o:p>System setup: I have 3 systems = <o:p></o:p><o:p> </o:p>The connection between the Engine and IPA is working = fine. (I can log in with IPA users etc.) Connection is made according to = this document: = https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtuali= zation/3.6/html-single/Administration_Guide/index.html#sect-Configuring_a= n_External_LDAP_Provider<o:p></o:p><o:p> </o:p>Configuration of the client is done according to this = document: = https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtuali= zation/3.6/html/Virtual_Machine_Management_Guide/chap-Additional_Configur= ation.html#sect-Configuring_Single_Sign-On_for_Virtual_Machines<o:p></o:p= ><o:p> </o:p>--- = Hosted Engine:<o:p></o:p>[root@engine ~]# cat = /etc/redhat-release<o:p></o:p>CentOS Linux = release 7.2.1511 (Core)<o:p></o:p>[root@engine = ~]# uname -a<o:p></o:p>Linux engine.DOMAIN.COM = 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 = x86_64 x86_64 GNU/Linux<o:p></o:p>[root@engine = ~]# rpm -qa | grep ovirt<o:p></o:p>ovirt-vmconsole-1.0.0-1.el7.centos.noarch<o:p></o:p></p= >ovirt-engine-restapi-3.6.2.6-1.el7.centos.noarch<o:p></= o:p>ovirt-setup-lib-1.0.1-1.el7.centos.noarch<o:p></o:p></p= >ovirt-engine-setup-plugin-ovirt-engine-common-3.6.3.4-1= .el7.centos.noarch<o:p></o:p>ovirt-engine-setup-3.6.3.4-1.el7.centos.noarch<o:p></o:= p>ovirt-image-uploader-3.6.0-1.el7.centos.noarch<o:p></o:= p>ovirt-engine-extension-aaa-jdbc-1.0.5-1.el7.noarch<o:p>= </o:p>ovirt-host-deploy-1.4.1-1.el7.centos.noarch<o:p></o:p><= /p>ovirt-engine-extension-aaa-ldap-setup-1.1.2-1.el7.cento= s.noarch<o:p></o:p>ovirt-engine-wildfly-overlay-8.0.4-1.el7.noarch<o:p></o= :p>ovirt-engine-wildfly-8.2.1-1.el7.x86_64<o:p></o:p><= p = class=3DMsoNormal>ovirt-vmconsole-proxy-1.0.0-1.el7.centos.noarch<o:p></o= :p>ovirt-engine-tools-3.6.2.6-1.el7.centos.noarch<o:p></o:= p>ovirt-engine-dbscripts-3.6.2.6-1.el7.centos.noarch<o:p>= </o:p>ovirt-engine-backend-3.6.2.6-1.el7.centos.noarch<o:p></= o:p>ovirt-engine-3.6.2.6-1.el7.centos.noarch<o:p></o:p>= ovirt-engine-extension-aaa-ldap-1.1.2-1.el7.centos.noar= ch<o:p></o:p>ovirt-engine-setup-base-3.6.3.4-1.el7.centos.noarch<o:p= ></o:p>ovirt-engine-setup-plugin-ovirt-engine-3.6.3.4-1.el7.ce= ntos.noarch<o:p></o:p>ovirt-engine-setup-plugin-websocket-proxy-3.6.3.4-1.el7= .centos.noarch<o:p></o:p>ovirt-engine-vmconsole-proxy-helper-3.6.3.4-1.el7.cento= s.noarch<o:p></o:p>ovirt-engine-cli-3.6.2.0-1.el7.centos.noarch<o:p></o:p>= ovirt-host-deploy-java-1.4.1-1.el7.centos.noarch<o:p></= o:p>ovirt-engine-userportal-3.6.2.6-1.el7.centos.noarch<o:p= ></o:p>ovirt-engine-webadmin-portal-3.6.2.6-1.el7.centos.noarc= h<o:p></o:p>ovirt-guest-agent-common-1.0.11-1.el7.noarch<o:p></o:p>= ovirt-release36-003-1.noarch<o:p></o:p>ovirt-iso-uploader-3.6.0-1.el7.centos.noarch<o:p></o:p>= ovirt-engine-lib-3.6.3.4-1.el7.centos.noarch<o:p></o:p>= ovirt-engine-sdk-python-3.6.3.0-1.el7.centos.noarch<o:p= ></o:p>ovirt-engine-setup-plugin-vmconsole-proxy-helper-3.6.3.= 4-1.el7.centos.noarch<o:p></o:p>ovirt-engine-websocket-proxy-3.6.3.4-1.el7.centos.noarc= h<o:p></o:p>ovirt-log-collector-3.6.1-1.el7.centos.noarch<o:p></o:p= >ovirt-engine-extensions-api-impl-3.6.3.4-1.el7.centos.n= oarch<o:p></o:p><o:p> </o:p>--- FreeIPA:<o:p></o:p>[root@ipa01 ~]# cat = /etc/redhat-release<o:p></o:p>CentOS Linux = release 7.2.1511 (Core) <o:p></o:p>[root@ipa01 = ~]#  uname -a<o:p></o:p>Linux = ipa01.DOMAIN.COM 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 = UTC 2016 x86_64 x86_64 x86_64 GNU/Linux<o:p></o:p>[root@ipa01 ~]# rpm -qa | grep ipa<o:p></o:p>ipa-python-4.2.0-15.el7_2.6.x86_64<o:p></o:p>ipa-client-4.2.0-15.el7_2.6.x86_64<o:p></o:p>python-libipa_hbac-1.13.0-40.el7_2.1.x86_64<o:p></o:p><= /p>python-iniparse-0.4-9.el7.noarch<o:p></o:p>libipa_hbac-1.13.0-40.el7_2.1.x86_64<o:p></o:p>sssd-ipa-1.13.0-40.el7_2.1.x86_64<o:p></o:p>ipa-admintools-4.2.0-15.el7_2.6.x86_64<o:p></o:p><p= class=3DMsoNormal>ipa-server-4.2.0-15.el7_2.6.x86_64<o:p></o:p>ipa-server-dns-4.2.0-15.el7_2.6.x86_64<o:p></o:p><p= class=3DMsoNormal><o:p> </o:p>--- = Client:<o:p></o:p>[root@test06 ~]# cat = /etc/redhat-release<o:p></o:p>CentOS Linux = release 7.2.1511 (Core) <o:p></o:p>[root@test06 = ~]# uname -a<o:p></o:p>Linux test06.DOMAIN.COM = 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 = x86_64 x86_64 GNU/Linux<o:p></o:p>[root@test06 = ~]# rpm -qa | grep ipa<o:p></o:p>python-libipa_hbac-1.13.0-40.el7_2.1.x86_64<o:p></o:p><= /p>python-iniparse-0.4-9.el7.noarch<o:p></o:p>sssd-ipa-1.13.0-40.el7_2.1.x86_64<o:p></o:p>ipa-client-4.2.0-15.0.1.el7.centos.6.x86_64<o:p></o:p><= /p>libipa_hbac-1.13.0-40.el7_2.1.x86_64<o:p></o:p>ipa-python-4.2.0-15.0.1.el7.centos.6.x86_64<o:p></o:p><= /p>device-mapper-multipath-0.4.9-85.el7.x86_64<o:p></o:p><= /p>device-mapper-multipath-libs-0.4.9-85.el7.x86_64<o:p></= o:p>[root@test06 ~]# rpm -qa | grep = guest-agent<o:p></o:p>qemu-guest-agent-2.3.0-4.el7.x86_64<o:p></o:p>ovirt-guest-agent-pam-module-1.0.11-1.el7.x86_64<o:p></= o:p>ovirt-guest-agent-gdm-plugin-1.0.11-1.el7.noarch<o:p></= o:p>ovirt-guest-agent-common-1.0.11-1.el7.noarch<o:p></o:p>= <o:p> </o:p>---------------------------------------------------<o:p= ></o:p>Relevant logs:<o:p></o:p>--- Engine:<o:p></o:p>//var/log/ovirt-engine/engine<o:p></o:p>2016-03-17 15:22:10,516 INFO  = [org.ovirt.engine.core.bll.aaa.LoginUserCommand] (default task-22) [] = Running command: LoginUserCommand internal: false.<o:p></o:p>2016-03-17 15:22:10,568 INFO  = [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] = (default task-22) [] Correlation ID: null, Call Stack: null, Custom = Event ID: -1, Message: User test6@DOMAIN logged in.<o:p></o:p>2016-03-17 15:22:13,795 WARN  = [org.ovirt.engine.core.dal.job.ExecutionMessageDirector] (default = task-6) [7400ae46] The message key 'VmLogon' is missing from = 'bundles/ExecutionMessages'<o:p></o:p>2016-03-17 15:22:13,839 INFO  = [org.ovirt.engine.core.bll.VmLogonCommand] (default task-6) [7400ae46] = Running command: VmLogonCommand internal: false. Entities affected = :  ID: 64a84b40-6050-4a96-a59d-d557a317c38c Type: VMAction group = CONNECT_TO_VM with role type USER<o:p></o:p>2016-03-17 15:22:13,842 INFO  = [org.ovirt.engine.core.vdsbroker.vdsbroker.VmLogonVDSCommand] (default = task-6) [7400ae46] START, VmLogonVDSCommand(HostName =3D host01, = VmLogonVDSCommandParameters:{runAsync=3D'true', = hostId=3D'225157c0-224b-4aa6-9210-db4de7c7fc30', = vmId=3D'64a84b40-6050-4a96-a59d-d557a317c38c', domain=3D'DOMAIN-authz', = password=3D'***', userName=3D'test6@DOMAIN'}), log id: = 2015a1e0<o:p></o:p>2016-03-17 15:22:14,848 = INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.VmLogonVDSCommand] = (default task-6) [7400ae46] FINISH, VmLogonVDSCommand, log id: = 2015a1e0<o:p></o:p>2016-03-17 15:22:15,317 = INFO  [org.ovirt.engine.core.bll.SetVmTicketCommand] (default = task-18) [10dad788] Running command: SetVmTicketCommand internal: true. = Entities affected :  ID: 64a84b40-6050-4a96-a59d-d557a317c38c Type: = VMAction group CONNECT_TO_VM with role type USER<o:p></o:p>2016-03-17 15:22:15,322 INFO  = [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] = (default task-18) [10dad788] START, SetVmTicketVDSCommand(HostName =3D = host01, SetVmTicketVDSCommandParameters:{runAsync=3D'true', = hostId=3D'225157c0-224b-4aa6-9210-db4de7c7fc30', = vmId=3D'64a84b40-6050-4a96-a59d-d557a317c38c', protocol=3D'SPICE', = ticket=3D'rd8avqvdBnRl', validTime=3D'120', userName=3D'test6', = userId=3D'10b2da3e-6401-4a09-a330-c0780bc0faef', = disconnectAction=3D'LOCK_SCREEN'}), log id: 72efb73b<o:p></o:p>2016-03-17 15:22:16,340 INFO  = [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] = (default task-18) [10dad788] FINISH, SetVmTicketVDSCommand, log id: = 72efb73b<o:p></o:p>2016-03-17 15:22:16,377 = INFO  = [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] = (default task-18) [10dad788] Correlation ID: 10dad788, Call Stack: null, = Custom Event ID: -1, Message: User test6@DOMAIN initiated console = session for VM test06<o:p></o:p>2016-03-17 = 15:22:19,418 INFO  = [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] = (DefaultQuartzScheduler_Worker-53) [] Correlation ID: null, Call Stack: = null, Custom Event ID: -1, Message: User test6@DOMAIN-authz is connected = to VM test06.<o:p></o:p><o:p> </o:p>--- Client:<o:p></o:p>/var/log/ovirt-guest-agent/ovirt-guest-agent.log<o:p></= o:p>MainThread::INFO::2016-03-17 = 15:20:58,145::ovirt-guest-agent::57::root::Starting oVirt guest = agent<o:p></o:p>CredServer::INFO::2016-03-17 = 15:20:58,214::CredServer::257::root::CredServer is = running...<o:p></o:p>Dummy-1::INFO::2016-03-17 = 15:20:58,216::OVirtAgentLogic::294::root::Received an external command: = lock-screen...<o:p></o:p>Dummy-1::INFO::2016-03-17 = 15:22:13,104::OVirtAgentLogic::294::root::Received an external command: = login...<o:p></o:p>Dummy-1::INFO::2016-03-17 = 15:22:13,104::CredServer::207::root::The following users are allowed to = connect: [0]<o:p></o:p>Dummy-1::INFO::2016-03-17 = 15:22:13,104::CredServer::273::root::Opening credentials = channel...<o:p></o:p>Dummy-1::INFO::2016-03-17 = 15:22:13,105::CredServer::132::root::Emitting user authenticated signal = (651416).<o:p></o:p>CredChannel::INFO::2016-03-17 = 15:22:13,188::CredServer::225::root::Incomming connection from user: 0 = process: 2570<o:p></o:p>CredChannel::INFO::2016-03-17 = 15:22:13,188::CredServer::232::root::Sending user's credential (token: = 651416)<o:p></o:p>Dummy-1::INFO::2016-03-17 = 15:22:13,189::CredServer::277::root::Credentials channel was = closed.<o:p></o:p><o:p> </o:p>/var/log/secure<o:p></o:p>Mar = 17 15:21:07 test06 gdm-launch-environment]: = pam_unix(gdm-launch-environment:session): session opened for user gdm by = (uid=3D0)<o:p></o:p>Mar 17 15:21:10 test06 = polkitd[749]: Registered Authentication Agent for unix-session:c1 = (system bus name :1.34 [gnome-shell --mode=3Dgdm], object path = /org/freedesktop/PolicyKit1/AuthenticationAgent, locale = en_US.UTF-8)<o:p></o:p>Mar 17 15:22:13 test06 = gdm-ovirtcred]: pam_sss(gdm-ovirtcred:auth): authentication failure; = logname=3D uid=3D0 euid=3D0 tty=3D ruser=3D rhost=3D = user=3Dtest6<o:p></o:p>Mar 17 15:22:13 test06 gdm-ovirtcred]: = pam_sss(gdm-ovirtcred:auth): received for user test6: 17 (Failure = setting user credentials)<o:p></o:p><o:p> </o:p>/var/log/sssd/krb5_child.log (debug-level = 10)<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [[sssd[krb5_child[2575]]]] [get_and_save_tgt] (0x0020): 1234: = [-1765328360][Preauthentication failed]<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [[sssd[krb5_child[2575]]]] [map_krb5_error] (0x0020): 1303: = [-1765328360][Preauthentication failed]<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [[sssd[krb5_child[2575]]]] [k5c_send_data] (0x0200): Received = error code 1432158215<o:p></o:p>(Thu = Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [pack_response_packet] = (0x2000): response packet size: [4]<o:p></o:p>(Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] = [k5c_send_data] (0x4000): Response sent.<o:p></o:p>(Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] = [main] (0x0400): krb5_child completed successfully<o:p></o:p><o:p> </o:p>/var/log/sssd/sssd_DOMAIN.COM.log (debug-level = 10)<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [be_pam_handler] (0x0100): Got request with the = following data<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): command: = PAM_AUTHENTICATE<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): domain: = DOMAIN.COM<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): user: = test6<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): service: = gdm-ovirtcred<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): = tty:<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): = ruser:<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): = rhost:<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): authtok type: = 1<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): newauthtok type: = 0<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): priv: = 1<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): cli_pid: = 2570<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): logon name: not = set<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [krb5_auth_queue_send] (0x1000): Wait queue of = user [test6] is empty, running request [0x7fe30df03cc0] = immediately.<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [sssd[be[DOMAIN.COM]]] [krb5_setup] (0x4000): No mapping for: = test6<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Added timed event = "ltdb_callback": 0x7fe30df07120<o:p></o:p><o:p> </o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Added timed event = "ltdb_timeout": 0x7fe30df16590<o:p></o:p><o:p> </o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Running timer = event 0x7fe30df07120 "ltdb_callback"<o:p></o:p><o:p> </o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Destroying timer = event 0x7fe30df16590 "ltdb_timeout"<o:p></o:p><o:p> </o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Ending timer event = 0x7fe30df07120 "ltdb_callback"<o:p></o:p><o:p> </o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [fo_resolve_service_send] = (0x0100): Trying to resolve service 'IPA'<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [get_server_status] (0x1000): Status of server 'ipa01.DOMAIN.COM' is = 'working'<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [get_port_status] (0x1000): Port status of port = 389 for server 'ipa01.DOMAIN.COM' is 'working'<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 = seconds<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [resolve_srv_send] (0x0200): The status of SRV = lookup is resolved<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [get_server_status] (0x1000): = Status of server 'ipa01.DOMAIN.COM' is 'working'<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [be_resolve_server_process] (0x1000): Saving the first resolved = server<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [be_resolve_server_process] (0x0200): Found = address for server ipa01.DOMAIN.COM: [10.0.1.21] TTL = 1200<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [ipa_resolve_callback] (0x0400): Constructed uri = 'ldap://ipa01.DOMAIN.COM'<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sss_krb5_realm_has_proxy] = (0x0040): profile_get_values failed.<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [child_handler_setup] (0x2000): Setting up signal handler up for pid = [2575]<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [child_handler_setup] (0x2000): Signal handler = set up for pid [2575]<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [write_pipe_handler] (0x0400): All = data has been sent!<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [child_sig_handler] (0x1000): = Waiting for child [2575].<o:p></o:p><o:p> </o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [child_sig_handler] (0x0100): = child [2575] finished successfully.<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [read_pipe_handler] (0x0400): EOF received, client = finished<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [check_wait_queue] (0x1000): Wait queue for user = [test6] is empty.<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [krb5_auth_queue_done] (0x1000): = krb5_auth_queue request [0x7fe30df03cc0] done.<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_id_op_connect_step] (0x4000): reusing cached = connection<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_print_server] (0x2000): Searching = 10.0.1.21<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x0400): calling = ldap_search_ext with = [(&(cn=3DipaConfig)(objectClass=3DipaGuiConfig))][cn=3Detc,dc=3DDOMAI= N,dc=3Dcom].<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x1000): = Requesting attrs: [ipaMigrationEnabled]<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_get_generic_ext_step] (0x1000): Requesting attrs: = [ipaSELinuxUserMapDefault]<o:p></o:p>(Thu Mar = 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] = (0x1000): Requesting attrs: [ipaSELinuxUserMapOrder]<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid =3D = 122<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_op_add] (0x2000): New operation 122 timeout = 60<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: = sh[0x7fe30deef090], connected[1], ops[0x7fe30df094a0], = ldap[0x7fe30def2920]<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_message] (0x4000): = Message type: [LDAP_RES_SEARCH_ENTRY]<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_parse_entry] (0x1000): OriginalDN: = [cn=3DipaConfig,cn=3Detc,dc=3DDOMAIN,dc=3Dcom].<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_parse_range] (0x2000): No sub-attributes for = [ipaMigrationEnabled]<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_parse_range] (0x2000): No = sub-attributes for [ipaSELinuxUserMapDefault]<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_parse_range] (0x2000): No sub-attributes for = [ipaSELinuxUserMapOrder]<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): = Trace: sh[0x7fe30deef090], connected[1], ops[0x7fe30df094a0], = ldap[0x7fe30def2920]<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_message] (0x4000): = Message type: [LDAP_RES_SEARCH_RESULT]<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no = errmsg set<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_op_destructor] (0x2000): Operation 122 = finished <o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_id_op_destroy] (0x4000): releasing = operation connection <o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ipa_get_migration_flag_done] = (0x0100): Password migration is not enabled. <o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [sssd[be[DOMAIN.COM]]] [be_pam_handler_callback] (0x0100): Backend = returned: (0, 17, <NULL>) [Success (Failure setting user = credentials)] <o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_pam_handler_callback] = (0x0100): Sending result [17][DOMAIN.COM] <o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [be_pam_handler_callback] (0x0100): Sent result [17][DOMAIN.COM] = <o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: = sh[0x7fe30deef090], connected[1], ops[(nil)], ldap[0x7fe30def2920] = <o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: = ldap_result found nothing!<o:p></o:p><o:p> </o:p> = <o:p></o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p></div></body></html> ------=_NextPart_000_0050_01D18069.35C995E0--

8 years, 2 months

2
5
0 / 0

Changing gateway ping address

by Matteo

Hi all, I need to change the gateway ping address, the one used by hosted engine setup. Is ok to edit /etc/ovirt-hosted-engine/hosted-engine.conf on each node, update the gateway param with the new ip address and restart the agent&broker on each node? With a blind test seems ok, but need to understand if is the right procedure. Thanks, Matteo

8 years, 3 months

4
7
0 / 0

[ovirt-shell] update hostnic/nic ???

by Bloemen, Jurriën

--_000_5697777B2050209dmcamcnetworkscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkZpcnN0IEkgY3JlYXRlZCBhIGJvbmRpbmcgaW50ZXJmYWNlOg0KDQojIGFkZCBuaWMg LS1wYXJlbnQtaG9zdC1uYW1lIHNlcnZlcjAxIC0tbmFtZSBib25kMCAtLW5ldHdvcmstbmFtZSBW TEFONjAyIC0tYm9uZGluZy1zbGF2ZXMtaG9zdF9uaWMgaG9zdF9uaWMubmFtZT1lbm8xIC0tYm9u ZGluZy1zbGF2ZXMtaG9zdF9uaWMgaG9zdF9uaWMubmFtZT1lbm8yDQoNClRoaXMgd29ya3MgZ3Jl YXQgYnV0IG5vIElQIGlzIHNldCBvbiBWTEFONjAyLg0KDQpUaGVuIEknbSB0cnlpbmcgdG8gYWRk IGFuIGlwIGFkZHJlc3MgdG8gYSBuZXR3b3JrIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5kOg0K DQojIHVwZGF0ZSBob3N0bmljIC0tcGFyZW50LWhvc3QtbmFtZSBzZXJ2ZXIwMSAtLW5ldHdvcmst bmFtZSBWTEFONjAyIC0tYm9vdF9wcm90b2NvbCBzdGF0aWMgLS1pcC1hZGRyZXNzIDEwLjEwLjEw LjEwIC0taXAtbmV0bWFzayAyNTUuMjU1LjI1NS4wDQoNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IEVSUk9SID09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgd3JvbmcgbnVtYmVyIG9mIGFyZ3VtZW50cywgdHJ5ICdoZWxwIHVwZGF0ZScgZm9yIGhl bHAuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KDQpMb29raW5nIGF0IHRoaXMgZG9jdW1lbnQgaHR0cHM6Ly9hY2Nlc3MucmVkaGF0LmNvbS9k b2N1bWVudGF0aW9uL2VuLVVTL1JlZF9IYXRfRW50ZXJwcmlzZV9WaXJ0dWFsaXphdGlvbi8zLjYt QmV0YS9odG1sL1JIRVZNX1NoZWxsX0d1aWRlL25pYy5odG1sIEkgbmVlZCB0byB1c2UgIm5pYyIg aW5zdGVhZCBvZiAiaG9zdG5pYyIgYnV0IHRoZW4gSSBkb24ndCBoYXZlIHRoZSBvcHRpb25zIHRv IHNheSB0aGlzIGlzIGEgLS1wYXJlbnQtaG9zdC1uYW1lLiBPbmx5IFZNIHJlbGF0ZWQgY29tbWFu ZCBvcHRpb25zLg0KDQpTbyBJIHRoaW5rIHRoZSBkb2N1bWVudGF0aW9uIGlzIGJlaGluZC4NCg0K Q2FuIHNvbWVib2R5IGhlbHAgbWUgd2l0aCB3aGF0IHRoZSBjb21tYW5kIGlzIHRvIGFkZCBhIElQ IHRvIGEgVkxBTi9OZXR3b3JrIGZvciBhIGhvc3Q/DQoNCg0KLS0NCktpbmQgcmVnYXJkcywNCg0K SnVycmnDq24gQmxvZW1lbg0KDQpUaGlzIG1lc3NhZ2UgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVu dHMpIG1heSBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgcHJpdmlsZWdlZCBvciBjb25maWRl bnRpYWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgZW1haWwgaW1tZWRpYXRlbHkgZnJvbSB5b3Vy IHN5c3RlbXMgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiBpdC4gWW91IG1heSBub3QsIGRpcmVj dGx5IG9yIGluZGlyZWN0bHksIHVzZSwgZGlzY2xvc2UsIGRpc3RyaWJ1dGUsIHByaW50IG9yIGNv cHkgdGhpcyBlbWFpbCBvciBhbnkgcGFydCBvZiBpdCBpZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50DQo= --_000_5697777B2050209dmcamcnetworkscom_ Content-Type: text/html; charset="utf-8" Content-ID: <DED479EC8EDE1E4F9CD5EE636812330C(a)chellomedia.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHRleHQ9IiMwMDAwMDAi IGJnY29sb3I9IiNGRkZGRkYiPg0KPHR0PkhpLDxicj4NCjxicj4NCkZpcnN0IEkgY3JlYXRlZCBh IGJvbmRpbmcgaW50ZXJmYWNlOjxicj4NCjxicj4NCiMgYWRkIG5pYyAtLXBhcmVudC1ob3N0LW5h bWUgc2VydmVyMDEgLS1uYW1lIGJvbmQwIC0tbmV0d29yay1uYW1lIFZMQU42MDIgLS1ib25kaW5n LXNsYXZlcy1ob3N0X25pYyBob3N0X25pYy5uYW1lPWVubzEgLS1ib25kaW5nLXNsYXZlcy1ob3N0 X25pYyBob3N0X25pYy5uYW1lPWVubzI8YnI+DQo8YnI+DQpUaGlzIHdvcmtzIGdyZWF0IGJ1dCBu byBJUCBpcyBzZXQgb24gVkxBTjYwMi48YnI+DQo8YnI+DQpUaGVuIEknbSB0cnlpbmcgdG8gYWRk IGFuIGlwIGFkZHJlc3MgdG8gYSBuZXR3b3JrIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5kOjxi cj4NCjxicj4NCiMgdXBkYXRlIGhvc3RuaWMgLS1wYXJlbnQtaG9zdC1uYW1lIHNlcnZlcjAxIC0t bmV0d29yay1uYW1lIFZMQU42MDIgLS1ib290X3Byb3RvY29sIHN0YXRpYyAtLWlwLWFkZHJlc3Mg MTAuMTAuMTAuMTAgLS1pcC1uZXRtYXNrIDI1NS4yNTUuMjU1LjA8YnI+DQo8YnI+DQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSBFUlJPUiA9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg d3JvbmcgbnVtYmVyIG9mIGFyZ3VtZW50cywgdHJ5ICdoZWxwIHVwZGF0ZScgZm9yIGhlbHAuPGJy Pg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08 YnI+DQo8YnI+DQpMb29raW5nIGF0IHRoaXMgZG9jdW1lbnQgPGEgY2xhc3M9Im1vei10eHQtbGlu ay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly9hY2Nlc3MucmVkaGF0LmNvbS9kb2N1bWVudGF0aW9u L2VuLVVTL1JlZF9IYXRfRW50ZXJwcmlzZV9WaXJ0dWFsaXphdGlvbi8zLjYtQmV0YS9odG1sL1JI RVZNX1NoZWxsX0d1aWRlL25pYy5odG1sIj4NCmh0dHBzOi8vYWNjZXNzLnJlZGhhdC5jb20vZG9j dW1lbnRhdGlvbi9lbi1VUy9SZWRfSGF0X0VudGVycHJpc2VfVmlydHVhbGl6YXRpb24vMy42LUJl dGEvaHRtbC9SSEVWTV9TaGVsbF9HdWlkZS9uaWMuaHRtbDwvYT4gSSBuZWVkIHRvIHVzZSAmcXVv dDtuaWMmcXVvdDsgaW5zdGVhZCBvZiAmcXVvdDtob3N0bmljJnF1b3Q7IGJ1dCB0aGVuIEkgZG9u J3QgaGF2ZSB0aGUgb3B0aW9ucyB0byBzYXkgdGhpcyBpcyBhIC0tcGFyZW50LWhvc3QtbmFtZS4g T25seSBWTSByZWxhdGVkIGNvbW1hbmQNCiBvcHRpb25zLjxicj4NCjxicj4NClNvIEkgdGhpbmsg dGhlIGRvY3VtZW50YXRpb24gaXMgYmVoaW5kLiA8YnI+DQo8YnI+DQpDYW4gc29tZWJvZHkgaGVs cCBtZSB3aXRoIHdoYXQgdGhlIGNvbW1hbmQgaXMgdG8gYWRkIGEgSVAgdG8gYSBWTEFOL05ldHdv cmsgZm9yIGEgaG9zdD88YnI+DQo8YnI+DQo8YnI+DQo8L3R0Pg0KPGRpdiBjbGFzcz0ibW96LXNp Z25hdHVyZSI+LS0gPGJyPg0KPHRpdGxlPjwvdGl0bGU+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4 OyBmb250LWZhbWlseToNCiAgICAgICAgICBDYWxpYnJpLCBzYW5zLXNlcmlmOyBtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7Ij4NCjxiPjxmb250IGZhY2U9IkFyaWFsLHNhbnMtc2VyaWYiIGNvbG9y PSIjMmM4Y2I2Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+Szwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOg0KICAgICAgICAgICAgICAgIDEzcHg7Ij5pPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7Ij5uZCByZWdhcmRzLDwvc3Bhbj48L2ZvbnQ+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 Og0KICAgICAgICAgIENhbGlicmksIHNhbnMtc2VyaWY7IG1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFs LCBzYW5zLXNlcmlmOw0KICAgICAgICAgICAgICBjb2xvcjogcmdiKDQ0LCAxNDAsIDE4Mik7Ij4m bmJzcDs8L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXNp emU6IDE0cHg7IGZvbnQtZmFtaWx5Og0KICAgICAgICAgIENhbGlicmksIHNhbnMtc2VyaWY7IG1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiPg0KPGIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7DQogICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYig0NCwgMTQwLCAxODIpOyI+SnVycmnDq24gQmxv ZW1lbjwvc3Bhbj48L2I+PGIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCiAgICAgICAg ICAgICAgY29sb3I6IGdyYXk7Ij48YnI+DQo8L3NwYW4+PC9iPjxmb250IGZhY2U9IkFyaWFsLHNh bnMtc2VyaWYiIGNvbG9yPSIjODA4MDgwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+ PC9zcGFuPjwvZm9udD48L3A+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KVGhpcyBtZXNzYWdlIChp bmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlz IHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGVtYWls IGltbWVkaWF0ZWx5IGZyb20geW91ciBzeXN0ZW1zIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2Yg aXQuIFlvdSBtYXkgbm90LA0KIGRpcmVjdGx5IG9yIGluZGlyZWN0bHksIHVzZSwgZGlzY2xvc2Us IGRpc3RyaWJ1dGUsIHByaW50IG9yIGNvcHkgdGhpcyBlbWFpbCBvciBhbnkgcGFydCBvZiBpdCBp ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5697777B2050209dmcamcnetworkscom_--

8 years, 5 months

3
10
0 / 0

upgrade hosted-engine os ( not hosts )

by Paul Groeneweg | Pazion

I am looking for a way to get my hosted-engine running on el7 so I can upgrade to oVirt 4.0. Currently my hosts already run el7, but my hosted-engine is still el6. I read https://www.ovirt.org/documentation/how-to/hosted-engine-host-OS-upgrade/ but this is only about the hosts. I read https://www.ovirt.org/documentation/how-to/hosted-engine/, but it only mentions upgrade of the hosted-engine software, not the OS. I understood I can do a fresh hosted-engine install, and then import my storage domain to the new hosted engine, but: - Do I need to restore my hosted engine database? ( like described here: http://www.ovirt.org/develop/developer-guide/engine/migrate-to-hosted-eng... ) - Can I directly install hosted-engine 4.0 and then import the storage domain? Or should I install same hosted-engine version? - Do I first need another master storage domain or can I directly import my old master storage domain? - When importing the storage domain what is the risk it fails ( I have backups, but it would cost a day to restore all ) - How long would import take? few minutes or hours? ( I want to keep down time as low as possible ). Another option would be upgrade the OS ( with redhat-upgrade-tool ) or is this a path for disaster? I hope someone can tell me how I can smoothly upgrade my hosted-engine up to el7 and run oVirt 4.

8 years, 5 months

4
16
0 / 0

can't import vm from KVM host

by Nelson Lameiras

Hello, I'm trying to import virtual machines from a KVM host (centos 7.2) to an oVirt 4.0.2 Cluster using the "import" feature on GUI. If the original VM is using RAW/QCOW2 files as storage, everything works fine. But if the original VM is using a special block special device as storage (like a LVM or SAN volume), it's simply not recognized. The VM does appear in the import list of the KVM host, but it's disk count is 0! Is this a known technical obstacle or am I doing something wrong ? below is the storage part of the xml describing the original VM : <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source dev='/dev/mapper/vg_01-lv_sys'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </disk> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source dev='/dev/sdc'/> <target dev='vdb' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </disk> We have hundreds of virtual machines in production with this type of configuration... How can we migrate them safely to oVirt? thanks Nelson

8 years, 7 months

4
30
0 / 0

Storage VLAN Issue

by Kendal Montgomery

--_000_0366DCE80EE9443B80C6E891426FBB27cbuscollaboratorycom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGp1c3QgcmVjZW50bHkgc3RhcnRlZCB0ZXN0aW5nIG91dCBvVmlydCBpbiBv dXIgbGFiLiAgSeKAmW0gdXNpbmcgQ2VudE9TIDcgb24gbXkgaG9zdHMgYW5kIHVzaW5nIHRoZSBo b3N0ZWQtZW5naW5lIG1vZGVsLCBhbmQgdGhlIG9WaXJ0IDMuNiByZXBvc2l0b3J5LiAgSSBoYXZl IE5GUyBzdG9yYWdlLiAgSSByYW4gYWNyb3NzIHdoYXQgSSB0aGluayBpcyBhIGJ1ZyBvZiBzb21l IHNvcnQsIGFuZCBJ4oCZbSBjdXJpb3VzIGlmIGFueW9uZSBlbHNlIGhhcyB0cmllZCB0aGlzIG9y IGtub3cgd2hhdOKAmXMgZ29pbmcgb24uDQoNCkkgd2FudGVkIHRvIGJlIGFibGUgdG8gZXhwb3Nl IHRoZSBORlMgc2VydmVyIChub3QgbmVjZXNzYXJpbHkgdGhlIHNoYXJlIHVzZWQgZm9yIG9WaXJ0 IHN0b3JhZ2UgZG9tYWlucywgYnV0IG90aGVyIHNoYXJlcyBvbiB0aGUgTkZTIHNlcnZlcikgdG8g Vk1zIHJ1bm5pbmcgb24gbXkgaG9zdCAoY3VycmVudGx5IG15IHNldHVwIG9ubHkgaW52b2x2ZXMg YSBzaW5nbGUgaG9zdCkuIEkgaGF2ZSB0d28gMTBHYmFzZVQgaW50ZXJmYWNlZCBib25kZWQgdG9n ZXRoZXIgb24gdGhlIGhvc2Ugd2l0aCB0d28gVkxBTiBuZXR3b3JrcyBvbiBpdCBjdXJyZW50bHks IG9uZSBmb3IgdGhlIG1hbmFnZW1lbnQgbmV0d29yaywgb25lIGZvciBzdG9yYWdlLiAgV2hlbiB0 aGUgaG9zdGVkLWVuZ2luZSBkZXBsb3ltZW50IHdhcyBzZXQgdXAsIEkgZW5kZWQgdXAgd2l0aCBh biBvdmlydG1nbXQgaW50ZXJmYWNlIHRoYXQgd2FzIGJyaWRnZWQgdG8gbXkgaW5mcmFzdHJ1Y3R1 cmUgdmxhbiBpbnRlcmZhY2UgKHZsYW4gMTA4MCkuICBTbywgSSBhZGRlZCBhbm90aGVyIG5ldHdv cmsgaW4gbXkgb1ZpcnQgY2x1c3RlciBuYW1lZCBWTS1TdG9yYWdlIHdpdGggdmxhbiAxMDkyICht eSBzdG9yYWdlIG5ldHdvcmspLiAgSGVyZSBpcyBhcHByb3hpbWF0ZWx5IGhvdyBJIGV4cGVjdGVk IHRoaXMgdG8gZW5kIHVwOg0KDQpib25kMCAtIChib25kZWQgaW50ZXJmYWNlKQ0KICAtIGJvbmQw LjEwOTIgKFNUT1JBR0UgLSB2bGFuIGludGVyZmFjZSkNCiAgICAgLSBWTS1zdG9yYWdlIChicmlk Z2VkIGludGVyZmFjZSkNCiAgLSBib25kMC4xMDgwIChJTkZSIC0gdmFuIGludGVyZmFjZSkNCiAg ICAtIG92aXJ0bWdtdCAoYnJpZGdlZCBpbnRlcmZhY2UpDQoNCkhvd2V2ZXIsIHdoZW4gSSBkaWQg bmV0d29yayBzZXR1cCBvbiB0aGUgaG9zdCwgYW5kIGRyYWdnZWQgdGhlIFZNLVN0b3JhZ2UgbmV0 d29yayBvdmVyIHRvIHRoZSBuZXR3b3JrIGludGVyZmFjZSBhbmQgaGl0IE9LLCB0aGUgVUkganVz dCBmcm96ZSwgYW5kIGZvciBhIGZldyBzZWNvbmRzIEkgY2hlY2tlZCBvbiB0aGUgaG9zdCB2aWEg c3NoIHNlc3Npb24gYW5kIHRoZSBWTS1zdG9yYWdlIGJyaWRnZSB3YXMgc2V0dXAsIHRoZW4gdGhl IHNlcnZlciBqdXN0IHJlYm9vdGVkLiAgQWZ0ZXIgaXQgcmVib290ZWQsIG15IHZsYW4gaW50ZXJm YWNlIHdhcyBubyBsb25nZXIgdGhlcmUgYW5kIGl0IHNlZW1zIGxpa2UgYm90aCB0aGUgaG9zdGVk IGVuZ2luZSBWTSBhbmQgdGhlIGhvc3QgZW5kZWQgdXAgYmVpbmcgcmVib290ZWQuICBJbiB0aGlu a2luZyBhYm91dCBpdCwgSSBtYXkgaGF2ZSBjYXVzZWQgYXQgbGVhc3QgYSB0ZW1wb3Jhcnkgb3V0 YWdlIHdpdGggbXkgTkZTIHN0b3JhZ2Ugd2hlbiB0aGUgbmV3IGJyaWRnZWQgaW50ZXJmYWNlIHdh cyBzZXQgdXAgd2hpY2ggY2F1c2VkIChtYXliZSkgdGhlIEhBIGFnZW50IHRvIHRoaW5rIHRoZSBo b3N0ZWQgZW5naW5lIHZtIHdlbnQgYXdheSBvciBzb21ldGhpbmcsIGFuZCB0aGF0IGNhdXNlIHRo ZSByZWJvb3RzLiAgTm90IGVudGlyZWx5IHN1cmUsIGJ1dCB0aGlzIHdhcyBjZXJ0YWlubHkgdW5l eHBlY3RlZC4gIEkgaGF2ZSB0cmllZCBzZXZlcmFsIHRpbWVzIGFuZCB0aGUgc2FtZSByZXN1bHQg ZWFjaCB0aW1lLg0KDQpJIGRpZCBjaGVjayB0aGF0IGFueSBvdGhlciBWTSBuZXR3b3JrIHdpdGgg YSBkaWZmZXJlbnQgVkxBTiBJRCBwcm92aXNpb25zIGp1c3QgZmluZSBvbiB0aGUgaG9zdCwgc28g SSBhc3N1bWUgdGhlcmXigJlzIHNvbWV0aGluZyB0aGF0IGhhcHBlbnMgd2hlbiB0aGlzIHN0b3Jh Z2UgbmV0d29yayBpcyBwcm92aXNpb25lZCB0aGF0IGlzIGNhdGNoaW5nIG9WaXJ0IG9mZi1ndWFy ZCBzb21laG93Lg0KDQpBbnlvbmUgZWxzZSBoYXZlIHRoaXMgaXNzdWUgYmVmb3JlPyAgQ2FuIEkg c29sdmUgdGhpcyBieSBhZGRpbmcgYW5vdGhlciBob3N0LCB0aGVuIG1vdmluZyB0aGUgaG9zdGVk LWVuZ2luZSB0byBhIGRpZmZlcmVudCBob3N0IHdoaWxlIEkgYWRkIHRoZSBzdG9yYWdlIG5ldHdv cmsgdG8gZWFjaCBob3N0Pw0KDQpUaGFua3MuDQoNCktlbmRhbCBNb250Z29tZXJ5DQpMYWIgTWFu YWdlcg0KTzogNjE0LjQwNy41NTg0IHwgTTogNjE0LjU3MS4wMTcyDQprbW9udGdvbWVyeUBjYnVz Y29sbGFib3JhdG9yeS5jb208bWFpbHRvOmttb250Z29tZXJ5QGNidXNjb2xsYWJvcmF0b3J5LmNv bT4NCg0K --_000_0366DCE80EE9443B80C6E891426FBB27cbuscollaboratorycom_ Content-Type: text/html; charset="utf-8" Content-ID: <91F0E571AB281F44B836DAD9F2229895(a)namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBhbGws PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5JIGp1c3QgcmVjZW50bHkgc3RhcnRlZCB0ZXN0aW5nIG91dCBvVmlydCBpbiBvdXIgbGFiLiAm bmJzcDtJ4oCZbSB1c2luZyBDZW50T1MgNyBvbiBteSBob3N0cyBhbmQgdXNpbmcgdGhlIGhvc3Rl ZC1lbmdpbmUgbW9kZWwsIGFuZCB0aGUgb1ZpcnQgMy42IHJlcG9zaXRvcnkuICZuYnNwO0kgaGF2 ZSBORlMgc3RvcmFnZS4gJm5ic3A7SSByYW4gYWNyb3NzIHdoYXQgSSB0aGluayBpcyBhIGJ1ZyBv ZiBzb21lIHNvcnQsIGFuZCBJ4oCZbSBjdXJpb3VzIGlmIGFueW9uZQ0KIGVsc2UgaGFzIHRyaWVk IHRoaXMgb3Iga25vdyB3aGF04oCZcyBnb2luZyBvbi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgd2FudGVkIHRvIGJlIGFibGUgdG8g ZXhwb3NlIHRoZSBORlMgc2VydmVyIChub3QgbmVjZXNzYXJpbHkgdGhlIHNoYXJlIHVzZWQgZm9y IG9WaXJ0IHN0b3JhZ2UgZG9tYWlucywgYnV0IG90aGVyIHNoYXJlcyBvbiB0aGUgTkZTIHNlcnZl cikgdG8gVk1zIHJ1bm5pbmcgb24gbXkgaG9zdCAoY3VycmVudGx5IG15IHNldHVwIG9ubHkgaW52 b2x2ZXMgYSBzaW5nbGUgaG9zdCkuIEkgaGF2ZSB0d28gMTBHYmFzZVQgaW50ZXJmYWNlZA0KIGJv bmRlZCB0b2dldGhlciBvbiB0aGUgaG9zZSB3aXRoIHR3byBWTEFOIG5ldHdvcmtzIG9uIGl0IGN1 cnJlbnRseSwgb25lIGZvciB0aGUgbWFuYWdlbWVudCBuZXR3b3JrLCBvbmUgZm9yIHN0b3JhZ2Uu ICZuYnNwO1doZW4gdGhlIGhvc3RlZC1lbmdpbmUgZGVwbG95bWVudCB3YXMgc2V0IHVwLCBJIGVu ZGVkIHVwIHdpdGggYW4gb3ZpcnRtZ210IGludGVyZmFjZSB0aGF0IHdhcyBicmlkZ2VkIHRvIG15 IGluZnJhc3RydWN0dXJlIHZsYW4gaW50ZXJmYWNlDQogKHZsYW4gMTA4MCkuICZuYnNwO1NvLCBJ IGFkZGVkIGFub3RoZXIgbmV0d29yayBpbiBteSBvVmlydCBjbHVzdGVyIG5hbWVkIFZNLVN0b3Jh Z2Ugd2l0aCB2bGFuIDEwOTIgKG15IHN0b3JhZ2UgbmV0d29yaykuICZuYnNwO0hlcmUgaXMgYXBw cm94aW1hdGVseSBob3cgSSBleHBlY3RlZCB0aGlzIHRvIGVuZCB1cDo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmJvbmQwIC0gKGJvbmRl ZCBpbnRlcmZhY2UpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAtIGJvbmQwLjEwOTIgKFNU T1JBR0UgLSB2bGFuIGludGVyZmFjZSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDstIFZNLXN0b3JhZ2UgKGJyaWRnZWQgaW50ZXJmYWNlKTwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4mbmJzcDsgLSBib25kMC4xMDgwIChJTkZSIC0gdmFuIGludGVyZmFjZSk8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAtIG92aXJ0bWdtdCAoYnJpZGdlZCBpbnRlcmZhY2Up PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5Ib3dldmVyLCB3aGVuIEkgZGlkIG5ldHdvcmsgc2V0dXAgb24gdGhlIGhvc3QsIGFuZCBkcmFn Z2VkIHRoZSBWTS1TdG9yYWdlIG5ldHdvcmsgb3ZlciB0byB0aGUgbmV0d29yayBpbnRlcmZhY2Ug YW5kIGhpdCBPSywgdGhlIFVJIGp1c3QgZnJvemUsIGFuZCBmb3IgYSBmZXcgc2Vjb25kcyBJIGNo ZWNrZWQgb24gdGhlIGhvc3QgdmlhIHNzaCBzZXNzaW9uIGFuZCB0aGUgVk0tc3RvcmFnZSBicmlk Z2Ugd2FzIHNldHVwLCB0aGVuDQogdGhlIHNlcnZlciBqdXN0IHJlYm9vdGVkLiAmbmJzcDtBZnRl ciBpdCByZWJvb3RlZCwgbXkgdmxhbiBpbnRlcmZhY2Ugd2FzIG5vIGxvbmdlciB0aGVyZSBhbmQg aXQgc2VlbXMgbGlrZSBib3RoIHRoZSBob3N0ZWQgZW5naW5lIFZNIGFuZCB0aGUgaG9zdCBlbmRl ZCB1cCBiZWluZyByZWJvb3RlZC4gJm5ic3A7SW4gdGhpbmtpbmcgYWJvdXQgaXQsIEkgbWF5IGhh dmUgY2F1c2VkIGF0IGxlYXN0IGEgdGVtcG9yYXJ5IG91dGFnZSB3aXRoIG15IE5GUyBzdG9yYWdl IHdoZW4NCiB0aGUgbmV3IGJyaWRnZWQgaW50ZXJmYWNlIHdhcyBzZXQgdXAgd2hpY2ggY2F1c2Vk IChtYXliZSkgdGhlIEhBIGFnZW50IHRvIHRoaW5rIHRoZSBob3N0ZWQgZW5naW5lIHZtIHdlbnQg YXdheSBvciBzb21ldGhpbmcsIGFuZCB0aGF0IGNhdXNlIHRoZSByZWJvb3RzLiAmbmJzcDtOb3Qg ZW50aXJlbHkgc3VyZSwgYnV0IHRoaXMgd2FzIGNlcnRhaW5seSB1bmV4cGVjdGVkLiAmbmJzcDtJ IGhhdmUgdHJpZWQgc2V2ZXJhbCB0aW1lcyBhbmQgdGhlIHNhbWUgcmVzdWx0DQogZWFjaCB0aW1l LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+SSBkaWQgY2hlY2sgdGhhdCBhbnkgb3RoZXIgVk0gbmV0d29yayB3aXRoIGEgZGlmZmVyZW50 IFZMQU4gSUQgcHJvdmlzaW9ucyBqdXN0IGZpbmUgb24gdGhlIGhvc3QsIHNvIEkgYXNzdW1lIHRo ZXJl4oCZcyBzb21ldGhpbmcgdGhhdCBoYXBwZW5zIHdoZW4gdGhpcyBzdG9yYWdlIG5ldHdvcmsg aXMgcHJvdmlzaW9uZWQgdGhhdCBpcyBjYXRjaGluZyBvVmlydCBvZmYtZ3VhcmQgc29tZWhvdy48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkFueW9uZSBlbHNlIGhhdmUgdGhpcyBpc3N1ZSBiZWZvcmU/ICZuYnNwO0NhbiBJIHNvbHZlIHRo aXMgYnkgYWRkaW5nIGFub3RoZXIgaG9zdCwgdGhlbiBtb3ZpbmcgdGhlIGhvc3RlZC1lbmdpbmUg dG8gYSBkaWZmZXJlbnQgaG9zdCB3aGlsZSBJIGFkZCB0aGUgc3RvcmFnZSBuZXR3b3JrIHRvIGVh Y2ggaG9zdD88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPlRoYW5rcy48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9 ImZvbnQtc2l6ZTogMTRweDsgbWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyI+PHNwYW4gY2xhc3M9 IiIgc3R5bGU9ImNvbG9yOiByZ2IoMjM3LCAxMDMsIDIxKTsiPjxmb250IGZhY2U9IlRpbWVzIiBz aXplPSIzIiBjbGFzcz0iIj48YiBjbGFzcz0iIj5LZW5kYWwgTW9udGdvbWVyeTwvYj48L2ZvbnQ+ PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48Zm9udCBmYWNlPSJUaW1lcyIgY2xhc3M9IiI+PGIgY2xh c3M9IiI+TGFiIE1hbmFnZXI8L2I+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i Zm9udC1zaXplOiAxNHB4OyBtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7Ij48Zm9udCBmYWNlPSJU aW1lcyIgY2xhc3M9IiI+TzogNjE0LjQwNy41NTg0IHwmbmJzcDtNOiA2MTQuNTcxLjAxNzI8L2Zv bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IG1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsiPjxmb250IGZhY2U9IlRpbWVzIiBjbGFzcz0iIj48YSBocmVmPSJt YWlsdG86a21vbnRnb21lcnlAY2J1c2NvbGxhYm9yYXRvcnkuY29tIiBjbGFzcz0iIj5rbW9udGdv bWVyeUBjYnVzY29sbGFib3JhdG9yeS5jb208L2E+PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0366DCE80EE9443B80C6E891426FBB27cbuscollaboratorycom_--

8 years, 8 months

7
14
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Users August 2016