Re: [ovirt-users] Problems installing Ovirt 4.02 Node

[Peter Michael Calum]

Hi,

I tried the changes in /etc/fstab and rebooted.
Now  imgbase status: OK

But I see this in /var/log/messages after the change :  Starting kdump: [FAILED]

Jul 27 07:44:08 khk9dsk34 dracut: *** Including module: base ***
Jul 27 07:44:08 khk9dsk34 dracut: *** Including module: fs-lib ***
Jul 27 07:44:08 khk9dsk34 dracut: *** Including module: kdumpbase ***
Jul 27 07:44:08 khk9dsk34 kernel: device-mapper: table: 253:8: multipath: error 
getting device
Jul 27 07:44:08 khk9dsk34 kernel: device-mapper: ioctl: error adding target to 
table
Jul 27 07:44:08 khk9dsk34 multipathd: dm-8: remove map (uevent)
Jul 27 07:44:08 khk9dsk34 multipathd: dm-8: remove map (uevent)

Jul 27 07:44:08 khk9dsk34 kdumpctl: Bad kdump location: khk9dsg34.ip.tdk.dk
Jul 27 07:44:09 khk9dsk34 kdumpctl: mkdumprd: failed to make kdump initrd
Jul 27 07:44:09 khk9dsk34 kdumpctl: Starting kdump: [FAILED]
Jul 27 07:44:09 khk9dsk34 systemd: kdump.service: main process exited, 
code=exited, status=1/FAILURE
Jul 27 07:44:09 khk9dsk34 systemd: Failed to start Crash recovery kernel arming.

Jul 27 07:44:09 khk9dsk34 systemd: Startup finished in 5.673s (kernel) + 8.024s 
(initrd) + 43.476s (userspace) = 57.173s.
Jul 27 07:44:09 khk9dsk34 systemd: Unit kdump.service entered failed state.
Jul 27 07:44:09 khk9dsk34 systemd: kdump.service failed.
Jul 27 07:44:32 khk9dsk34 systemd: Starting Stop Read-Ahead Data Collection...
Jul 27 07:44:32 khk9dsk34 systemd: Started Stop Read-Ahead Data Collection.
Jul 27 07:44:32 khk9dsk34 systemd-logind: New session 1 of user root.
Jul 27 07:44:32 khk9dsk34 systemd: Created slice user-0.slice.
Jul 27 07:44:32 khk9dsk34 systemd: Starting user-0.slice.
Jul 27 07:44:32 khk9dsk34 systemd: Started Session 1 of user root.
Jul 27 07:44:32 khk9dsk34 systemd: Starting Session 1 of user root.
Jul 27 07:44:45 khk9dsk34 kernel: device-mapper: table: 253:8: multipath: error 
getting device
Jul 27 07:44:45 khk9dsk34 kernel: device-mapper: ioctl: error adding target to 
table
Jul 27 07:44:45 khk9dsk34 multipathd: dm-8: remove map (uevent)
Jul 27 07:44:45 khk9dsk34 multipathd: dm-8: remove map (uevent)

I checked messages in my other hypervisor where /etc/fstab was not modified, 
KDUMP was OK there.

The question about registrating the host in the manager i got solved, it is now 
done from the manager.
(I come from the Redhat 3.5, and are just started on Ovirt 4)

Thanks for helping
Peter

-Oprindelig meddelelse-
Fra: Giorgio Biacchi [mailto:gior...@di.unimi.it] 
Sendt: 27. juli 2016 00:05
Til: Peter Michael Calum ; users@ovirt.org
Emne: Re: [ovirt-users] Problems installing Ovirt 4.02 Node

On 26/07/2016 08:51, Peter Michael Calum wrote:

>   imgbase status: DEGRADED
>
>   Please check the status manually using `imgbase check`

Got the same problem, add discard option to fstab for / and /var like this:

#
# /etc/fstab
# Created by anaconda on Fri Jul 22 11:08:40 2016 # # Accessible filesystems, 
by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info #
/dev/HostVG/ovirt-node-ng-4.0.2-0.20160721.0+1 / ext4 defaults,discard 1 1
UUID=a96d5a4c-bc4b-481c-bf6e-af47318d8b7b /boot   ext4 
  defaults1 2
/dev/mapper/HostVG-var  /varext4defaults,discard 1 2
/dev/mapper/HostVG-swap swapswapdefaults0 0

then remount or reboot.

>
> Another question : Where do I define the Ovirt manager address.

For this one I can't help, but you can add the new host from the manager..

>
>
>
> Venlig hilsen / Kind regards
>
> *Peter Calum *
>
> Tlf: +45 66 69 36 82
> Mobil: +45 40 41 71 85
> E-mail pe...@tdc.dk 
>
>
> TDC Group
> Teknologi & Kapacitet
> Systemer, OTMS
> Teglholmsgade 1,
> F-059 2450 København SV
>
>
>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt 4 Hosted Engine deploy on fc storage - [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 101] Network is unreachable

[Roy Golan]

Edi, danken, this is again the malfunctioning heuristics in the client for
handling ipv6. Is there a bug on this issue ?

On Jul 27, 2016 8:57 AM,  wrote:

> I enabled ipv6 for "lo" and "ovirtmgmt" interfaces and deployment process
> overt completed successfully.
>
> # cat /etc/sysctl.conf
>
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.lo.disable_ipv6 = 0
> net.ipv6.conf.ovirtmgmt.disable_ipv6 = 0
>
> Thank you for your Help!
>
> 26.07.2016, 09:13, "Edward Haas" :
>
>
>
> On Mon, Jul 25, 2016 at 4:02 PM, Simone Tiraboschi 
> wrote:
>
> On Mon, Jul 25, 2016 at 2:38 PM,   wrote:
> > telnet kom-ad01-vm31.holding.com 54321 = success connection
> >
> > telnet ::1 54321
> > Trying ::1...
> > telnet: connect to address ::1: Network is unreachable
> >
> > (ipv6 on my server disabled)
>
> Ok, so the issue seams here: now by default vdsm binds on :: and its
> heuristc can end up using ipv6.
> See this one: https://bugzilla.redhat.com/show_bug.cgi?id=1350883
>
> Can you please try enabling ipv6 on your host or setting
>  management_ip = 0.0.0.0
> under the [address] section in /etc/vdsm/vdsm.conf
> and then restarting vdsm.
>
>
>
> Could you please also add the 'ip addr' output? Just interested to see how
> IPv6 was
> disabled on the host.
> It will be even better if you could apply the patch (
> https://gerrit.ovirt.org/#/c/60020) and check.
>
>
>
>
>
> > 25.07.2016, 15:35, "Simone Tiraboschi" :
> >> On Mon, Jul 25, 2016 at 2:15 PM,  wrote:
> >>>  # ss -plutn
> >>>
> >>>  Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
> >>>
> >>>  udp UNCONN 0 0 *:111 *:* users:(("rpcbind",pid=827,fd=6))
> >>>  udp UNCONN 0 0 *:161 *:* users:(("snmpd",pid=1609,fd=6))
> >>>  udp UNCONN 0 0 127.0.0.1:323 *:* users:(("chronyd",pid=795,fd=1))
> >>>  udp UNCONN 0 0 *:959 *:* users:(("rpcbind",pid=827,fd=7))
> >>>  udp UNCONN 0 0 127.0.0.1:25375 *:* users:(("snmpd",pid=1609,fd=8))
> >>>  udp UNCONN 0 0 127.0.0.1:25376 *:* users:(("cmapeerd",pid=2056,fd=5))
> >>>  udp UNCONN 0 0 127.0.0.1:25393 *:* users:(("cmanicd",pid=2278,fd=3))
> >>>  udp UNCONN 0 0 :::111 :::* users:(("rpcbind",pid=827,fd=9))
> >>>  udp UNCONN 0 0 :::959 :::* users:(("rpcbind",pid=827,fd=10))
> >>>  tcp LISTEN 0 128 *:2381 *:*
> users:(("hpsmhd",pid=3903,fd=4),("hpsmhd",pid=3901,fd=4),("hpsmhd",pid=3900,fd=4),("hpsmhd",pid=3899,fd=4),("hpsmhd",pid=3898,fd=4),("hpsmhd",pid=3893,fd=4))
> >>>  tcp LISTEN 0 128 *:111 *:* users:(("rpcbind",pid=827,fd=8))
> >>>  tcp LISTEN 0 5 *:54322 *:* users:(("ovirt-imageio-d",pid=753,fd=3))
> >>>  tcp LISTEN 0 128 *:22 *:* users:(("sshd",pid=1606,fd=3))
> >>>  tcp LISTEN 0 100 127.0.0.1:25 *:* users:(("master",pid=1948,fd=13))
> >>>  tcp LISTEN 0 128 *:2301 *:*
> users:(("hpsmhd",pid=3903,fd=3),("hpsmhd",pid=3901,fd=3),("hpsmhd",pid=3900,fd=3),("hpsmhd",pid=3899,fd=3),("hpsmhd",pid=3898,fd=3),("hpsmhd",pid=3893,fd=3))
> >>>  tcp LISTEN 0 30 *:16514 *:* users:(("libvirtd",pid=10688,fd=13))
> >>>  tcp LISTEN 0 128 127.0.0.1:199 *:* users:(("snmpd",pid=1609,fd=9))
> >>>  tcp LISTEN 0 128 :::111 :::* users:(("rpcbind",pid=827,fd=11))
> >>>  tcp LISTEN 0 5 :::54321 :::* users:(("vdsm",pid=11077,fd=23))
> >>
> >> vdsm is properly bind over ipv6.
> >>
> >> Can you please check if you can connect to vdsm with:
> >>  telnet kom-ad01-vm31.holding.com 54321
> >> and with
> >>  telnet ::1 54321
> >> ?
> >>
> >>>  tcp LISTEN 0 30 :::16514 :::* users:(("libvirtd",pid=10688,fd=14))
> >>>
> >>>  25.07.2016, 15:11, "Simone Tiraboschi" :
>   On Mon, Jul 25, 2016 at 2:03 PM,  wrote:
> >   Yes.
> >
> >   # ping $(python -c 'import socket; print(socket.gethostname())')
> >
> >   PING KOM-AD01-VM31.holding.com (10.1.0.231) 56(84) bytes of data.
> >   64 bytes from kom-ad01-vm31.holding.com (10.1.0.231): icmp_seq=1
> ttl=64 time=0.030 ms
> >   64 bytes from kom-ad01-vm31.holding.com (10.1.0.231): icmp_seq=2
> ttl=64 time=0.015 ms
> >   64 bytes from kom-ad01-vm31.holding.com (10.1.0.231): icmp_seq=3
> ttl=64 time=0.011 ms
> >   ^C
> >   --- KOM-AD01-VM31.holding.com ping statistics ---
> >   3 packets transmitted, 3 received, 0% packet loss, time 2001ms
> >   rtt min/avg/max/mdev = 0.011/0.018/0.030/0.009 ms
> >
> >   but...
> 
>   and the output of
>    ss -plutn
> 
> >   # vdsClient -s 0 getVdsCaps
> >
> >   Traceback (most recent call last):
> > File "/usr/share/vdsm/vdsClient.py", line 2980, in 
> >   code, message = commands[command][0](commandArgs)
> > File "/usr/share/vdsm/vdsClient.py", line 543, in do_getCap
> >   return self.ExecAndExit(self.s.getVdsCapabilities())
> > File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
> >   return self.__send(self.__name, args)
> > File "/usr/lib64/python2.7/xmlrpclib.py", line 1587, in __request
> >   verbose=self.__verbose
> > File "/usr/lib64/python2.7/xmlrpclib.py", line 1273

Re: [ovirt-users] oVirt 4 Hosted Engine deploy on fc storage - [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 101] Network is unreachable

[aleksey . maksimov]

I enabled ipv6 for "lo" and "ovirtmgmt" interfaces and deployment process overt completed successfully.# cat /etc/sysctl.confnet.ipv6.conf.all.disable_ipv6 = 1net.ipv6.conf.default.disable_ipv6 = 1net.ipv6.conf.lo.disable_ipv6 = 0net.ipv6.conf.ovirtmgmt.disable_ipv6 = 0Thank you for your Help! 26.07.2016, 09:13, "Edward Haas" :  On Mon, Jul 25, 2016 at 4:02 PM, Simone Tiraboschi  wrote:On Mon, Jul 25, 2016 at 2:38 PM,   wrote:> telnet kom-ad01-vm31.holding.com 54321 = success connection>> telnet ::1 54321> Trying ::1...> telnet: connect to address ::1: Network is unreachable>> (ipv6 on my server disabled)Ok, so the issue seams here: now by default vdsm binds on :: and itsheuristc can end up using ipv6.See this one: https://bugzilla.redhat.com/show_bug.cgi?id=1350883Can you please try enabling ipv6 on your host or setting management_ip = 0.0.0.0under the [address] section in /etc/vdsm/vdsm.confand then restarting vdsm.  Could you please also add the 'ip addr' output? Just interested to see how IPv6 wasdisabled on the host.It will be even better if you could apply the patch (https://gerrit.ovirt.org/#/c/60020) and check. > 25.07.2016, 15:35, "Simone Tiraboschi" :>> On Mon, Jul 25, 2016 at 2:15 PM,  wrote:>>>  # ss -plutn>>  Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port>>  udp UNCONN 0 0 *:111 *:* users:(("rpcbind",pid=827,fd=6))>>>  udp UNCONN 0 0 *:161 *:* users:(("snmpd",pid=1609,fd=6))>>>  udp UNCONN 0 0 127.0.0.1:323 *:* users:(("chronyd",pid=795,fd=1))>>>  udp UNCONN 0 0 *:959 *:* users:(("rpcbind",pid=827,fd=7))>>>  udp UNCONN 0 0 127.0.0.1:25375 *:* users:(("snmpd",pid=1609,fd=8))>>>  udp UNCONN 0 0 127.0.0.1:25376 *:* users:(("cmapeerd",pid=2056,fd=5))>>>  udp UNCONN 0 0 127.0.0.1:25393 *:* users:(("cmanicd",pid=2278,fd=3))>>>  udp UNCONN 0 0 :::111 :::* users:(("rpcbind",pid=827,fd=9))>>>  udp UNCONN 0 0 :::959 :::* users:(("rpcbind",pid=827,fd=10))>>>  tcp LISTEN 0 128 *:2381 *:* users:(("hpsmhd",pid=3903,fd=4),("hpsmhd",pid=3901,fd=4),("hpsmhd",pid=3900,fd=4),("hpsmhd",pid=3899,fd=4),("hpsmhd",pid=3898,fd=4),("hpsmhd",pid=3893,fd=4))>>>  tcp LISTEN 0 128 *:111 *:* users:(("rpcbind",pid=827,fd=8))>>>  tcp LISTEN 0 5 *:54322 *:* users:(("ovirt-imageio-d",pid=753,fd=3))>>>  tcp LISTEN 0 128 *:22 *:* users:(("sshd",pid=1606,fd=3))>>>  tcp LISTEN 0 100 127.0.0.1:25 *:* users:(("master",pid=1948,fd=13))>>>  tcp LISTEN 0 128 *:2301 *:* users:(("hpsmhd",pid=3903,fd=3),("hpsmhd",pid=3901,fd=3),("hpsmhd",pid=3900,fd=3),("hpsmhd",pid=3899,fd=3),("hpsmhd",pid=3898,fd=3),("hpsmhd",pid=3893,fd=3))>>>  tcp LISTEN 0 30 *:16514 *:* users:(("libvirtd",pid=10688,fd=13))>>>  tcp LISTEN 0 128 127.0.0.1:199 *:* users:(("snmpd",pid=1609,fd=9))>>>  tcp LISTEN 0 128 :::111 :::* users:(("rpcbind",pid=827,fd=11))>>>  tcp LISTEN 0 5 :::54321 :::* users:(("vdsm",pid=11077,fd=23)) vdsm is properly bind over ipv6. Can you please check if you can connect to vdsm with:>>  telnet kom-ad01-vm31.holding.com 54321>> and with>>  telnet ::1 54321>> ?>  tcp LISTEN 0 30 :::16514 :::* users:(("libvirtd",pid=10688,fd=14))>>  25.07.2016, 15:11, "Simone Tiraboschi" :  On Mon, Jul 25, 2016 at 2:03 PM,  wrote:>   Yes.>>   # ping $(python -c 'import socket; print(socket.gethostname())')>>   PING KOM-AD01-VM31.holding.com (10.1.0.231) 56(84) bytes of data.>   64 bytes from kom-ad01-vm31.holding.com (10.1.0.231): icmp_seq=1 ttl=64 time=0.030 ms>   64 bytes from kom-ad01-vm31.holding.com (10.1.0.231): icmp_seq=2 ttl=64 time=0.015 ms>   64 bytes from kom-ad01-vm31.holding.com (10.1.0.231): icmp_seq=3 ttl=64 time=0.011 ms>   ^C>   --- KOM-AD01-VM31.holding.com ping statistics --->   3 packets transmitted, 3 received, 0% packet loss, time 2001ms>   rtt min/avg/max/mdev = 0.011/0.018/0.030/0.009 ms>>   but...  and the output of   ss -plutn>   # vdsClient -s 0 getVdsCaps>>   Traceback (most recent call last):>     File "/usr/share/vdsm/vdsClient.py", line 2980, in >       code, message = commands[command][0](commandArgs)>     File "/usr/share/vdsm/vdsClient.py", line 543, in do_getCap>       return self.ExecAndExit(self.s.getVdsCapabilities())>     File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__>       return self.__send(self.__name, args)>     File "/usr/lib64/python2.7/xmlrpclib.py", line 1587, in __request>       verbose=self.__verbose>     File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request>       return self.single_request(host, handler, request_body, verbose)>     File "/usr/lib64/python2.7/xmlrpclib.py", line 1301, in single_request>       self.send_content(h, request_body)>     File "/usr/lib64/python2.7/xmlrpclib.py", line 1448, in send_content>       connection.endheaders(request_body)> 

Re: [ovirt-users] Problems installing Ovirt 4.02 Node

[Giorgio Biacchi]

On 26/07/2016 08:51, Peter Michael Calum wrote:


  imgbase status: DEGRADED

  Please check the status manually using `imgbase check`


Got the same problem, add discard option to fstab for / and /var like this:

#
# /etc/fstab
# Created by anaconda on Fri Jul 22 11:08:40 2016
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/HostVG/ovirt-node-ng-4.0.2-0.20160721.0+1 / ext4 defaults,discard 1 1
UUID=a96d5a4c-bc4b-481c-bf6e-af47318d8b7b /boot   ext4 
 defaults1 2

/dev/mapper/HostVG-var  /varext4defaults,discard 1 2
/dev/mapper/HostVG-swap swapswapdefaults0 0

then remount or reboot.



Another question : Where do I define the Ovirt manager address.


For this one I can't help, but you can add the new host from the manager..





Venlig hilsen / Kind regards

*Peter Calum *

Tlf: +45 66 69 36 82
Mobil: +45 40 41 71 85
E-mail pe...@tdc.dk 


TDC Group
Teknologi & Kapacitet
Systemer, OTMS
Teglholmsgade 1,
F-059 2450 København SV





___
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] Windows 10 + qemu + Blue Iris = Blue screen

[Frank Wall]

On Fri, Jul 22, 2016 at 03:58:56PM -0500, Blaster wrote:
> 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?

In my case I could solve this issue by changing the number of (virtual)
CPUs to only 1 for the Windows 10 VM. The Windows 10 VM is running
pretty stable for several months now.

IIRC this is related to the Host CPU or Cluster CPU Type.


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

[ovirt-users] Problems installing Ovirt 4.02 Node

[Peter Michael Calum]

Hi group,

Im trying to install a Ovirt 4.02 Hypervisor Node 
(ovirt-node-ng-installer-ovirt-4.0-pre-2016072108.iso).
Hardware is IBM X3550M4 with 256 GB Ram.
I follow the installation steps and use automatic partitioning and installation 
goes fine without errors.
I only create the root user.

When I log in after reboot I get this error :

Last login: Tue Jul 26 08:30:58 2016 from slt-vpn-62-242-222-13.eng.tdc.net

  imgbase status: DEGRADED
  Please check the status manually using `imgbase check`

[root@khk9dsk34 ~]# imgbase check
Status: FAILED
Mount points ... FAILED - This can happen if the installation was performed 
incorrectly
  Separate /var ... OK
  Discard is used ... FAILED - 'discard' mount option was not added or got 
removed
Basic storage ... OK
  Initialized VG ... OK
  Initialized Thin Pool ... OK
  Initialized LVs ... OK
Thin storage ... OK
  Checking available space in thinpool ... OK
  Checking thinpool auto-extend ... OK

Another question : Where do I define the Ovirt manager address.

Venlig hilsen / Kind regards
Peter Calum
Tlf: +45 66 69 36 82
Mobil: +45 40 41 71 85
E-mail pe...@tdc.dk
[cid:image001.png@01D1E71A.D0172A00]
TDC Group
Teknologi & Kapacitet
Systemer, OTMS
Teglholmsgade 1,
F-059 2450 København SV


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

Re: [ovirt-users] ERROR [org.ovirt.vdsm.jsonrpc.client.reactors.Reactor] (SSL Stomp Reactor) [] Unable to process messages

[Martin Perina]

On Tue, Jul 26, 2016 at 5:39 PM, Jiri Belka  wrote:

> > Hi,
> >
> > Unfortunately, upgrading to 4.0.1RC didn't solve the problem. Actually,
> > the error changed to 'General SSLEngine problem', but the result was the
> > same, like this:
> >
> > 2016-07-13 09:52:22,010 INFO
> > [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp
> > Reactor) [] Connecting to /10.X.X.X
> > 2016-07-13 09:52:22,018 ERROR
> > [org.ovirt.vdsm.jsonrpc.client.reactors.Reactor] (SSL Stomp Reactor) []
> > Unable to process messages: General SSLEngine problem
> >
> > It's worth mentioning that we're using our own SSL certificates (not
> > self-signed), and I imported the combined certificate into the
> > /etc/pki/ovirt-engine/.truststore key file. Not sure if related, but
> > just in case.
> >
> > I had to downgrade to 3.6.7. I'm attaching requested logs, if you need
> > anything else don't hesitate to ask.
>
>
> FYI I migrated my 3.6 env (engine + 1 host) to 4.0 and the host is up
> and running fine on datacenter/cluster 4.0 compat level.
>
> FYA there's a BZ about engine certs
> https://bugzilla.redhat.com/show_bug.cgi?id=1336838


​We should mention​
​ that above bug described how to use custom HTTPS certificate signed by
custom CA. But even if this is configured, all communication between engine
and host will still use certificate signed by internal oVirt CA.


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

Re: [ovirt-users] ERROR [org.ovirt.vdsm.jsonrpc.client.reactors.Reactor] (SSL Stomp Reactor) [] Unable to process messages

[Jiri Belka]

> > Unfortunately, upgrading to 4.0.1RC didn't solve the problem. Actually,
> > the error changed to 'General SSLEngine problem', but the result was the
> > same, like this:
> > 
> > 2016-07-13 09:52:22,010 INFO
> > [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp
> > Reactor) [] Connecting to /10.X.X.X
> > 2016-07-13 09:52:22,018 ERROR
> > [org.ovirt.vdsm.jsonrpc.client.reactors.Reactor] (SSL Stomp Reactor) []
> > Unable to process messages: General SSLEngine problem
> > 
> > It's worth mentioning that we're using our own SSL certificates (not
> > self-signed), and I imported the combined certificate into the
> > /etc/pki/ovirt-engine/.truststore key file. Not sure if related, but
> > just in case.
> > 
> > I had to downgrade to 3.6.7. I'm attaching requested logs, if you need
> > anything else don't hesitate to ask.
> 
> 
> FYI I migrated my 3.6 env (engine + 1 host) to 4.0 and the host is up
> and running fine on datacenter/cluster 4.0 compat level.
> 
> FYA there's a BZ about engine certs
> https://bugzilla.redhat.com/show_bug.cgi?id=1336838

Ah, I forgot to mention that I used my own CA and thus custom certificate
for Apache httpd.

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

Re: [ovirt-users] ERROR [org.ovirt.vdsm.jsonrpc.client.reactors.Reactor] (SSL Stomp Reactor) [] Unable to process messages

[Jiri Belka]

> Hi,
> 
> Unfortunately, upgrading to 4.0.1RC didn't solve the problem. Actually,
> the error changed to 'General SSLEngine problem', but the result was the
> same, like this:
> 
> 2016-07-13 09:52:22,010 INFO
> [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp
> Reactor) [] Connecting to /10.X.X.X
> 2016-07-13 09:52:22,018 ERROR
> [org.ovirt.vdsm.jsonrpc.client.reactors.Reactor] (SSL Stomp Reactor) []
> Unable to process messages: General SSLEngine problem
> 
> It's worth mentioning that we're using our own SSL certificates (not
> self-signed), and I imported the combined certificate into the
> /etc/pki/ovirt-engine/.truststore key file. Not sure if related, but
> just in case.
> 
> I had to downgrade to 3.6.7. I'm attaching requested logs, if you need
> anything else don't hesitate to ask.


FYI I migrated my 3.6 env (engine + 1 host) to 4.0 and the host is up
and running fine on datacenter/cluster 4.0 compat level.

FYA there's a BZ about engine certs 
https://bugzilla.redhat.com/show_bug.cgi?id=1336838

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

Re: [ovirt-users] Unable to import pre-configured nfs data domain

[Logan Kuhn]

I'd be happy to, but how/where do I do that? 

Regards, 
Logan 

- On Jul 25, 2016, at 2:56 PM, Sandro Bonazzola  
wrote: 

| Il 22/Lug/2016 17:10, "Logan Kuhn" < log...@wolfram.com > ha scritto:

| > Thank you!

| > That does do some interesting things, but doesn't appear to work.

|> I've added a new storage domain, merged the differences in the metadata file
|> back to the old one and powered it up. When I start up the nodes they 
endlessly
|> report: VDSM ovirt-reqa1 command failed: (-226, 'Unable to read resource
| > owners', 'Sanlock exception')

|> I tried reinstalling one of them and the error message continues. At least 
for
| > now I've restored the old config and the error is gone.

| > Regards,
| > Logan


| Logan, do you mind to write a testcase in ovirt.org website for the disaster
| recovery test you are doing? Milan, if Logan write it, can you please review
| it?

| > - On Jul 22, 2016, at 3:06 AM, Milan Zamazal mzama...@redhat.com wrote:

| > | Logan Kuhn < log...@wolfram.com > writes:

| > |> Am I correct in the assumption that importing a previously master data 
domain
| > |> into a fresh engine without a current master domain is supported?

| > | It's supported only in case the master domain was previously correctly
| > | detached from the data center.

| > | In case of an unexpected complete disaster, when a fresh engine is
| > | installed and used, it's still possible to recover the master domain in
| > | theory. You must find `metadata' file in the master domain and edit it
| > | for the new engine. It's completely unsupported and it may or may not
| > | work. We don't have guidelines how to do it, but you may try to create
| > | a new master domain, then detach it and compare the two metadata files.
| > ___
| > Users mailing list
| > Users@ovirt.org
| > http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] ovirt 3.6.6 and gluster 3.7.13

[David Gossage]

On Tue, Jul 26, 2016 at 4:37 AM, Krutika Dhananjay 
wrote:

> Hi,
>
> 1.  Could you please attach the glustershd logs from all three nodes?
>

Here are ccgl1 and ccgl2.  as previously mentioned ccgl3 third node was
down from bad nic so no relevant logs would be on that node.


>
> 2. Also, so far what we know is that the 'Operation not permitted' errors
> are on the main vm image itself and not its individual shards (ex
> deb61291-5176-4b81-8315-3f1cf8e3534d). Could you do the following:
> Get the inode number of
> .glusterfs/de/b6/deb61291-5176-4b81-8315-3f1cf8e3534d (ls -li) from the
> first brick. I'll call this number INODE_NUMBER.
> Execute `find . -inum INODE_NUMBER` from the brick root on first brick to
> print the hard links against the file in the prev step and share the output.
>
[dgossage@ccgl1 ~]$ sudo ls -li
/gluster1/BRICK1/1/.glusterfs/de/b6/deb61291-5176-4b81-8315-3f1cf8e3534d
16407 -rw-r--r--. 2 36 36 466 Jun  5 16:52
/gluster1/BRICK1/1/.glusterfs/de/b6/deb61291-5176-4b81-8315-3f1cf8e3534d
[dgossage@ccgl1 ~]$ cd /gluster1/BRICK1/1/
[dgossage@ccgl1 1]$ sudo find . -inum 16407
./7c73a8dd-a72e-4556-ac88-7f6813131e64/dom_md/metadata
./.glusterfs/de/b6/deb61291-5176-4b81-8315-3f1cf8e3534d



>
> 3. Did you delete any vms at any point before or after the upgrade?
>

Immediately before or after on same day pretty sure I deleted nothing.
During week prior I deleted a few dev vm's that were never setup and some
the week after upgrade as I was preparing for moving disks off and on
storage to get them sharded and felt it would be easier to just recreate
some disks that had no data yet rather than move them off and on later.

>
> -Krutika
>
> On Mon, Jul 25, 2016 at 11:30 PM, David Gossage <
> dgoss...@carouselchecks.com> wrote:
>
>>
>> On Mon, Jul 25, 2016 at 9:58 AM, Krutika Dhananjay 
>> wrote:
>>
>>> OK, could you try the following:
>>>
>>> i. Set network.remote-dio to off
>>> # gluster volume set  network.remote-dio off
>>>
>>> ii. Set performance.strict-o-direct to on
>>> # gluster volume set  performance.strict-o-direct on
>>>
>>> iii. Stop the affected vm(s) and start again
>>>
>>> and tell me if you notice any improvement?
>>>
>>>
>> Previous instll I had issue with is still on gluster 3.7.11
>>
>> My test install of ovirt 3.6.7 and gluster 3.7.13 with 3 bricks on a
>> locak disk right now isn't allowing me to add the gluster storage at all.
>>
>> Keep getting some type of UI error
>>
>> 2016-07-25 12:49:09,277 ERROR
>> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
>> (default task-33) [] Permutation name: 430985F23DFC1C8BE1C7FDD91EDAA785
>> 2016-07-25 12:49:09,277 ERROR
>> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
>> (default task-33) [] Uncaught exception: : java.lang.ClassCastException
>> at Unknown.ps(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@3837)
>>at Unknown.ts(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@20)
>>  at Unknown.vs(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@18)
>>  at Unknown.iJf(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@19)
>> at Unknown.Xab(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@48)
>> at Unknown.P8o(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@4447)
>>   at Unknown.jQr(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@21)
>> at Unknown.A8o(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@51)
>> at Unknown.u8o(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@101)
>>at Unknown.Eap(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@10718)
>>  at Unknown.p8n(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@161)
>>at Unknown.Cao(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@31)
>> at Unknown.Bap(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@10469)
>>  at Unknown.kRn(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@49)
>> at Unknown.nRn(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@438)
>>at Unknown.eVn(
>> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@40)
>> at Unknown.h

Re: [ovirt-users] How do I activate a hot-plugged disk (in v3 Python SDK) ?

[Juan Hernández]

On 07/26/2016 08:53 AM, Yaniv Kaul wrote:
> 
> 
> On Mon, Jul 25, 2016 at 4:36 PM, Ondra Machacek  > wrote:
> 
> You actually have to run method 'activate()'[1] on VM disk.
> 
> So it will look like this:
> 
>  api.vms.get(VM0_NAME).disks.get(DISK1_NAME).activate()
> 
> [1]
> 
> https://gerrit.ovirt.org/gitweb?p=ovirt-engine-sdk.git;a=blob;f=src/ovirtsdk/infrastructure/brokers.py;h=7def8a5adea3357d31827f754a1e644b70de146d;hb=sdk_3.6#l31779
> 
> 
> Thanks.
> I've ended up adding 'active=True' to the disk when adding it - and it
> seems to do the same. Is that correct?
> Y.
>  

Yes, it is correct.

Note also that in general setting a property of an object in the SDK
doesn't do anything, you need to call the "update" method:

  disk = api.vms.get(VM0_NAME).disks.get(DISK1_NAME)
  disk.set_active(true)
  disk.update()

> 
> 
> 
> On 07/25/2016 03:13 PM, Yaniv Kaul wrote:
> 
> After successfully attaching a disk and verifying its status is
> in 'ok',
> I've tried:
> api.vms.get(VM0_NAME).disks.get(DISK1_NAME).set_active(True)
> 
> But it doesn't really activate it. What's the correct way to
> activate it?
> (It works well via the UI).
> 
> TIA,
> Y.

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Some question about vdsm rpc

[lifuqiong]

1.   We know that xmlrpc and jsonrpc are enabled default in vdsm, vdsm
supply these two service in one port or two? What's the port number and how
we can change it?

 

2.   How can we know a vdsm host can supply an xmlrpc service or a
jsonrpc service?

 

3.   I found that while ovirt engine installing a vdsm host, engine will
check whether we are connecting to vdsm which supports xmlrpc only, engine
send a 'Host.ping' jsonrpc request,  why the code will enter into
bindingxmlrpc.py?

Did both jsonrpc and xmlrpc will call bindingxmlrpc.py?

 

4.   Then, I just get an json return with code = 0 or code = 99. What
does these error code mean ? I can't find detail in rpcjson
Specification(http://www.jsonrpc.org/specification)

 

5.   When installing vdsm, I got an "Host server117 installation failed.
Host is not reachable" error. Debugging code as follows:

Bindingxmlrpc.py

line637  def ping(self):

line638   # print 'os.getuid()',os.getuid() = 0

line639   # print 'os.getegit()',os.getegid() =0

line640api = API.Global()

line641return api.ping()

 

the api.ping() just open an file and update the file updating time, why
these will throw an error code 0 or 99? And I see the ping() function
created file /var/run/vdsm/client.log already exists in os, 

the only difference is the file is owned by root:root , not the vdsm:kvm?
Why?

 

Thank you.

 

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

Re: [ovirt-users] Fedora 24 SSO

[Tadas]

Thank you. This did the trickOn Tue, 2016-07-26 at 12:26 +0200, Vinzenz 
Feenstra wrote:
> 
> > On Jul 26, 2016, at 11:39 AM, Vinzenz Feenstra  > > wrote:
> > 
> > > On Jul 22, 2016, at 7:38 AM, Tadas  wrote:
> > > 
> > > Hello,
> > > I'm having problems to get SSO working on Fedora24 guest.
> > > 
> > > The following packages are installed on guest:
> > > 
> > > ovirt-guest-agent-common.noarch    1.0.12-
> > > 3.fc24    @updates    
> > > ovirt-guest-agent-gdm-plugin.noarch    1.0.12-
> > > 3.fc24    @updates    
> > > ovirt-guest-agent-pam-module.x86_64    1.0.12-
> > > 3.fc24    @updates   
> > > 
> > > 
> > > When user tries to login, the following lines are displayed in
> > > ovirt-
> > > guest-agent.log
> > > 
> > > 
> > > Dummy-3::DEBUG::2016-07-22
> > > 08:21:09,614::GuestAgentLinux2::152::root::PkgMgr: list_pkgs
> > > returns
> > > [['kernel-4.5.5-300.fc24', 'xorg-x11-drv-qxl-0.1.4-7.fc24',
> > > 'ovirt-
> > > guest-agent-common-1.0.12-3.fc24']]
> > > Dummy-3::DEBUG::2016-07-22
> > > 08:21:09,614::OVirtAgentLogic::197::root::Sending applications
> > > with
> > > args {'applications': ['kernel-4.5.5-300.fc24', 'xorg-x11-drv-
> > > qxl-
> > > 0.1.4-7.fc24', 'ovirt-guest-agent-common-1.0.12-3.fc24']}
> > > Dummy-2::INFO::2016-07-22
> > > 08:21:10,302::OVirtAgentLogic::307::root::Received an external
> > > command:
> > > login...
> > > Dummy-2::DEBUG::2016-07-22
> > > 08:21:10,302::OVirtAgentLogic::341::root::User log-in
> > > (credentials =
> > > '\x00\x00\x00\x04test\x00')
> > > Dummy-2::DEBUG::2016-07-22
> > > 08:21:10,302::OVirtAgentLogic::280::root::AgentLogicBase::doListe
> > > n() -
> > > in loop before vio.read
> > Hello there,
> > 
> > I am sorry for the delay I had to find the time to spin up a new
> > test VM for this and was quite busy yesterday.
> > 
> > The reason is a missing dependency which causes the Credential
> > Server not to be started. Please run the following commands as
> > root:
> > 
> > # dnf install pygobject2  -y && systemctl restart ovirt-guest-agent
> > 
> > and it should work
> > 
> > I will fix the dependency issue in the repository 
> 
> The dependency issue is fixed in the fedora updates testing
> repository - ovirt-guest-agent-common-1.0.12-4.fc24 contains the fix
> 
> > thanks for your report!
> > 
> > 
> > 
> > 
> > > But guest does not react in any way, it just displays login
> > > screen.
> > > Also there's anything in /var/log/secure log file. It seems that
> > > pam
> > > module is not accessed.
> > > 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

Re: [ovirt-users] Fedora 24 SSO

[Vinzenz Feenstra]

> On Jul 26, 2016, at 11:39 AM, Vinzenz Feenstra  wrote:
> 
>> 
>> On Jul 22, 2016, at 7:38 AM, Tadas  wrote:
>> 
>> Hello,
>> I'm having problems to get SSO working on Fedora24 guest.
>> 
>> The following packages are installed on guest:
>> 
>> ovirt-guest-agent-common.noarch1.0.12-
>> 3.fc24@updates
>> ovirt-guest-agent-gdm-plugin.noarch1.0.12-
>> 3.fc24@updates
>> ovirt-guest-agent-pam-module.x86_641.0.12-
>> 3.fc24@updates   
>> 
>> 
>> When user tries to login, the following lines are displayed in ovirt-
>> guest-agent.log
>> 
>> 
>> Dummy-3::DEBUG::2016-07-22
>> 08:21:09,614::GuestAgentLinux2::152::root::PkgMgr: list_pkgs returns
>> [['kernel-4.5.5-300.fc24', 'xorg-x11-drv-qxl-0.1.4-7.fc24', 'ovirt-
>> guest-agent-common-1.0.12-3.fc24']]
>> Dummy-3::DEBUG::2016-07-22
>> 08:21:09,614::OVirtAgentLogic::197::root::Sending applications with
>> args {'applications': ['kernel-4.5.5-300.fc24', 'xorg-x11-drv-qxl-
>> 0.1.4-7.fc24', 'ovirt-guest-agent-common-1.0.12-3.fc24']}
>> Dummy-2::INFO::2016-07-22
>> 08:21:10,302::OVirtAgentLogic::307::root::Received an external command:
>> login...
>> Dummy-2::DEBUG::2016-07-22
>> 08:21:10,302::OVirtAgentLogic::341::root::User log-in (credentials =
>> '\x00\x00\x00\x04test\x00')
>> Dummy-2::DEBUG::2016-07-22
>> 08:21:10,302::OVirtAgentLogic::280::root::AgentLogicBase::doListen() -
>> in loop before vio.read
> 
> Hello there,
> 
> I am sorry for the delay I had to find the time to spin up a new test VM for 
> this and was quite busy yesterday.
> 
> The reason is a missing dependency which causes the Credential Server not to 
> be started. Please run the following commands as root:
> 
> # dnf install pygobject2  -y && systemctl restart ovirt-guest-agent
> 
> and it should work
> 
> I will fix the dependency issue in the repository 

The dependency issue is fixed in the fedora updates testing repository - 
ovirt-guest-agent-common-1.0.12-4.fc24 contains the fix

> 
> thanks for your report!
> 
> 
> 
> 
>> 
>> But guest does not react in any way, it just displays login screen.
>> Also there's anything in /var/log/secure log file. It seems that pam
>> module is not accessed.
>> 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

Re: [ovirt-users] Fedora 24 SSO

[Vinzenz Feenstra]

> On Jul 22, 2016, at 7:38 AM, Tadas  wrote:
> 
> Hello,
> I'm having problems to get SSO working on Fedora24 guest.
> 
> The following packages are installed on guest:
> 
> ovirt-guest-agent-common.noarch1.0.12-
> 3.fc24@updates
> ovirt-guest-agent-gdm-plugin.noarch1.0.12-
> 3.fc24@updates
> ovirt-guest-agent-pam-module.x86_641.0.12-
> 3.fc24@updates   
> 
> 
> When user tries to login, the following lines are displayed in ovirt-
> guest-agent.log
> 
> 
> Dummy-3::DEBUG::2016-07-22
> 08:21:09,614::GuestAgentLinux2::152::root::PkgMgr: list_pkgs returns
> [['kernel-4.5.5-300.fc24', 'xorg-x11-drv-qxl-0.1.4-7.fc24', 'ovirt-
> guest-agent-common-1.0.12-3.fc24']]
> Dummy-3::DEBUG::2016-07-22
> 08:21:09,614::OVirtAgentLogic::197::root::Sending applications with
> args {'applications': ['kernel-4.5.5-300.fc24', 'xorg-x11-drv-qxl-
> 0.1.4-7.fc24', 'ovirt-guest-agent-common-1.0.12-3.fc24']}
> Dummy-2::INFO::2016-07-22
> 08:21:10,302::OVirtAgentLogic::307::root::Received an external command:
> login...
> Dummy-2::DEBUG::2016-07-22
> 08:21:10,302::OVirtAgentLogic::341::root::User log-in (credentials =
> '\x00\x00\x00\x04test\x00')
> Dummy-2::DEBUG::2016-07-22
> 08:21:10,302::OVirtAgentLogic::280::root::AgentLogicBase::doListen() -
> in loop before vio.read

Hello there,

I am sorry for the delay I had to find the time to spin up a new test VM for 
this and was quite busy yesterday.

The reason is a missing dependency which causes the Credential Server not to be 
started. Please run the following commands as root:

# dnf install pygobject2  -y && systemctl restart ovirt-guest-agent

 and it should work

I will fix the dependency issue in the repository 

thanks for your report!




> 
> But guest does not react in any way, it just displays login screen.
> Also there's anything in /var/log/secure log file. It seems that pam
> module is not accessed.
> 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

Re: [ovirt-users] ovirt 3.6.6 and gluster 3.7.13

[Krutika Dhananjay]

Hi,

1.  Could you please attach the glustershd logs from all three nodes?

2. Also, so far what we know is that the 'Operation not permitted' errors
are on the main vm image itself and not its individual shards (ex
deb61291-5176-4b81-8315-3f1cf8e3534d). Could you do the following:
Get the inode number of
.glusterfs/de/b6/deb61291-5176-4b81-8315-3f1cf8e3534d (ls -li) from the
first brick. I'll call this number INODE_NUMBER.
Execute `find . -inum INODE_NUMBER` from the brick root on first brick to
print the hard links against the file in the prev step and share the output.

3. Did you delete any vms at any point before or after the upgrade?

-Krutika

On Mon, Jul 25, 2016 at 11:30 PM, David Gossage  wrote:

>
> On Mon, Jul 25, 2016 at 9:58 AM, Krutika Dhananjay 
> wrote:
>
>> OK, could you try the following:
>>
>> i. Set network.remote-dio to off
>> # gluster volume set  network.remote-dio off
>>
>> ii. Set performance.strict-o-direct to on
>> # gluster volume set  performance.strict-o-direct on
>>
>> iii. Stop the affected vm(s) and start again
>>
>> and tell me if you notice any improvement?
>>
>>
> Previous instll I had issue with is still on gluster 3.7.11
>
> My test install of ovirt 3.6.7 and gluster 3.7.13 with 3 bricks on a locak
> disk right now isn't allowing me to add the gluster storage at all.
>
> Keep getting some type of UI error
>
> 2016-07-25 12:49:09,277 ERROR
> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
> (default task-33) [] Permutation name: 430985F23DFC1C8BE1C7FDD91EDAA785
> 2016-07-25 12:49:09,277 ERROR
> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
> (default task-33) [] Uncaught exception: : java.lang.ClassCastException
> at Unknown.ps(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@3837)
>at Unknown.ts(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@20)
>  at Unknown.vs(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@18)
>  at Unknown.iJf(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@19)
> at Unknown.Xab(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@48)
> at Unknown.P8o(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@4447)
>   at Unknown.jQr(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@21)
> at Unknown.A8o(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@51)
> at Unknown.u8o(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@101)
>at Unknown.Eap(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@10718)
>  at Unknown.p8n(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@161)
>at Unknown.Cao(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@31)
> at Unknown.Bap(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@10469)
>  at Unknown.kRn(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@49)
> at Unknown.nRn(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@438)
>at Unknown.eVn(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@40)
> at Unknown.hVn(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@25827)
>  at Unknown.MTn(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@25)
> at Unknown.PTn(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@24052)
>  at Unknown.KJe(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@21125)
>  at Unknown.Izk(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@10384)
>  at Unknown.P3(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@137)
> at Unknown.g4(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@8271)
>at Unknown.(
> https://ccengine2.carouselchecks.local/ovirt-engine/webadmin/430985F23DFC1C8BE1C7FDD91EDAA785.cache.html@65)
> at Unknown._t(
> https://ccengine2.carouselchecks.local/ovirt-en

Re: [ovirt-users] When debug vdsm branch 4.0, why there has some code will call function ping(self) in bindingxmlrpc.py cycle? Even the vdsm is not managed by ovirt-engine?

[Francesco Romani]

- Original Message -
> From: "lifuqiong" 
> To: users@ovirt.org, de...@ovirt.org
> Sent: Tuesday, July 26, 2016 7:26:04 AM
> Subject: [ovirt-users] When debug vdsm branch 4.0,why there has some code 
> will call function ping(self) in
>   bindingxmlrpc.py cycle? Even the vdsm is not managed by ovirt-engine?
> 
> 
> 
> Hi,
> 
> I setup a breakpoint in Line 637 in bindingxmlrpc.py , which as follows:
> (branch:4.0; code url is: https://github.com/oVirt/vdsm/tree/ovirt-4.0)
> 
> 636 def ping(self):
> 
> 637 api = API.Global()
> 
> 638 return api.ping()
> 
> 
> 
> But even the vdsm is not managed by any ovirt-engine , the line 637 will be
> called many times,
> 
> I thought the ping() function will be called only when the ovirt-engine will
> create connection with vdsm, so why it will be called cycle?

This should be caused by the MOM daemon, which periodically checks the 
availability
of Vdsm.

Bests,

-- 
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] vdsm ssl errors

[Piotr Kliczewski]

Christoph,

Please apply [1] we would know exactly what verbs were called by this local
client.

Thanks,
Piotr

[1] https://gerrit.ovirt.org/#/c/61367/

On Mon, Jul 25, 2016 at 9:50 PM, Piotr Kliczewski <
piotr.kliczew...@gmail.com> wrote:

> On Mon, Jul 25, 2016 at 6:18 PM, Nir Soffer  wrote:
> > On Mon, Jul 25, 2016 at 6:22 PM, C. Handel  wrote:
> >> two nodes (x.x.138.208, x.x.138.210), hosted-engine on x.x.139.240.
> >>
> >> the vdsm logs are from x.x.138.208 and the connection is from the node
> >> itself.
> >>
> >>> Running tcpdump it is a connect from the node to itself. I can't figure
> >>> out what is wrong. Can someone ?> give me a hint?
> >>
> >> so i know they are coming from the node itself. The process connecting
> is
> >> terminating too fast. the moment i see it in tcpdump, it is gone from
> the
> >> process table.
> >
> > I think this is ovirt hosted agent - check its logs, you will probably
> find that
> > it make some request in the same time you see the errors in your logs.
> >
> > Adding Martin, maintaining this project.
> >
> > These are the interesting events in the logs:
> >
> > $ grep 37678 vdsm.log
> > JsonRpc (StompReactor)::ERROR::2016-07-25
> > 13:48:58,074::betterAsyncore::113::vds.dispatcher::(recv) SSL error
> > during reading data from  > connected (':::140.181.138.208', 37678, 0, 0) at 0x42c9b90>:
> > unexpected eof
> >
> > $ grep 37684 vdsm.log
> > Reactor thread::INFO::2016-07-25
> >
> 13:49:00,205::protocoldetector::72::ProtocolDetector.AcceptorImpl::(handle_accept)
> > Accepting connection from :::140.181.138.208:37684
> > Reactor thread::INFO::2016-07-25
> >
> 13:49:00,211::protocoldetector::121::ProtocolDetector.Detector::(handle_read)
> > Detected protocol stomp from :::140.181.138.208:37684
> > Reactor thread::DEBUG::2016-07-25
> >
> 13:49:00,211::stompreactor::492::protocoldetector.StompDetector::(handle_socket)
> > Stomp detected from (':::140.181.138.208', 37684)
> > JsonRpc (StompReactor)::ERROR::2016-07-25
> > 13:49:01,824::betterAsyncore::113::vds.dispatcher::(recv) SSL error
> > during reading data from  > connected (':::140.181.138.208', 37684, 0, 0) at 0x42b0758>:
> > unexpected eof
> >
> > The log is too small, we see only one full request.
> >
> > Pitor, can you understand from this log what the request coming from
> > :::140.181.138.208:37684
> > is doing?
> >
>
> I stated above there are 2 verbs that were called each time:
>
>  Host.getStats and Host.getHardwareInfo
>
> >>
> >> Greetings
> >>Christoph
> >>
> >> On Mon, Jul 25, 2016 at 4:53 PM, Piotr Kliczewski
> >>  wrote:
> >>>
> >>> Christoph,
> >>>
> >>> In log snippets you provided I can see 2 occurrences of the log entry.
> >>> There is 3 seconds between the calls.
> >>>
> >>> Each time I see calls to Host.getStats and Host.getHardwareInfo both
> >>> from x.x.138.208.
> >>> I do not see any log entries in the engine log so it not engine who
> >>> connected.
> >>>
> >>> What host is it?
> >>>
> >>> Thanks,
> >>> Piotr
> >>>
> >>>
> >>> On Mon, Jul 25, 2016 at 3:45 PM, C. Handel 
> wrote:
> >>> > patch applied, The connection is from the node itself.
> >>> >
> >>> > logfiles with the last 100k (hope this is enough, the error happens
> >>> > every
> >>> > few seconds) of data attached.
> >>> >
> >>> > Greetings
> >>> >   Christoph
> >>> >
> >>> > On Mon, Jul 25, 2016 at 12:07 PM, Nir Soffer 
> wrote:
> >>> >>
> >>> >> On Thu, Jul 21, 2016 at 10:00 AM, C. Handel 
> >>> >> wrote:
> >>> >> > longer logs attached, excerpts:
> >>> >> >
> >>> >> > ---+ vdsm
> >>> >> >
> >>> >> > Reactor thread::INFO::2016-07-21
> >>> >> >
> >>> >> >
> >>> >> >
> 08:01:19,544::protocoldetector::72::ProtocolDetector.AcceptorImpl::(handle_accept)
> >>> >> > Accepting connection from :::140.181.138.208:59502
> >>> >> > Reactor thread::DEBUG::2016-07-21
> >>> >> >
> >>> >> >
> >>> >> >
> 08:01:19,551::protocoldetector::85::ProtocolDetector.Detector::(__init__)
> >>> >> > Using required_size=11
> >>> >> > Reactor thread::INFO::2016-07-21
> >>> >> >
> >>> >> >
> >>> >> >
> 08:01:19,553::protocoldetector::121::ProtocolDetector.Detector::(handle_read)
> >>> >> > Detected protocol stomp from :::140.181.138.208:59502
> >>> >> > Reactor thread::INFO::2016-07-21
> >>> >> >
> 08:01:19,553::stompreactor::101::Broker.StompAdapter::(_cmd_connect)
> >>> >> > Processing CONNECT request
> >>> >> > Reactor thread::DEBUG::2016-07-21
> >>> >> >
> >>> >> >
> >>> >> >
> 08:01:19,554::stompreactor::492::protocoldetector.StompDetector::(handle_socket)
> >>> >> > Stomp detected from (':::140.181.138.208', 59502)
> >>> >> > JsonRpc (StompReactor)::INFO::2016-07-21
> >>> >> >
> >>> >> >
> 08:01:19,554::stompreactor::128::Broker.StompAdapter::(_cmd_subscribe)
> >>> >> > Subscribe command received
> >>> >> > ...
> >>> >> >
> >>> >> > JsonRpc (StompReactor)::ERROR::2016-07-21
> >>> >> > 08:01:21,411::betterAsyncore::113::vds.dispatcher::(recv) SSL
> error
> >>> >> > during
> >>> >> > reading data: unexpected eof
> >

Re: [ovirt-users] Hosted Engine & FC Data Domain

[Simone Tiraboschi]

On Tue, Jul 26, 2016 at 12:47 AM, Anantha Raghava
 wrote:
> Hello,
>
> I had recently installed oVirt 4.0.1 Hosted Engine with FC (SAN) Storage.
>
> I could install the oVirt, deploy hosted-engine. But when I accessed the
> Engine Web Admin, I noticed the following:
>
> a. There was no Data Domain. I had to import the FC LUN, on which the Hosted
> Engine's Disk resided into Storage manually. But when I attempted to attach
> the data domain to Data Center, it failed.
>
> b. I ended up removing all configuration, and recreated the FC LUNs. This
> time, I created two LUNs, on one LUN, the Hosted Engine resided. This time,
> first, I had to import the second LUN as master Data Domain and add the LUN
> on which Engine VM resided as just another Data Domain.
>
> Now the questions:
>
> i. Will Hosted Engine not automatically import the hosted_storage as master
> data domain? Why does it throw error when attempted to import and attach to
> DC?

You have just to create the first storage domain for regular VMs which
will become the master storage domain.
At that point the datacenter can go up and the engine will import the
hosted-engine storage domain by itself.
I agree with you that the warning message is a bit confusing and
indeed we have an open bug to change it:
https://bugzilla.redhat.com/show_bug.cgi?id=1358313

> ii. Is it necessary to have another data domain as master data domain,
> before attaching hosted_storage?

Yes, you have.

> iii. How do we change the master data domain from one to another?

Please avoid it.

> --
>
> Thanks & Regards,
>
>
> Anantha Raghava
>
> ___
> 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