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

2016-07-26 Thread 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

2016-07-26 Thread 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

2016-07-26 Thread 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

2016-07-26 Thread 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

2016-07-26 Thread 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

2016-07-26 Thread 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

2016-07-26 Thread 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(
>>

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

2016-07-26 Thread 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

2016-07-26 Thread 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

2016-07-26 Thread 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

2016-07-26 Thread 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

2016-07-26 Thread 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

2016-07-26 Thread 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

Re: [ovirt-users] vdsm ssl errors

2016-07-26 Thread 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
> >>>

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

2016-07-26 Thread 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