date:20161205

Re: [ovirt-users] can not migrate vm

2016-12-05 Thread Yedidyah Bar David

On Mon, Dec 5, 2016 at 10:25 PM, Marcelo Leandro  wrote:
> Hello
> I am with problem, I can not migrate vm.
> Can someone help me?
>
> Message in log:
>
> Src vdsm log:
>
> Thread-89514 :: WARNING :: 2016-12-05 17: 01: 49,542 :: migration :: 683 ::
> virt.vm ::: monitor_migration vmId = `f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e`
> :: Migration Stalling: remaining
> (56MiB)> lowmark (2MiB). Refer to RHBZ # 919201.
> Thread-89514 :: DEBUG :: 2016-12-05 17: 01: 49,543 :: migration :: 689 ::
> virt.vm ::: monitor_migration vmId = `f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e`
> :: new Iteration detected: 15
> Thread-89514 :: WARNING :: 2016-12-05 17: 01: 49,543 :: migration :: 704 ::
> virt.vm ::: monitor_migration vmId = `f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e`
> :: Migration Is stuck: Has not pro
> Gressed in 240.071660042 seconds. Aborting.

This is usually a result of a too-busy VM, changing its memory faster than
the migration process can copy the changes to the destination.

You can try changing the cluster migration policy to "suspend workload
if needed".

For more details/background, see also:

https://www.ovirt.org/develop/release-management/features/migration-enhancements/

Best,

> Thread-89514 :: DEBUG :: 2016-12-05 17: 01: 49,544 :: migration :: 715 ::
> virt.vm ::: stop} vmId = `f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e` :: stopping
> Migration monitor thread
> Thread-89514 :: DEBUG :: 2016-12-05 17: 01: 49,545 :: migration :: 570 ::
> virt.vm ::: stop) vmId = `f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e` :: stopping
> Migration downtime thread
> Thread-89514 :: DEBUG :: 2016-12-05 17: 01: 49,545 :: migration :: 629 ::
> virt.vm ::: (run) vmId = `f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e` :: stopped
> Migration monitor thread
> Thread-89513 :: DEBUG :: 2016-12-05 17: 01: 49,766 :: migration :: 715 ::
> virt.vm ::: stop} vmId = `f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e` :: stopping
> Migration monitor thread
> Thread-89513 :: ERROR :: 2016-12-05 17: 01: 49,767 :: migration :: 252 ::
> virt.vm :: (_ recover) vmId = `f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e` ::
> operation Aborted: migration job: cancel
> D by cliente
>
> Dst vdsm.log:
>
> Periodic / 13 :: WARNING :: 2016-12-05 17: 01: 49,791 :: sampling :: 483 ::
> virt.sampling.StatsCache: :( put) dropped stale old sample: sampled
> 4303678.08 stored 4303693.07
> Periodic / 13 :: DEBUG :: 2016-12-05 17: 01: 49,791 :: executor :: 221 ::
> Executor :: (_ run) Worker was discarded
> Jsonrpc.Executor / 0 :: DEBUG :: 2016-12-05 17: 01: 49,792 :: __ init __ ::
> 530 :: jsonrpc.JsonRpcServer :: (_ handle_request) Calling 'VM.destroy' in
> bridge with {u'vmID ' : U'f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e '}
> Jsonrpc.Executor / 0 :: DEBUG :: 2016-12-05 17: 01: 49,793 :: API :: 314 ::
> vds :::( destroy) About to destroy VM f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e
> Jsonrpc.Executor / 0 :: DEBUG :: 2016-12-05 17:01:49,793 :: vm :: 4171 ::
> virt.vm :::( destroy) vmId = `f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e`: :
> Destroy Called
> Thread-483 :: ERROR :: 2016-12-05 17: 01: 49,793 :: vm :: 759 :: virt.vm ::
> (_ startUnderlyingVm) vmId = `f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e` ::
> Failed To start a migration destination vm
> Traceback (most recent call last):
>   File "/usr/share/vdsm/virt/vm.py", line 725, in _startUnderlyingVm
> Self._completeIncomingMigration ()
>   File "/usr/share/vdsm/virt/vm.py", line 3071, in
> _completeIncomingMigration
> Self._incomingMigrationFinished.isSet (), usedTimeout)
>   File "/usr/share/vdsm/virt/vm.py", line 3154, in
> _attachLibvirtDomainAfterMigration
> Raise MigrationError (e.get_error_message ())
> MigrationError: Domain not found: no domain with matching uuid
> 'f38b9f7d-5bd0-4bdf-885c-e03e8d6bc70e'
>
> The logs attached.
> Thanks.
>
> ___
> 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 4 / OVN / Communication issues of instances between nodes.

2016-12-05 Thread Devin Acosta

Lance,

Well I installed the new kernel module and it cleared up a lot of the
errors I was seeing in the log, but what I notice is that I still can't
ping instances between hosts.  I'm starting to wonder am I missing
something fundamental here? I don't see anything in the ovs-vswitchd.log to
show tunnel?

I do show in the kernel log on reload of the module:

[1056295.308707] openvswitch: module verification failed: signature and/or
required key missing - tainting kernel
[1056295.311034] openvswitch: Open vSwitch switching datapath 2.6.90
[1056295.311145] openvswitch: LISP tunneling driver
[1056295.311147] openvswitch: GRE over IPv4 tunneling driver
[1056295.311153] openvswitch: Geneve tunneling driver
[1056295.311164] openvswitch: VxLAN tunneling driver
[1056295.311166] openvswitch: STT tunneling driver

[node2]

[root@ovirt-node2 openvswitch]# cat ovs-vswitchd.log
2016-12-06T04:22:23.192Z|1|vlog|INFO|opened log file
/var/log/openvswitch/ovs-vswitchd.log
2016-12-06T04:22:23.194Z|2|ovs_numa|INFO|Discovered 16 CPU cores on
NUMA node 0
2016-12-06T04:22:23.194Z|3|ovs_numa|INFO|Discovered 16 CPU cores on
NUMA node 1
2016-12-06T04:22:23.194Z|4|ovs_numa|INFO|Discovered 2 NUMA nodes and 32
CPU cores
2016-12-06T04:22:23.194Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
connecting...
2016-12-06T04:22:23.195Z|6|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
connected
2016-12-06T04:22:23.197Z|7|ofproto_dpif|INFO|system@ovs-system:
Datapath supports recirculation
2016-12-06T04:22:23.197Z|8|ofproto_dpif|INFO|system@ovs-system: MPLS
label stack length probed as 1
2016-12-06T04:22:23.197Z|9|ofproto_dpif|INFO|system@ovs-system:
Datapath supports truncate action
2016-12-06T04:22:23.197Z|00010|ofproto_dpif|INFO|system@ovs-system:
Datapath supports unique flow ids
2016-12-06T04:22:23.197Z|00011|ofproto_dpif|INFO|system@ovs-system:
Datapath supports ct_state
2016-12-06T04:22:23.197Z|00012|ofproto_dpif|INFO|system@ovs-system:
Datapath supports ct_zone
2016-12-06T04:22:23.197Z|00013|ofproto_dpif|INFO|system@ovs-system:
Datapath supports ct_mark
2016-12-06T04:22:23.197Z|00014|ofproto_dpif|INFO|system@ovs-system:
Datapath supports ct_label
2016-12-06T04:22:23.197Z|00015|ofproto_dpif|INFO|system@ovs-system:
Datapath supports ct_state_nat
2016-12-06T04:22:23.339Z|1|ofproto_dpif_upcall(handler1)|INFO|received
packet on unassociated datapath port 0
2016-12-06T04:22:23.339Z|00016|bridge|INFO|bridge br-int: added interface
vnet0 on port 5
2016-12-06T04:22:23.339Z|00017|bridge|INFO|bridge br-int: added interface
br-int on port 65534
2016-12-06T04:22:23.339Z|00018|bridge|INFO|bridge br-int: using datapath ID
16d6e0b66442
2016-12-06T04:22:23.339Z|00019|connmgr|INFO|br-int: added service
controller "punix:/var/run/openvswitch/br-int.mgmt"
2016-12-06T04:22:23.340Z|00020|bridge|INFO|ovs-vswitchd (Open vSwitch)
2.6.90
2016-12-06T04:22:32.437Z|00021|bridge|INFO|bridge br-int: added interface
ovn-c0dc09-0 on port 6
2016-12-06T04:22:32.437Z|00022|bridge|INFO|bridge br-int: added interface
ovn-252778-0 on port 7
2016-12-06T04:22:33.342Z|00023|memory|INFO|281400 kB peak resident set size
after 10.2 seconds
2016-12-06T04:22:33.342Z|00024|memory|INFO|handlers:23 ofconns:2 ports:4
revalidators:9 rules:79
2016-12-06T04:22:42.440Z|00025|connmgr|INFO|br-int<->unix: 76 flow_mods 10
s ago (75 adds, 1 deletes)

[root@ovirt-node2 openvswitch]# cat ovn-controller.log
2016-12-06T04:22:32.398Z|1|vlog|INFO|opened log file
/var/log/openvswitch/ovn-controller.log
2016-12-06T04:22:32.400Z|2|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
connecting...
2016-12-06T04:22:32.400Z|3|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
connected
2016-12-06T04:22:32.402Z|4|reconnect|INFO|tcp:172.20.192.77:6642:
connecting...
2016-12-06T04:22:32.403Z|5|reconnect|INFO|tcp:172.20.192.77:6642:
connected
2016-12-06T04:22:32.406Z|6|binding|INFO|Claiming lport
56432d2b-a96d-4ac7-b0e9-3450a006e1d4 for this chassis.
2016-12-06T04:22:32.406Z|7|binding|INFO|Claiming 00:1a:4a:16:01:64
dynamic
2016-12-06T04:22:32.407Z|8|ofctrl|INFO|unix:/var/run/openvswitch/br-int.mgmt:
connecting to switch
2016-12-06T04:22:32.407Z|9|rconn|INFO|unix:/var/run/openvswitch/br-int.mgmt:
connecting...
2016-12-06T04:22:32.407Z|00010|pinctrl|INFO|unix:/var/run/openvswitch/br-int.mgmt:
connecting to switch
2016-12-06T04:22:32.407Z|00011|rconn|INFO|unix:/var/run/openvswitch/br-int.mgmt:
connecting...
2016-12-06T04:22:32.408Z|00012|rconn|INFO|unix:/var/run/openvswitch/br-int.mgmt:
connected
2016-12-06T04:22:32.408Z|00013|rconn|INFO|unix:/var/run/openvswitch/br-int.mgmt:
connected
2016-12-06T04:22:32.440Z|00014|ofctrl|INFO|dropping duplicate flow:
table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
2016-12-06T04:22:32.441Z|00015|ofctrl|INFO|dropping duplicate flow:
table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
2016-12-06T04:22:32.441Z|00016|ofctrl|INFO|dropping duplicate flow:
table_id=32,

Re: [ovirt-users] can not use iscsi storage type onovirtandGlusterfshyper-convergedenvironment

2016-12-05 Thread Nir Soffer

On Tue, Dec 6, 2016 at 3:15 AM, 胡茂荣  wrote:

>  Hi Nir ：
>  before change code ,supervdsm report error log like those :
> ===  -->
>
> MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02
> 17:12:16,372::supervdsmServer::92::SuperVdsm.ServerCallback::(wrapper)
> call getPathsStatus with () {}
>
> MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02
> 17:12:16,373::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus)
> /usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status (cwd None)
>
> MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02
> 17:12:16,377::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus)
> SUCCESS:  = '';  = 0
>
> MainProcess|jsonrpc.Executor/2::ERROR::2016-12-02
> 17:12:16,378::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper) Error
> in getPathsStatus
> ===  <
> my environment have other dm device , dmsetup status will show like
> this as follow, so will occure above error !
>  >
> flash_sdd: 0 976771072 flashcache stats:
> reads(5723182), writes(47879823)
> read hits(2938125), read hit percent(51)
> write hits(12617126) write hit percent(26)
> dirty write hits(4592227) dirty write hit percent(9)
> replacement(701168), write replacement(3189334)
> write invalidates(0), read invalidates(1)
> 
>    <--
>   use your patch to test , add or import iscsi type storage domain
> have no problem  , log like follow :
> == ->
>
> MainProcess|jsonrpc.Executor/1::DEBUG::2016-12-06
> 08:58:07,439::supervdsmServer::92::SuperVdsm.ServerCallback::(wrapper)
> call getPathsStatus with () {}
>
> MainProcess|jsonrpc.Executor/1::DEBUG::2016-12-06
> 08:58:07,439::devicemapper::155::Storage.Misc.excCmd::(_getPathsStatus)
> /usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status --target
> multipath (cwd None)
> MainProcess|jsonrpc.Executor/1::DEBUG::2016-12-06
> 08:58:07,443::devicemapper::155::Storage.Misc.excCmd::(_getPathsStatus)
> SUCCESS:  = '';  = 0
> 
> =
>
>   Regards,
> humaorong
>

Thanks for testing this.

Sahina, can you test if this solve the issue with hyperconverge setup?
Maybe we can enable multipath with this patch.

Cheers,
Nir


>
>
> -- Original --
> *From: * "Nir Soffer";
> *Date: * Tue, Dec 6, 2016 01:41 AM
> *To: * "胡茂荣";
> *Cc: * "users"; "Jeff Nelson";
> "胡晓宇";
> *Subject: * Re: [ovirt-users] can not use iscsi storage type
> onovirtandGlusterfshyper-convergedenvironment
>
> Hi 胡茂荣,
>
> Can you test this patch?
> https://gerrit.ovirt.org/67844
>
> I also need more information on your setup, to add more
> details to the commit message.
>
> Thanks for reporting this,
> Nir
>
> On Mon, Dec 5, 2016 at 10:28 AM, 胡茂荣  wrote:
>
>>
>>   Thanks for Yaniv Kaul ,  change code need build vdsm source code , and
>> if only  change /usr/share/vdsm/storage/devicemapper.py will not really
>> take effect .
>>
>>could this problem as a bug , and correct it to ovirt vdsm source code
>> ?
>>
>> -- Original --
>> *From: * "Yaniv Kaul";
>> *Date: * Sun, Dec 4, 2016 07:07 PM
>> *To: * "胡茂荣";
>> *Cc: * "胡晓宇"; "users"; "Sahina
>> Bose"; "Jeff Nelson";
>> *Subject: * Re: [ovirt-users] can not use iscsi storage type
>> onovirtandGlusterfshyper-converged environment
>>
>>
>>
>> On Dec 2, 2016 11:53 AM, "胡茂荣"  wrote:
>>
>>I find supervdsm  used " /usr/sbin/dmsetup status" :
>>
>> MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02
>> 17:12:16,372::supervdsmServer::92::SuperVdsm.ServerCallback::(wrapper)
>> call getPathsStatus with () {}
>> MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02
>> 17:12:16,373::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus)
>> /usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status (cwd None)
>> MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02
>> 17:12:16,377::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus)
>> SUCCESS:  = '';  = 0
>> MainProcess|jsonrpc.Executor/2::ERROR::2016-12-02
>> 17:12:16,378::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper) Error
>> in getPathsStatus
>>
>> problem :
>> how can I change  Storage.Misc.excCmd _getPathsStatus  "
>> /usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status"  to :
>>
>>/usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status  --target
>> multipah
>>
>>   I think add iscsi type storage ,  if supervdsm scan

Re: [ovirt-users] can not use iscsi storage type onovirtandGlusterfshyper-convergedenvironment

2016-12-05 Thread 胡茂荣

Hi Nir ：
 before change code ,supervdsm report error log like those :
===  -->

MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02 
17:12:16,372::supervdsmServer::92::SuperVdsm.ServerCallback::(wrapper) call 
getPathsStatus with () {}
 
MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02 
17:12:16,373::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus) 
/usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status (cwd None)
 
MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02 
17:12:16,377::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus) 
SUCCESS:  = '';  = 0
 
MainProcess|jsonrpc.Executor/2::ERROR::2016-12-02 
17:12:16,378::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper) Error in 
getPathsStatus

===  <
my environment have other dm device , dmsetup status will show like this as 
follow, so will occure above error ! 
 >
flash_sdd: 0 976771072 flashcache stats: 
reads(5723182), writes(47879823)
read hits(2938125), read hit percent(51)
write hits(12617126) write hit percent(26)
dirty write hits(4592227) dirty write hit percent(9)
replacement(701168), write replacement(3189334)
write invalidates(0), read invalidates(1)


   <--
  use your patch to test , add or import iscsi type storage domain have no 
problem  , log like follow :
== ->

MainProcess|jsonrpc.Executor/1::DEBUG::2016-12-06 
08:58:07,439::supervdsmServer::92::SuperVdsm.ServerCallback::(wrapper) call 
getPathsStatus with () {}
 
MainProcess|jsonrpc.Executor/1::DEBUG::2016-12-06 
08:58:07,439::devicemapper::155::Storage.Misc.excCmd::(_getPathsStatus) 
/usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status --target multipath 
(cwd None)
 MainProcess|jsonrpc.Executor/1::DEBUG::2016-12-06 
08:58:07,443::devicemapper::155::Storage.Misc.excCmd::(_getPathsStatus) 
SUCCESS:  = '';  = 0
=

  Regards,
humaorong
  
 
-- Original --
From:  "Nir Soffer";
Date:  Tue, Dec 6, 2016 01:41 AM
To:  "胡茂荣"; 
Cc:  "users"; "Jeff Nelson"; 
"胡晓宇"; 
Subject:  Re: [ovirt-users] can not use iscsi storage type 
onovirtandGlusterfshyper-convergedenvironment

 
Hi 胡茂荣,

Can you test this patch?
https://gerrit.ovirt.org/67844



I also need more information on your setup, to add more
details to the commit message.


Thanks for reporting this,
Nir


On Mon, Dec 5, 2016 at 10:28 AM, 胡茂荣  wrote:


  Thanks for Yaniv Kaul ,  change code need build vdsm source code , and if 
only  change /usr/share/vdsm/storage/devicemapper.py will not really take 
effect .
   
   could this problem as a bug , and correct it to ovirt vdsm source code ? 
 
-- Original --
From:  "Yaniv Kaul";
Date:  Sun, Dec 4, 2016 07:07 PM
To:  "胡茂荣"; 
Cc:  "胡晓宇"; "users"; "Sahina 
Bose"; "Jeff Nelson"; 
Subject:  Re: [ovirt-users] can not use iscsi storage type 
onovirtandGlusterfshyper-converged environment



 


On Dec 2, 2016 11:53 AM, "胡茂荣"  wrote:
   I find supervdsm  used " /usr/sbin/dmsetup status" :


MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02 
17:12:16,372::supervdsmServer::92::SuperVdsm.ServerCallback::(wrapper) call 
getPathsStatus with () {}
MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02 
17:12:16,373::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus) 
/usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status (cwd None)
MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02 
17:12:16,377::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus) 
SUCCESS:  = '';  = 0
MainProcess|jsonrpc.Executor/2::ERROR::2016-12-02 
17:12:16,378::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper) Error in 
getPathsStatus



problem :
how can I change  Storage.Misc.excCmd _getPathsStatus  " /usr/bin/taskset 
--cpu-list 0-7 /usr/sbin/dmsetup status"  to :


   /usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status  --target multipah 


  I think add iscsi type storage ,  if supervdsm scan mulitpah will solve my 
problem .(my environment have other dm devices, use "dmsetup status" will show 
them, and vdsm get dm path status will occur error )



so I changed some as follow :
 （1）
   I  define EXT_DMSETUP_STATUS   in  
/usr/lib/python2.7/site-packages/vdsm/constants.py : 


/usr/lib/python2.7/site-packages/vdsm/constants.py:EXT_DMSETUP =

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

2016-12-05 Thread Lance Richardson

> From: "Devin Acosta" 
> To: "Lance Richardson" 
> Cc: "Marcin Mirecki" , "users" 
> Sent: Monday, December 5, 2016 4:17:35 PM
> Subject: Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances 
> between nodes.
> 
> Lance,
> 
> I found some interesting logs, we have (3) oVIRT nodes.
> 
> We are running:
> CentOS Linux release 7.2.1511 (Core)
> Linux hostname 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC
> 2016 x86_64 x86_64 x86_64 GNU/Linux
> 



> 2016-12-05T20:47:56.774Z|00021|ofctrl|INFO|OpenFlow error: OFPT_ERROR
> (OF1.3) (xid=0x17): OFPBAC_BAD_TYPE

This (generally unintelligible message usually indicates that the kernel
openvswitch module doesn't support conntrack.



> 
> 2016-12-05T20:35:04.345Z|1|vlog|INFO|opened log file
> /var/log/openvswitch/ovs-vswitchd.log
> 2016-12-05T20:35:04.347Z|2|ovs_numa|INFO|Discovered 16 CPU cores on
> NUMA node 0
> 2016-12-05T20:35:04.347Z|3|ovs_numa|INFO|Discovered 16 CPU cores on
> NUMA node 1
> 2016-12-05T20:35:04.347Z|4|ovs_numa|INFO|Discovered 2 NUMA nodes and 32
> CPU cores
> 2016-12-05T20:35:04.348Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
> connecting...
> 2016-12-05T20:35:04.348Z|6|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
> connected
> 2016-12-05T20:35:04.350Z|7|ofproto_dpif|INFO|system@ovs-system:
> Datapath supports recirculation
> 2016-12-05T20:35:04.350Z|8|ofproto_dpif|INFO|system@ovs-system: MPLS
> label stack length probed as 1
> 2016-12-05T20:35:04.350Z|9|ofproto_dpif|INFO|system@ovs-system:
> Datapath does not support truncate action
> 2016-12-05T20:35:04.350Z|00010|ofproto_dpif|INFO|system@ovs-system:
> Datapath supports unique flow ids
> 2016-12-05T20:35:04.350Z|00011|ofproto_dpif|INFO|system@ovs-system:
> Datapath does not support ct_state
> 2016-12-05T20:35:04.350Z|00012|ofproto_dpif|INFO|system@ovs-system:
> Datapath does not support ct_zone
> 2016-12-05T20:35:04.350Z|00013|ofproto_dpif|INFO|system@ovs-system:
> Datapath does not support ct_mark
> 2016-12-05T20:35:04.350Z|00014|ofproto_dpif|INFO|system@ovs-system:
> Datapath does not support ct_label
> 2016-12-05T20:35:04.350Z|00015|ofproto_dpif|INFO|system@ovs-system:
> Datapath does not support ct_state_nat

OK, "Datapath does not support ct_*" confirms that the kernel openvswitch
module doesn't support the conntrack features needed by OVN.

Most likely the loaded module is the stock CentOS one, you can build
the out-of-tree kernel module RPM from the same source tree where you
built the other OVS/OVN RPMs via:

   make rpm-fedora-kmod

This should leave an RPM named something like:

   openvswitch-kmod-2.6.90-1.el7.centos.x86_64.rpm

Install that and reboot and things should be working better.

Regards,

   Lance


> 
> Your help is greatly appreciated!
> 
> Devin
> 
> On Mon, Dec 5, 2016 at 12:31 PM, Lance Richardson 
> wrote:
> 
> > > From: "Devin Acosta" 
> > > To: "Marcin Mirecki" 
> > > Cc: "users" 
> > > Sent: Monday, December 5, 2016 12:11:46 PM
> > > Subject: Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of
> > instances between nodes.
> > >
> > > Marcin,
> > >
> > > Also I noticed in your original post it mentions:
> > >
> > > ip link - the result should include a link called genev_sys_ ...
> > >
> > > I noticed that on my hosts I don't see any links with name: genev_sys_ ??
> > > Could this be a problem?
> > >
> > > lo:
> > > enp4s0f0:
> > > enp4s0f1:
> > > enp7s0f0:
> > > enp7s0f1:
> > > bond0:
> > > DEV-NOC:
> > > ovirtmgmt:
> > > bond0.700@bond0:
> > > DEV-VM-NET:
> > > bond0.705@bond0:
> > > ;vdsmdummy;:
> > > vnet0:
> > > vnet1:
> > > vnet2:
> > > vnet3:
> > > vnet4:
> > > ovs-system:
> > > br-int:
> > > vnet5:
> > > vnet6:
> > >
> >
> > Hi Devin,
> >
> > What distribution and kernel version are you using?
> >
> > One thing you could check is whether the vport_geneve kernel module
> > is being loaded, e.g. you should see something like:
> >
> > $ lsmod | grep vport
> > vport_geneve   12560  1
> > openvswitch   246755  5 vport_geneve
> >
> > If vport_geneve is  not loaded, you could "sudo modprobe vport_geneve"
> > to make sure it's available and can be loaded.
> >
> > The first 100 lines or so of ovs-vswitchd.log might have some useful
> > information about where things are going wrong.
> >
> > It does sound as though there is some issue with geneve tunnels,
> > which would certainly explain issues with inter-node traffic.
> >
> > Regards,
> >
> > Lance
> >
> 
> 
> 
> --
> 
> Devin Acosta
> Red Hat Certified Architect, LinuxStack
> 602-354-1220 || de...@linuxguru.co
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

2016-12-05 Thread Devin Acosta

Lance,

I found some interesting logs, we have (3) oVIRT nodes.

We are running:
CentOS Linux release 7.2.1511 (Core)
Linux hostname 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux

What is interesting now is my 2nd node now won't hand out DHCP any more,
however it does have a strange "tunnel" error message on node2 also, see
below. What is bizarre node1 nor node3 show that bizarre tunnel message?


[ovirt-node1]

[root@ovirt-node1 ~]# lsmod | grep vport
vport_geneve   12815  1
geneve 13381  1 vport_geneve
openvswitch84535  1 vport_geneve

[ovirt-node1 /  ovn-controller.log]

2016-12-05T20:47:56.761Z|1|vlog|INFO|opened log file
/var/log/openvswitch/ovn-controller.log
2016-12-05T20:47:56.762Z|2|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
connecting...
2016-12-05T20:47:56.762Z|3|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
connected
2016-12-05T20:47:56.764Z|4|reconnect|INFO|tcp:172.20.192.77:6642:
connecting...
2016-12-05T20:47:56.764Z|5|reconnect|INFO|tcp:172.20.192.77:6642:
connected
2016-12-05T20:47:56.768Z|6|binding|INFO|Claiming lport
91d4f4f5-4b9f-42c0-aa2c-8a101474bb84 for this chassis.
2016-12-05T20:47:56.768Z|7|binding|INFO|Claiming 00:1a:4a:16:01:5e
dynamic
2016-12-05T20:47:56.768Z|8|binding|INFO|Claiming lport
71ef81f1-7c20-4c68-b536-d274703f7541 for this chassis.
2016-12-05T20:47:56.768Z|9|binding|INFO|Claiming 00:1a:4a:16:01:61
dynamic
2016-12-05T20:47:56.768Z|00010|ofctrl|INFO|unix:/var/run/openvswitch/br-int.mgmt:
connecting to switch
2016-12-05T20:47:56.768Z|00011|rconn|INFO|unix:/var/run/openvswitch/br-int.mgmt:
connecting...
2016-12-05T20:47:56.768Z|00012|pinctrl|INFO|unix:/var/run/openvswitch/br-int.mgmt:
connecting to switch
2016-12-05T20:47:56.768Z|00013|rconn|INFO|unix:/var/run/openvswitch/br-int.mgmt:
connecting...
2016-12-05T20:47:56.768Z|00014|ofctrl|INFO|dropping duplicate flow:
table_id=29, priority=50, metadata=0x2,dl_dst=00:1a:4a:16:01:62,
actions=set_field:0x5->reg15,resubmit(,32)
2016-12-05T20:47:56.770Z|00015|rconn|INFO|unix:/var/run/openvswitch/br-int.mgmt:
connected
2016-12-05T20:47:56.770Z|00016|rconn|INFO|unix:/var/run/openvswitch/br-int.mgmt:
connected
2016-12-05T20:47:56.770Z|00017|ofctrl|INFO|dropping duplicate flow:
table_id=29, priority=50, metadata=0x2,dl_dst=00:1a:4a:16:01:62,
actions=set_field:0x5->reg15,resubmit(,32)
2016-12-05T20:47:56.771Z|00018|ofctrl|INFO|dropping duplicate flow:
table_id=29, priority=50, metadata=0x2,dl_dst=00:1a:4a:16:01:62,
actions=set_field:0x5->reg15,resubmit(,32)
2016-12-05T20:47:56.772Z|00019|ofctrl|INFO|dropping duplicate flow:
table_id=29, priority=50, metadata=0x2,dl_dst=00:1a:4a:16:01:62,
actions=set_field:0x5->reg15,resubmit(,32)
2016-12-05T20:47:56.773Z|00020|ofctrl|INFO|dropping duplicate flow:
table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
2016-12-05T20:47:56.774Z|00021|ofctrl|INFO|OpenFlow error: OFPT_ERROR
(OF1.3) (xid=0x17): OFPBAC_BAD_TYPE
OFPT_FLOW_MOD (OF1.3) (xid=0x17):
(***truncated to 64 bytes from 120***)
  04 0e 00 78 00 00 00 17-00 00 00 00 00 00 00 00 |...x|
0010  00 00 00 00 00 00 00 00-32 00 00 00 00 00 00 64 |2..d|
0020  ff ff ff ff ff ff ff ff-ff ff ff ff 00 00 00 00 ||
0030  00 01 00 22 80 00 0a 02-86 dd 00 01 01 08 00 00 |..."|
2016-12-05T20:47:56.774Z|00022|ofctrl|INFO|OpenFlow error: OFPT_ERROR
(OF1.3) (xid=0x1f): OFPBAC_BAD_TYPE
OFPT_FLOW_MOD (OF1.3) (xid=0x1f):
(***truncated to 64 bytes from 160***)
  04 0e 00 a0 00 00 00 1f-00 00 00 00 00 00 00 00 ||
0010  00 00 00 00 00 00 00 00-36 00 00 00 00 00 00 64 |6..d|
0020  ff ff ff ff ff ff ff ff-ff ff ff ff 00 00 00 00 ||
0030  00 01 00 22 80 00 0a 02-08 00 00 01 01 08 00 00 |..."|
2016-12-05T20:47:56.774Z|00023|ofctrl|INFO|OpenFlow error: OFPT_ERROR
(OF1.3) (xid=0x21): OFPBAC_BAD_TYPE
OFPT_FLOW_MOD (OF1.3) (xid=0x21):
(***truncated to 64 bytes from 136***)
  04 0e 00 88 00 00 00 21-00 00 00 00 00 00 00 00 |...!|
0010  00 00 00 00 00 00 00 00-19 00 00 00 00 00 00 64 |...d|
0020  ff ff ff ff ff ff ff ff-ff ff ff ff 00 00 00 00 ||
0030  00 01 00 22 80 00 0a 02-86 dd 00 01 01 08 00 00 |..."|
2016-12-05T20:47:56.774Z|00024|ofctrl|INFO|OpenFlow error: OFPT_ERROR
(OF1.3) (xid=0x2c): OFPBAC_BAD_TYPE
OFPT_FLOW_MOD (OF1.3) (xid=0x2c):
(***truncated to 64 bytes from 160***)
  04 0e 00 a0 00 00 00 2c-00 00 00 00 00 00 00 00 |...,|
0010  00 00 00 00 00 00 00 00-19 00 00 00 00 00 00 64 |...d|
0020  ff ff ff ff ff ff ff ff-ff ff ff ff 00 00 00 00 ||
0030  00 01 00 22 80 00 0a 02-86 dd 00 01 01 08 00 00 |..."|
2016-12-05T20:47:56.774Z|00025|ofctrl|INFO|OpenFlow error: OFPT_ERROR
(OF1.3) (xid=0x2d): OFPBAC_BAD_TYPE
OFPT_FLOW_MOD (OF1.3)

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

2016-12-05 Thread Lance Richardson

> From: "Devin Acosta" 
> To: "Marcin Mirecki" 
> Cc: "users" 
> Sent: Monday, December 5, 2016 12:11:46 PM
> Subject: Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances 
> between nodes.
> 
> Marcin,
> 
> Also I noticed in your original post it mentions:
> 
> ip link - the result should include a link called genev_sys_ ...
> 
> I noticed that on my hosts I don't see any links with name: genev_sys_ ??
> Could this be a problem?
> 
> lo:
> enp4s0f0:
> enp4s0f1:
> enp7s0f0:
> enp7s0f1:
> bond0:
> DEV-NOC:
> ovirtmgmt:
> bond0.700@bond0:
> DEV-VM-NET:
> bond0.705@bond0:
> ;vdsmdummy;:
> vnet0:
> vnet1:
> vnet2:
> vnet3:
> vnet4:
> ovs-system:
> br-int:
> vnet5:
> vnet6:
> 

Hi Devin,

What distribution and kernel version are you using?

One thing you could check is whether the vport_geneve kernel module
is being loaded, e.g. you should see something like:

$ lsmod | grep vport
vport_geneve   12560  1 
openvswitch   246755  5 vport_geneve

If vport_geneve is  not loaded, you could "sudo modprobe vport_geneve"
to make sure it's available and can be loaded.

The first 100 lines or so of ovs-vswitchd.log might have some useful
information about where things are going wrong.

It does sound as though there is some issue with geneve tunnels,
which would certainly explain issues with inter-node traffic.

Regards,

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

Re: [ovirt-users] web-ui issues

2016-12-05 Thread Alexander Wels

On Monday, December 5, 2016 7:11:52 PM EST Maton, Brett wrote:
> Yup those are the logs from the hosted engine,
> 
>   ui.log is still empty, all very very odd...
> 

Can you send me a screenshot of what you are seeing? As it makes no sense that 
the UI.log is empty, since the exception handler tries to write to the backend 
UI log.

> On 5 December 2016 at 18:12, Alexander Wels  wrote:
> > On Monday, December 5, 2016 5:41:59 PM EST Maton, Brett wrote:
> > > Logs are here
> > >  > 
> > 7a4ccbeab673dfda8aa0c38676063b
> > 
> > > 7a=11138>
> > 
> > Are you sure those are the correct logs? The UI.log is empty and the other
> > logs don't have much of anything in them.
> > 
> > > On 5 December 2016 at 16:57, Alexander Wels  wrote:
> > > > On Monday, December 5, 2016 4:55:19 PM EST Maton, Brett wrote:
> > > > > Hi,
> > > > > 
> > > > >   I tried restarting the browser and clearing the cache but I still
> > 
> > have
> > 
> > > > > the same problem.
> > > > > 
> > > > >   Symbol maps it is then
> > > > 
> > > > To install the symbol maps do the following on the ENGINE:
> > > > 
> > > > 1. yum install ovirt-engine-webadmin-portal-debuginfo
> > > > 2. restart engine
> > > > 3. Reproduce the problem.
> > > > 4. Send me the UI.log from the engine machine.
> > > > 
> > > > > On 5 December 2016 at 16:00, Alexander Wels 
> > 
> > wrote:
> > > > > > On Sunday, December 4, 2016 5:57:50 PM EST Maton, Brett wrote:
> > > > > > > Hi Oved,
> > > > > > > 
> > > > > > >   I've upload the logs here
> > > > > > > 
> > > > > > >  > > > > > 
> > > > > > bd24f303b23c2cd393676f0da5c323
> > > > > > 
> > > > > > > d8=10263>
> > > > > > > 
> > > > > > > On 4 December 2016 at 12:25, Oved Ourfali 
> > > > 
> > > > wrote:
> > > > > > > > Please attach complete logs.
> > > > > > > > Engine, server and ui logs.
> > > > > > > > 
> > > > > > > > Thanks,
> > > > > > > > Oved
> > > > > > > > 
> > > > > > > > On Dec 4, 2016 13:45, "Maton, Brett"  > > > 
> > > > wrote:
> > > > > > > >> Since I upgraded to 4.0.6-3 I've been having problems with
> > 
> > the UI
> > 
> > > > > > > >> When I login the dash board presents a bunch of Operation
> > > > > > > >> Canceled
> > > > > > > >> dialogs,
> > > > > > > >> 
> > > > > > > >> 
> > > > > > > >> ! Operation canceled
> > > > > > > >> 
> > > > > > > >> Error while executing query: null
> > > > > > > >> 
> > > > > > > >> 
> > > > > > > >> 
> > > > > > > >> ! Operation canceled
> > > > > > > >> 
> > > > > > > >> Error while executing action: A Request to the Server failed:
> > > > > > > >> java.lang.reflect.InvocationTargetException
> > > > > > > >> 
> > > > > > > >> 
> > > > > > > >> The only error I see in engine.log is
> > > > > > > >> 
> > > > > > > >> 2016-12-04 11:34:07,945 INFO  [org.ovirt.engine.docs.utils.s
> > > > > > > >> ervlet.ContextSensitiveHelpMappingServlet] (default task-1)
> > 
> > []
> > 
> > > > > > > >> Context-sensitive help is not installed. Manual directory
> > 
> > doesn't
> > 
> > > > > > exist:
> > > > > > > >> /usr/share/ovirt-engine/manual
> > > > > > > >> 
> > > > > > > >> Eventually after closing the error dialogs the dash board is
> > > > > > 
> > > > > > displayed.
> > > > > > 
> > > > > > > >> Most of the UI tabs then work normally, however 'Virtual
> > > > > > > >> Machines'
> > > > > > > >> tab
> > > > > > > >> doesn't display any information, just the progress 'dots' on
> > 
> > the
> > 
> > > > > > > >> first
> > > > > > > >> line, it then cycles through the null query error dialogs.
> > > > > > > >> 
> > > > > > > >> This error also appeared in the log while I was writing this:
> > > > > > > >> 
> > > > > > > >> 2016-12-04 11:40:09,276 INFO
> > > > > > > >> [org.ovirt.engine.core.bll.EngineBackupAwarenessManager]
> > > > > > > >> (DefaultQuartzScheduler5) [7b442cfe] Backup check started.
> > > > > > > >> 2016-12-04 11:40:09,278 INFO
> > > > > > > >> [org.ovirt.engine.core.bll.EngineBackupAwarenessManager]
> > > > > > > >> (DefaultQuartzScheduler5) [7b442cfe] Backup check completed.
> > > > > > > >> 2016-12-04 11:40:09,772 INFO
> > > > > > > >> [org.ovirt.engine.core.bll.storage.ovfstore.OvfDataUpdater]
> > > > > > > >> (DefaultQuartzScheduler3) [2701e060] Attempting to update
> > > > > > 
> > > > > > VMs/Templates
> > > > > > 
> > > > > > > >> Ovf. 2016-12-04 11:40:09,774 INFO
> > 
> > [org.ovirt.engine.core.bll.sto
> > 
> > > > > > > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > > > > > > >> (DefaultQuartzScheduler3) [5358e209] Before acquiring and
> > > > > > > >> wait
> > > > 
> > > > lock
> > > > 
> > > > > > > >> 'EngineLock:{exclusiveLocks='[57fc8739-0039-00c7-0322-
> > > > > > 
> > > > > > 01e5= > > > > > 
> > > > > > > >> PDATE, ACTION_TYPE_FAILED_OBJECT_LOCKED>]',
> > 
> > sharedLocks='null'}'
> > 
> > > > > > > >> 2016-12-04 11:40:09,774

Re: [ovirt-users] Storage domains not found by vdsm after a reboot

2016-12-05 Thread Yoann Laissus

Thanks for your answer.

Based on your advices, I improved my shutdown script by doing manually
all actions the engine does while putting an host into maintenance
(via vdsClient : stopping SPM, disconnecting the SP, disconnecting and
unlocking all SD)
So no need to use my previous hacks anymore :) I can post this script
if anyone is interested.

About the delay issue after a reboot, I investigated that a bit more.

It seems to not be related to vdsm and the lockspace, but the engine itself.
 When the engine starts, it probably doesn't know the host was down.
So it doesn't send domain informations and keeps trying to reconstruct
the SPM on the main host until a timeout occurs (found in the engine
logs). It also explains why it works immediately after restarting
vdsm, as the engine see the host down for a couple of time.

My usage is clearly not common but maybe the ideal solution would be
to have a special "maintenance" state to inform the engine the host
will be rebooted while it isn't alive.
But I can live with a small script which restart vdsm once the engine boots.

2016-12-03 20:58 GMT+01:00 Nir Soffer :
> On Sat, Dec 3, 2016 at 6:14 PM, Yoann Laissus  wrote:
>> Hello,
>>
>> I'm running into some weird issues with vdsm and my storage domains
>> after a reboot or a shutdown. I can't manage to figure out what's
>> going on...
>>
>> Currently, my cluster (4.0.5 with hosted engine) is composed of one
>> main node. (and another inactive one but unrelated to this issue).
>> It has local storage exposed to oVirt via 3 NFS exports (one specific
>> for the hosted engine vm) reachable from my local network.
>>
>> When I wan't to shutdown or reboot my main host (and so the whole
>> cluster), I use a custom script :
>> 1. Shutdown all VM
>> 2. Shutdown engine VM
>> 3. Stop HA agent and broker
>> 4. Stop vdsmd
>
> This leave vdsm connected to all storage domains, and sanlock is
> still maintaining the lockspace on all storage domains.
>
>> 5. Release the sanlock on the hosted engine SD
>
> You should not do that but use local/global maintenance mode in hosted
> engine agent.
>
>> 6. Shutdown / Reboot
>>
>> It works just fine, but at the next boot, VDSM takes at least 10-15
>> minutes to find storage domains, except the hosted engine one. The
>> engine loops trying to reconstruct the SPM.
>> During this time, vdsClient getConnectedStoragePoolsList returns nothing.
>> getStorageDomainsList returns only the hosted engine domain.
>> NFS exports are mountable from another server.
>
> The correct way to shutdown a host is to move the host to maintenance.
> This deactivate all storage domains on this host, release sanlock leases
> and disconnect from the storage server (e.g. log out from iscsi connection,
> unmount nfs mounts).
>
> If you don't this, sanlock will need more time to join the lockspace in the
> next time.
>
> I'm not sure what is the correct procedure when using hosted engine, since
> hosted engine will not let you put a host into maintenance if the hosted
> engine vm is running on this host. You can stop the hosted engine vm
> but then you cannot move the host into maintenance since you don't have
> engine :-)
>
> There must be a documented way to perform this operation, I hope that
> Simone will point us to the documentation.
>
> Nir
>
>>
>> But when I restart vdsm manually after the boot, it seems to detect
>> immediately the storage domains.
>>
>> Is there some kind of staled storage data used by vdsm and a timeout
>> to invalidate them ?
>> Am I missing something on the vdsm side in my shutdown procedure ?
>>
>> Thanks !
>>
>> Engine and vdsm logs are attached.
>>
>>
>> --
>> Yoann Laissus
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>



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

Re: [ovirt-users] web-ui issues

2016-12-05 Thread Alexander Wels

On Monday, December 5, 2016 5:41:59 PM EST Maton, Brett wrote:
> Logs are here
>  7a=11138>

Are you sure those are the correct logs? The UI.log is empty and the other 
logs don't have much of anything in them.

> On 5 December 2016 at 16:57, Alexander Wels  wrote:
> > On Monday, December 5, 2016 4:55:19 PM EST Maton, Brett wrote:
> > > Hi,
> > > 
> > >   I tried restarting the browser and clearing the cache but I still have
> > > 
> > > the same problem.
> > > 
> > >   Symbol maps it is then
> > 
> > To install the symbol maps do the following on the ENGINE:
> > 
> > 1. yum install ovirt-engine-webadmin-portal-debuginfo
> > 2. restart engine
> > 3. Reproduce the problem.
> > 4. Send me the UI.log from the engine machine.
> > 
> > > On 5 December 2016 at 16:00, Alexander Wels  wrote:
> > > > On Sunday, December 4, 2016 5:57:50 PM EST Maton, Brett wrote:
> > > > > Hi Oved,
> > > > > 
> > > > >   I've upload the logs here
> > > > > 
> > > > >  > > > 
> > > > bd24f303b23c2cd393676f0da5c323
> > > > 
> > > > > d8=10263>
> > > > > 
> > > > > On 4 December 2016 at 12:25, Oved Ourfali 
> > 
> > wrote:
> > > > > > Please attach complete logs.
> > > > > > Engine, server and ui logs.
> > > > > > 
> > > > > > Thanks,
> > > > > > Oved
> > > > > > 
> > > > > > On Dec 4, 2016 13:45, "Maton, Brett" 
> > 
> > wrote:
> > > > > >> Since I upgraded to 4.0.6-3 I've been having problems with the UI
> > > > > >> 
> > > > > >> When I login the dash board presents a bunch of Operation
> > > > > >> Canceled
> > > > > >> dialogs,
> > > > > >> 
> > > > > >> 
> > > > > >> ! Operation canceled
> > > > > >> 
> > > > > >> Error while executing query: null
> > > > > >> 
> > > > > >> 
> > > > > >> 
> > > > > >> ! Operation canceled
> > > > > >> 
> > > > > >> Error while executing action: A Request to the Server failed:
> > > > > >> java.lang.reflect.InvocationTargetException
> > > > > >> 
> > > > > >> 
> > > > > >> The only error I see in engine.log is
> > > > > >> 
> > > > > >> 2016-12-04 11:34:07,945 INFO  [org.ovirt.engine.docs.utils.s
> > > > > >> ervlet.ContextSensitiveHelpMappingServlet] (default task-1) []
> > > > > >> Context-sensitive help is not installed. Manual directory doesn't
> > > > 
> > > > exist:
> > > > > >> /usr/share/ovirt-engine/manual
> > > > > >> 
> > > > > >> Eventually after closing the error dialogs the dash board is
> > > > 
> > > > displayed.
> > > > 
> > > > > >> Most of the UI tabs then work normally, however 'Virtual
> > > > > >> Machines'
> > > > > >> tab
> > > > > >> doesn't display any information, just the progress 'dots' on the
> > > > > >> first
> > > > > >> line, it then cycles through the null query error dialogs.
> > > > > >> 
> > > > > >> This error also appeared in the log while I was writing this:
> > > > > >> 
> > > > > >> 2016-12-04 11:40:09,276 INFO
> > > > > >> [org.ovirt.engine.core.bll.EngineBackupAwarenessManager]
> > > > > >> (DefaultQuartzScheduler5) [7b442cfe] Backup check started.
> > > > > >> 2016-12-04 11:40:09,278 INFO
> > > > > >> [org.ovirt.engine.core.bll.EngineBackupAwarenessManager]
> > > > > >> (DefaultQuartzScheduler5) [7b442cfe] Backup check completed.
> > > > > >> 2016-12-04 11:40:09,772 INFO
> > > > > >> [org.ovirt.engine.core.bll.storage.ovfstore.OvfDataUpdater]
> > > > > >> (DefaultQuartzScheduler3) [2701e060] Attempting to update
> > > > 
> > > > VMs/Templates
> > > > 
> > > > > >> Ovf. 2016-12-04 11:40:09,774 INFO  [org.ovirt.engine.core.bll.sto
> > > > > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > > > > >> (DefaultQuartzScheduler3) [5358e209] Before acquiring and wait
> > 
> > lock
> > 
> > > > > >> 'EngineLock:{exclusiveLocks='[57fc8739-0039-00c7-0322-
> > > > 
> > > > 01e5= > > > 
> > > > > >> PDATE, ACTION_TYPE_FAILED_OBJECT_LOCKED>]', sharedLocks='null'}'
> > > > > >> 2016-12-04 11:40:09,774 INFO  [org.ovirt.engine.core.bll.sto
> > > > > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > > > > >> (DefaultQuartzScheduler3) [5358e209] Lock-wait acquired to object
> > > > > >> 'EngineLock:{exclusiveLocks='[57fc8739-0039-00c7-0322-
> > > > 
> > > > 01e5= > > > 
> > > > > >> PDATE, ACTION_TYPE_FAILED_OBJECT_LOCKED>]', sharedLocks='null'}'
> > > > > >> 2016-12-04 11:40:09,775 INFO  [org.ovirt.engine.core.bll.sto
> > > > > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > > > > >> (DefaultQuartzScheduler3) [5358e209] Running command:
> > > > > >> ProcessOvfUpdateForStoragePoolCommand internal: true. Entities
> > > > 
> > > > affected
> > > > 
> > > > > >> :  ID: 57fc8739-0039-00c7-0322-01e5 Type: StoragePool
> > > > > >> 
> > > > > >> 2016-12-04 11:40:09,781 INFO  [org.ovirt.engine.core.bll.sto
> > > > > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > > > > >> (DefaultQuartzScheduler3)

[ovirt-users] User portal permissions

2016-12-05 Thread Pavel Gashev

Hello,

I’d like to use the User Portal. Unfortunately, I’ve found no documentation 
about setting it up.
How to give a way for a user to create and manage VMs within a quota? Which 
permissions should I set for Network/Storage/Cluster?

Any help is appreciated.

Thanks

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

Re: [ovirt-users] web-ui issues

2016-12-05 Thread Maton, Brett

Logs are here


On 5 December 2016 at 16:57, Alexander Wels  wrote:

> On Monday, December 5, 2016 4:55:19 PM EST Maton, Brett wrote:
> > Hi,
> >
> >   I tried restarting the browser and clearing the cache but I still have
> > the same problem.
> >   Symbol maps it is then
> >
>
> To install the symbol maps do the following on the ENGINE:
>
> 1. yum install ovirt-engine-webadmin-portal-debuginfo
> 2. restart engine
> 3. Reproduce the problem.
> 4. Send me the UI.log from the engine machine.
>
> > On 5 December 2016 at 16:00, Alexander Wels  wrote:
> > > On Sunday, December 4, 2016 5:57:50 PM EST Maton, Brett wrote:
> > > > Hi Oved,
> > > >
> > > >   I've upload the logs here
> > > >
> > > >  > >
> > > bd24f303b23c2cd393676f0da5c323
> > >
> > > > d8=10263>
> > > >
> > > > On 4 December 2016 at 12:25, Oved Ourfali 
> wrote:
> > > > > Please attach complete logs.
> > > > > Engine, server and ui logs.
> > > > >
> > > > > Thanks,
> > > > > Oved
> > > > >
> > > > > On Dec 4, 2016 13:45, "Maton, Brett" 
> wrote:
> > > > >> Since I upgraded to 4.0.6-3 I've been having problems with the UI
> > > > >>
> > > > >> When I login the dash board presents a bunch of Operation Canceled
> > > > >> dialogs,
> > > > >>
> > > > >>
> > > > >> ! Operation canceled
> > > > >>
> > > > >> Error while executing query: null
> > > > >>
> > > > >>
> > > > >>
> > > > >> ! Operation canceled
> > > > >>
> > > > >> Error while executing action: A Request to the Server failed:
> > > > >> java.lang.reflect.InvocationTargetException
> > > > >>
> > > > >>
> > > > >> The only error I see in engine.log is
> > > > >>
> > > > >> 2016-12-04 11:34:07,945 INFO  [org.ovirt.engine.docs.utils.s
> > > > >> ervlet.ContextSensitiveHelpMappingServlet] (default task-1) []
> > > > >> Context-sensitive help is not installed. Manual directory doesn't
> > >
> > > exist:
> > > > >> /usr/share/ovirt-engine/manual
> > > > >>
> > > > >> Eventually after closing the error dialogs the dash board is
> > >
> > > displayed.
> > >
> > > > >> Most of the UI tabs then work normally, however 'Virtual Machines'
> > > > >> tab
> > > > >> doesn't display any information, just the progress 'dots' on the
> > > > >> first
> > > > >> line, it then cycles through the null query error dialogs.
> > > > >>
> > > > >> This error also appeared in the log while I was writing this:
> > > > >>
> > > > >> 2016-12-04 11:40:09,276 INFO
> > > > >> [org.ovirt.engine.core.bll.EngineBackupAwarenessManager]
> > > > >> (DefaultQuartzScheduler5) [7b442cfe] Backup check started.
> > > > >> 2016-12-04 11:40:09,278 INFO
> > > > >> [org.ovirt.engine.core.bll.EngineBackupAwarenessManager]
> > > > >> (DefaultQuartzScheduler5) [7b442cfe] Backup check completed.
> > > > >> 2016-12-04 11:40:09,772 INFO
> > > > >> [org.ovirt.engine.core.bll.storage.ovfstore.OvfDataUpdater]
> > > > >> (DefaultQuartzScheduler3) [2701e060] Attempting to update
> > >
> > > VMs/Templates
> > >
> > > > >> Ovf. 2016-12-04 11:40:09,774 INFO  [org.ovirt.engine.core.bll.sto
> > > > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > > > >> (DefaultQuartzScheduler3) [5358e209] Before acquiring and wait
> lock
> > > > >> 'EngineLock:{exclusiveLocks='[57fc8739-0039-00c7-0322-
> > >
> > > 01e5= > >
> > > > >> PDATE, ACTION_TYPE_FAILED_OBJECT_LOCKED>]', sharedLocks='null'}'
> > > > >> 2016-12-04 11:40:09,774 INFO  [org.ovirt.engine.core.bll.sto
> > > > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > > > >> (DefaultQuartzScheduler3) [5358e209] Lock-wait acquired to object
> > > > >> 'EngineLock:{exclusiveLocks='[57fc8739-0039-00c7-0322-
> > >
> > > 01e5= > >
> > > > >> PDATE, ACTION_TYPE_FAILED_OBJECT_LOCKED>]', sharedLocks='null'}'
> > > > >> 2016-12-04 11:40:09,775 INFO  [org.ovirt.engine.core.bll.sto
> > > > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > > > >> (DefaultQuartzScheduler3) [5358e209] Running command:
> > > > >> ProcessOvfUpdateForStoragePoolCommand internal: true. Entities
> > >
> > > affected
> > >
> > > > >> :  ID: 57fc8739-0039-00c7-0322-01e5 Type: StoragePool
> > > > >>
> > > > >> 2016-12-04 11:40:09,781 INFO  [org.ovirt.engine.core.bll.sto
> > > > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > > > >> (DefaultQuartzScheduler3) [5358e209] Attempting to update VM OVFs
> in
> > >
> > > Data
> > >
> > > > >> Center 'Default'
> > > > >> 2016-12-04 11:40:09,788 INFO  [org.ovirt.engine.core.bll.sto
> > > > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > > > >> (DefaultQuartzScheduler3) [5358e209] Successfully updated VM OVFs
> in
> > >
> > > Data
> > >
> > > > >> Center 'Default'
> > > > >> 2016-12-04 11:40:09,789 INFO  [org.ovirt.engine.core.bll.sto
> > > > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > > > >>

Re: [ovirt-users] can not use iscsi storage type onovirtandGlusterfshyper-converged environment

2016-12-05 Thread Nir Soffer

Hi 胡茂荣,

Can you test this patch?
https://gerrit.ovirt.org/67844

I also need more information on your setup, to add more
details to the commit message.

Thanks for reporting this,
Nir

On Mon, Dec 5, 2016 at 10:28 AM, 胡茂荣  wrote:

>
>   Thanks for Yaniv Kaul ,  change code need build vdsm source code , and
> if only  change /usr/share/vdsm/storage/devicemapper.py will not really
> take effect .
>
>could this problem as a bug , and correct it to ovirt vdsm source code
> ?
>
> -- Original --
> *From: * "Yaniv Kaul";
> *Date: * Sun, Dec 4, 2016 07:07 PM
> *To: * "胡茂荣";
> *Cc: * "胡晓宇"; "users"; "Sahina
> Bose"; "Jeff Nelson";
> *Subject: * Re: [ovirt-users] can not use iscsi storage type
> onovirtandGlusterfshyper-converged environment
>
>
>
> On Dec 2, 2016 11:53 AM, "胡茂荣"  wrote:
>
>I find supervdsm  used " /usr/sbin/dmsetup status" :
>
> MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02
> 17:12:16,372::supervdsmServer::92::SuperVdsm.ServerCallback::(wrapper)
> call getPathsStatus with () {}
> MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02
> 17:12:16,373::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus)
> /usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status (cwd None)
> MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02
> 17:12:16,377::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus)
> SUCCESS:  = '';  = 0
> MainProcess|jsonrpc.Executor/2::ERROR::2016-12-02
> 17:12:16,378::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper) Error
> in getPathsStatus
>
> problem :
> how can I change  Storage.Misc.excCmd _getPathsStatus  " /usr/bin/taskset
> --cpu-list 0-7 /usr/sbin/dmsetup status"  to :
>
>/usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status  --target
> multipah
>
>   I think add iscsi type storage ,  if supervdsm scan mulitpah will solve
> my problem .(my environment have other dm devices, use "dmsetup status"
> will show them, and vdsm get dm path status will occur error )
>
> 
> 
> so I changed some as follow :
>  （1）
>I  define EXT_DMSETUP_STATUS   in  
> /usr/lib/python2.7/site-packages/vdsm/constants.py
> :
>
> /usr/lib/python2.7/site-packages/vdsm/constants.py:EXT_DMSETUP =
> '/usr/sbin/dmsetup'
> /usr/lib/python2.7/site-packages/vdsm/constants.py:EXT_DMSETUP_STATUS =
> "/usr/sbin/dmsetup status --target multipath"
>
>  (2)
>  /usr/share/vdsm/storage/devicemapper.py add :
> from vdsm.constants import EXT_DMSETUP_STATUS
>
> and changed  getPathsStatus cmd  to " EXT_DMSETUP_STATUS" :
>
> def _getPathsStatus():
> cmd = [EXT_DMSETUP_STATUS]# before : cmd=[
> EXT_DMSETUP,"status"]
>
>
> Why not change this to:
> cmd = [EXT_DMSETUP,  "status", "--target", "multipath"]
>
> Y.
>
> rc, out, err = misc.execCmd(cmd)
> 
> ===
>
>  but log in supervdsm log also not change . Please help me ，how to change
> code to let supervdsm exec "/usr/sbin/dmsetup status --target multipath"
>   in function  getPathsStatus（） 。
>
>
>
>
> -- Original --
> *From: * "胡茂荣";
> *Date: * Fri, Nov 25, 2016 05:44 PM
> *To: * "Sahina Bose";
> *Cc: * "Maor Lipchuk"; "Jeff Nelson"<
> jenel...@redhat.com>; "users";
> *Subject: * Re: [ovirt-users] can not use iscsi storage type on
> ovirtandGlusterfshyper-converged environment
>
>
> ===---
>
>###vdsm or supervdsm log  report :
>
> MainProcess|jsonrpc.Executor/7::ERROR::2016-11-01
> 11:07:00,178::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper)
> Error in getPathsStatus
>
> MainProcess|jsonrpc.Executor/4::ERROR::2016-11-01
> 11:07:20,964::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper)
> Error in getPathsStatus
>    some code info >
> [root@horeba storage]# pwd
> /usr/share/vdsm/storage
>
> [root@horeba storage]# grep "getPathsStatus" -R ./
> ./devicemapper.py:def _getPathsStatus():
> ./devicemapper.py:def getPathsStatus():
> ./devicemapper.py:return getProxy().getPathsStatus()
> ./multipath.py:pathStatuses = devicemapper.getPathsStatus()
>
> def _getPathsStatus():
> cmd = [EXT_DMSETUP, "status"]
> rc, out, err = misc.execCmd(cmd)
> if rc != 0:
> raise Exception("Could not get device statuses")
>
> res = {}
> for statusLine in out:
> try:
> devName, statusLine = statusLine.split(":", 1)
> except ValueError:
> if len(out) == 1:
> # return an empty dict when status output is: No devices
> found
> return res
> else:
>

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

2016-12-05 Thread Devin Acosta

Marcin,

Also I noticed in your original post it mentions:

ip link - the result should include a link called genev_sys_ ...

I noticed that on my hosts I don't see any links with name: genev_sys_ ??
Could this be a problem?

lo:
enp4s0f0:
enp4s0f1:
enp7s0f0:
enp7s0f1:
bond0:
DEV-NOC:
ovirtmgmt:
bond0.700@bond0:
DEV-VM-NET:
bond0.705@bond0:
;vdsmdummy;:
vnet0:
vnet1:
vnet2:
vnet3:
vnet4:
ovs-system:
br-int:
vnet5:
vnet6:


However, the br-int appears to have been configured:

[root@las01-902-001 ~]# ovs-vsctl show
4c817c66-9842-471d-b53a-963e27e3364f
Bridge br-int
fail_mode: secure
Port "vnet6"
Interface "vnet6"
Port "vnet5"
Interface "vnet5"
Port "ovn-456949-0"
Interface "ovn-456949-0"
type: geneve
options: {csum="true", key=flow, remote_ip="172.10.10.74"}
Port "ovn-252778-0"
Interface "ovn-252778-0"
type: geneve
options: {csum="true", key=flow, remote_ip="172.10.10.75"}
Port br-int
Interface br-int
type: internal
ovs_version: "2.6.90"

However there is no traffic showing:

[root@las01-902-001 ~]# ifconfig br-int
br-int: flags=4098  mtu 1500
ether 2e:c4:a6:fa:0c:40  txqueuelen 0  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

On Mon, Dec 5, 2016 at 8:05 AM, Devin Acosta  wrote:

>
> Marcin,
>
> For OVN to work properly does the port that the traffic flows over need to
> be a bridge, or OVS port? Right now it's just going over the ovirtmgmt
> network which is just a standard port. I know like in Neutron you have to
> configure (br-ex) and then it would need to be using the OVS protocol, and
> then all the nodes would need to be an OVS port. I presume OVN tries to
> simplify this setup?
> I also seen that there is (openvswitch-ovn-vtep), would this need to be
> configured in any way?
>
>
> On Mon, Dec 5, 2016 at 1:43 AM, Marcin Mirecki 
> wrote:
>
>> Devin,
>>
>> Please not the OVN-controller is not the central part where OVN northd is
>> running.
>> OVN-controllers are the OVN processes deployed on the hosts.
>> The correct usage of the 'vdsm-tool ovn-config'.
>>  - the IP of the OVN-central (not to be confused with OVN-controllers,
>> which is the part of OVN running on the hosts)
>>  - the local host IP to be used for tunneling to other OVN hosts
>> for example, if the OVN-central IP should be 10.10.10.1, and the IP of
>> the local host used for tunneling: 10.10.10.101:
>> vdsm-tool ovn-config 10.10.10.1 10.10.10.101
>>
>> Looking at the output of 'ovs-vsctl' the tunnels have been created.
>>
>> The OVN log saying 'dropping duplicate flow' is worrying, let me forward
>> this to
>> the OVN team to take a look at it.
>>
>> Marcin
>>
>>
>>
>> - Original Message -
>> > From: "Devin Acosta" 
>> > To: "users" 
>> > Sent: Saturday, December 3, 2016 12:24:21 AM
>> > Subject: [ovirt-users] oVIRT 4 / OVN / Communication issues of
>> instances  between nodes.
>> >
>> >
>> > Note: When I configured vdsm-tool ovn-config, I passed it the IP
>> address of
>> > the OVN-Controller which is using the ovirtmgmt network, which is just
>> one
>> > of the NIC's on the nodes.
>> >
>> > I am opening up new thread as this I feel differs a bit from my original
>> > request. I have OVN which I believe is deployed correctly. I have
>> noticed
>> > that if instances get spun up on the same oVIRT node they can all talk
>> > without issues to one another, however if one instance gets spun up on
>> > another node even if it has the same (OVN network/subnet), it can't
>> ping or
>> > reach other instances in the subnet. I noticed that the OVN-Controller
>> of
>> > the instance that can't talk is logging:
>> >
>> > 2016-12-02T22:50:54.907Z|00181|pinctrl|INFO|DHCPOFFER 00:1a:4a:16:01:5c
>> > 10.10.10.4
>> > 2016-12-02T22:50:54.908Z|00182|pinctrl|INFO|DHCPACK 00:1a:4a:16:01:5c
>> > 10.10.10.4
>> > 2016-12-02T22:50:55.695Z|00183|ofctrl|INFO|Dropped 7 log messages in
>> last 10
>> > seconds (most recently, 0 seconds ago) due to excessive rate
>> > 2016-12-02T22:50:55.695Z|00184|ofctrl|INFO|dropping duplicate flow:
>> > table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
>> > 2016-12-02T22:51:10.705Z|00185|ofctrl|INFO|Dropped 6 log messages in
>> last 15
>> > seconds (most recently, 5 seconds ago) due to excessive rate
>> > 2016-12-02T22:51:10.705Z|00186|ofctrl|INFO|dropping duplicate flow:
>> > table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
>> > 2016-12-02T22:51:20.710Z|00187|ofctrl|INFO|Dropped 4 log messages in
>> last 10
>> > seconds (most recently, 5 seconds ago) due to excessive rate
>> >

Re: [ovirt-users] web-ui issues

2016-12-05 Thread Maton, Brett

Hi,

  I tried restarting the browser and clearing the cache but I still have
the same problem.
  Symbol maps it is then

On 5 December 2016 at 16:00, Alexander Wels  wrote:

> On Sunday, December 4, 2016 5:57:50 PM EST Maton, Brett wrote:
> > Hi Oved,
> >
> >   I've upload the logs here
> >  bd24f303b23c2cd393676f0da5c323
> > d8=10263>
> > On 4 December 2016 at 12:25, Oved Ourfali  wrote:
> > > Please attach complete logs.
> > > Engine, server and ui logs.
> > >
> > > Thanks,
> > > Oved
> > >
> > > On Dec 4, 2016 13:45, "Maton, Brett"  wrote:
> > >> Since I upgraded to 4.0.6-3 I've been having problems with the UI
> > >>
> > >> When I login the dash board presents a bunch of Operation Canceled
> > >> dialogs,
> > >>
> > >>
> > >> ! Operation canceled
> > >>
> > >> Error while executing query: null
> > >>
> > >>
> > >>
> > >> ! Operation canceled
> > >>
> > >> Error while executing action: A Request to the Server failed:
> > >> java.lang.reflect.InvocationTargetException
> > >>
> > >>
> > >> The only error I see in engine.log is
> > >>
> > >> 2016-12-04 11:34:07,945 INFO  [org.ovirt.engine.docs.utils.s
> > >> ervlet.ContextSensitiveHelpMappingServlet] (default task-1) []
> > >> Context-sensitive help is not installed. Manual directory doesn't
> exist:
> > >> /usr/share/ovirt-engine/manual
> > >>
> > >> Eventually after closing the error dialogs the dash board is
> displayed.
> > >>
> > >> Most of the UI tabs then work normally, however 'Virtual Machines' tab
> > >> doesn't display any information, just the progress 'dots' on the first
> > >> line, it then cycles through the null query error dialogs.
> > >>
> > >> This error also appeared in the log while I was writing this:
> > >>
> > >> 2016-12-04 11:40:09,276 INFO
> > >> [org.ovirt.engine.core.bll.EngineBackupAwarenessManager]
> > >> (DefaultQuartzScheduler5) [7b442cfe] Backup check started.
> > >> 2016-12-04 11:40:09,278 INFO
> > >> [org.ovirt.engine.core.bll.EngineBackupAwarenessManager]
> > >> (DefaultQuartzScheduler5) [7b442cfe] Backup check completed.
> > >> 2016-12-04 11:40:09,772 INFO
> > >> [org.ovirt.engine.core.bll.storage.ovfstore.OvfDataUpdater]
> > >> (DefaultQuartzScheduler3) [2701e060] Attempting to update
> VMs/Templates
> > >> Ovf. 2016-12-04 11:40:09,774 INFO  [org.ovirt.engine.core.bll.sto
> > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > >> (DefaultQuartzScheduler3) [5358e209] Before acquiring and wait lock
> > >> 'EngineLock:{exclusiveLocks='[57fc8739-0039-00c7-0322-
> 01e5= > >> PDATE, ACTION_TYPE_FAILED_OBJECT_LOCKED>]', sharedLocks='null'}'
> > >> 2016-12-04 11:40:09,774 INFO  [org.ovirt.engine.core.bll.sto
> > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > >> (DefaultQuartzScheduler3) [5358e209] Lock-wait acquired to object
> > >> 'EngineLock:{exclusiveLocks='[57fc8739-0039-00c7-0322-
> 01e5= > >> PDATE, ACTION_TYPE_FAILED_OBJECT_LOCKED>]', sharedLocks='null'}'
> > >> 2016-12-04 11:40:09,775 INFO  [org.ovirt.engine.core.bll.sto
> > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > >> (DefaultQuartzScheduler3) [5358e209] Running command:
> > >> ProcessOvfUpdateForStoragePoolCommand internal: true. Entities
> affected
> > >>
> > >> :  ID: 57fc8739-0039-00c7-0322-01e5 Type: StoragePool
> > >>
> > >> 2016-12-04 11:40:09,781 INFO  [org.ovirt.engine.core.bll.sto
> > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > >> (DefaultQuartzScheduler3) [5358e209] Attempting to update VM OVFs in
> Data
> > >> Center 'Default'
> > >> 2016-12-04 11:40:09,788 INFO  [org.ovirt.engine.core.bll.sto
> > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > >> (DefaultQuartzScheduler3) [5358e209] Successfully updated VM OVFs in
> Data
> > >> Center 'Default'
> > >> 2016-12-04 11:40:09,789 INFO  [org.ovirt.engine.core.bll.sto
> > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > >> (DefaultQuartzScheduler3) [5358e209] Attempting to update template
> OVFs
> > >> in
> > >> Data Center 'Default'
> > >> 2016-12-04 11:40:09,790 INFO  [org.ovirt.engine.core.bll.sto
> > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > >> (DefaultQuartzScheduler3) [5358e209] Successfully updated templates
> OVFs
> > >> in
> > >> Data Center 'Default'
> > >> 2016-12-04 11:40:09,790 INFO  [org.ovirt.engine.core.bll.sto
> > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > >> (DefaultQuartzScheduler3) [5358e209] Attempting to remove unneeded
> > >> template/vm OVFs in Data Center 'Default'
> > >> 2016-12-04 11:40:09,793 INFO  [org.ovirt.engine.core.bll.sto
> > >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> > >> (DefaultQuartzScheduler3) [5358e209] Successfully removed unneeded
> > >> template/vm OVFs in Data Center 'Default'
> > >> 2016-12-04 11:40:09,793 INFO  [org.ovirt.engine.core.bll.sto
> > >>

Re: [ovirt-users] web-ui issues

2016-12-05 Thread Alexander Wels

On Sunday, December 4, 2016 5:57:50 PM EST Maton, Brett wrote:
> Hi Oved,
> 
>   I've upload the logs here
>  d8=10263>
> On 4 December 2016 at 12:25, Oved Ourfali  wrote:
> > Please attach complete logs.
> > Engine, server and ui logs.
> > 
> > Thanks,
> > Oved
> > 
> > On Dec 4, 2016 13:45, "Maton, Brett"  wrote:
> >> Since I upgraded to 4.0.6-3 I've been having problems with the UI
> >> 
> >> When I login the dash board presents a bunch of Operation Canceled
> >> dialogs,
> >> 
> >> 
> >> ! Operation canceled
> >> 
> >> Error while executing query: null
> >> 
> >> 
> >> 
> >> ! Operation canceled
> >> 
> >> Error while executing action: A Request to the Server failed:
> >> java.lang.reflect.InvocationTargetException
> >> 
> >> 
> >> The only error I see in engine.log is
> >> 
> >> 2016-12-04 11:34:07,945 INFO  [org.ovirt.engine.docs.utils.s
> >> ervlet.ContextSensitiveHelpMappingServlet] (default task-1) []
> >> Context-sensitive help is not installed. Manual directory doesn't exist:
> >> /usr/share/ovirt-engine/manual
> >> 
> >> Eventually after closing the error dialogs the dash board is displayed.
> >> 
> >> Most of the UI tabs then work normally, however 'Virtual Machines' tab
> >> doesn't display any information, just the progress 'dots' on the first
> >> line, it then cycles through the null query error dialogs.
> >> 
> >> This error also appeared in the log while I was writing this:
> >> 
> >> 2016-12-04 11:40:09,276 INFO 
> >> [org.ovirt.engine.core.bll.EngineBackupAwarenessManager]
> >> (DefaultQuartzScheduler5) [7b442cfe] Backup check started.
> >> 2016-12-04 11:40:09,278 INFO 
> >> [org.ovirt.engine.core.bll.EngineBackupAwarenessManager]
> >> (DefaultQuartzScheduler5) [7b442cfe] Backup check completed.
> >> 2016-12-04 11:40:09,772 INFO 
> >> [org.ovirt.engine.core.bll.storage.ovfstore.OvfDataUpdater]
> >> (DefaultQuartzScheduler3) [2701e060] Attempting to update VMs/Templates
> >> Ovf. 2016-12-04 11:40:09,774 INFO  [org.ovirt.engine.core.bll.sto
> >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> >> (DefaultQuartzScheduler3) [5358e209] Before acquiring and wait lock
> >> 'EngineLock:{exclusiveLocks='[57fc8739-0039-00c7-0322-01e5= >> PDATE, ACTION_TYPE_FAILED_OBJECT_LOCKED>]', sharedLocks='null'}'
> >> 2016-12-04 11:40:09,774 INFO  [org.ovirt.engine.core.bll.sto
> >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> >> (DefaultQuartzScheduler3) [5358e209] Lock-wait acquired to object
> >> 'EngineLock:{exclusiveLocks='[57fc8739-0039-00c7-0322-01e5= >> PDATE, ACTION_TYPE_FAILED_OBJECT_LOCKED>]', sharedLocks='null'}'
> >> 2016-12-04 11:40:09,775 INFO  [org.ovirt.engine.core.bll.sto
> >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> >> (DefaultQuartzScheduler3) [5358e209] Running command:
> >> ProcessOvfUpdateForStoragePoolCommand internal: true. Entities affected
> >> 
> >> :  ID: 57fc8739-0039-00c7-0322-01e5 Type: StoragePool
> >> 
> >> 2016-12-04 11:40:09,781 INFO  [org.ovirt.engine.core.bll.sto
> >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> >> (DefaultQuartzScheduler3) [5358e209] Attempting to update VM OVFs in Data
> >> Center 'Default'
> >> 2016-12-04 11:40:09,788 INFO  [org.ovirt.engine.core.bll.sto
> >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> >> (DefaultQuartzScheduler3) [5358e209] Successfully updated VM OVFs in Data
> >> Center 'Default'
> >> 2016-12-04 11:40:09,789 INFO  [org.ovirt.engine.core.bll.sto
> >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> >> (DefaultQuartzScheduler3) [5358e209] Attempting to update template OVFs
> >> in
> >> Data Center 'Default'
> >> 2016-12-04 11:40:09,790 INFO  [org.ovirt.engine.core.bll.sto
> >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> >> (DefaultQuartzScheduler3) [5358e209] Successfully updated templates OVFs
> >> in
> >> Data Center 'Default'
> >> 2016-12-04 11:40:09,790 INFO  [org.ovirt.engine.core.bll.sto
> >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> >> (DefaultQuartzScheduler3) [5358e209] Attempting to remove unneeded
> >> template/vm OVFs in Data Center 'Default'
> >> 2016-12-04 11:40:09,793 INFO  [org.ovirt.engine.core.bll.sto
> >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> >> (DefaultQuartzScheduler3) [5358e209] Successfully removed unneeded
> >> template/vm OVFs in Data Center 'Default'
> >> 2016-12-04 11:40:09,793 INFO  [org.ovirt.engine.core.bll.sto
> >> rage.ovfstore.ProcessOvfUpdateForStoragePoolCommand]
> >> (DefaultQuartzScheduler3) [5358e209] Lock freed to object
> >> 'EngineLock:{exclusiveLocks='[57fc8739-0039-00c7-0322-01e5= >> PDATE, ACTION_TYPE_FAILED_OBJECT_LOCKED>]', sharedLocks='null'}'
> >> 
> >> 
> >> 
> >> If I restart the ovirt-engine process, the UI works for a while before
> >> the Operation Canceled dialogs start appearing again.
> >> 
> >> Any suggestions ?
> >>

Re: [ovirt-users] Self hosted single server network requirements

2016-12-05 Thread Mark Steckel

Follow-up - I finally discovered the source of my networking troubles.

The provider (Hetzner) configures the primary IP in a somewhat odd manner for 
Cent OS 7.2.

For instance, here is /etc/sysconfig/network-scripts/ifcfg-eth0 (lightly edited)

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
IPADDR=A.B.4.9
NETMASK=255.255.255.255
SCOPE="peer A.B.4.1"

And /etc/sysconfig/network-scripts/route-eth0

ADDRESS0=0.0.0.0
NETMASK0=0.0.0.0
GATEWAY0=A.B.4.1

The key thing is the SCOPE line.

This creates a private link between the server's IP and the gw IP. The server's 
IP address no longer has a netmask, which is now specified on the gw IP.

The odd network config appears to confuse the hosted-engine deploy process 
because it was unable to configure the ovirtmgmt bridge in a working manner.

Once I delete route-eth0 and changed ifcfg-eth0 to a more typical configuration 
all started working.

Now I just need to figure out how to configure the /29 for the VMs.

Thanks
Mark


- Derek Atkins  wrote:
> Hi,
> 
> On Mon, November 21, 2016 4:30 pm, Mark Steckel wrote:
> >
> [snip]
> >> >> > Advice so far seems to be:
> >> >> > * Use 'screen' when deploying. Easy
> >> >> > * Don't use/disable Network-Manager. Easy
> >> >> > * Preconfigure the ovirtmgmt bridge. I've got questions...
> >> >> >
> >> >> > The server has a public /32 as the primary IP, and a public /29
> >> which
> >> >> > will be used for the VMs.
> >> >> >
> >> >> > Besides creating the ovirtmgmt bridge is there anything specific
> >> for
> >> >> > how I should configure it?
> [snip]
> >
> > Yeah, I was hoping that would be the case for me too. :-)
> 
> For what it's worth, it took me about 4 tries to get it all working.
> I wound up using a script I found to clean the host and re-install it all.
>  Of course the cleanup process let the firewall in a state where it
> blocked all traffic (including SSH), but I figured that part out on the
> 2nd try so added it back into my script for the 3rd.  ;)
> 
> The other difference is that I had already created a bond0 interface which
> was my default (with a non-NM-controlled static network).  However, that
> shouldn't have made a difference.
> 
> >> What did your /etc/sysconfig/network-scripts/ifcfg- file look like?
> >> (And what does the ifcfg-ovirtmgmt file look like)?
> >
> > Sadly, thinking I messed things up I scrubbed the machine and started
> > over. I have a fresh CentOS 7.2 install waiting to run 'hosted-engine
> > --deploy' on it once I have a better sense what if anything I need to
> > prepare from a networking stand point.
> 
> Okay, so go and try it!  :)
> 
> Worst case, you need to run hosted-engine-cleanup.sh and then reset the
> firewall and reboot, and then re-install everything:
> 
> https://access.redhat.com/documentation/en/red-hat-virtualization/4.0/paged/self-hosted-engine-guide/chapter-2-deploying-self-hosted-engine
> http://www.ovirt.org/documentation/how-to/hosted-engine/#fresh-install
> 
> [snip]
> >> >> As for the /29 -- don't worry about it now, that would be a routing
> >> >> issue you can apply later.  Is it the same network as the /32?  Or is
> >> it
> >> >> a different network?
> >> >
> >> > Different.
> >>
> >> I assume both networks are available on your host interface?
> >
> > At this point only the /32 is on the host interface. The /29 is not
> > assigned at the moment.
> 
> You shouldn't need to "assign" anything in the /29 to the host.  All
> that's important is that the physical network can reach the /29.  I.e.,
> you could do something like:
> 
>  /32   /32/29
> router --- host   VMs
>  /29
> 
> The host will bridge the network to the VMs, but it can be on a different
> network.
> 
> > Mark
> 
> -derek
> 
> -- 
>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 4 and Neutron

2016-12-05 Thread Marcin Mirecki

Devin,

The ovs-vswitchd process pegged at 100% is a known OVS problem. It is 
interesting however
that you see it on all the hosts at the same time. Can you please report this 
against OVS?
I assume the OVS team should take interest in this (they will also know what 
additional
info to ask about).

Could you please send me the ui.log and engine.log (/var/log/ovirt-engine) and
/var/log/ovirt-provider-ovn.log (from the host where the provider is located)
when you see the UI error again?

> One other thing that I notice is that when I got to Provision a Virtual 
> Machine from the Main Data Center, my Networks don't show under the NIC where 
> I could select them? Am I missing something on this?
Could you please elaborate on this? I am not quite sure I understand this.
Could it be that the network is not assigned to the cluster?

Marcin

- Original Message -
> Sent: Friday, December 2, 2016 11:15:22 PM
> Subject: Re: [ovirt-users] oVirt 4 and Neutron
> 
> Ok i figured out my issue, the network wasn't configured under the Cluster
> section to be allowed to see, I have now been able to spin up my own
> network/subnet and then spin up 2 instances both getting DHCP addresses and
> able to talk to each other. The ONLY issue i'm seeing is that random UI
> error that i have e-mailed over to Alexander about. I'll let you know if i
> have any other questions. I think for now I'm golden.
> 
> 
> On Fri, Dec 2, 2016 at 1:23 PM, Devin Acosta  wrote:
> 
> > Marcin,
> >
> > So an update on my situation, I restarted all OpenVSwitch processes on all
> > boxes and was able to get the CPU issue with ovs-vswitchd to return to
> > normal. So I believe all those issues are resolved. I can create
> > networks/subnets, minus that one strange UI issue which I'll work with
> > Alexander Wels to resolve. When I still go to launch a Virtual Machine,
> > should I be seeing the subnets that I created? Am I missing something? It
> > seems like i'm about 95% there and I am just missing something.
> >
> >
> > On Fri, Dec 2, 2016 at 11:44 AM, Devin Acosta 
> > wrote:
> >
> >> Marcin,
> >>
> >> I installed the OVN-Central on a dedicated VM that lives on the ovirtmgmt
> >> network, I also installed the OVN-Provider on this same instance. I then
> >> installed the OVN-Controllers on all 3 of my oVirt Nodes, with the OVN
> >> provider driver, and configured the vdsm ovn-controller {central-ip}
> >> {ovirt-node-ip} on each of the boxes. It appears to be running but what I
> >> am noticing is that the ovs-vswitchd process is pegged at 100% on all the
> >> oVirt nodes.
> >>
> >> So for instance from oVirt Node 3 (IP 75) the ovs-vsctl shows the IPs for
> >> the other 2 nodes in it's configuration. It seems to be that way across
> >> all
> >> 3 nodes, they know about the other nodes in the cluster. I was able to
> >> create a network inside of oVIRT using the external provider. After i
> >> create a subnet inside oVirt I do get an error at the top but seems to be
> >> ok?
> >>
> >>
> >> [image: Inline image 2]
> >>
> >> (Output from Node3 IP 75, of: ovs-vsctl show)
> >>
> >> 61af799c-a621-445e-8183-23dcb38ea3cc
> >> Bridge br-int
> >> fail_mode: secure
> >> Port "ovn-c0dc09-0"
> >> Interface "ovn-c0dc09-0"
> >> type: geneve
> >> options: {csum="true", key=flow, remote_ip="172.10.10.73"}
> >> Port "ovn-456949-0"
> >> Interface "ovn-456949-0"
> >> type: geneve
> >> options: {csum="true", key=flow, remote_ip="172.10.10.74"}
> >> Port br-int
> >> Interface br-int
> >> type: internal
> >> ovs_version: "2.6.90"
> >>
> >>
> >>
> >> Example where the (ovs-vswitchd) is running at 100% on all 3 oVirt Nodes.
> >>
> >>   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
> >> COMMAND
> >>  1768 root  10 -10   49680  10808   9388 R 100.0  0.0  24:48.85
> >> ovs-vswitchd
> >>
> >>
> >> [root@ovirt01 openvswitch]# tail -f ovs-vswitchd.log
> >> 2016-12-02T18:27:12.174Z|00604|poll_loop|INFO|Dropped 557231 log
> >> messages in last 6 seconds (most recently, 0 seconds ago) due to excessive
> >> rate
> >> 2016-12-02T18:27:12.174Z|00605|poll_loop|INFO|wakeup due to 0-ms timeout
> >> at vswitchd/bridge.c:3031 (100% CPU usage)
> >> 2016-12-02T18:27:18.174Z|00606|poll_loop|INFO|Dropped 536053 log
> >> messages in last 6 seconds (most recently, 0 seconds ago) due to excessive
> >> rate
> >> 2016-12-02T18:27:18.174Z|00607|poll_loop|INFO|wakeup due to 0-ms timeout
> >> at vswitchd/bridge.c:3031 (100% CPU usage)
> >> 2016-12-02T18:27:24.174Z|00608|poll_loop|INFO|Dropped 536369 log
> >> messages in last 6 seconds (most recently, 0 seconds ago) due to excessive
> >> rate
> >> 2016-12-02T18:27:24.174Z|00609|poll_loop|INFO|wakeup due to 0-ms timeout
> >> at vswitchd/bridge.c:3031 (100% CPU usage)
> >>

[ovirt-users] [Call to Action] packaging for your preferred distribution

2016-12-05 Thread Sandro Bonazzola

Hi,
we released oVirt 4.1 beta last week providing RPMs for  latest Red Hat
Enterprise Linux release and its derivatives like CentOS Linux and
Scientific Linux and Fedora or similar distributions.
Virt support for Fedora is provided as tech preview / best effort being
Fedora so fast moving which is too difficult to stay aligned with.

We have still 2 months to GA so if you'd like to get oVirt 4.1 on your
preferred distribution and you've packaging skills, this is a good chance
to start packaging it playing with 4.1 beta released code.

You can find some information about porting oVirt to your preferred
distribution starting from [1]

[1] https://www.ovirt.org/develop/developer-guide/porting-ovirt/

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

[ovirt-users] [Call to Action] oVirt 4.1 translation

2016-12-05 Thread Sandro Bonazzola

Hi,
we released 4.1 beta 1 last week and we're going fast toward the GA
currently scheduled for January 24th[1].
We have a scheduled string freeze on December 21st to allow translators to
complete the translations but looking at zanata[2] I think it's time to go
there and start translating to your preferred language.

[1]
http://www.ovirt.org/develop/release-management/releases/4.1/release-management/
[2] https://translate.zanata.org/project/view/ovirt?dswid=9807

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

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

2016-12-05 Thread Marcin Mirecki

Lance,

We have a problem with communication between different hosts in OVN.
Could you please take a look at the log below?
The part with "dropping duplicate flow" sounds worrying.

Thanks,
Marcin


- Original Message -
> From: "Devin Acosta" 
> To: "users" 
> Sent: Saturday, December 3, 2016 12:24:21 AM
> Subject: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances  
> between nodes.
> 
> 
> Note: When I configured vdsm-tool ovn-config, I passed it the IP address of
> the OVN-Controller which is using the ovirtmgmt network, which is just one
> of the NIC's on the nodes.
> 
> I am opening up new thread as this I feel differs a bit from my original
> request. I have OVN which I believe is deployed correctly. I have noticed
> that if instances get spun up on the same oVIRT node they can all talk
> without issues to one another, however if one instance gets spun up on
> another node even if it has the same (OVN network/subnet), it can't ping or
> reach other instances in the subnet. I noticed that the OVN-Controller of
> the instance that can't talk is logging:
> 
> 2016-12-02T22:50:54.907Z|00181|pinctrl|INFO|DHCPOFFER 00:1a:4a:16:01:5c
> 10.10.10.4
> 2016-12-02T22:50:54.908Z|00182|pinctrl|INFO|DHCPACK 00:1a:4a:16:01:5c
> 10.10.10.4
> 2016-12-02T22:50:55.695Z|00183|ofctrl|INFO|Dropped 7 log messages in last 10
> seconds (most recently, 0 seconds ago) due to excessive rate
> 2016-12-02T22:50:55.695Z|00184|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:10.705Z|00185|ofctrl|INFO|Dropped 6 log messages in last 15
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:51:10.705Z|00186|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:20.710Z|00187|ofctrl|INFO|Dropped 4 log messages in last 10
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:51:20.710Z|00188|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:35.718Z|00189|ofctrl|INFO|Dropped 5 log messages in last 15
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:51:35.718Z|00190|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:45.724Z|00191|ofctrl|INFO|Dropped 3 log messages in last 10
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:51:45.724Z|00192|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:55.730Z|00193|ofctrl|INFO|Dropped 5 log messages in last 10
> seconds (most recently, 0 seconds ago) due to excessive rate
> 2016-12-02T22:51:55.730Z|00194|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:52:10.738Z|00195|ofctrl|INFO|Dropped 5 log messages in last 15
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:52:10.739Z|00196|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:52:20.744Z|00197|ofctrl|INFO|Dropped 3 log messages in last 10
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:52:20.744Z|00198|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:52:35.752Z|00199|ofctrl|INFO|Dropped 5 log messages in last 15
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:52:35.752Z|00200|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:52:45.758Z|00201|ofctrl|INFO|Dropped 4 log messages in last 10
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:52:45.758Z|00202|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 
> From the OVN-Controller:
> 
> [root@dev001-022-002 ~]# ovn-nbctl show
> switch ddb3b92f-b359-4b59-a41a-ebae6df7fe9a (devins-net)
> port 6b289418-8b8e-42b4-8334-c71584afcd3e
> addresses: ["00:1a:4a:16:01:5c dynamic"]
> port 71ef81f1-7c20-4c68-b536-d274703f7541
> addresses: ["00:1a:4a:16:01:61 dynamic"]
> port 91d4f4f5-4b9f-42c0-aa2c-8a101474bb84
> addresses: ["00:1a:4a:16:01:5e dynamic"]
> 
> Do I need to do something special in order to allow communication between
> nodes of instances on same OVN network?
> 
> Output of ovs-vsctl show from node3:
> 
> 61af799c-a621-445e-8183-23dcb38ea3cc
> Bridge br-int
> fail_mode: secure
> Port "ovn-456949-0"
> Interface "ovn-456949-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.10.10.74"}
> Port "ovn-c0dc09-0"
> Interface "ovn-c0dc09-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.10.10.73"}
> Port br-int
>

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

2016-12-05 Thread Marcin Mirecki

Devin,

Please not the OVN-controller is not the central part where OVN northd is 
running.
OVN-controllers are the OVN processes deployed on the hosts.
The correct usage of the 'vdsm-tool ovn-config'.
 - the IP of the OVN-central (not to be confused with OVN-controllers, which is 
the part of OVN running on the hosts)
 - the local host IP to be used for tunneling to other OVN hosts
for example, if the OVN-central IP should be 10.10.10.1, and the IP of the 
local host used for tunneling: 10.10.10.101:
vdsm-tool ovn-config 10.10.10.1 10.10.10.101

Looking at the output of 'ovs-vsctl' the tunnels have been created.

The OVN log saying 'dropping duplicate flow' is worrying, let me forward this to
the OVN team to take a look at it.

Marcin



- Original Message -
> From: "Devin Acosta" 
> To: "users" 
> Sent: Saturday, December 3, 2016 12:24:21 AM
> Subject: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances  
> between nodes.
> 
> 
> Note: When I configured vdsm-tool ovn-config, I passed it the IP address of
> the OVN-Controller which is using the ovirtmgmt network, which is just one
> of the NIC's on the nodes.
> 
> I am opening up new thread as this I feel differs a bit from my original
> request. I have OVN which I believe is deployed correctly. I have noticed
> that if instances get spun up on the same oVIRT node they can all talk
> without issues to one another, however if one instance gets spun up on
> another node even if it has the same (OVN network/subnet), it can't ping or
> reach other instances in the subnet. I noticed that the OVN-Controller of
> the instance that can't talk is logging:
> 
> 2016-12-02T22:50:54.907Z|00181|pinctrl|INFO|DHCPOFFER 00:1a:4a:16:01:5c
> 10.10.10.4
> 2016-12-02T22:50:54.908Z|00182|pinctrl|INFO|DHCPACK 00:1a:4a:16:01:5c
> 10.10.10.4
> 2016-12-02T22:50:55.695Z|00183|ofctrl|INFO|Dropped 7 log messages in last 10
> seconds (most recently, 0 seconds ago) due to excessive rate
> 2016-12-02T22:50:55.695Z|00184|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:10.705Z|00185|ofctrl|INFO|Dropped 6 log messages in last 15
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:51:10.705Z|00186|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:20.710Z|00187|ofctrl|INFO|Dropped 4 log messages in last 10
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:51:20.710Z|00188|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:35.718Z|00189|ofctrl|INFO|Dropped 5 log messages in last 15
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:51:35.718Z|00190|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:45.724Z|00191|ofctrl|INFO|Dropped 3 log messages in last 10
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:51:45.724Z|00192|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:55.730Z|00193|ofctrl|INFO|Dropped 5 log messages in last 10
> seconds (most recently, 0 seconds ago) due to excessive rate
> 2016-12-02T22:51:55.730Z|00194|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:52:10.738Z|00195|ofctrl|INFO|Dropped 5 log messages in last 15
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:52:10.739Z|00196|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:52:20.744Z|00197|ofctrl|INFO|Dropped 3 log messages in last 10
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:52:20.744Z|00198|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:52:35.752Z|00199|ofctrl|INFO|Dropped 5 log messages in last 15
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:52:35.752Z|00200|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:52:45.758Z|00201|ofctrl|INFO|Dropped 4 log messages in last 10
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:52:45.758Z|00202|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 
> From the OVN-Controller:
> 
> [root@dev001-022-002 ~]# ovn-nbctl show
> switch ddb3b92f-b359-4b59-a41a-ebae6df7fe9a (devins-net)
> port 6b289418-8b8e-42b4-8334-c71584afcd3e
> addresses: ["00:1a:4a:16:01:5c dynamic"]
> port 71ef81f1-7c20-4c68-b536-d274703f7541
> addresses: ["00:1a:4a:16:01:61 dynamic"]
> port

Re: [ovirt-users] can not use iscsi storage type onovirtandGlusterfshyper-converged environment

2016-12-05 Thread Fred Rolland

Hi,
After changing the code, you need to restart the VDSM service to take
effect.

Regards,
Fred

On Mon, Dec 5, 2016 at 10:28 AM, 胡茂荣  wrote:

>
>   Thanks for Yaniv Kaul ,  change code need build vdsm source code , and
> if only  change /usr/share/vdsm/storage/devicemapper.py will not really
> take effect .
>
>could this problem as a bug , and correct it to ovirt vdsm source code
> ?
>
> -- Original --
> *From: * "Yaniv Kaul";
> *Date: * Sun, Dec 4, 2016 07:07 PM
> *To: * "胡茂荣";
> *Cc: * "胡晓宇"; "users"; "Sahina
> Bose"; "Jeff Nelson";
> *Subject: * Re: [ovirt-users] can not use iscsi storage type
> onovirtandGlusterfshyper-converged environment
>
>
>
> On Dec 2, 2016 11:53 AM, "胡茂荣"  wrote:
>
>I find supervdsm  used " /usr/sbin/dmsetup status" :
>
> MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02
> 17:12:16,372::supervdsmServer::92::SuperVdsm.ServerCallback::(wrapper)
> call getPathsStatus with () {}
> MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02
> 17:12:16,373::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus)
> /usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status (cwd None)
> MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02
> 17:12:16,377::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus)
> SUCCESS:  = '';  = 0
> MainProcess|jsonrpc.Executor/2::ERROR::2016-12-02
> 17:12:16,378::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper) Error
> in getPathsStatus
>
> problem :
> how can I change  Storage.Misc.excCmd _getPathsStatus  " /usr/bin/taskset
> --cpu-list 0-7 /usr/sbin/dmsetup status"  to :
>
>/usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status  --target
> multipah
>
>   I think add iscsi type storage ,  if supervdsm scan mulitpah will solve
> my problem .(my environment have other dm devices, use "dmsetup status"
> will show them, and vdsm get dm path status will occur error )
>
> 
> 
> so I changed some as follow :
>  （1）
>I  define EXT_DMSETUP_STATUS   in  
> /usr/lib/python2.7/site-packages/vdsm/constants.py
> :
>
> /usr/lib/python2.7/site-packages/vdsm/constants.py:EXT_DMSETUP =
> '/usr/sbin/dmsetup'
> /usr/lib/python2.7/site-packages/vdsm/constants.py:EXT_DMSETUP_STATUS =
> "/usr/sbin/dmsetup status --target multipath"
>
>  (2)
>  /usr/share/vdsm/storage/devicemapper.py add :
> from vdsm.constants import EXT_DMSETUP_STATUS
>
> and changed  getPathsStatus cmd  to " EXT_DMSETUP_STATUS" :
>
> def _getPathsStatus():
> cmd = [EXT_DMSETUP_STATUS]# before : cmd=[
> EXT_DMSETUP,"status"]
>
>
> Why not change this to:
> cmd = [EXT_DMSETUP,  "status", "--target", "multipath"]
>
> Y.
>
> rc, out, err = misc.execCmd(cmd)
> 
> ===
>
>  but log in supervdsm log also not change . Please help me ，how to change
> code to let supervdsm exec "/usr/sbin/dmsetup status --target multipath"
>   in function  getPathsStatus（） 。
>
>
>
>
> -- Original --
> *From: * "胡茂荣";
> *Date: * Fri, Nov 25, 2016 05:44 PM
> *To: * "Sahina Bose";
> *Cc: * "Maor Lipchuk"; "Jeff Nelson"<
> jenel...@redhat.com>; "users";
> *Subject: * Re: [ovirt-users] can not use iscsi storage type on
> ovirtandGlusterfshyper-converged environment
>
>
> ===---
>
>###vdsm or supervdsm log  report :
>
> MainProcess|jsonrpc.Executor/7::ERROR::2016-11-01
> 11:07:00,178::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper)
> Error in getPathsStatus
>
> MainProcess|jsonrpc.Executor/4::ERROR::2016-11-01
> 11:07:20,964::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper)
> Error in getPathsStatus
>    some code info >
> [root@horeba storage]# pwd
> /usr/share/vdsm/storage
>
> [root@horeba storage]# grep "getPathsStatus" -R ./
> ./devicemapper.py:def _getPathsStatus():
> ./devicemapper.py:def getPathsStatus():
> ./devicemapper.py:return getProxy().getPathsStatus()
> ./multipath.py:pathStatuses = devicemapper.getPathsStatus()
>
> def _getPathsStatus():
> cmd = [EXT_DMSETUP, "status"]
> rc, out, err = misc.execCmd(cmd)
> if rc != 0:
> raise Exception("Could not get device statuses")
>
> res = {}
> for statusLine in out:
> try:
> devName, statusLine = statusLine.split(":", 1)
> except ValueError:
> if len(out) == 1:
> # return an empty dict when status output is: No devices
> found
> return res
> else:
> raise
>
> for m in PATH_STATUS_RE.finditer(statusLine):
>

Re: [ovirt-users] VM config warning

2016-12-05 Thread Andrea Ghelardi

Same issue here right after importing my VMs from Ovirt3.5.5 to Ovirt4.0
All windows server report that OS differs from configuration while all settings 
seems correct.
Cheers
AG

From: Gary Pedretty [mailto:g...@ravnalaska.net]
Sent: Sunday, December 04, 2016 00:33
To: users 
Subject: [ovirt-users] VM config warning

When running a Windows 2012 R2 Server VM, why does it report that the OS 
differs from the Configuration when the selected OS in the config is Windows 
2012R2 x64.   Also what is the correct way to do timezones in the config on 
these VMs, no matter what I pick it reports that Actual Timezone is different 
in the guest versus the config, when they are both the same.

Gary

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

Re: [ovirt-users] can not use iscsi storage type onovirtandGlusterfshyper-converged environment

2016-12-05 Thread 胡茂荣

Thanks for Yaniv Kaul ,  change code need build vdsm source code , and if only  
change /usr/share/vdsm/storage/devicemapper.py will not really take effect .
   
   could this problem as a bug , and correct it to ovirt vdsm source code ? 
 
-- Original --
From:  "Yaniv Kaul";
Date:  Sun, Dec 4, 2016 07:07 PM
To:  "胡茂荣"; 
Cc:  "胡晓宇"; "users"; "Sahina 
Bose"; "Jeff Nelson"; 
Subject:  Re: [ovirt-users] can not use iscsi storage type 
onovirtandGlusterfshyper-converged environment

 


On Dec 2, 2016 11:53 AM, "胡茂荣"  wrote:
   I find supervdsm  used " /usr/sbin/dmsetup status" :


MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02 
17:12:16,372::supervdsmServer::92::SuperVdsm.ServerCallback::(wrapper) call 
getPathsStatus with () {}
MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02 
17:12:16,373::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus) 
/usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status (cwd None)
MainProcess|jsonrpc.Executor/2::DEBUG::2016-12-02 
17:12:16,377::devicemapper::154::Storage.Misc.excCmd::(_getPathsStatus) 
SUCCESS:  = '';  = 0
MainProcess|jsonrpc.Executor/2::ERROR::2016-12-02 
17:12:16,378::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper) Error in 
getPathsStatus



problem :
how can I change  Storage.Misc.excCmd _getPathsStatus  " /usr/bin/taskset 
--cpu-list 0-7 /usr/sbin/dmsetup status"  to :


   /usr/bin/taskset --cpu-list 0-7 /usr/sbin/dmsetup status  --target multipah 


  I think add iscsi type storage ,  if supervdsm scan mulitpah will solve my 
problem .(my environment have other dm devices, use "dmsetup status" will show 
them, and vdsm get dm path status will occur error )



so I changed some as follow :
 （1）
   I  define EXT_DMSETUP_STATUS   in  
/usr/lib/python2.7/site-packages/vdsm/constants.py : 


/usr/lib/python2.7/site-packages/vdsm/constants.py:EXT_DMSETUP = 
'/usr/sbin/dmsetup'
/usr/lib/python2.7/site-packages/vdsm/constants.py:EXT_DMSETUP_STATUS = 
"/usr/sbin/dmsetup status --target multipath"


 (2)
 /usr/share/vdsm/storage/devicemapper.py add :
from vdsm.constants import EXT_DMSETUP_STATUS


and changed  getPathsStatus cmd  to " EXT_DMSETUP_STATUS" :


def _getPathsStatus():
cmd = [EXT_DMSETUP_STATUS]# before : 
cmd=[EXT_DMSETUP,"status"]









Why not change this to:
cmd = [EXT_DMSETUP,  "status", "--target", "multipath"] 


Y. 


rc, out, err = misc.execCmd(cmd)

===





 but log in supervdsm log also not change . Please help me ，how to change code 
to let supervdsm exec "/usr/sbin/dmsetup status --target multipath"   in 
function  getPathsStatus（） 。






 
-- Original --
From:  "胡茂荣";
Date:  Fri, Nov 25, 2016 05:44 PM
To:  "Sahina Bose"; 
Cc:  "Maor Lipchuk"; "Jeff Nelson"; 
"users"; 
Subject:  Re: [ovirt-users] can not use iscsi storage type on 
ovirtandGlusterfshyper-converged environment


 



===---

   ###vdsm or supervdsm log  report :

MainProcess|jsonrpc.Executor/7::ERROR::2016-11-01 
11:07:00,178::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper) Error in 
getPathsStatus

MainProcess|jsonrpc.Executor/4::ERROR::2016-11-01 
11:07:20,964::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper) Error in 
getPathsStatus

   some code info >
[root@horeba storage]# pwd
/usr/share/vdsm/storage


[root@horeba storage]# grep "getPathsStatus" -R ./
./devicemapper.py:def _getPathsStatus():
./devicemapper.py:def getPathsStatus():
./devicemapper.py:return getProxy().getPathsStatus()
./multipath.py:pathStatuses = devicemapper.getPathsStatus()



def _getPathsStatus():
cmd = [EXT_DMSETUP, "status"]
rc, out, err = misc.execCmd(cmd)
if rc != 0:
raise Exception("Could not get device statuses")


res = {}
for statusLine in out:
try:
devName, statusLine = statusLine.split(":", 1)
except ValueError:
if len(out) == 1:
# return an empty dict when status output is: No devices found
return res
else:
raise


for m in PATH_STATUS_RE.finditer(statusLine):
devNum, status = m.groups()
physdevName = findDev(*[int(i) for i in devNum.split(":")])
res[physdevName] = {"A": "active", "F": "failed"}[status]


return res
def getPathsStatus():
return getProxy().getPathsStatus()

=
  and flashcache dm device will error  when use getPathsStatus()

Re: [ovirt-users] shutdown and kernel panic

2016-12-05 Thread Synt - Support Service

2016-11-23 18:06 GMT+01:00 Pavel Gashev :

> It’s necessary to put a host into maintenance mode before shutdown.


I cant put host in maintenance mode before, because the host-egnie is a VM
inside the single host.
... unfortunately the shutdown problem persist ... :-(


-- 


*Luigi** Fanton*
Tecnical Support
Office +39.0422.545487
supp...@synt.net

*Synt.net S.r.l.*
Viale IV Novembre, 85/3
31100 - Treviso - Italy
P.IVA 04586950265
Tel +39.0422.545487
Fax +39.0422.0247047

i...@synt.net
www.synt.net

*Soluzioni in movimento per le Imprese*





* Le informazioni contenute in questo messaggio di posta elettronica e
negli eventuali allegati sono riservate e confidenziali e sono indirizzate
esclusivamente al destinatario. Si prega di non fare copia, inoltrare a
terzi o conservare tale messaggio se non si è il legittimo destinatario
dello stesso. Qualora questo messaggio sia stato ricevuto per errore, si
prega di rinviarlo al mittente e di cancellarlo permanentemente dal proprio
computer. Ogni prezzo indicato è puramente indicativo e soggetto a
verifica. The information contained in this message and in any attachment
is intended exclusively for the recipient. If you are not the intended
recipient you are hereby notified not to copy, save, disclose, or
distribute it to any third party. If you erroneously received this message
you are kindly requested to return it to the sender and eliminate it
permanently from your computer.*
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] can not migrate vm

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

Re: [ovirt-users] can not use iscsi storage type onovirtandGlusterfshyper-convergedenvironment

Re: [ovirt-users] can not use iscsi storage type onovirtandGlusterfshyper-convergedenvironment

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

Re: [ovirt-users] web-ui issues

Re: [ovirt-users] Storage domains not found by vdsm after a reboot

Re: [ovirt-users] web-ui issues

[ovirt-users] User portal permissions

Re: [ovirt-users] web-ui issues

Re: [ovirt-users] can not use iscsi storage type onovirtandGlusterfshyper-converged environment

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

Re: [ovirt-users] web-ui issues

Re: [ovirt-users] web-ui issues

Re: [ovirt-users] Self hosted single server network requirements

Re: [ovirt-users] oVirt 4 and Neutron

[ovirt-users] [Call to Action] packaging for your preferred distribution

[ovirt-users] [Call to Action] oVirt 4.1 translation

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

Re: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances between nodes.

Re: [ovirt-users] can not use iscsi storage type onovirtandGlusterfshyper-converged environment

Re: [ovirt-users] VM config warning

Re: [ovirt-users] can not use iscsi storage type onovirtandGlusterfshyper-converged environment

Re: [ovirt-users] shutdown and kernel panic

26 matches

Site Navigation

Mail list logo

Footer information