Re: [ovirt-users] Safe to upgrade HE hosts from GUI?

2016-07-29 Thread Kenneth Bingham
Aw crap. I did exactly the same thing and this could explain a lot of the
issues I've been pulling out my beard over. Every time I did 'hosted-engine
--deploy' on the RHEV-M|NODE host I entered the FQDN of *that* host, not
the first host, as the origin of the Gluster FS volume because at the time
I didn't realize that
a. the manager would key deduplication on the URI of the volume
b. that the volume would be mounted on FUSE, not NFS, and therefore no
single point of entry is created by using the FQDN of the first host
because the GFS client will persist connections with all peers

On Fri, Jul 29, 2016 at 6:08 AM Simone Tiraboschi 
wrote:

> On Fri, Jul 29, 2016 at 11:35 AM, Wee Sritippho 
> wrote:
> > On 29/7/2559 15:50, Simone Tiraboschi wrote:
> >>
> >> On Fri, Jul 29, 2016 at 6:31 AM, Wee Sritippho 
> wrote:
> >>>
> >>> On 28/7/2559 15:54, Simone Tiraboschi wrote:
> >>>
> >>> On Thu, Jul 28, 2016 at 10:41 AM, Wee Sritippho 
> >>> wrote:
> 
>  On 21/7/2559 16:53, Simone Tiraboschi wrote:
> 
>  On Thu, Jul 21, 2016 at 11:43 AM, Wee Sritippho 
>  wrote:
> 
> > Can I just follow
> >
> >
> http://www.ovirt.org/documentation/how-to/hosted-engine/#upgrade-hosted-engine
> > until step 3 and do everything else via GUI?
> 
>  Yes, absolutely.
> 
> 
>  Hi, I upgrade a host (host02) via GUI and now its score is 0.
> Restarted
>  the services but the result is still the same. Kinda lost now. What
>  should I
>  do next?
> 
> >>> Can you please attach ovirt-ha-agent logs?
> >>>
> >>>
> >>> Yes, here are the logs:
> >>> https://app.box.com/s/b4urjty8dsuj98n3ywygpk3oh5o7pbsh
> >>
> >> Thanks Wee,
> >> your issue is here:
> >> MainThread::ERROR::2016-07-17
> >>
> >>
> 14:32:45,586::storage_server::143::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(_validate_pre_connected_path)
> >> The hosted-engine storage domain is already mounted on
> >>
> >> '/rhev/data-center/mnt/glusterSD/host02.ovirt.forest.go.th:
> _hosted__engine/639e689c-8493-479b-a6eb-cc92b6fc4cf4'
> >> with a path that is not supported anymore: the right path should be
> >>
> >> '/rhev/data-center/mnt/glusterSD/host01.ovirt.forest.go.th:
> _hosted__engine/639e689c-8493-479b-a6eb-cc92b6fc4cf4'.
> >>
> >> Did you manually tried to avoid the issue of a single entry point for
> >> the gluster FS volume using host01.ovirt.forest.go.th:_hosted__engine
> >> and host02.ovirt.forest.go.th:_hosted__engine there?
> >> This could cause a lot of confusion since the code could not detect
> >> that the storage domain is the same and you can end with it mounted
> >> twice into different locations and a lot of issues.
> >> The correct solution of that issue was this one:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1298693#c20
> >>
> >> Now, to have it fixed on your env you have to hack a bit.
> >> First step, you have to edit
> >> /etc/ovirt-hosted-engine/hosted-engine.conf on all your hosted-engine
> >> hosts to ensure that the storage field always point to the same entry
> >> point (host01 for instance)
> >> Then on each host you can add something like:
> >>
> >> mnt_options=backupvolfile-server=host02.ovirt.forest.go.th:h
> ost03.ovirt.forest.go.th
> ,fetch-attempts=2,log-level=WARNING,log-file=/var/log/engine_domain.log
> >>
> >> Then check the representation of your storage connection in the table
> >> storage_server_connections of the engine DB and make sure that
> >> connection refers to the entry point you used in hosted-engine.conf on
> >> all your hosts, you have lastly to set the value of mount_options also
> >> here.
> >
> > Weird. The configuration in all hosts are already referring to host01.
>
> but for sure you have a connection pointing to host02 somewhere, did
> you try to manually deploy from CLI connecting the gluster volume on
> host02?
>
> > Also, in the storage_server_connections table:
> >
> > engine=> SELECT * FROM storage_server_connections;
> >   id  | connection|
> > user_name | password | iqn | port | portal | storage_type |
> mount_options |
> > vfs_type
> >  | nfs_version | nfs_timeo | nfs_retrans
> >
> --+--+---+--+-+--++--+---+--
> > -+-+---+-
> >  bd78d299-c8ff-4251-8aab-432ce6443ae8 |
> > host01.ovirt.forest.go.th:/hosted_engine |   | | |  | 1
> > |7 |   | glusterfs
> >  | |   |
> > (1 row)
> >
> >
> >>
> >> Please tune also the value of network.ping-timeout for your glusterFS
> >> volume to avoid this:
> >>   https://bugzilla.redhat.com/show_bug.cgi?id=1319657#c17
> >
> >
> > --
> > Wee
> >
> ___
> Users mailing list
> 

[ovirt-users] Is it is possible to edit the list of Operating Systems for a VM ?

2016-07-29 Thread Peter Michael Calum
Hi,

Does anyone know if it is possible to edit the list of Operating Systems for a 
VM. 
- I'd like it to, for example, "Centos Linux 6.x x64" or "Fedora xx" in this 
list.

Kind regards 
Peter Calum 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Infrastructure Engineers / System Administrator Appreciation Day

2016-07-29 Thread Karli Sjöberg

Den 29 jul 2016 3:30 em skrev Sandro Bonazzola :
>
> Hi,
> I'd like to thank all Infrastructure Engineers / System Administrator[1] 
> working on the oVirt project infrastructure and whish them stable OSs and 
> reliable hardware :-)
> http://sysadminday.com/
>
> Thanks to all Infrastructure Engineers / System Administrator using oVirt, 
> helping users, opening bugs and making oVirt a better community.

Thanks! And if anyone would like to buy me a Tesla out of sheer appreciation, 
I'd definitely consider it:)

/K

>
> [1] http://sysadminday.com/
>
>
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


[ovirt-users] Infrastructure Engineers / System Administrator Appreciation Day

2016-07-29 Thread Sandro Bonazzola
Hi,
I'd like to thank all Infrastructure Engineers / System Administrator[1]
working on the oVirt project infrastructure and whish them stable OSs and
reliable hardware :-)
http://sysadminday.com/

Thanks to all Infrastructure Engineers / System Administrator using oVirt,
helping users, opening bugs and making oVirt a better community.

[1] http://sysadminday.com/


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Debian - based OS and SSO

2016-07-29 Thread Tadas
It seems that gdm3 is trying to start xserver using user, which was
passed to pam-ovirt plugin rights. It fails due lack of permissions on
some devices. After changing permissions a bit, I'm getting following
errors:

Jul 29 14:56:01 jessie gdm3: GdmManager: trying to register new display
Jul 29 14:56:01 jessie gdm3: GdmManager: Error while retrieving session
id for sender: Error getting session id from systemd: No such device or
address
Jul 29 14:56:01 jessie gdm-x-session: Could not register display:
GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No display
available

Okay, after poking around a bit, i've found solution:
On Debian based distros you need this kind of /etc/pam.d/gdm-ovirtcred

#%PAM-1.0
authrequiredpam_ovirt_cred.so
authinclude passwd
account include passwd
passwordinclude passwd
session requiredpam_systemd.so open
session include passwd


Now it seems, that login works just fine.
THank you for your help.
On Fri, 2016-07-29 at 14:41 +0300, Tadas wrote:
> Okay, now its different story. ovirt-agent finally passes through all
> login steps:
> 
> Dummy-1::INFO::2016-07-29
> 14:37:38,088::OVirtAgentLogic::294::root::Received an external
> command:
> login...
> Dummy-1::DEBUG::2016-07-29
> 14:37:38,088::OVirtAgentLogic::328::root::User log-in (credentials =
> '\x00\x00\x00\x04test\x00')
> Dummy-1::INFO::2016-07-29 14:37:38,088::CredServer::207::root::The
> following users are allowed to connect: [0]
> Dummy-1::DEBUG::2016-07-29
> 14:37:38,088::CredServer::272::root::Token:
> 493871
> Dummy-1::INFO::2016-07-29
> 14:37:38,088::CredServer::273::root::Opening
> credentials channel...
> Dummy-1::INFO::2016-07-29
> 14:37:38,089::CredServer::132::root::Emitting
> user authenticated signal (493871).
> CredChannel::DEBUG::2016-07-29
> 14:37:38,159::CredServer::166::root::Receiving user's credential ret
> =
> 2 errno = 0
> CredChannel::DEBUG::2016-07-29
> 14:37:38,159::CredServer::177::root::cmsgp: len=28 level=1 type=2
> CredChannel::INFO::2016-07-29
> 14:37:38,159::CredServer::225::root::Incomming connection from user:
> 0
> process: 4343
> CredChannel::INFO::2016-07-29
> 14:37:38,159::CredServer::232::root::Sending user's credential
> (token:
> 493871)
> Dummy-1::INFO::2016-07-29
> 14:37:38,160::CredServer::277::root::Credentials channel was closed.
> 
> 
> Though gdm3 fails to load session with following error:
> 
> http://paste.ubuntu.com/21392715/
> 
> On Fri, 2016-07-29 at 13:25 +0200, Vinzenz Feenstra wrote:
> > 
> > > 
> > > 
> > > On Jul 29, 2016, at 12:35 PM, Tadas  wrote:
> > > 
> > > There's another interesting error thrown out from ovirt-guest
> > > agent,
> > > when you try to login:
> > > 
> > > 
> > > Jul 29 13:30:24 jessie python[1969]: Exception in thread
> > > CredChannel:
> > > Ju
> > > l 29 13:30:24 jessie python[1969]: Traceback (most recent call
> > > last):
> > > Ju
> > > l 29 13:30:24 jessie python[1969]:   File
> > > "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
> > > Jul 29
> > > 13:30:24 jessie python[1969]: self.run()
> > > Jul 29 13:30:24 jessie
> > > python[1969]:   File "/usr/share/ovirt-guest-
> > > agent/CredServer.py",
> > > line
> > > 217, in run
> > > Jul 29 13:30:24 jessie python[1969]: cred =
> > > self._read_cred(conn)
> > > Jul 29 13:30:24 jessie python[1969]:   File
> > > "/usr/share/ovirt-guest-agent/CredServer.py", line 146, in
> > > _read_cred
> > > Ju
> > > l 29 13:30:24 jessie
> > > python[1969]: conn.setsockopt(socket.SOL_SOCKET,
> > > socket.SO_PASSCRED, 1)
> > > Jul 29 13:30:24 jessie python[1969]:
> > > AttributeError: 'module' object has no attribute ‘SO_PASSCRED'
> > 
> > I knew I forgot about something, yes you’re right - I fixed that
> > manually and continued and forgot about it. 
> > 
> > SO_PASSCRED seems not to be actually available by default on
> > python.
> > The systems we supported so far (excluding the debian based ones)
> > had
> > this constant available.
> > Long story short: You can replace socket.SO_PASSCRED with the value
> > 16 for now and it should work as expected.
> > 
> > 
> > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On Fri, 2016-07-29 at 13:13 +0300, Tadas wrote:
> > > > 
> > > > 
> > > > Yes, it seems that authentication does not work in any of
> > > > debian
> > > > releases. Oh well.
> > > > On Fri, 2016-07-29 at 09:37 +0200, Vinzenz Feenstra wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Jul 28, 2016, at 4:11 PM, Tadas  wrote:
> > > > > > 
> > > > > > Thank you for your reply.
> > > > > > Strange, but i do not see any errors in gdm debug log, just
> > > > > > this:
> > > > > > http://paste.ubuntu.com/21275558/
> > > > > 
> > > > > Well if it works for you, the better. It didn’t work for me
> > > > > though
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  
> > > > > > I will try installing debian unstable and 

Re: [ovirt-users] Debian - based OS and SSO

2016-07-29 Thread Tadas
Okay, now its different story. ovirt-agent finally passes through all
login steps:

Dummy-1::INFO::2016-07-29
14:37:38,088::OVirtAgentLogic::294::root::Received an external command:
login...
Dummy-1::DEBUG::2016-07-29
14:37:38,088::OVirtAgentLogic::328::root::User log-in (credentials =
'\x00\x00\x00\x04test\x00')
Dummy-1::INFO::2016-07-29 14:37:38,088::CredServer::207::root::The
following users are allowed to connect: [0]
Dummy-1::DEBUG::2016-07-29 14:37:38,088::CredServer::272::root::Token:
493871
Dummy-1::INFO::2016-07-29 14:37:38,088::CredServer::273::root::Opening
credentials channel...
Dummy-1::INFO::2016-07-29 14:37:38,089::CredServer::132::root::Emitting
user authenticated signal (493871).
CredChannel::DEBUG::2016-07-29
14:37:38,159::CredServer::166::root::Receiving user's credential ret =
2 errno = 0
CredChannel::DEBUG::2016-07-29
14:37:38,159::CredServer::177::root::cmsgp: len=28 level=1 type=2
CredChannel::INFO::2016-07-29
14:37:38,159::CredServer::225::root::Incomming connection from user: 0
process: 4343
CredChannel::INFO::2016-07-29
14:37:38,159::CredServer::232::root::Sending user's credential (token:
493871)
Dummy-1::INFO::2016-07-29
14:37:38,160::CredServer::277::root::Credentials channel was closed.


Though gdm3 fails to load session with following error:

http://paste.ubuntu.com/21392715/

On Fri, 2016-07-29 at 13:25 +0200, Vinzenz Feenstra wrote:
> > 
> > On Jul 29, 2016, at 12:35 PM, Tadas  wrote:
> > 
> > There's another interesting error thrown out from ovirt-guest
> > agent,
> > when you try to login:
> > 
> > 
> > Jul 29 13:30:24 jessie python[1969]: Exception in thread
> > CredChannel:
> > Ju
> > l 29 13:30:24 jessie python[1969]: Traceback (most recent call
> > last):
> > Ju
> > l 29 13:30:24 jessie python[1969]:   File
> > "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
> > Jul 29
> > 13:30:24 jessie python[1969]: self.run()
> > Jul 29 13:30:24 jessie
> > python[1969]:   File "/usr/share/ovirt-guest-agent/CredServer.py",
> > line
> > 217, in run
> > Jul 29 13:30:24 jessie python[1969]: cred =
> > self._read_cred(conn)
> > Jul 29 13:30:24 jessie python[1969]:   File
> > "/usr/share/ovirt-guest-agent/CredServer.py", line 146, in
> > _read_cred
> > Ju
> > l 29 13:30:24 jessie
> > python[1969]: conn.setsockopt(socket.SOL_SOCKET,
> > socket.SO_PASSCRED, 1)
> > Jul 29 13:30:24 jessie python[1969]:
> > AttributeError: 'module' object has no attribute ‘SO_PASSCRED'
> 
> I knew I forgot about something, yes you’re right - I fixed that
> manually and continued and forgot about it. 
> 
> SO_PASSCRED seems not to be actually available by default on python.
> The systems we supported so far (excluding the debian based ones) had
> this constant available.
> Long story short: You can replace socket.SO_PASSCRED with the value
> 16 for now and it should work as expected.
> 
> 
> 
> > 
> > 
> > 
> > 
> > On Fri, 2016-07-29 at 13:13 +0300, Tadas wrote:
> > > 
> > > Yes, it seems that authentication does not work in any of debian
> > > releases. Oh well.
> > > On Fri, 2016-07-29 at 09:37 +0200, Vinzenz Feenstra wrote:
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > On Jul 28, 2016, at 4:11 PM, Tadas  wrote:
> > > > > 
> > > > > Thank you for your reply.
> > > > > Strange, but i do not see any errors in gdm debug log, just
> > > > > this:
> > > > > http://paste.ubuntu.com/21275558/
> > > > 
> > > > Well if it works for you, the better. It didn’t work for me
> > > > though
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > >  
> > > > > I will try installing debian unstable and several ubuntu
> > > > > versions
> > > > > tomorrow.
> > > > >  
> > > > > From: Vinzenz Feenstra
> > > > > Sent: Thursday, July 28, 2016 4:18 PM
> > > > > To: ta...@ring.lt
> > > > > Cc: users
> > > > > Subject: Re: [ovirt-users] Debian - based OS and SSO
> > > > >  
> > > > >  
> > > > > > 
> > > > > > 
> > > > > > On Jul 28, 2016, at 3:11 PM, Vinzenz Feenstra  > > > > > hat.
> > > > > > co
> > > > > > m> wrote:
> > > > > >  
> > > > > >  
> > > > > > > 
> > > > > > > 
> > > > > > > On Jul 28, 2016, at 11:53 AM, Tadas 
> > > > > > > wrote:
> > > > > > >  
> > > > > > > Hello,
> > > > > > > still having issues with ovirt SSO and Debian OS.
> > > > > > > Other OSes (Windows/Fedora 24) works just fine.
> > > > > > > Some information:
> > > > > > > OS: Debian 8.5 (jessie)
> > > > > > > I've followed manual on https://www.ovirt.org/documentati
> > > > > > > on/h
> > > > > > > ow
> > > > > > > -to/gues
> > > > > > > t-agent/install-the-guest-agent-in-debian/ and installed
> > > > > > > ovirt-
> > > > > > > agent.
> > > > > > > I can get info via spice socket on hypervisor side, this
> > > > > > > means
> > > > > > > that
> > > > > > > agent works fine.
> > > > > > > I've compiled pam-ovirt-cred and copied it into
> > > > > > > /lib/x86_64-
> > > > > > > linux-
> > > > > > > gnu/security/
> > > > > >  
> > > > > > It should 

Re: [ovirt-users] Windows 10 + qemu + Blue Iris = Blue screen

2016-07-29 Thread Michal Skrivanek

> On 22 Jul 2016, at 22:58, Blaster  wrote:
> 
> 
>> On Jul 22, 2016, at 4:27 AM, Michal Skrivanek  
>> wrote:
>> 
>> 
>>> On 21 Jul 2016, at 20:05, Blaster  wrote:
>>> 
>>> I am running an application called Blue Iris which records video from IP 
>>> cameras.
>>> 
>>> This was working great under Ovirt 3.6.3 + Windows 7.  Now I’ve upgraded to 
>>> Windows 10 and as soon as the Blue Iris service starts, the VM blue screens.
>>> 
>>> I talked to the software vendor, and they said it’s not their problem, they 
>>> aren’t doing anything that could cause a blue screen, so it must be  
>>> driver/memory/hardware problem.  They say the application works just fine 
>>> under Windows 10.
>>> 
>>> So thinking maybe the upgrade went bad, I created a new VM, used e1000 and 
>>> IDE interfaces (i.e., no Virtualized hardware or drivers were used) and 
>>> re-installed Blue Iris.
>> 
>> I would expect better luck with virtio drivers. Either way, if it was 
>> working before and not working in Win10 it’s likely related to drivers. Can 
>> you make sure you try latest drivers? Can you pinpoint the blue screen…to 
>> perhaps USB or other subsystem?
>> Might be worth trying on clean Win10 install just to rule out upgrade issues 
>> (I didn’t understand whether you cloned the old VM and just reinstalled blue 
>> iris or reinstalled everything) , and if it still reproduces it is likely 
>> some low level incompatibility in QEMU/KVM. You would likely have to try 
>> experiment with qemu cmdline or use latest qemu and check the qemu mailing 
>> list
>> 
>> Thanks,
>> michal
> 
> Hi Michal, 
> 
> I did try a clean install.  Both an upgrade and a fresh install cause a blue 
> screen.How do I pin point the blue screen?  I’m guessing it’s a QEMU 
> issue with Win 10.  I’m on Fed 22, how do I get a newer QEMU than what’s in 
> the distribution?  or should I just 
> upgrade to Fedora 24?

Hi,
As the next email in the thread mentions, worth trying different CPU family 
(make sure you dont’ use anything too old due like Conroe), or host CPU 
passthrough.
I would certainly suggest to try the qemu-kvm-rhev/ev since it focuses on 
stability. Try RHEL/CentOS host instead of Fedora. 

Thanks,
michal

> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 
> 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Debian - based OS and SSO

2016-07-29 Thread Tadas
As far as I understand, there's something really wrong with credential
check on Debian distribution. ovirt-agent fails to set PASSCRED flag on
socket and thus throws exception. If i try to catch it, it fails
silently and agent is unable to get credentials from pam module via
socket. So it fails credential check.
If I comment out credential validation segment in CredServer.py,
authentication seems to pass, gdm3 tries to load user profile and then
crashes:

http://paste.ubuntu.com/21391057/




On Fri, 2016-07-29 at 13:35 +0300, Tadas wrote:
> There's another interesting error thrown out from ovirt-guest agent,
> when you try to login:
> 
> 
> Jul 29 13:30:24 jessie python[1969]: Exception in thread CredChannel:
> Ju
> l 29 13:30:24 jessie python[1969]: Traceback (most recent call last):
> Ju
> l 29 13:30:24 jessie python[1969]:   File
> "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
> Jul 29
> 13:30:24 jessie python[1969]: self.run()
> Jul 29 13:30:24 jessie
> python[1969]:   File "/usr/share/ovirt-guest-agent/CredServer.py",
> line
> 217, in run
> Jul 29 13:30:24 jessie python[1969]: cred =
> self._read_cred(conn)
> Jul 29 13:30:24 jessie python[1969]:   File
> "/usr/share/ovirt-guest-agent/CredServer.py", line 146, in _read_cred
> Ju
> l 29 13:30:24 jessie
> python[1969]: conn.setsockopt(socket.SOL_SOCKET,
> socket.SO_PASSCRED, 1)
> Jul 29 13:30:24 jessie python[1969]:
> AttributeError: 'module' object has no attribute 'SO_PASSCRED'
> 
> 
> 
> On Fri, 2016-07-29 at 13:13 +0300, Tadas wrote:
> > 
> > Yes, it seems that authentication does not work in any of debian
> > releases. Oh well.
> > On Fri, 2016-07-29 at 09:37 +0200, Vinzenz Feenstra wrote:
> > > 
> > > 
> > > 
> > > > 
> > > > 
> > > > On Jul 28, 2016, at 4:11 PM, Tadas  wrote:
> > > > 
> > > > Thank you for your reply.
> > > > Strange, but i do not see any errors in gdm debug log, just
> > > > this:
> > > > http://paste.ubuntu.com/21275558/
> > > 
> > > Well if it works for you, the better. It didn’t work for me
> > > though
> > > 
> > > 
> > > > 
> > > > 
> > > >  
> > > > I will try installing debian unstable and several ubuntu
> > > > versions
> > > > tomorrow.
> > > >  
> > > > From: Vinzenz Feenstra
> > > > Sent: Thursday, July 28, 2016 4:18 PM
> > > > To: ta...@ring.lt
> > > > Cc: users
> > > > Subject: Re: [ovirt-users] Debian - based OS and SSO
> > > >  
> > > >  
> > > > > 
> > > > > 
> > > > > On Jul 28, 2016, at 3:11 PM, Vinzenz Feenstra  > > > > t.
> > > > > co
> > > > > m> wrote:
> > > > >  
> > > > >  
> > > > > > 
> > > > > > 
> > > > > > On Jul 28, 2016, at 11:53 AM, Tadas  wrote:
> > > > > >  
> > > > > > Hello,
> > > > > > still having issues with ovirt SSO and Debian OS.
> > > > > > Other OSes (Windows/Fedora 24) works just fine.
> > > > > > Some information:
> > > > > > OS: Debian 8.5 (jessie)
> > > > > > I've followed manual on https://www.ovirt.org/documentation
> > > > > > /h
> > > > > > ow
> > > > > > -to/gues
> > > > > > t-agent/install-the-guest-agent-in-debian/ and installed
> > > > > > ovirt-
> > > > > > agent.
> > > > > > I can get info via spice socket on hypervisor side, this
> > > > > > means
> > > > > > that
> > > > > > agent works fine.
> > > > > > I've compiled pam-ovirt-cred and copied it into
> > > > > > /lib/x86_64-
> > > > > > linux-
> > > > > > gnu/security/
> > > > >  
> > > > > It should be in /lib/security afaik
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > I've configured /etc/pamd/gdm-ovirtcred (just copied from
> > > > > > working
> > > > > > Fedora 24)
> > > > >  
> > > > > replace in that file all occurences of password-auth with
> > > > > passwd
> > > > >  
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > But still login fails. I can see this in ovirt-agent log
> > > > > > file:
> > > > >  
> > > > > It some how fails for me in some cases with this now:
> > > > >  
> > > >  
> > > > Correction its here:
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794064
> > > > 
> > > > > 
> > > > > 
> > > > > https://bugs.freedesktop.org/show_bug.cgi?id=71525
> > > > >  
> > > > > There’s not much I can do about that though
> > > > >  
> > > > >  
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Dummy-2::INFO::2016-07-28
> > > > > > 12:49:51,046::OVirtAgentLogic::270::root::Received an
> > > > > > external
> > > > > > command:
> > > > > > login...
> > > > > > Dummy-2::DEBUG::2016-07-28
> > > > > > 12:49:51,047::OVirtAgentLogic::304::root::User log-in
> > > > > > (credentials =
> > > > > > '\x00\x00\x00\x04test\x00')
> > > > > > Dummy-2::INFO::2016-07-28
> > > > > > 12:49:51,047::CredServer::207::root::The
> > > > > > following users are allowed to connect: [0]
> > > > > > Dummy-2::DEBUG::2016-07-28
> > > > > > 12:49:51,047::CredServer::272::root::Token:
> > > > > > 760258
> > > > > > Dummy-2::INFO::2016-07-28
> > > > > > 12:49:51,047::CredServer::273::root::Opening
> > > > > > 

Re: [ovirt-users] How to access ovirt 4.0 desktop from iOS spice client?

2016-07-29 Thread Michal Skrivanek

> On 28 Jul 2016, at 11:34, 敖青云  wrote:
> 
> How can I access ovirt 4.0 desktop from iPad with iOS spice client? As I 
> know, ovirt 4.0 seems not support IP address access.

what do you mean about IP address?
Are you referring to something like this 
https://jfsaucier.wordpress.com/2013/02/03/accessing-your-rhev-vms-with-your-ipad-and-spice/
 ?

> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] ovirt4.0.1 and new node, migration fails

2016-07-29 Thread Michal Skrivanek

> On 28 Jul 2016, at 18:37, Bill James  wrote:
> 
> I'm trying to test out ovirt4.0.1.
> I added a new hardware node to the cluster. Its status is Up.
> But for some reason when I create a new VM and try to select "Specific Host" 
> the radio button doesn't let me select it so I can't assign a VM to new node.

please raise that as a bug if there is no explanation why

> 
> When I try to migrate a VM to new node it fails with:
> 
> MigrationError: Domain not found: no domain with matching uuid 
> '45f4f24b-2dfa-401b-8557-314
> 055a4662c'
> 
> 
> What did I miss?

for migration issues you always need to include vdsm logs from both source and 
destination host. Hard to say otherwise. Anything special about your deployment?

> 
> ovirt-engine-4.0.1.1-1.el7.centos.noarch
> vdsm-4.18.6-1.el7.centos.x86_64
> 
> storage is NFS.
> 
> Attached logs.
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Debian - based OS and SSO

2016-07-29 Thread Tadas
There's another interesting error thrown out from ovirt-guest agent,
when you try to login:


Jul 29 13:30:24 jessie python[1969]: Exception in thread CredChannel:
Ju
l 29 13:30:24 jessie python[1969]: Traceback (most recent call last):
Ju
l 29 13:30:24 jessie python[1969]:   File
"/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
Jul 29
13:30:24 jessie python[1969]: self.run()
Jul 29 13:30:24 jessie
python[1969]:   File "/usr/share/ovirt-guest-agent/CredServer.py", line
217, in run
Jul 29 13:30:24 jessie python[1969]: cred =
self._read_cred(conn)
Jul 29 13:30:24 jessie python[1969]:   File
"/usr/share/ovirt-guest-agent/CredServer.py", line 146, in _read_cred
Ju
l 29 13:30:24 jessie
python[1969]: conn.setsockopt(socket.SOL_SOCKET,
socket.SO_PASSCRED, 1)
Jul 29 13:30:24 jessie python[1969]:
AttributeError: 'module' object has no attribute 'SO_PASSCRED'



On Fri, 2016-07-29 at 13:13 +0300, Tadas wrote:
> Yes, it seems that authentication does not work in any of debian
> releases. Oh well.
> On Fri, 2016-07-29 at 09:37 +0200, Vinzenz Feenstra wrote:
> > 
> > 
> > > 
> > > On Jul 28, 2016, at 4:11 PM, Tadas  wrote:
> > > 
> > > Thank you for your reply.
> > > Strange, but i do not see any errors in gdm debug log, just this:
> > > http://paste.ubuntu.com/21275558/
> > 
> > Well if it works for you, the better. It didn’t work for me though
> > 
> > 
> > > 
> > >  
> > > I will try installing debian unstable and several ubuntu versions
> > > tomorrow.
> > >  
> > > From: Vinzenz Feenstra
> > > Sent: Thursday, July 28, 2016 4:18 PM
> > > To: ta...@ring.lt
> > > Cc: users
> > > Subject: Re: [ovirt-users] Debian - based OS and SSO
> > >  
> > >  
> > > > 
> > > > On Jul 28, 2016, at 3:11 PM, Vinzenz Feenstra  > > > co
> > > > m> wrote:
> > > >  
> > > >  
> > > > > 
> > > > > On Jul 28, 2016, at 11:53 AM, Tadas  wrote:
> > > > >  
> > > > > Hello,
> > > > > still having issues with ovirt SSO and Debian OS.
> > > > > Other OSes (Windows/Fedora 24) works just fine.
> > > > > Some information:
> > > > > OS: Debian 8.5 (jessie)
> > > > > I've followed manual on https://www.ovirt.org/documentation/h
> > > > > ow
> > > > > -to/gues
> > > > > t-agent/install-the-guest-agent-in-debian/ and installed
> > > > > ovirt-
> > > > > agent.
> > > > > I can get info via spice socket on hypervisor side, this
> > > > > means
> > > > > that
> > > > > agent works fine.
> > > > > I've compiled pam-ovirt-cred and copied it into /lib/x86_64-
> > > > > linux-
> > > > > gnu/security/
> > > >  
> > > > It should be in /lib/security afaik
> > > > 
> > > > > 
> > > > > I've configured /etc/pamd/gdm-ovirtcred (just copied from
> > > > > working
> > > > > Fedora 24)
> > > >  
> > > > replace in that file all occurences of password-auth with
> > > > passwd
> > > >  
> > > > 
> > > > > 
> > > > > 
> > > > > But still login fails. I can see this in ovirt-agent log
> > > > > file:
> > > >  
> > > > It some how fails for me in some cases with this now:
> > > >  
> > >  
> > > Correction its here:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794064
> > > 
> > > > 
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=71525
> > > >  
> > > > There’s not much I can do about that though
> > > >  
> > > >  
> > > > 
> > > > > 
> > > > > 
> > > > > Dummy-2::INFO::2016-07-28
> > > > > 12:49:51,046::OVirtAgentLogic::270::root::Received an
> > > > > external
> > > > > command:
> > > > > login...
> > > > > Dummy-2::DEBUG::2016-07-28
> > > > > 12:49:51,047::OVirtAgentLogic::304::root::User log-in
> > > > > (credentials =
> > > > > '\x00\x00\x00\x04test\x00')
> > > > > Dummy-2::INFO::2016-07-28
> > > > > 12:49:51,047::CredServer::207::root::The
> > > > > following users are allowed to connect: [0]
> > > > > Dummy-2::DEBUG::2016-07-28
> > > > > 12:49:51,047::CredServer::272::root::Token:
> > > > > 760258
> > > > > Dummy-2::INFO::2016-07-28
> > > > > 12:49:51,047::CredServer::273::root::Opening
> > > > > credentials channel...
> > > > > Dummy-2::INFO::2016-07-28
> > > > > 12:49:51,047::CredServer::132::root::Emitting
> > > > > user authenticated signal (760258).
> > > > > Dummy-2::INFO::2016-07-28
> > > > > 12:49:51,178::CredServer::277::root::Credentials channel was
> > > > > closed.
> > > > > 
> > > >  
> > > >  
> > > >  
> > > > 
> > > > > 
> > > > > This looks okay. The error is on pam side (auth.log):
> > > > > 
> > > > > Jul 28 12:49:39 desktop64 gdm-ovirtcred]: pam_succeed_if(gdm-
> > > > > ovirtcred:auth): error retrieving user name: Conversation
> > > > > error
> > > > > Jul 28 12:49:39 desktop64 gdm-ovirtcred]: pam_ovirt_cred(gdm-
> > > > > ovirtcred:auth): Failed to acquire user's credentials
> > > > > 
> > > > > Have no idea, where it fails.
> > > > > Would appreciate, if you could help me here a bit.
> > > > > Thank you.
> > > > > 
> > > > > 
> > > > > ___
> > > > > Users mailing list
> > > > > Users@ovirt.org
> > 

Re: [ovirt-users] Debian - based OS and SSO

2016-07-29 Thread Tadas
Yes, it seems that authentication does not work in any of debian
releases. Oh well.
On Fri, 2016-07-29 at 09:37 +0200, Vinzenz Feenstra wrote:
> 
> > On Jul 28, 2016, at 4:11 PM, Tadas  wrote:
> > 
> > Thank you for your reply.
> > Strange, but i do not see any errors in gdm debug log, just this:
> > http://paste.ubuntu.com/21275558/
> 
> Well if it works for you, the better. It didn’t work for me though
> 
> 
> >  
> > I will try installing debian unstable and several ubuntu versions
> > tomorrow.
> >  
> > From: Vinzenz Feenstra
> > Sent: Thursday, July 28, 2016 4:18 PM
> > To: ta...@ring.lt
> > Cc: users
> > Subject: Re: [ovirt-users] Debian - based OS and SSO
> >  
> >  
> > > On Jul 28, 2016, at 3:11 PM, Vinzenz Feenstra  > > m> wrote:
> > >  
> > >  
> > > > On Jul 28, 2016, at 11:53 AM, Tadas  wrote:
> > > >  
> > > > Hello,
> > > > still having issues with ovirt SSO and Debian OS.
> > > > Other OSes (Windows/Fedora 24) works just fine.
> > > > Some information:
> > > > OS: Debian 8.5 (jessie)
> > > > I've followed manual on https://www.ovirt.org/documentation/how
> > > > -to/gues
> > > > t-agent/install-the-guest-agent-in-debian/ and installed ovirt-
> > > > agent.
> > > > I can get info via spice socket on hypervisor side, this means
> > > > that
> > > > agent works fine.
> > > > I've compiled pam-ovirt-cred and copied it into /lib/x86_64-
> > > > linux-
> > > > gnu/security/
> > >  
> > > It should be in /lib/security afaik
> > > 
> > > > I've configured /etc/pamd/gdm-ovirtcred (just copied from
> > > > working
> > > > Fedora 24)
> > >  
> > > replace in that file all occurences of password-auth with passwd
> > >  
> > > 
> > > > 
> > > > But still login fails. I can see this in ovirt-agent log file:
> > >  
> > > It some how fails for me in some cases with this now:
> > >  
> >  
> > Correction its here:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794064
> > 
> > > https://bugs.freedesktop.org/show_bug.cgi?id=71525
> > >  
> > > There’s not much I can do about that though
> > >  
> > >  
> > > 
> > > > 
> > > > Dummy-2::INFO::2016-07-28
> > > > 12:49:51,046::OVirtAgentLogic::270::root::Received an external
> > > > command:
> > > > login...
> > > > Dummy-2::DEBUG::2016-07-28
> > > > 12:49:51,047::OVirtAgentLogic::304::root::User log-in
> > > > (credentials =
> > > > '\x00\x00\x00\x04test\x00')
> > > > Dummy-2::INFO::2016-07-28
> > > > 12:49:51,047::CredServer::207::root::The
> > > > following users are allowed to connect: [0]
> > > > Dummy-2::DEBUG::2016-07-28
> > > > 12:49:51,047::CredServer::272::root::Token:
> > > > 760258
> > > > Dummy-2::INFO::2016-07-28
> > > > 12:49:51,047::CredServer::273::root::Opening
> > > > credentials channel...
> > > > Dummy-2::INFO::2016-07-28
> > > > 12:49:51,047::CredServer::132::root::Emitting
> > > > user authenticated signal (760258).
> > > > Dummy-2::INFO::2016-07-28
> > > > 12:49:51,178::CredServer::277::root::Credentials channel was
> > > > closed.
> > > > 
> > >  
> > >  
> > >  
> > > 
> > > > This looks okay. The error is on pam side (auth.log):
> > > > 
> > > > Jul 28 12:49:39 desktop64 gdm-ovirtcred]: pam_succeed_if(gdm-
> > > > ovirtcred:auth): error retrieving user name: Conversation error
> > > > Jul 28 12:49:39 desktop64 gdm-ovirtcred]: pam_ovirt_cred(gdm-
> > > > ovirtcred:auth): Failed to acquire user's credentials
> > > > 
> > > > Have no idea, where it fails.
> > > > Would appreciate, if you could help me here a bit.
> > > > Thank you.
> > > > 
> > > > 
> > > > ___
> > > > Users mailing list
> > > > Users@ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/users
> > >  
> >  
> > ___
> > Users mailing list
> > Users@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Safe to upgrade HE hosts from GUI?

2016-07-29 Thread Simone Tiraboschi
On Fri, Jul 29, 2016 at 11:35 AM, Wee Sritippho  wrote:
> On 29/7/2559 15:50, Simone Tiraboschi wrote:
>>
>> On Fri, Jul 29, 2016 at 6:31 AM, Wee Sritippho  wrote:
>>>
>>> On 28/7/2559 15:54, Simone Tiraboschi wrote:
>>>
>>> On Thu, Jul 28, 2016 at 10:41 AM, Wee Sritippho 
>>> wrote:

 On 21/7/2559 16:53, Simone Tiraboschi wrote:

 On Thu, Jul 21, 2016 at 11:43 AM, Wee Sritippho 
 wrote:

> Can I just follow
>
> http://www.ovirt.org/documentation/how-to/hosted-engine/#upgrade-hosted-engine
> until step 3 and do everything else via GUI?

 Yes, absolutely.


 Hi, I upgrade a host (host02) via GUI and now its score is 0. Restarted
 the services but the result is still the same. Kinda lost now. What
 should I
 do next?

>>> Can you please attach ovirt-ha-agent logs?
>>>
>>>
>>> Yes, here are the logs:
>>> https://app.box.com/s/b4urjty8dsuj98n3ywygpk3oh5o7pbsh
>>
>> Thanks Wee,
>> your issue is here:
>> MainThread::ERROR::2016-07-17
>>
>> 14:32:45,586::storage_server::143::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(_validate_pre_connected_path)
>> The hosted-engine storage domain is already mounted on
>>
>> '/rhev/data-center/mnt/glusterSD/host02.ovirt.forest.go.th:_hosted__engine/639e689c-8493-479b-a6eb-cc92b6fc4cf4'
>> with a path that is not supported anymore: the right path should be
>>
>> '/rhev/data-center/mnt/glusterSD/host01.ovirt.forest.go.th:_hosted__engine/639e689c-8493-479b-a6eb-cc92b6fc4cf4'.
>>
>> Did you manually tried to avoid the issue of a single entry point for
>> the gluster FS volume using host01.ovirt.forest.go.th:_hosted__engine
>> and host02.ovirt.forest.go.th:_hosted__engine there?
>> This could cause a lot of confusion since the code could not detect
>> that the storage domain is the same and you can end with it mounted
>> twice into different locations and a lot of issues.
>> The correct solution of that issue was this one:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1298693#c20
>>
>> Now, to have it fixed on your env you have to hack a bit.
>> First step, you have to edit
>> /etc/ovirt-hosted-engine/hosted-engine.conf on all your hosted-engine
>> hosts to ensure that the storage field always point to the same entry
>> point (host01 for instance)
>> Then on each host you can add something like:
>>
>> mnt_options=backupvolfile-server=host02.ovirt.forest.go.th:host03.ovirt.forest.go.th,fetch-attempts=2,log-level=WARNING,log-file=/var/log/engine_domain.log
>>
>> Then check the representation of your storage connection in the table
>> storage_server_connections of the engine DB and make sure that
>> connection refers to the entry point you used in hosted-engine.conf on
>> all your hosts, you have lastly to set the value of mount_options also
>> here.
>
> Weird. The configuration in all hosts are already referring to host01.

but for sure you have a connection pointing to host02 somewhere, did
you try to manually deploy from CLI connecting the gluster volume on
host02?

> Also, in the storage_server_connections table:
>
> engine=> SELECT * FROM storage_server_connections;
>   id  | connection|
> user_name | password | iqn | port | portal | storage_type | mount_options |
> vfs_type
>  | nfs_version | nfs_timeo | nfs_retrans
> --+--+---+--+-+--++--+---+--
> -+-+---+-
>  bd78d299-c8ff-4251-8aab-432ce6443ae8 |
> host01.ovirt.forest.go.th:/hosted_engine |   | | |  | 1
> |7 |   | glusterfs
>  | |   |
> (1 row)
>
>
>>
>> Please tune also the value of network.ping-timeout for your glusterFS
>> volume to avoid this:
>>   https://bugzilla.redhat.com/show_bug.cgi?id=1319657#c17
>
>
> --
> Wee
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Safe to upgrade HE hosts from GUI?

2016-07-29 Thread Wee Sritippho

On 29/7/2559 15:50, Simone Tiraboschi wrote:

On Fri, Jul 29, 2016 at 6:31 AM, Wee Sritippho  wrote:

On 28/7/2559 15:54, Simone Tiraboschi wrote:

On Thu, Jul 28, 2016 at 10:41 AM, Wee Sritippho  wrote:

On 21/7/2559 16:53, Simone Tiraboschi wrote:

On Thu, Jul 21, 2016 at 11:43 AM, Wee Sritippho 
wrote:


Can I just follow
http://www.ovirt.org/documentation/how-to/hosted-engine/#upgrade-hosted-engine
until step 3 and do everything else via GUI?

Yes, absolutely.


Hi, I upgrade a host (host02) via GUI and now its score is 0. Restarted
the services but the result is still the same. Kinda lost now. What should I
do next?


Can you please attach ovirt-ha-agent logs?


Yes, here are the logs:
https://app.box.com/s/b4urjty8dsuj98n3ywygpk3oh5o7pbsh

Thanks Wee,
your issue is here:
MainThread::ERROR::2016-07-17
14:32:45,586::storage_server::143::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(_validate_pre_connected_path)
The hosted-engine storage domain is already mounted on
'/rhev/data-center/mnt/glusterSD/host02.ovirt.forest.go.th:_hosted__engine/639e689c-8493-479b-a6eb-cc92b6fc4cf4'
with a path that is not supported anymore: the right path should be
'/rhev/data-center/mnt/glusterSD/host01.ovirt.forest.go.th:_hosted__engine/639e689c-8493-479b-a6eb-cc92b6fc4cf4'.

Did you manually tried to avoid the issue of a single entry point for
the gluster FS volume using host01.ovirt.forest.go.th:_hosted__engine
and host02.ovirt.forest.go.th:_hosted__engine there?
This could cause a lot of confusion since the code could not detect
that the storage domain is the same and you can end with it mounted
twice into different locations and a lot of issues.
The correct solution of that issue was this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1298693#c20

Now, to have it fixed on your env you have to hack a bit.
First step, you have to edit
/etc/ovirt-hosted-engine/hosted-engine.conf on all your hosted-engine
hosts to ensure that the storage field always point to the same entry
point (host01 for instance)
Then on each host you can add something like:
mnt_options=backupvolfile-server=host02.ovirt.forest.go.th:host03.ovirt.forest.go.th,fetch-attempts=2,log-level=WARNING,log-file=/var/log/engine_domain.log

Then check the representation of your storage connection in the table
storage_server_connections of the engine DB and make sure that
connection refers to the entry point you used in hosted-engine.conf on
all your hosts, you have lastly to set the value of mount_options also
here.

Weird. The configuration in all hosts are already referring to host01.

Also, in the storage_server_connections table:

engine=> SELECT * FROM storage_server_connections;
  id  | connection| 
user_name | password | iqn | port | portal | storage_type | 
mount_options | vfs_type

 | nfs_version | nfs_timeo | nfs_retrans
--+--+---+--+-+--++--+---+--
-+-+---+-
 bd78d299-c8ff-4251-8aab-432ce6443ae8 | 
host01.ovirt.forest.go.th:/hosted_engine |   | | |  | 
1  |7 |   | glusterfs

 | |   |
(1 row)



Please tune also the value of network.ping-timeout for your glusterFS
volume to avoid this:
  https://bugzilla.redhat.com/show_bug.cgi?id=1319657#c17


--
Wee

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Safe to upgrade HE hosts from GUI?

2016-07-29 Thread Simone Tiraboschi
On Fri, Jul 29, 2016 at 6:31 AM, Wee Sritippho  wrote:
> On 28/7/2559 15:54, Simone Tiraboschi wrote:
>
> On Thu, Jul 28, 2016 at 10:41 AM, Wee Sritippho  wrote:
>>
>> On 21/7/2559 16:53, Simone Tiraboschi wrote:
>>
>> On Thu, Jul 21, 2016 at 11:43 AM, Wee Sritippho 
>> wrote:
>>
>>>
>>> Can I just follow
>>> http://www.ovirt.org/documentation/how-to/hosted-engine/#upgrade-hosted-engine
>>> until step 3 and do everything else via GUI?
>>
>> Yes, absolutely.
>>
>>
>> Hi, I upgrade a host (host02) via GUI and now its score is 0. Restarted
>> the services but the result is still the same. Kinda lost now. What should I
>> do next?
>>
>
> Can you please attach ovirt-ha-agent logs?
>
>
> Yes, here are the logs:
> https://app.box.com/s/b4urjty8dsuj98n3ywygpk3oh5o7pbsh

Thanks Wee,
your issue is here:
MainThread::ERROR::2016-07-17
14:32:45,586::storage_server::143::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(_validate_pre_connected_path)
The hosted-engine storage domain is already mounted on
'/rhev/data-center/mnt/glusterSD/host02.ovirt.forest.go.th:_hosted__engine/639e689c-8493-479b-a6eb-cc92b6fc4cf4'
with a path that is not supported anymore: the right path should be
'/rhev/data-center/mnt/glusterSD/host01.ovirt.forest.go.th:_hosted__engine/639e689c-8493-479b-a6eb-cc92b6fc4cf4'.

Did you manually tried to avoid the issue of a single entry point for
the gluster FS volume using host01.ovirt.forest.go.th:_hosted__engine
and host02.ovirt.forest.go.th:_hosted__engine there?
This could cause a lot of confusion since the code could not detect
that the storage domain is the same and you can end with it mounted
twice into different locations and a lot of issues.
The correct solution of that issue was this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1298693#c20

Now, to have it fixed on your env you have to hack a bit.
First step, you have to edit
/etc/ovirt-hosted-engine/hosted-engine.conf on all your hosted-engine
hosts to ensure that the storage field always point to the same entry
point (host01 for instance)
Then on each host you can add something like:
mnt_options=backupvolfile-server=host02.ovirt.forest.go.th:host03.ovirt.forest.go.th,fetch-attempts=2,log-level=WARNING,log-file=/var/log/engine_domain.log

Then check the representation of your storage connection in the table
storage_server_connections of the engine DB and make sure that
connection refers to the entry point you used in hosted-engine.conf on
all your hosts, you have lastly to set the value of mount_options also
here.

Please tune also the value of network.ping-timeout for your glusterFS
volume to avoid this:
 https://bugzilla.redhat.com/show_bug.cgi?id=1319657#c17

> --
> Wee
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Debian - based OS and SSO

2016-07-29 Thread Vinzenz Feenstra

> On Jul 28, 2016, at 4:11 PM, Tadas  wrote:
> 
> Thank you for your reply.
> Strange, but i do not see any errors in gdm debug log, just this:
> http://paste.ubuntu.com/21275558/ 
Well if it works for you, the better. It didn’t work for me though


>  
> I will try installing debian unstable and several ubuntu versions tomorrow.
>  
> From: Vinzenz Feenstra 
> Sent: Thursday, July 28, 2016 4:18 PM
> To: ta...@ring.lt 
> Cc: users 
> Subject: Re: [ovirt-users] Debian - based OS and SSO
>  
>  
>> On Jul 28, 2016, at 3:11 PM, Vinzenz Feenstra > > wrote:
>>  
>>  
>>> On Jul 28, 2016, at 11:53 AM, Tadas > 
>>> wrote:
>>>  
>>> Hello,
>>> still having issues with ovirt SSO and Debian OS.
>>> Other OSes (Windows/Fedora 24) works just fine.
>>> Some information:
>>> OS: Debian 8.5 (jessie)
>>> I've followed manual on https://www.ovirt.org/documentation/how-to/gues 
>>> 
>>> t-agent/install-the-guest-agent-in-debian/ and installed ovirt-agent.
>>> I can get info via spice socket on hypervisor side, this means that
>>> agent works fine.
>>> I've compiled pam-ovirt-cred and copied it into /lib/x86_64-linux-
>>> gnu/security/
>>  
>> It should be in /lib/security afaik
>> 
>>> I've configured /etc/pamd/gdm-ovirtcred (just copied from working
>>> Fedora 24)
>>  
>> replace in that file all occurences of password-auth with passwd
>>  
>> 
>>> 
>>> But still login fails. I can see this in ovirt-agent log file:
>>  
>> It some how fails for me in some cases with this now:
>>  
>  
> Correction its here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794064 
> 
>> https://bugs.freedesktop.org/show_bug.cgi?id=71525 
>> 
>>  
>> There’s not much I can do about that though
>>  
>>  
>> 
>>> 
>>> Dummy-2::INFO::2016-07-28
>>> 12:49:51,046::OVirtAgentLogic::270::root::Received an external command:
>>> login...
>>> Dummy-2::DEBUG::2016-07-28
>>> 12:49:51,047::OVirtAgentLogic::304::root::User log-in (credentials =
>>> '\x00\x00\x00\x04test\x00')
>>> Dummy-2::INFO::2016-07-28 12:49:51,047::CredServer::207::root::The
>>> following users are allowed to connect: [0]
>>> Dummy-2::DEBUG::2016-07-28 12:49:51,047::CredServer::272::root::Token:
>>> 760258
>>> Dummy-2::INFO::2016-07-28 12:49:51,047::CredServer::273::root::Opening
>>> credentials channel...
>>> Dummy-2::INFO::2016-07-28 12:49:51,047::CredServer::132::root::Emitting
>>> user authenticated signal (760258).
>>> Dummy-2::INFO::2016-07-28
>>> 12:49:51,178::CredServer::277::root::Credentials channel was closed.
>>> 
>>  
>>  
>>  
>> 
>>> This looks okay. The error is on pam side (auth.log):
>>> 
>>> Jul 28 12:49:39 desktop64 gdm-ovirtcred]: pam_succeed_if(gdm-
>>> ovirtcred:auth): error retrieving user name: Conversation error
>>> Jul 28 12:49:39 desktop64 gdm-ovirtcred]: pam_ovirt_cred(gdm-
>>> ovirtcred:auth): Failed to acquire user's credentials
>>> 
>>> Have no idea, where it fails.
>>> Would appreciate, if you could help me here a bit.
>>> Thank you.
>>> 
>>> 
>>> ___
>>> Users mailing list
>>> Users@ovirt.org 
>>> http://lists.ovirt.org/mailman/listinfo/users 
>>> 
>> 
>>  
> 
>  
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users