Re: [ovirt-users] Is windows sso still working on ovirt 4.1 ?

2017-05-08 Thread Yedidyah Bar David 
On Mon, May 8, 2017 at 8:04 PM, plysan  wrote:
> Solved by the additional configuration in
> https://github.com/Seitanas/kvm-vdi/blob/master/guest_agent/README.md
>
> It seems that ovirt-guest-tools-iso-4.1-3.fc24.noarch doesn't provide any
> credential providers dll, is there any reason why it's not included in the
> upstream ?

Not sure. Can you please open a bug about this?

Adding Vinzenz.

Thanks for the report!

>
> thanks
>
> 2017-05-07 21:47 GMT+08:00 plysan :
>>
>> OK, seems the problem is in guest agent:
>>
>> after login in vm manually, I see the following logs in
>> C:\Windows\SysWOW64\ovirt-guest-agent.log
>>
>> //begin log
>> Dummy-1::INFO::2017-05-07
>> 21:29:55,956::OVirtGuestService::84::root::Starting OVirt Guest Agent
>> service
>> Dummy-2::INFO::2017-05-07
>> 21:30:06,545::OVirtAgentLogic::321::root::Received an external command:
>> api-version...
>> Dummy-2::INFO::2017-05-07 21:30:06,545::OVirtAgentLogic::117::root::API
>> Version updated from 0 to 3
>> Dummy-2::INFO::2017-05-07
>> 21:30:59,503::OVirtAgentLogic::321::root::Received an external command:
>> lock-screen...
>> Dummy-2::INFO::2017-05-07
>> 21:31:13,756::OVirtAgentLogic::321::root::Received an external command:
>> login...
>> Dummy-2::ERROR::2017-05-07 21:31:14,756::GuestAgentWin32::311::root::Error
>> writing credentials to pipe [1/3] (error = 2)
>> Dummy-2::ERROR::2017-05-07 21:31:15,756::GuestAgentWin32::311::root::Error
>> writing credentials to pipe [2/3] (error = 2)
>> Dummy-2::ERROR::2017-05-07 21:31:16,755::GuestAgentWin32::311::root::Error
>> writing credentials to pipe [3/3] (error = 2)
>> //end log
>>
>> Digging into agent code to find the answer...
>>
>>
>>
>> 2017-05-07 16:28 GMT+08:00 plysan :
>>>
>>> Hi,
>>>
>>> I have recently set up a ovirt 4.1 environment to test vm sso.
>>>
>>> spec:
>>> * host: centos 7.3.1611
>>> * ovirt-engine: commit af393b7d3a494917dbda33a06813e8e8a8c6698a from
>>> branch ovirt-engine-4.1 , self compiled.
>>> * vdsm: vdsm-4.19.10.1-1.el7.centos.x86_64
>>> * windows 2008 r2 with active directory setup(domain name is "ply.local",
>>> test user is "ply@ply.local")
>>> * windows 7 vm with guest tools setup using
>>> ovirt-guest-tools-iso-4.1-3.fc24.noarch
>>>
>>> I can add AD to ovirt engine successfully using
>>> ovirt-engine-extension-aaa-ldap-setup tool.[1]
>>> After adding AD domain to windows7 vm, I can login manually using AD user
>>> with no problem.
>>>
>>> I can see the logs[2] when I login in to userportal with AD user, and
>>> spice client pop up automatically.
>>> But the spice client just stops at the windows7 login screen. asking for
>>> password.
>>> In the vm, vdagent and vdservice are all running fine. I can provide
>>> guest agent logs if needed.
>>>
>>> So, anyone can point me to the right direction?
>>>
>>> cheers
>>>
>>>
>>> [1]: see attachment:
>>> ovirt-engine-extension-aaa-ldap-setup-20170507034924-w5fwc9.log
>>> [2]: see attachment: vdsm-log,ovirt-engine-log
>>>
>>>
>>>
>>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>



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

Re: [ovirt-users] Various issues trying to get a new 4.1 install up and running

2017-05-08 Thread Jason Ziemba 
Took me a few other 'self inflicted' configuration issues and reloads.
Though, as soon as I added the extra Storage Domains, sure enough, the
hosted_engine domain (as well as the Hosted Engine) showed up.  Thank you!

On Wed, May 3, 2017 at 1:43 PM, Jason Brooks  wrote:

> On Wed, May 3, 2017 at 9:34 AM, Jason Ziemba  wrote:
> > I'm utilizing the latest node ISO
> > (ovirt-node-ng-installer-ovirt-4.1-2017050204.iso), upon installing on a
> > system I utilize the Web Cockpit UI to install the 4.1 hosted engine
> > (successfully), resulting in the following engine version:
> > 4.1.1.8-1.el7.centos.  The node is also running 4.1.1.1
> >
> > After installing the engine and accessing the Engine Web Admin I'm
> > encountering the following issues:
> >
> > I'm not seeing any storage domains in the console (though the engine is
> > installed using NFS).
> > Attempts to import the NFS storage domain that the engine resides in (for
> > other VMs to also reside in) fail due to inability to find host ID.
>
> You need to add a data domain, and after you do that, the hosted
> engine domain will show up.
>
> >
> > Attempts to add (import) the storage domain again once again fails,
> though
> > this time it states that the Storage connection already exists (yet it
> isn't
> > listed in the storage domains).
> >
> > The hosted engine doesn't show up in the console, though Bug 1269768
> states
> > that was supposed to be corrected in 3.6.1
> > Installing (from the same ISO) subsequent hosts and then using the
> Engine to
> > bring the node in to the cluster, the additional nodes don't have the
> > ability to run the hosted engine (based on the lack of the crown icon),
> > preventing the original node from entering maintenance mode as the engine
> > (which can't be seen) isn't able to migrate to a different node.
> >
> > I'm not sure where to begin reviewing/troubleshooting based on these
> items.
> > Any guidance would be greatly appreciated.
> >
> > ___
> > 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] Is windows sso still working on ovirt 4.1 ?

2017-05-08 Thread plysan 
Solved by the additional configuration in
https://github.com/Seitanas/kvm-vdi/blob/master/guest_agent/README.md

It seems that ovirt-guest-tools-iso-4.1-3.fc24.noarch doesn't provide any
credential providers dll, is there any reason why it's not included in the
upstream ?

thanks

2017-05-07 21:47 GMT+08:00 plysan :

> OK, seems the problem is in guest agent:
>
> after login in vm manually, I see the following logs
> in C:\Windows\SysWOW64\ovirt-guest-agent.log
>
> //begin log
> Dummy-1::INFO::2017-05-07 21:29:55,956::OVirtGuestService::84::root::Starting
> OVirt Guest Agent service
> Dummy-2::INFO::2017-05-07 21:30:06,545::OVirtAgentLogic::321::root::Received
> an external command: api-version...
> Dummy-2::INFO::2017-05-07 21:30:06,545::OVirtAgentLogic::117::root::API
> Version updated from 0 to 3
> Dummy-2::INFO::2017-05-07 21:30:59,503::OVirtAgentLogic::321::root::Received
> an external command: lock-screen...
> Dummy-2::INFO::2017-05-07 21:31:13,756::OVirtAgentLogic::321::root::Received
> an external command: login...
> Dummy-2::ERROR::2017-05-07 21:31:14,756::GuestAgentWin32::311::root::Error
> writing credentials to pipe [1/3] (error = 2)
> Dummy-2::ERROR::2017-05-07 21:31:15,756::GuestAgentWin32::311::root::Error
> writing credentials to pipe [2/3] (error = 2)
> Dummy-2::ERROR::2017-05-07 21:31:16,755::GuestAgentWin32::311::root::Error
> writing credentials to pipe [3/3] (error = 2)
> //end log
>
> Digging into agent code to find the answer...
>
>
>
> 2017-05-07 16:28 GMT+08:00 plysan :
>
>> Hi,
>>
>> I have recently set up a ovirt 4.1 environment to test vm sso.
>>
>> spec:
>> * host: centos 7.3.1611
>> * ovirt-engine: commit af393b7d3a494917dbda33a06813e8e8a8c6698a from
>> branch ovirt-engine-4.1 , self compiled.
>> * vdsm: vdsm-4.19.10.1-1.el7.centos.x86_64
>> * windows 2008 r2 with active directory setup(domain name is "ply.local",
>> test user is "ply@ply.local")
>> * windows 7 vm with guest tools setup using ovirt-guest-tools-iso-4.
>> 1-3.fc24.noarch
>>
>> I can add AD to ovirt engine successfully using 
>> ovirt-engine-extension-aaa-ldap-setup
>> tool.[1]
>> After adding AD domain to windows7 vm, I can login manually using AD user
>> with no problem.
>>
>> I can see the logs[2] when I login in to userportal with AD user, and
>> spice client pop up automatically.
>> But the spice client just stops at the windows7 login screen. asking for
>> password.
>> In the vm, vdagent and vdservice are all running fine. I can provide
>> guest agent logs if needed.
>>
>> So, anyone can point me to the right direction?
>>
>> cheers
>>
>>
>> [1]: see attachment: ovirt-engine-extension-aaa-lda
>> p-setup-20170507034924-w5fwc9.log
>> [2]: see attachment: vdsm-log,ovirt-engine-log
>>
>>
>>
>>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Force-Shutdown a VM?

2017-05-08 Thread Derek Atkins 
Hi Michal,

Michal Skrivanek  writes:

>> On 5 May 2017, at 16:42, Derek Atkins  wrote:
>> 
>> Kai,
>> 
>> Kai Wagner  writes:
>> 
>>> Just click twice on the "shutdown" button -> this will kill the VM process
>>> immediately
>> 
>> Is this documented somewhere?  In googling various terms like "power
>> off", "force shutdown", etc I didn't find this trick anywhere (nor did I
>> find the right-click menu).  My searching did come up with the "Reboot"
>> feature which was supposed to force-shutdown after a timeout, but that
>> is apparently not implemented yet.
>
> Hi Derek,
> it is implemented, it may not work as supposed to though:)
> Did you try it, how long did you wait, was the VM completely stuck or
> services were supposed to be running ok, do you have guest-agent
> running in the guest?

The VM was completely stuck..  Connecting to the console I'd see an
image but the "clock" was frozen, the mouse wouldn't move, and it
wouldn't respond to any keypresses.  The VM guest normally does run the
guest agent tools, but I suspect they were not repsonding at all.

What I tried:

1) The reboot button.
2) The shutdown button.
3) The shutdown button again (still only a single click).
4) (after this thread) Right Click -> Power Off

I have not tried clicking twice on the shutdown button.  If this VM
hangs again I can try it again.  I don't know what caused the VM to hang
so I'm not sure exactly how to reproduce this issue.

In terms of the "reboot" feature that I claim not not be implemented,
I'm referring to [0].  The documentation of this feature claims that it
will timeout and force a power off.  Assuming the current reboot is this
feature, it did not do that.  Interestingly, as I re-read this page now
it DOES mention the context menu and a "power off" feature!

Thank you,

> Thanks,
> michal

-derek

[0] 
http://www.ovirt.org/develop/release-management/features/engine/guest-reboot/

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Ovirt Installation on Centos 7.3 1704 is broken

2017-05-08 Thread Oliver Dietzel 
Thx a lot!

Von: Eduardo Mayoral [mailto:emayo...@arsys.es]
Gesendet: Montag, 8. Mai 2017 12:22
An: Oliver Dietzel ; 'users@ovirt.org' 
Betreff: Re: [ovirt-users] Ovirt Installation on Centos 7.3 1704 is broken


Quoted from https://www.ovirt.org/release/4.1.1/#fedora--centos--rhel



EPEL

TL;DR Don't enable all of EPEL on oVirt machines.

The ovirt-release package enables the epel repositories and includes several 
specific packages that are required from there. It also enables and uses the 
CentOS OpsTools SIG repos, for other packages.

EPEL currently includes collectd 5.7.1, and the collectd package there includes 
the write_ plugin.

OpsTools currently includes collectd 5.7.0, and the write_ plugin is packaged 
separately.

ovirt-release does not use collectd from epel, so if you only use it, you 
should be ok.

If you want to use other packages from EPEL, you should make sure to not 
include collectd. Either use includepkgs and add those you need, or use 
excludepkgs=collectd*.

The correct directive is "exclude=collectd*" , not "excludepkgs=collectd*" , 
but other than that, this looks like what you are experiencing.



Eduardo Mayoral Jimeno (emayo...@arsys.es)

Administrador de sistemas. Departamento de Plataformas. Arsys internet.

+34 941 620 145 ext. 5153
On 08/05/17 12:14, Oliver Dietzel wrote:

Collectd-disk and -write_http require an older version of collectd than offered 
by the repos (7.2.0-2 instead of 7.2.1-2 as offered by repo).



Will there be updated versions of collectd-disk and -write_http?



To reproduce try # yum -y install ovirt-engine



on a fully updated Centos 7.3 1704

https://buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-Minimal-1704-01.iso





___

Oliver Dietzel





___

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] Hosted Engine Setup with the gluster bricks on the same disk as the OS

2017-05-08 Thread knarra 

On 05/07/2017 04:48 PM, Mike DePaulo wrote:

Hi. I am trying to follow this guide. Is it possible to use part of my
OS disk /dev/sda for the bricks?
https://www.ovirt.org/blog/2017/04/up-and-running-with-ovirt-4-1-and-gluster-storage/

I am using oVirt Node 4.1.1.1. I am aware of the manual partitioning
requirements. I am guessing I have to create an LV for the OS that
does not take up the entire disk during install, manually create a pv
like /dev/sda3 afterwards, and then run Hosted Engine Setup and
specify /sda3 rather than sdb?

Thanks,
-Mike
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Hi Mike,

If you create gluster bricks on the same disk as OS it works but we 
do not recommend setting up gluster bricks on the same disk as the os. 
When user tries to create a gluster volume using by specifying the 
bricks from root partition it displays an error message "Bricks in root 
parition not recommended and use force at the end to create volume".


Thanks

kasturi

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

Re: [ovirt-users] Ovirt Installation on Centos 7.3 1704 is broken

2017-05-08 Thread Yedidyah Bar David 
On Mon, May 8, 2017 at 1:22 PM, Eduardo Mayoral  wrote:
> Quoted from https://www.ovirt.org/release/4.1.1/#fedora--centos--rhel
>
>
> EPEL
>
> TL;DR Don't enable all of EPEL on oVirt machines.
>
> The ovirt-release package enables the epel repositories and includes several
> specific packages that are required from there. It also enables and uses the
> CentOS OpsTools SIG repos, for other packages.
>
> EPEL currently includes collectd 5.7.1, and the collectd package there
> includes the write_ plugin.
>
> OpsTools currently includes collectd 5.7.0, and the write_ plugin is
> packaged separately.
>
> ovirt-release does not use collectd from epel, so if you only use it, you
> should be ok.
>
> If you want to use other packages from EPEL, you should make sure to not
> include collectd. Either use includepkgs and add those you need, or use
> excludepkgs=collectd*.
>
> The correct directive is "exclude=collectd*" , not "excludepkgs=collectd*" ,
> but other than that, this looks like what you are experiencing.

Thanks for noting this. No idea what I had in my mind - most likely
"extrapolated" this from includepkgs.

https://github.com/oVirt/ovirt-site/pull/944

Best,

>
>
> Eduardo Mayoral Jimeno (emayo...@arsys.es)
> Administrador de sistemas. Departamento de Plataformas. Arsys internet.
> +34 941 620 145 ext. 5153
>
> On 08/05/17 12:14, Oliver Dietzel wrote:
>
> Collectd-disk and -write_http require an older version of collectd than
> offered by the repos (7.2.0-2 instead of 7.2.1-2 as offered by repo).
>
> Will there be updated versions of collectd-disk and -write_http?
>
> To reproduce try # yum -y install ovirt-engine
>
> on a fully updated Centos 7.3 1704
> https://buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-Minimal-1704-01.iso
>
>
> ___
> Oliver Dietzel
>
>
> ___
> 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
>



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

Re: [ovirt-users] Ovirt Installation on Centos 7.3 1704 is broken

2017-05-08 Thread Eduardo Mayoral 
Quoted from https://www.ovirt.org/release/4.1.1/#fedora--centos--rhel


>   EPEL
>
> TL;DR Don't enable all of EPEL on oVirt machines.
>
> The ovirt-release package enables the epel repositories and includes
> several specific packages that are required from there. It also
> enables and uses the CentOS OpsTools SIG repos, for other packages.
>
> EPEL currently includes collectd 5.7.1, and the collectd package there
> includes the write_plugin.
>
> OpsTools currently includes collectd 5.7.0, and the write_plugin is
> packaged separately.
>
> ovirt-release does not use collectd from epel, so if you only use it,
> you should be ok.
>
> If you want to use other packages from EPEL, you should make sure to
> not include collectd. Either use |includepkgs| and add those you need,
> or use |excludepkgs=collectd*|.
>
The correct directive is "exclude=collectd*" , not
"excludepkgs=collectd*" , but other than that, this looks like what you
are experiencing.


Eduardo Mayoral Jimeno (emayo...@arsys.es)
Administrador de sistemas. Departamento de Plataformas. Arsys internet.
+34 941 620 145 ext. 5153

On 08/05/17 12:14, Oliver Dietzel wrote:
> Collectd-disk and -write_http require an older version of collectd than 
> offered by the repos (7.2.0-2 instead of 7.2.1-2 as offered by repo).
>
> Will there be updated versions of collectd-disk and -write_http?
>
> To reproduce try # yum -y install ovirt-engine
>
> on a fully updated Centos 7.3 1704
> https://buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-Minimal-1704-01.iso
>
>
> ___
> Oliver Dietzel
>  
>
> ___
> 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

[ovirt-users] Ovirt Installation on Centos 7.3 1704 is broken

2017-05-08 Thread Oliver Dietzel 
Collectd-disk and -write_http require an older version of collectd than offered 
by the repos (7.2.0-2 instead of 7.2.1-2 as offered by repo).

Will there be updated versions of collectd-disk and -write_http?

To reproduce try # yum -y install ovirt-engine

on a fully updated Centos 7.3 1704
https://buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-Minimal-1704-01.iso


___
Oliver Dietzel
 

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

Re: [ovirt-users] High latency on storage domains and sanlock renewal error

2017-05-08 Thread Stefano Bovina 
Yes,
this configuration is the one suggested by EMC for EL7.

By the way,
"The parameters rr_min_io vs. rr_min_io_rq mean the same thing but are used
for device-mapper-multipath on differing kernel versions." and rr_min_io_rq
default value is 1, rr_min_io default value is 1000, so it should be fine.


2017-05-08 9:39 GMT+02:00 Yaniv Kaul :

>
> On Sun, May 7, 2017 at 1:27 PM, Stefano Bovina  wrote:
>
>> Sense data are 0x0/0x0/0x0
>
>
> Interesting - first time I'm seeing 0/0/0. The 1st is usually 0x2 (see
> [1]), and then the rest [2], [3] make sense.
>
> A google search found another user with Clarion with the exact same
> error[4], so I'm leaning toward misconfiguration of multipathing/clarion
> here.
>
> Is your multipathing configuration working well for you?
> Are you sure it's a EL7 configuration? For example, I believe you should
> have rr_min_io_rq and not rr_min_io .
> Y.
>
> [1] http://www.t10.org/lists/2status.htm
> [2] http://www.t10.org/lists/2sensekey.htm
> [3] http://www.t10.org/lists/asc-num.htm
> [4] http://www.linuxquestions.org/questions/centos-111/multi
> path-problems-4175544908/
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] VM disk update failure

2017-05-08 Thread Stefano Bovina 
Hi,
Ok, ignore what I said regards step 2. The volume exists.

2017-05-07 20:27 GMT+02:00 Stefano Bovina :

> Hi,
> 1)
> What do you need exactly? Shutdown VM, edit disk, "extend size by" --->
> error
>
> 2)
> storage domain is up and running, but with lvm command, vg exists, lv does
> not exist
>
> Powering up a machine, I also saw these lines in vdsm log:
>
>
> Thread-22::DEBUG::2017-05-07 18:59:54,115::blockSD::596::St
> orage.Misc.excCmd::(getReadDelay) SUCCESS:  = '1+0 records in\n1+0
> records out\n4096 bytes (4.1 kB) copied, 0.000411491 s, 10.0 MB/s\n'; 
> = 0
> Thread-300::DEBUG::2017-05-07 
> 18:59:55,539::libvirtconnection::151::root::(wrapper)
> Unknown libvirterror: ecode: 80 edom: 20 level: 2 message: metadata not
> found: Requested metadata element is not present
> Thread-1101::DEBUG::2017-05-07 
> 18:59:55,539::libvirtconnection::151::root::(wrapper)
> Unknown libvirterror: ecode: 80 edom: 20 level: 2 message: metadata not
> found: Requested metadata element is not present
> VM Channels Listener::INFO::2017-05-07 
> 18:59:55,560::guestagent::180::vm.Vm::(_handleAPIVersion)
> vmId=`79cd29dc-bb6c-4f1f-ae38-54d6cac05489`::Guest API version changed
> from 3 to 1
> VM Channels Listener::INFO::2017-05-07 
> 18:59:55,865::guestagent::180::vm.Vm::(_handleAPIVersion)
> vmId=`d37b37e9-1dd7-4a90-8d8c-755743c714ad`::Guest API version changed
> from 2 to 1
> VM Channels Listener::INFO::2017-05-07 
> 18:59:57,414::guestagent::180::vm.Vm::(_handleAPIVersion)
> vmId=`8a034ac2-2646-4fe7-8fda-7c33affa8009`::Guest API version changed
> from 2 to 1
> VM Channels Listener::INFO::2017-05-07 
> 18:59:58,178::guestagent::180::vm.Vm::(_handleAPIVersion)
> vmId=`4d1dad66-4ada-445a-b5f6-c695220d6b19`::Guest API version changed
> from 3 to 1
> Thread-272::DEBUG::2017-05-07 
> 18:59:58,187::libvirtconnection::151::root::(wrapper)
> Unknown libvirterror: ecode: 80 edom: 20 level: 2 message: metadata not
> found: Requested metadata element is not present
> Thread-166::DEBUG::2017-05-07 
> 18:59:58,539::libvirtconnection::151::root::(wrapper)
> Unknown libvirterror: ecode: 80 edom: 20 level: 2 message: metadata not
> found: Requested metadata element is not present
> Thread-18::DEBUG::2017-05-07 19:00:33,805::persistentDict::
> 234::Storage.PersistentDict::(refresh) read lines (LvMetadataRW)=[]
> Thread-18::DEBUG::2017-05-07 19:00:33,805::persistentDict::
> 252::Storage.PersistentDict::(refresh) Empty metadata
> Thread-18::DEBUG::2017-05-07 19:00:33,805::persistentDict::
> 192::Storage.PersistentDict::(__init__) Created a persistent dict with
> VGTagMetadataRW backend
> Thread-18::DEBUG::2017-05-07 19:00:33,805::lvm::504::Storag
> e.OperationMutex::(_invalidatevgs) Operation 'lvm invalidate operation'
> got the operation mutex
> Thread-18::DEBUG::2017-05-07 19:00:33,806::lvm::506::Storag
> e.OperationMutex::(_invalidatevgs) Operation 'lvm invalidate operation'
> released the operation mutex
> Thread-18::DEBUG::2017-05-07 19:00:33,806::lvm::514::Storag
> e.OperationMutex::(_invalidatelvs) Operation 'lvm invalidate operation'
> got the operation mutex
> Thread-18::DEBUG::2017-05-07 19:00:33,806::lvm::526::Storag
> e.OperationMutex::(_invalidatelvs) Operation 'lvm invalidate operation'
> released the operation mutex
> Thread-18::DEBUG::2017-05-07 
> 19:00:33,806::lvm::371::Storage.OperationMutex::(_reloadvgs)
> Operation 'lvm reload operation' got the operation mutex
> Thread-18::DEBUG::2017-05-07 
> 19:00:33,806::lvm::291::Storage.Misc.excCmd::(cmd)
> /usr/bin/sudo -n /sbin/lvm vgs --config ' devices { preferred_names =
> ["^/dev/mapper/"] ignore_suspended_devices=1 write_cache_state=0
> disable_after_error_count=3 obtain_device_list_from_udev=0 filter = [
> '\''a|/dev/mapper/360060160a62134002818778f949de411|/dev/
> mapper/360060160a621340040652b7582f5e511|/dev/mapper/3600601
> 60a621340064b1034cbbfce511|/dev/mapper/360060160a6213400c4
> b39e80949de411|/dev/mapper/360060160a6213400cce46e40949de411
> |/dev/mapper/360060160a6213400e622de69949de411|/dev/mapper/3
> 60060160a6213400fa2d31acbbfce511|'\'', '\''r|.*|'\'' ] }  global {
>  locking_type=1  prioritise_write_locks=1  wait_for_locks=1  use_lvmetad=0
> }  backup {  retain_min = 50  retain_days = 0 } ' --noheadings --units b
> --nosuffix --separator '|' --ignoreskippedcluster -o
> uuid,name,attr,size,free,extent_size,extent_count,free_count
> ,tags,vg_mda_size,vg_mda_free,lv_count,pv_count,pv_name
> 2c501858-bf8d-49a5-a42b-bca341b47827 (cwd None)
> Thread-18::DEBUG::2017-05-07 
> 19:00:33,962::lvm::291::Storage.Misc.excCmd::(cmd)
> SUCCESS:  = '  WARNING: lvmetad is running but disabled. Restart
> lvmetad before enabling it!\n';  = 0
> Thread-18::DEBUG::2017-05-07 
> 19:00:33,962::lvm::416::Storage.OperationMutex::(_reloadvgs)
> Operation 'lvm reload operation' released the operation mutex
> Thread-18::DEBUG::2017-05-07 19:00:33,963::persistentDict::
> 234::Storage.PersistentDict::(refresh) read lines
> (VGTagMetadataRW)=['CLASS=Data',

Re: [ovirt-users] High latency on storage domains and sanlock renewal error

2017-05-08 Thread Stefano Bovina 
Hi,

thanks for the advice. The upgrade is already scheduled, but I would like
to fix this issue before proceeding with a big upgrade (unless an upgrade
will fixes the problem).

The problem is on all hypervisors.

We have 2 cluster (both connected to the same storage system):
 - the old one with FC
 - the new one with FCoE


With dmesg -T and looking at /var/log/messages we found several problems
like these:

1)
[Wed May  3 10:40:11 2017] sd 12:0:0:3: Parameters changed
[Wed May  3 10:40:11 2017] sd 12:0:1:3: Parameters changed
[Wed May  3 10:40:11 2017] sd 12:0:1:1: Parameters changed
[Wed May  3 10:40:12 2017] sd 13:0:0:1: Parameters changed
[Wed May  3 10:40:12 2017] sd 13:0:0:3: Parameters changed
[Wed May  3 10:40:12 2017] sd 13:0:1:3: Parameters changed
[Wed May  3 12:39:32 2017] device-mapper: multipath: Failing path 65:144.
[Wed May  3 12:39:37 2017] sd 13:0:1:2: alua: port group 01 state A
preferred supports tolUsNA

2)
[Wed May  3 17:08:17 2017] perf interrupt took too long (2590 > 2500),
lowering kernel.perf_event_max_sample_rate to 5

3)
[Wed May  3 19:16:21 2017] bnx2fc: els 0x5: tgt not ready
[Wed May  3 19:16:21 2017] bnx2fc: Relogin to the tgt

4)
sd 13:0:1:0: [sdx] FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
sd 13:0:1:0: [sdx] CDB: Read(16) 88 00 00 00 00 00 00 58 08 00 00 00 04 00
00 00
blk_update_request: I/O error, dev sdx, sector 5769216
device-mapper: multipath: Failing path 65:112.
sd 13:0:1:0: alua: port group 01 state A preferred supports tolUsNA

5)
multipathd: 360060160a6213400cce46e40949de411: sdaa - emc_clariion_checker:
Read error for WWN 60060160a6213400cce46e40949de411.  Sense data are
0x0/0x0/0x0.
multipathd: checker failed path 65:160 in map
360060160a6213400cce46e40949de411
multipathd: 360060160a6213400cce46e40949de411: remaining active paths: 3
kernel: device-mapper: multipath: Failing path 65:160.
multipathd: 360060160a6213400cce46e40949de411: sdaa - emc_clariion_checker:
Active path is healthy.
multipathd: 65:160: reinstated
multipathd: 360060160a6213400cce46e40949de411: remaining active paths: 4

6)
[Sat May  6 11:37:07 2017] megaraid_sas :02:00.0: Firmware crash dump
is not available


Multipath configuration is the following (recommended by EMC):

# RHEV REVISION 1.1
# RHEV PRIVATE

devices {
device {
vendor  "DGC"
product ".*"
product_blacklist   "LUNZ"
path_grouping_policygroup_by_prio
path_selector   "round-robin 0"
path_checkeremc_clariion
features"1 queue_if_no_path"
hardware_handler"1 alua"
prioalua
failbackimmediate
rr_weight   uniform
no_path_retry   60
rr_min_io   1
}
}

Regards,

Stefano


2017-05-07 8:36 GMT+02:00 Yaniv Kaul :

>
>
> On Tue, May 2, 2017 at 11:09 PM, Stefano Bovina  wrote:
>
>> Hi, the engine logs show high latency on storage domains: "Storage domain
>>  experienced a high latency of 19.2814 seconds from .. This may
>> cause performance and functional issues."
>>
>> Looking at host logs, I found also these locking errors:
>>
>> 2017-05-02 20:52:13+0200 33883 [10098]: s1 renewal error -202
>> delta_length 10 last_success 33853
>> 2017-05-02 20:52:19+0200 33889 [10098]: 6a386652 aio collect 0
>> 0x7f1fb80008c0:0x7f1fb80008d0:0x7f1fbe9fb000 result 1048576:0 other free
>> 2017-05-02 21:08:51+0200 34880 [10098]: 6a386652 aio timeout 0
>> 0x7f1fb80008c0:0x7f1fb80008d0:0x7f1fbe4f2000 ioto 10 to_count 24
>> 2017-05-02 21:08:51+0200 34880 [10098]: s1 delta_renew read rv -202
>> offset 0 /dev/6a386652-629d-4045-835b-21d2f5c104aa/ids
>> 2017-05-02 21:08:51+0200 34880 [10098]: s1 renewal error -202
>> delta_length 10 last_success 34850
>> 2017-05-02 21:08:53+0200 34883 [10098]: 6a386652 aio collect 0
>> 0x7f1fb80008c0:0x7f1fb80008d0:0x7f1fbe4f2000 result 1048576:0 other free
>> 2017-05-02 21:30:40+0200 36189 [10098]: 6a386652 aio timeout 0
>> 0x7f1fb80008c0:0x7f1fb80008d0:0x7f1fbe9fb000 ioto 10 to_count 25
>> 2017-05-02 21:30:40+0200 36189 [10098]: s1 delta_renew read rv -202
>> offset 0 /dev/6a386652-629d-4045-835b-21d2f5c104aa/ids
>> 2017-05-02 21:30:40+0200 36189 [10098]: s1 renewal error -202
>> delta_length 10 last_success 36159
>> 2017-05-02 21:30:45+0200 36195 [10098]: 6a386652 aio collect 0
>> 0x7f1fb80008c0:0x7f1fb80008d0:0x7f1fbe9fb000 result 1048576:0 other free
>>
>> and this vdsm errors too:
>>
>> Thread-22::ERROR::2017-05-02 21:53:48,147::sdc::137::Storag
>> e.StorageDomainCache::(_findDomain) looking for unfetched domain
>> f8f21d6c-2425-45c4-aded-4cb9b53ebd96
>> Thread-22::ERROR::2017-05-02 21:53:48,148::sdc::154::Storag
>> e.StorageDomainCache::(_findUnfetchedDomain) looking for domain
>> f8f21d6c-2425-45c4-aded-4cb9b53ebd96
>>
>> Engine instead is showing this errors:
>>
>> 2017-05-02 21:40:38,089 ERROR [org.ovirt.engine.core.vdsbrok
>> er.vdsbroker.SpmStatusVDSCommand]

Re: [ovirt-users] High latency on storage domains and sanlock renewal error

2017-05-08 Thread Yaniv Kaul 
On Sun, May 7, 2017 at 1:27 PM, Stefano Bovina  wrote:

> Sense data are 0x0/0x0/0x0


Interesting - first time I'm seeing 0/0/0. The 1st is usually 0x2 (see
[1]), and then the rest [2], [3] make sense.

A google search found another user with Clarion with the exact same
error[4], so I'm leaning toward misconfiguration of multipathing/clarion
here.

Is your multipathing configuration working well for you?
Are you sure it's a EL7 configuration? For example, I believe you should
have rr_min_io_rq and not rr_min_io .
Y.

[1] http://www.t10.org/lists/2status.htm
[2] http://www.t10.org/lists/2sensekey.htm
[3] http://www.t10.org/lists/asc-num.htm
[4] http://www.linuxquestions.org/questions/centos-111/
multipath-problems-4175544908/
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] New oVirt Node 4.0.6.1 network problem with bond and many vlans - Network.service timeout failed

2017-05-08 Thread Sandro Bonazzola 
On Sat, May 6, 2017 at 11:27 PM, Rogério Ceni Coelho <
rogeriocenicoe...@gmail.com> wrote:

> To install 4.1.1 node  i need to update ovirt engine ?


Since 4.0 is unsupported I would recomment to update ovirt-engine to 4.1.1
too.



>
>
> Em Sáb, 6 de mai de 2017 13:07, Sandro Bonazzola 
> escreveu:
>
>>
>>
>> Il 04/Mag/2017 20:02, "Rogério Ceni Coelho" 
>> ha scritto:
>>
>> Hi oVirt admins,
>>
>> Yesterday, i install a new node 4.0.6.1
>>
>>
>> I would suggest to go with 4.1.1 nodes since 4.0 is not supported anymore.
>>
>>
>> and after config network bond (1) + vlans ( about 50 ), network.service
>> failed with timeout as above. All my old and working fine oVirt nodes run
>> 4.0.5 and have the same 5 min timeout on systemd.
>>
>> When i try to run vms on this new server, some networks are ok and some
>> not.
>>
>> I install oVirt Node with 4.0.3 on same server and this problem do not
>> occur.
>>
>> How can i workaround or change timeout to network.service ?
>>
>> In time, there are any way to update oVirt Node to 4.0.5 from 4.0.3
>> install iso ?
>>
>> [root@prd-rbs-ovirt-kvm21-poa ~]# systemctl status network.service
>> â— network.service - LSB: Bring up/down networking
>>Loaded: loaded (/etc/rc.d/init.d/network; bad; vendor preset: disabled)
>>Active: failed (Result: timeout) since Thu 2017-05-04 11:29:43 BRT; 3h
>> 12min ago
>>  Docs: man:systemd-sysv-generator(8)
>>   Process: 7574 ExecStart=/etc/rc.d/init.d/network start (code=killed,
>> signal=TERM)
>>
>> May 04 11:29:12 prd-rbs-ovirt-kvm21-poa.rbs.com.br network[7574]:
>> Bringing up interface o_p_s_a_lb_758:  [  OK  ]
>> May 04 11:29:18 prd-rbs-ovirt-kvm21-poa.rbs.com.br network[7574]:
>> Bringing up interface o_p_sites_a_755:  [  OK  ]
>> May 04 11:29:23 prd-rbs-ovirt-kvm21-poa.rbs.com.br network[7574]:
>> Bringing up interface o_prod_app_757:  [  OK  ]
>> May 04 11:29:28 prd-rbs-ovirt-kvm21-poa.rbs.com.br network[7574]:
>> Bringing up interface o_prod_db_756:  [  OK  ]
>> May 04 11:29:38 prd-rbs-ovirt-kvm21-poa.rbs.com.br network[7574]:
>> Bringing up interface ovirtmgmt:  [  OK  ]
>> *May 04 11:29:43 prd-rbs-ovirt-kvm21-poa.rbs.com.br
>>  systemd[1]: network.service
>> start operation timed out. Terminating.*
>> May 04 11:29:43 prd-rbs-ovirt-kvm21-poa.rbs.com.br systemd[1]: Failed to
>> start LSB: Bring up/down networking.
>> May 04 11:29:43 prd-rbs-ovirt-kvm21-poa.rbs.com.br systemd[1]: Unit
>> network.service entered failed state.
>> May 04 11:29:43 prd-rbs-ovirt-kvm21-poa.rbs.com.br systemd[1]:
>> network.service failed.
>> May 04 11:29:43 prd-rbs-ovirt-kvm21-poa.rbs.com.br network[7574]:
>> Bringing up interface paas_1305:
>> [root@prd-rbs-ovirt-kvm21-poa ~]#
>>
>> [root@prd-rbs-ovirt-kvm21-poa ~]# systemctl restart network.service
>> Job for network.service failed because a timeout was exceeded. See
>> "systemctl status network.service" and "journalctl -xe" for details.
>> [root@prd-rbs-ovirt-kvm21-poa ~]# systemctl status network.service
>> â— network.service - LSB: Bring up/down networking
>>Loaded: loaded (/etc/rc.d/init.d/network; bad; vendor preset: disabled)
>>Active: failed (Result: timeout) since Thu 2017-05-04 14:55:34 BRT;
>> 4min 46s ago
>>  Docs: man:systemd-sysv-generator(8)
>>   Process: 40810 ExecStart=/etc/rc.d/init.d/network start (code=killed,
>> signal=TERM)
>>
>> May 04 14:55:21 prd-rbs-ovirt-kvm21-poa.rbs.com.br network[40810]: [  OK
>>  ]
>> May 04 14:55:23 prd-rbs-ovirt-kvm21-poa.rbs.com.br network[40810]:
>> Bringing up interface o_hlg_db_766:  RTNETLINK answers: File exists
>> May 04 14:55:26 prd-rbs-ovirt-kvm21-poa.rbs.com.br network[40810]: [  OK
>>  ]
>> May 04 14:55:28 prd-rbs-ovirt-kvm21-poa.rbs.com.br network[40810]:
>> Bringing up interface o_p_s_a_lb_758:  RTNETLINK answers: File exists
>> May 04 14:55:31 prd-rbs-ovirt-kvm21-poa.rbs.com.br network[40810]: [  OK
>>  ]
>> May 04 14:55:33 prd-rbs-ovirt-kvm21-poa.rbs.com.br network[40810]:
>> Bringing up interface o_p_sites_a_755:  RTNETLINK answers: File exists
>> May 04 14:55:34 prd-rbs-ovirt-kvm21-poa.rbs.com.br systemd[1]:
>> network.service start operation timed out. Terminating.
>> May 04 14:55:34 prd-rbs-ovirt-kvm21-poa.rbs.com.br systemd[1]: Failed to
>> start LSB: Bring up/down networking.
>> May 04 14:55:34 prd-rbs-ovirt-kvm21-poa.rbs.com.br systemd[1]: Unit
>> network.service entered failed state.
>> May 04 14:55:34 prd-rbs-ovirt-kvm21-poa.rbs.com.br systemd[1]:
>> network.service failed.
>> [root@prd-rbs-ovirt-kvm21-poa ~]#
>>
>>
>>
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>>


-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

TRIED. TESTED. TRUSTED.