[ovirt-users] Issue with OVN/OVS and mandatory ovirtmgmt network
Marcin Mirecki
mmirecki at redhat.com
Wed Jan 18 10:20:44 UTC 2017
It's visible now.
I'll try to review it asap.
On Wed, Jan 18, 2017 at 11:07 AM, Sverker Abrahamsson <
sverker at abrahamsson.com> wrote:
> Ok, thank you. Done that now
> /Sverker
> Den 2017-01-18 kl. 10:14, skrev Fred Rolland:
>
> Go to https://gerrit.ovirt.org/70588 and click on the publish button.
> Drafts are not visible to everybody.
> Or you can push to master directly.
>
> On Tue, Jan 17, 2017 at 7:39 PM, Sverker Abrahamsson <
> sverker at abrahamsson.com> wrote:
>
>> I still had the window open where I did that step. This is how it looked
>> like:
>>
>> [root at h2 ovirt-provider-ovn]# git push origin HEAD:refs/drafts/master
>> Counting objects: 9, done.
>> Delta compression using up to 8 threads.
>> Compressing objects: 100% (5/5), done.
>> Writing objects: 100% (6/6), 1.79 KiB | 0 bytes/s, done.
>> Total 6 (delta 2), reused 0 (delta 0)
>> remote: Resolving deltas: 100% (2/2)
>> remote: Processing changes: new: 1, refs: 1, done
>> remote: (W) 16d5be4: commit subject >65 characters; use shorter first
>> paragraph
>> remote:
>> remote: New Changes:
>> remote: https://gerrit.ovirt.org/70588 Properly handle to set id when
>> interface already has a virtualport element ... [DRAFT]
>> remote:
>> To gerrit.ovirt.org:ovirt-provider-ovn
>> * [new branch] HEAD -> refs/drafts/master
>>
>> I see the difference is that I pushed to HEAD:refs/drafts/master as
>> instructed at http://www.ovirt.org/develop/d
>> ev-process/working-with-gerrit/
>>
>> Should I push it to HEAD:refs/for/master instead?
>>
>> /Sverker
>> Den 2017-01-17 kl. 12:09, skrev Marcin Mirecki:
>>
>> Sverker,
>> I can see you as a user in gerrit (sverker at abrahamsson.com), but there
>> are no patches for your name.
>> Please check for any errors after you issue:
>> git push gerrit.ovirt.org:ovirt-provider-ovn HEAD:refs/for/master
>>
>> Also, please let me know if you need any other help on with gerrit.
>>
>> On Mon, Jan 16, 2017 at 8:49 PM, Sverker Abrahamsson <
>> sverker at abrahamsson.com> wrote:
>>
>>> I've followed the instructions to best effort, so hopefully it's right..
>>>
>>>
>>> Den 2017-01-13 kl. 10:31, skrev Marcin Mirecki:
>>>
>>>> Please push the patch into: https://gerrit.ovirt.org/ovirt-provider-ovn
>>>> (let me know if you need some directions)
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>
>>>>> From: "Sverker Abrahamsson" <sverker at abrahamsson.com>
>>>>> To: "Marcin Mirecki" <mmirecki at redhat.com>
>>>>> Cc: "Ovirt Users" <users at ovirt.org>
>>>>> Sent: Monday, January 9, 2017 1:45:37 PM
>>>>> Subject: Re: [ovirt-users] Issue with OVN/OVS and mandatory ovirtmgmt
>>>>> network
>>>>>
>>>>> Ok, found it. The issue is right here:
>>>>>
>>>>> <interface type="bridge">
>>>>> <mac address="00:1a:4a:16:01:54" />
>>>>> <model type="virtio" />
>>>>> <source bridge="br-int" />
>>>>> <virtualport type="openvswitch" />
>>>>> <link state="up" />
>>>>> <boot order="2" />
>>>>> <bandwidth />
>>>>> <virtualport type="openvswitch">
>>>>> <parameters
>>>>> interfaceid="912cba79-982e-4a87-868e-241fedccb59a" />
>>>>> </virtualport>
>>>>> </interface>
>>>>>
>>>>> There are two elements for virtualport, the first without id and the
>>>>> second with. On h2 I had fixed this which was the patch I posted
>>>>> earlier
>>>>> although I switched back to use br-int after understanding that was the
>>>>> correct way. When that hook was copied to h1 the port gets attached
>>>>> fine.
>>>>>
>>>>> Patch with updated testcase attached.
>>>>>
>>>>> /Sverker
>>>>>
>>>>>
>>>>> Den 2017-01-09 kl. 10:41, skrev Sverker Abrahamsson:
>>>>>
>>>>>> This is the content of vdsm.log on h1 at this time:
>>>>>>
>>>>>> 2017-01-06 20:54:12,636 INFO (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC
>>>>>> call VM.create succeeded in 0.01 seconds (__init__:515)
>>>>>> 2017-01-06 20:54:12,636 INFO (vm/6dd5291e) [virt.vm]
>>>>>> (vmId='6dd5291e-6556-4d29-8b4e-ea896e627645') VM wrapper has started
>>>>>> (vm:1901)
>>>>>> 2017-01-06 20:54:12,636 INFO (vm/6dd5291e) [vds] prepared volume
>>>>>> path:
>>>>>> /rhev/data-center/mnt/h2-int.limetransit.com:_var_lib_export
>>>>>> s_iso/1d49c4bc-0fec-4503-a583-d476fa3a370d/images/11111111-1
>>>>>> 111-1111-1111-111111111111/CentOS-7-x86_64-NetInstall-1611.iso
>>>>>> (clientIF:374)
>>>>>> 2017-01-06 20:54:12,743 INFO (vm/6dd5291e) [root] (hooks:108)
>>>>>> 2017-01-06 20:54:12,847 INFO (vm/6dd5291e) [root] (hooks:108)
>>>>>> 2017-01-06 20:54:12,863 INFO (vm/6dd5291e) [virt.vm]
>>>>>> (vmId='6dd5291e-6556-4d29-8b4e-ea896e627645') <?xml version='1.0'
>>>>>> encoding='UTF-8'?>
>>>>>> <domain xmlns:ovirt="http://ovirt.org/vm/tune/1.0" type="kvm">
>>>>>> <name>CentOS7_3</name>
>>>>>> <uuid>6dd5291e-6556-4d29-8b4e-ea896e627645</uuid>
>>>>>> <memory>1048576</memory>
>>>>>> <currentMemory>1048576</currentMemory>
>>>>>> <maxMemory slots="16">4294967296</maxMemory>
>>>>>> <vcpu current="1">16</vcpu>
>>>>>> <devices>
>>>>>> <channel type="unix">
>>>>>> <target name="com.redhat.rhevm.vdsm" type="virtio" />
>>>>>> <source mode="bind"
>>>>>> path="/var/lib/libvirt/qemu/channels/6dd5291e-6556-4d29-8b4e
>>>>>> -ea896e627645.com.redhat.rhevm.vdsm"
>>>>>> />
>>>>>> </channel>
>>>>>> <channel type="unix">
>>>>>> <target name="org.qemu.guest_agent.0" type="virtio" />
>>>>>> <source mode="bind"
>>>>>> path="/var/lib/libvirt/qemu/channels/6dd5291e-6556-4d29-8b4e
>>>>>> -ea896e627645.org.qemu.guest_agent.0"
>>>>>> />
>>>>>> </channel>
>>>>>> <input bus="ps2" type="mouse" />
>>>>>> <memballoon model="virtio" />
>>>>>> <controller index="0" model="virtio-scsi" type="scsi" />
>>>>>> <controller index="0" ports="16" type="virtio-serial" />
>>>>>> <video>
>>>>>> <model heads="1" ram="65536" type="qxl" vgamem="16384"
>>>>>> vram="32768" />
>>>>>> </video>
>>>>>> <graphics autoport="yes" defaultMode="secure" passwd="*****"
>>>>>> passwdValidTo="1970-01-01T00:00:01" port="-1" tlsPort="-1"
>>>>>> type="spice">
>>>>>> <channel mode="secure" name="main" />
>>>>>> <channel mode="secure" name="inputs" />
>>>>>> <channel mode="secure" name="cursor" />
>>>>>> <channel mode="secure" name="playback" />
>>>>>> <channel mode="secure" name="record" />
>>>>>> <channel mode="secure" name="display" />
>>>>>> <channel mode="secure" name="smartcard" />
>>>>>> <channel mode="secure" name="usbredir" />
>>>>>> <listen network="vdsm-ovirtmgmt" type="network" />
>>>>>> </graphics>
>>>>>> <interface type="bridge">
>>>>>> <mac address="00:1a:4a:16:01:54" />
>>>>>> <model type="virtio" />
>>>>>> <source bridge="br-int" />
>>>>>> <virtualport type="openvswitch" />
>>>>>> <link state="up" />
>>>>>> <boot order="2" />
>>>>>> <bandwidth />
>>>>>> <virtualport type="openvswitch">
>>>>>> <parameters
>>>>>> interfaceid="912cba79-982e-4a87-868e-241fedccb59a" />
>>>>>> </virtualport>
>>>>>> </interface>
>>>>>> <disk device="cdrom" snapshot="no" type="file">
>>>>>> <source
>>>>>> file="/rhev/data-center/mnt/h2-int.limetransit.com:_var_lib_
>>>>>> exports_iso/1d49c4bc-0fec-4503-a583-d476fa3a370d/images/1111
>>>>>> 1111-1111-1111-1111-111111111111/CentOS-7-x86_64-NetInstall-1611.iso"
>>>>>> startupPolicy="optional" />
>>>>>> <target bus="ide" dev="hdc" />
>>>>>> <readonly />
>>>>>> <boot order="1" />
>>>>>> </disk>
>>>>>> <channel type="spicevmc">
>>>>>> <target name="com.redhat.spice.0" type="virtio" />
>>>>>> </channel>
>>>>>> </devices>
>>>>>> <metadata>
>>>>>> <ovirt:qos />
>>>>>> </metadata>
>>>>>> <os>
>>>>>> <type arch="x86_64" machine="pc-i440fx-rhel7.2.0">hvm</type>
>>>>>> <smbios mode="sysinfo" />
>>>>>> <bootmenu enable="yes" timeout="10000" />
>>>>>> </os>
>>>>>> <sysinfo type="smbios">
>>>>>> <system>
>>>>>> <entry name="manufacturer">oVirt</entry>
>>>>>> <entry name="product">oVirt Node</entry>
>>>>>> <entry name="version">7-3.1611.el7.centos</entry>
>>>>>> <entry
>>>>>> name="serial">62f1adff-b29e-4a7c-abba-c2c4c73248c6</entry>
>>>>>> <entry
>>>>>> name="uuid">6dd5291e-6556-4d29-8b4e-ea896e627645</entry>
>>>>>> </system>
>>>>>> </sysinfo>
>>>>>> <clock adjustment="0" offset="variable">
>>>>>> <timer name="rtc" tickpolicy="catchup" />
>>>>>> <timer name="pit" tickpolicy="delay" />
>>>>>> <timer name="hpet" present="no" />
>>>>>> </clock>
>>>>>> <features>
>>>>>> <acpi />
>>>>>> </features>
>>>>>> <cpu match="exact">
>>>>>> <model>SandyBridge</model>
>>>>>> <topology cores="1" sockets="16" threads="1" />
>>>>>> <numa>
>>>>>> <cell cpus="0" memory="1048576" />
>>>>>> </numa>
>>>>>> </cpu>
>>>>>> </domain>
>>>>>> (vm:1988)
>>>>>> 2017-01-06 20:54:13,046 INFO (libvirt/events) [virt.vm]
>>>>>> (vmId='6dd5291e-6556-4d29-8b4e-ea896e627645') CPU running: onResume
>>>>>> (vm:4863)
>>>>>> 2017-01-06 20:54:13,058 INFO (vm/6dd5291e) [virt.vm]
>>>>>> (vmId='6dd5291e-6556-4d29-8b4e-ea896e627645') Starting connection
>>>>>> (guestagent:245)
>>>>>> 2017-01-06 20:54:13,060 INFO (vm/6dd5291e) [virt.vm]
>>>>>> (vmId='6dd5291e-6556-4d29-8b4e-ea896e627645') CPU running: domain
>>>>>> initialization (vm:4863)
>>>>>> 2017-01-06 20:54:15,154 INFO (jsonrpc/6) [jsonrpc.JsonRpcServer] RPC
>>>>>> call Host.getVMFullList succeeded in 0.01 seconds (__init__:515)
>>>>>> 2017-01-06 20:54:17,571 INFO (periodic/2) [dispatcher] Run and
>>>>>> protect: getVolumeSize(sdUUID=u'2ee54fb8-48f2-4576-8cff-f2346504b08b'
>>>>>> ,
>>>>>> spUUID=u'584ebd64-0268-0193-025b-00000000038e',
>>>>>> imgUUID=u'5a3aae57-ffe0-4a3b-aa87-8461669db7f9',
>>>>>> volUUID=u'b6a88789-fcb1-4d3e-911b-2a4d3b6c69c7', options=None)
>>>>>> (logUtils:49)
>>>>>> 2017-01-06 20:54:17,573 INFO (periodic/2) [dispatcher] Run and
>>>>>> protect: getVolumeSize, Return response: {'truesize': '1859723264',
>>>>>> 'apparentsize': '21474836480'} (logUtils:52)
>>>>>> 2017-01-06 20:54:21,211 INFO (periodic/2) [dispatcher] Run and
>>>>>> protect: repoStats(options=None) (logUtils:49)
>>>>>> 2017-01-06 20:54:21,212 INFO (periodic/2) [dispatcher] Run and
>>>>>> protect: repoStats, Return response:
>>>>>> {u'2ee54fb8-48f2-4576-8cff-f2346504b08b': {'code': 0, 'actual': True,
>>>>>> 'version': 3, 'acquired': True, 'delay': '0.000936552', 'lastCheck':
>>>>>> '1.4', 'valid': True}, u'1d49c4bc-0fec-4503-a583-d476fa3a370d':
>>>>>> {'code': 0, 'actual': True, 'version': 0, 'acquired': True, 'delay':
>>>>>> '0.000960248', 'lastCheck': '1.4', 'valid': True}} (logUtils:52)
>>>>>> 2017-01-06 20:54:23,543 INFO (jsonrpc/2) [jsonrpc.JsonRpcServer] RPC
>>>>>> call Host.getAllVmStats succeeded in 0.00 seconds (__init__:515)
>>>>>> 2017-01-06 20:54:23,641 INFO (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC
>>>>>> call Host.getAllVmIoTunePolicies succeeded in 0.00 seconds
>>>>>> (__init__:515)
>>>>>> 2017-01-06 20:54:24,918 INFO (jsonrpc/0) [dispatcher] Run and
>>>>>> protect: repoStats(options=None) (logUtils:49)
>>>>>> 2017-01-06 20:54:24,918 INFO (jsonrpc/0) [dispatcher] Run and
>>>>>> protect: repoStats, Return response:
>>>>>> {u'2ee54fb8-48f2-4576-8cff-f2346504b08b': {'code': 0, 'actual': True,
>>>>>> 'version': 3, 'acquired': True, 'delay': '0.000936552', 'lastCheck':
>>>>>> '5.1', 'valid': True}, u'1d49c4bc-0fec-4503-a583-d476fa3a370d':
>>>>>> {'code': 0, 'actual': True, 'version': 0, 'acquired': True, 'delay':
>>>>>> '0.000960248', 'lastCheck': '2.1', 'valid': True}} (logUtils:52)
>>>>>> 2017-01-06 20:54:24,924 INFO (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC
>>>>>> call Host.getStats succeeded in 0.01 seconds (__init__:515)
>>>>>>
>>>>>> Vdsm and the OVN driver must have been called as the port IS created,
>>>>>> but with the wrong id. I don't find the faulty id in vdsm.log neither,
>>>>>> the xml above have the correct id.
>>>>>> /Sverker
>>>>>>
>>>>>> Den 2017-01-09 kl. 10:06, skrev Marcin Mirecki:
>>>>>>
>>>>>>> The port is set up on the host by the ovirt-provider-ovn-driver.
>>>>>>> The driver is invoked by the vdsm hook whenever any operation on
>>>>>>> the port is done.
>>>>>>> Please ensure that this is installed properly.
>>>>>>> You can check the vdsm log (/var/log/vdsm/vdsm.log) to see if the
>>>>>>> hook was executed properly.
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>
>>>>>>>> From: "Sverker Abrahamsson" <sverker at abrahamsson.com>
>>>>>>>> To: "Marcin Mirecki" <mmirecki at redhat.com>
>>>>>>>> Cc: "Ovirt Users" <users at ovirt.org>
>>>>>>>> Sent: Friday, January 6, 2017 9:00:26 PM
>>>>>>>> Subject: Re: [ovirt-users] Issue with OVN/OVS and mandatory
>>>>>>>> ovirtmgmt network
>>>>>>>>
>>>>>>>> I created a new VM in the ui and assigned it to host h1. In
>>>>>>>> /var/log/ovirt-provider-ovn.log I get the following:
>>>>>>>>
>>>>>>>> 2017-01-06 20:54:11,940 Request: GET : /v2.0/ports
>>>>>>>> 2017-01-06 20:54:11,940 Connecting to remote ovn database:
>>>>>>>> tcp:127.0.0.1:6641
>>>>>>>> 2017-01-06 20:54:12,157 Connected (number of retries: 2)
>>>>>>>> 2017-01-06 20:54:12,158 Response code: 200
>>>>>>>> 2017-01-06 20:54:12,158 Response body: {"ports": [{"name":
>>>>>>>> "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873", "network_id":
>>>>>>>> "e53554cf-e553-40a1-8d22-9c8d95ec0601", "device_owner": "oVirt",
>>>>>>>> "mac_address": "00:1a:4a:16:01:51", "id":
>>>>>>>> "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873", "device_id":
>>>>>>>> "40cd7328-d575-4c3d-b656-9ef9bacc0078"}, {"name":
>>>>>>>> "92f6d3c8-68b3-4986-9c09-60bee04644b5", "network_id":
>>>>>>>> "e53554cf-e553-40a1-8d22-9c8d95ec0601", "device_owner": "oVirt",
>>>>>>>> "mac_address": "00:1a:4a:16:01:52", "id":
>>>>>>>> "92f6d3c8-68b3-4986-9c09-60bee04644b5", "device_id":
>>>>>>>> "4baefa8c-3822-4de0-9cd0-1d025bab7844"}]}
>>>>>>>> 2017-01-06 20:54:12,160 Request: SHOW :
>>>>>>>> /v2.0/networks/e53554cf-e553-40a1-8d22-9c8d95ec0601
>>>>>>>> 2017-01-06 20:54:12,160 Connecting to remote ovn database:
>>>>>>>> tcp:127.0.0.1:6641
>>>>>>>> 2017-01-06 20:54:12,377 Connected (number of retries: 2)
>>>>>>>> 2017-01-06 20:54:12,378 Response code: 200
>>>>>>>> 2017-01-06 20:54:12,378 Response body: {"network": {"id":
>>>>>>>> "e53554cf-e553-40a1-8d22-9c8d95ec0601", "name": "ovirtbridge"}}
>>>>>>>> 2017-01-06 20:54:12,380 Request: POST : /v2.0/ports
>>>>>>>> 2017-01-06 20:54:12,380 Request body:
>>>>>>>> {
>>>>>>>> "port" : {
>>>>>>>> "name" : "nic1",
>>>>>>>> "binding:host_id" : "h1.limetransit.com",
>>>>>>>> "admin_state_up" : true,
>>>>>>>> "device_id" : "e8553a88-05f0-401d-8b9b-5fff77f7bbbe",
>>>>>>>> "device_owner" : "oVirt",
>>>>>>>> "mac_address" : "00:1a:4a:16:01:54",
>>>>>>>> "network_id" : "e53554cf-e553-40a1-8d22-9c8d95ec0601"
>>>>>>>> }
>>>>>>>> }
>>>>>>>> 2017-01-06 20:54:12,380 Connecting to remote ovn database:
>>>>>>>> tcp:127.0.0.1:6641
>>>>>>>> 2017-01-06 20:54:12,610 Connected (number of retries: 2)
>>>>>>>> 2017-01-06 20:54:12,614 Response code: 200
>>>>>>>> 2017-01-06 20:54:12,614 Response body: {"port": {"name":
>>>>>>>> "912cba79-982e-4a87-868e-241fedccb59a", "network_id":
>>>>>>>> "e53554cf-e553-40a1-8d22-9c8d95ec0601", "device_owner": "oVirt",
>>>>>>>> "mac_address": "00:1a:4a:16:01:54", "id":
>>>>>>>> "912cba79-982e-4a87-868e-241fedccb59a", "device_id":
>>>>>>>> "e8553a88-05f0-401d-8b9b-5fff77f7bbbe"}}
>>>>>>>>
>>>>>>>> h1:/var/log/messages
>>>>>>>> Jan 6 20:54:12 h1 ovs-vsctl: ovs|00001|vsctl|INFO|Called as
>>>>>>>> ovs-vsctl
>>>>>>>> --timeout=5 -- --if-exists del-port vnet1 -- add-port br-int vnet1
>>>>>>>> --
>>>>>>>> set Interface vnet1
>>>>>>>> "external-ids:attached-mac=\"00:1a:4a:16:01:54\"" --
>>>>>>>> set Interface vnet1
>>>>>>>> "external-ids:iface-id=\"20388407-0f76-41d8-97aa-8e2b5978f908\""
>>>>>>>> -- set
>>>>>>>> Interface vnet1
>>>>>>>> "external-ids:vm-id=\"6dd5291e-6556-4d29-8b4e-ea896e627645\"" --
>>>>>>>> set
>>>>>>>> Interface vnet1 external-ids:iface-status=active
>>>>>>>>
>>>>>>>> [root at h2 ~]# ovn-nbctl show
>>>>>>>> switch e53554cf-e553-40a1-8d22-9c8d95ec0601 (ovirtbridge)
>>>>>>>> port 4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873
>>>>>>>> addresses: ["00:1a:4a:16:01:51"]
>>>>>>>> port 912cba79-982e-4a87-868e-241fedccb59a
>>>>>>>> addresses: ["00:1a:4a:16:01:54"]
>>>>>>>> port 92f6d3c8-68b3-4986-9c09-60bee04644b5
>>>>>>>> addresses: ["00:1a:4a:16:01:52"]
>>>>>>>> port ovirtbridge-port2
>>>>>>>> addresses: ["unknown"]
>>>>>>>> port ovirtbridge-port1
>>>>>>>> addresses: ["unknown"]
>>>>>>>> [root at h2 ~]# ovn-sbctl show
>>>>>>>> Chassis "6e4dd29f-7607-48d7-8e5a-eef4c6aeefb5"
>>>>>>>> hostname: "h2.limetransit.com"
>>>>>>>> Encap geneve
>>>>>>>> ip: "148.251.126.50"
>>>>>>>> options: {csum="true"}
>>>>>>>> Port_Binding "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873"
>>>>>>>> Port_Binding "ovirtbridge-port1"
>>>>>>>> Chassis "4f10fb04-8fb2-48d7-8a3f-ea6444c02cf9"
>>>>>>>> hostname: "h1.limetransit.com"
>>>>>>>> Encap geneve
>>>>>>>> ip: "144.76.84.73"
>>>>>>>> options: {csum="true"}
>>>>>>>> Port_Binding "ovirtbridge-port2"
>>>>>>>> Port_Binding "92f6d3c8-68b3-4986-9c09-60bee04644b5"
>>>>>>>>
>>>>>>>> I.e. same issue
>>>>>>>> /Sverker
>>>>>>>>
>>>>>>>> Den 2017-01-06 kl. 20:49, skrev Sverker Abrahamsson:
>>>>>>>>
>>>>>>>>> The port is created from Ovirt UI, the ovs-vsctl command below is
>>>>>>>>> executed when VM is started. In /var/log/ovirt-provider-ovn.log
>>>>>>>>> on h2
>>>>>>>>> I get the following:
>>>>>>>>>
>>>>>>>>> 2017-01-06 20:19:25,452 Request: GET : /v2.0/ports
>>>>>>>>> 2017-01-06 20:19:25,452 Connecting to remote ovn database:
>>>>>>>>> tcp:127.0.0.1:6641
>>>>>>>>> 2017-01-06 20:19:25,670 Connected (number of retries: 2)
>>>>>>>>> 2017-01-06 20:19:25,670 Response code: 200
>>>>>>>>> 2017-01-06 20:19:25,670 Response body: {"ports": [{"name":
>>>>>>>>> "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873", "network_id":
>>>>>>>>> "e53554cf-e553-40a1-8d22-9c8d95ec0601", "device_owner": "oVirt",
>>>>>>>>> "mac_address": "00:1a:4a:16:01:51", "id":
>>>>>>>>> "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873", "device_id":
>>>>>>>>> "40cd7328-d575-4c3d-b656-9ef9bacc0078"}, {"name":
>>>>>>>>> "92f6d3c8-68b3-4986-9c09-60bee04644b5", "network_id":
>>>>>>>>> "e53554cf-e553-40a1-8d22-9c8d95ec0601", "device_owner": "oVirt",
>>>>>>>>> "mac_address": "00:1a:4a:16:01:52", "id":
>>>>>>>>> "92f6d3c8-68b3-4986-9c09-60bee04644b5", "device_id":
>>>>>>>>> "4baefa8c-3822-4de0-9cd0-1d025bab7844"}]}
>>>>>>>>> 2017-01-06 20:19:25,673 Request: PUT :
>>>>>>>>> /v2.0/ports/92f6d3c8-68b3-4986-9c09-60bee04644b5
>>>>>>>>> 2017-01-06 20:19:25,673 Request body:
>>>>>>>>> {
>>>>>>>>> "port" : {
>>>>>>>>> "binding:host_id" : "h1.limetransit.com",
>>>>>>>>> "security_groups" : null
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> 2017-01-06 20:19:25,673 Connecting to remote ovn database:
>>>>>>>>> tcp:127.0.0.1:6641
>>>>>>>>> 2017-01-06 20:19:25,890 Connected (number of retries: 2)
>>>>>>>>> 2017-01-06 20:19:25,891 Response code: 200
>>>>>>>>> 2017-01-06 20:19:25,891 Response body: {"port": {"name":
>>>>>>>>> "92f6d3c8-68b3-4986-9c09-60bee04644b5", "network_id":
>>>>>>>>> "e53554cf-e553-40a1-8d22-9c8d95ec0601", "device_owner": "oVirt",
>>>>>>>>> "mac_address": "00:1a:4a:16:01:52", "id":
>>>>>>>>> "92f6d3c8-68b3-4986-9c09-60bee04644b5", "device_id":
>>>>>>>>> "4baefa8c-3822-4de0-9cd0-1d025bab7844"}}
>>>>>>>>>
>>>>>>>>> In /var/log/messages on h1 I get the following:
>>>>>>>>>
>>>>>>>>> Jan 6 20:18:56 h1 dbus-daemon: dbus[1339]: [system] Successfully
>>>>>>>>> activated service 'org.freedesktop.problems'
>>>>>>>>> Jan 6 20:19:26 h1 ovs-vsctl: ovs|00001|vsctl|INFO|Called as
>>>>>>>>> ovs-vsctl
>>>>>>>>> --timeout=5 -- --if-exists del-port vnet0 -- add-port br-int vnet0
>>>>>>>>> --
>>>>>>>>> set Interface vnet0 "external-ids:attached-mac=\"0
>>>>>>>>> 0:1a:4a:16:01:52\""
>>>>>>>>> -- set Interface vnet0
>>>>>>>>> "external-ids:iface-id=\"72dafda5-03c2-4bb6-bcb6-241fa5c0a1f3\""
>>>>>>>>> --
>>>>>>>>> set Interface vnet0
>>>>>>>>> "external-ids:vm-id=\"4d0c134a-11a0-40f4-b2fb-c13c17c7251c\"" --
>>>>>>>>> set
>>>>>>>>> Interface vnet0 external-ids:iface-status=active
>>>>>>>>> Jan 6 20:19:26 h1 kernel: device vnet0 entered promiscuous mode
>>>>>>>>> Jan 6 20:19:26 h1 avahi-daemon[1391]: Registering new address
>>>>>>>>> record
>>>>>>>>> for fe80::fc1a:4aff:fe16:152 on vnet0.*.
>>>>>>>>> Jan 6 20:19:26 h1 systemd-machined: New machine qemu-4-CentOS72.
>>>>>>>>> Jan 6 20:19:26 h1 systemd: Started Virtual Machine
>>>>>>>>> qemu-4-CentOS72.
>>>>>>>>> Jan 6 20:19:26 h1 systemd: Starting Virtual Machine
>>>>>>>>> qemu-4-CentOS72.
>>>>>>>>>
>>>>>>>>> [root at h2 ~]# ovn-nbctl show
>>>>>>>>> switch e53554cf-e553-40a1-8d22-9c8d95ec0601 (ovirtbridge)
>>>>>>>>> port 4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873
>>>>>>>>> addresses: ["00:1a:4a:16:01:51"]
>>>>>>>>> port 92f6d3c8-68b3-4986-9c09-60bee04644b5
>>>>>>>>> addresses: ["00:1a:4a:16:01:52"]
>>>>>>>>> port ovirtbridge-port2
>>>>>>>>> addresses: ["unknown"]
>>>>>>>>> port ovirtbridge-port1
>>>>>>>>> addresses: ["unknown"]
>>>>>>>>> [root at h2 ~]# ovn-sbctl show
>>>>>>>>> Chassis "6e4dd29f-7607-48d7-8e5a-eef4c6aeefb5"
>>>>>>>>> hostname: "h2.limetransit.com"
>>>>>>>>> Encap geneve
>>>>>>>>> ip: "148.251.126.50"
>>>>>>>>> options: {csum="true"}
>>>>>>>>> Port_Binding "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873"
>>>>>>>>> Port_Binding "ovirtbridge-port1"
>>>>>>>>> Chassis "4f10fb04-8fb2-48d7-8a3f-ea6444c02cf9"
>>>>>>>>> hostname: "h1.limetransit.com"
>>>>>>>>> Encap geneve
>>>>>>>>> ip: "144.76.84.73"
>>>>>>>>> options: {csum="true"}
>>>>>>>>> Port_Binding "ovirtbridge-port2"
>>>>>>>>>
>>>>>>>>> I.e. the port is set up with the wrong ID and not attached to OVN.
>>>>>>>>>
>>>>>>>>> If I correct external-ids:iface-id like this:
>>>>>>>>> [root at h1 ~]# ovs-vsctl set Interface vnet0
>>>>>>>>> "external-ids:iface-id=\"92f6d3c8-68b3-4986-9c09-60bee04644b5\""
>>>>>>>>>
>>>>>>>>> then sb is correct:
>>>>>>>>> [root at h2 ~]# ovn-sbctl show
>>>>>>>>> Chassis "6e4dd29f-7607-48d7-8e5a-eef4c6aeefb5"
>>>>>>>>> hostname: "h2.limetransit.com"
>>>>>>>>> Encap geneve
>>>>>>>>> ip: "148.251.126.50"
>>>>>>>>> options: {csum="true"}
>>>>>>>>> Port_Binding "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873"
>>>>>>>>> Port_Binding "ovirtbridge-port1"
>>>>>>>>> Chassis "4f10fb04-8fb2-48d7-8a3f-ea6444c02cf9"
>>>>>>>>> hostname: "h1.limetransit.com"
>>>>>>>>> Encap geneve
>>>>>>>>> ip: "144.76.84.73"
>>>>>>>>> options: {csum="true"}
>>>>>>>>> Port_Binding "ovirtbridge-port2"
>>>>>>>>> Port_Binding "92f6d3c8-68b3-4986-9c09-60bee04644b5"
>>>>>>>>>
>>>>>>>>> I don't know from where the ID 72dafda5-03c2-4bb6-bcb6-241fa5
>>>>>>>>> c0a1f3
>>>>>>>>> comes from, doesn't show in any log other than /var/log/messages.
>>>>>>>>>
>>>>>>>>> If I do the same exercise on the same host as engine is running on
>>>>>>>>> then the port for the VM gets the right id and is working from
>>>>>>>>> beginning.
>>>>>>>>> /Sverker
>>>>>>>>>
>>>>>>>>> Den 2017-01-03 kl. 10:23, skrev Marcin Mirecki:
>>>>>>>>>
>>>>>>>>>> How did you create this port?
>>>>>>>>>> From the oVirt engine UI?
>>>>>>>>>> The OVN provider creates the port when you add the port in the
>>>>>>>>>> engine UI,
>>>>>>>>>> it is then plugged into the ovs bridge by the VIF driver.
>>>>>>>>>> Please attach /var/log/ovirt-provider-ovn.log
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>
>>>>>>>>>>> From: "Sverker Abrahamsson"<sverker at abrahamsson.com>
>>>>>>>>>>> To: "Marcin Mirecki"<mmirecki at redhat.com>
>>>>>>>>>>> Cc: "Ovirt Users"<users at ovirt.org>
>>>>>>>>>>> Sent: Tuesday, January 3, 2017 2:06:22 AM
>>>>>>>>>>> Subject: Re: [ovirt-users] Issue with OVN/OVS and mandatory
>>>>>>>>>>> ovirtmgmt
>>>>>>>>>>> network
>>>>>>>>>>>
>>>>>>>>>>> Found an issue with Ovirt - OVN integration.
>>>>>>>>>>>
>>>>>>>>>>> Engine and OVN central db running on host h2. Created VM to run
>>>>>>>>>>> on host
>>>>>>>>>>> h1, which is started. Ovn db state:
>>>>>>>>>>>
>>>>>>>>>>> [root at h2 env3]# ovn-nbctl show
>>>>>>>>>>> switch e53554cf-e553-40a1-8d22-9c8d95ec0601
>>>>>>>>>>> (ovirtbridge)
>>>>>>>>>>> port 4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873
>>>>>>>>>>> addresses: ["00:1a:4a:16:01:51"]
>>>>>>>>>>> port 92f6d3c8-68b3-4986-9c09-60bee04644b5
>>>>>>>>>>> addresses: ["00:1a:4a:16:01:52"]
>>>>>>>>>>> port ovirtbridge-port2
>>>>>>>>>>> addresses: ["unknown"]
>>>>>>>>>>> port ovirtbridge-port1
>>>>>>>>>>> addresses: ["unknown"]
>>>>>>>>>>> [root at h2 env3]# ovn-sbctl show
>>>>>>>>>>> Chassis "6e4dd29f-7607-48d7-8e5a-eef4c6aeefb5"
>>>>>>>>>>> hostname: "h2.limetransit.com"
>>>>>>>>>>> Encap geneve
>>>>>>>>>>> ip: "148.251.126.50"
>>>>>>>>>>> options: {csum="true"}
>>>>>>>>>>> Port_Binding "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873"
>>>>>>>>>>> Port_Binding "ovirtbridge-port1"
>>>>>>>>>>> Chassis "4f10fb04-8fb2-48d7-8a3f-ea6444c02cf9"
>>>>>>>>>>> hostname: "h1.limetransit.com"
>>>>>>>>>>> Encap geneve
>>>>>>>>>>> ip: "144.76.84.73"
>>>>>>>>>>> options: {csum="true"}
>>>>>>>>>>> Port_Binding "ovirtbridge-port2"
>>>>>>>>>>>
>>>>>>>>>>> Port 92f6d3c8-68b3-4986-9c09-60bee04644b5 is for the new VM
>>>>>>>>>>> which is
>>>>>>>>>>> started on h1, but it is not assigned to that chassis. The
>>>>>>>>>>> reason is
>>>>>>>>>>> that on h1 the port on br-int is created like this:
>>>>>>>>>>>
>>>>>>>>>>> ovs-vsctl --timeout=5 -- --if-exists del-port vnet0 -- add-port
>>>>>>>>>>> br-int
>>>>>>>>>>> vnet0 -- set Interface vnet0
>>>>>>>>>>> "external-ids:attached-mac=\"00:1a:4a:16:01:52\"" -- set
>>>>>>>>>>> Interface vnet0
>>>>>>>>>>> "external-ids:iface-id=\"35bcbe31-2c7e-4d97-add9-ce150eeb2f11\""
>>>>>>>>>>> -- set
>>>>>>>>>>> Interface vnet0
>>>>>>>>>>> "external-ids:vm-id=\"4d0c134a-11a0-40f4-b2fb-c13c17c7251c\""
>>>>>>>>>>> -- set
>>>>>>>>>>> Interface vnet0 external-ids:iface-status=active
>>>>>>>>>>>
>>>>>>>>>>> I.e. the extrernal id of interface is wrong. When I manually
>>>>>>>>>>> change to
>>>>>>>>>>> the right id like this the port works fine:
>>>>>>>>>>>
>>>>>>>>>>> ovs-vsctl --timeout=5 -- --if-exists del-port vnet0 -- add-port
>>>>>>>>>>> br-int
>>>>>>>>>>> vnet0 -- set Interface vnet0
>>>>>>>>>>> "external-ids:attached-mac=\"00:1a:4a:16:01:52\"" -- set
>>>>>>>>>>> Interface vnet0
>>>>>>>>>>> "external-ids:iface-id=\"92f6d3c8-68b3-4986-9c09-60bee04644b5\""
>>>>>>>>>>> -- set
>>>>>>>>>>> Interface vnet0
>>>>>>>>>>> "external-ids:vm-id=\"4d0c134a-11a0-40f4-b2fb-c13c17c7251c\""
>>>>>>>>>>> -- set
>>>>>>>>>>> Interface vnet0 external-ids:iface-status=active
>>>>>>>>>>>
>>>>>>>>>>> sb db after correcting the port:
>>>>>>>>>>>
>>>>>>>>>>> Chassis "6e4dd29f-7607-48d7-8e5a-eef4c6aeefb5"
>>>>>>>>>>> hostname: "h2.limetransit.com"
>>>>>>>>>>> Encap geneve
>>>>>>>>>>> ip: "148.251.126.50"
>>>>>>>>>>> options: {csum="true"}
>>>>>>>>>>> Port_Binding "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873"
>>>>>>>>>>> Port_Binding "ovirtbridge-port1"
>>>>>>>>>>> Chassis "4f10fb04-8fb2-48d7-8a3f-ea6444c02cf9"
>>>>>>>>>>> hostname: "h1.limetransit.com"
>>>>>>>>>>> Encap geneve
>>>>>>>>>>> ip: "144.76.84.73"
>>>>>>>>>>> options: {csum="true"}
>>>>>>>>>>> Port_Binding "ovirtbridge-port2"
>>>>>>>>>>> Port_Binding "92f6d3c8-68b3-4986-9c09-60bee04644b5"
>>>>>>>>>>>
>>>>>>>>>>> I don't know from where the faulty id comes from, it's not in any
>>>>>>>>>>> logs.
>>>>>>>>>>> In the domain xml as printed in vdsm.log the id is correct:
>>>>>>>>>>>
>>>>>>>>>>> <interface type="bridge">
>>>>>>>>>>> <mac address="00:1a:4a:16:01:52" />
>>>>>>>>>>> <model type="virtio" />
>>>>>>>>>>> <source bridge="br-int" />
>>>>>>>>>>> <virtualport type="openvswitch" />
>>>>>>>>>>> <link state="up" />
>>>>>>>>>>> <boot order="2" />
>>>>>>>>>>> <bandwidth />
>>>>>>>>>>> <virtualport type="openvswitch">
>>>>>>>>>>> <parameters
>>>>>>>>>>> interfaceid="92f6d3c8-68b3-4986-9c09-60bee04644b5" />
>>>>>>>>>>> </virtualport>
>>>>>>>>>>> </interface>
>>>>>>>>>>>
>>>>>>>>>>> Where is the ovs-vsctl command line built for this call?
>>>>>>>>>>>
>>>>>>>>>>> /Sverker
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Den 2017-01-02 kl. 13:40, skrev Sverker Abrahamsson:
>>>>>>>>>>>
>>>>>>>>>>>> Got it to work now by following the env8 example in OVN
>>>>>>>>>>>> tutorial,
>>>>>>>>>>>> where a port is added with type l2gateway. Not sure how that is
>>>>>>>>>>>> different from the localnet variant, but didn't suceed in
>>>>>>>>>>>> getting that
>>>>>>>>>>>> one working. Now I'm able to ping and telnet over the tunnel,
>>>>>>>>>>>> but not
>>>>>>>>>>>> ssh even when the port is answering on telnet. Neither does nfs
>>>>>>>>>>>> traffic work even though mount did. Suspecting MTU issue. I did
>>>>>>>>>>>> notice
>>>>>>>>>>>> that ovn-controller starts too early, before network interfaces
>>>>>>>>>>>> are
>>>>>>>>>>>> established and hence can't reach the db. As these is a purely
>>>>>>>>>>>> OVS/OVN
>>>>>>>>>>>> issue I'll ask about it on their mailing list.
>>>>>>>>>>>>
>>>>>>>>>>>> Getting back to the original issue with Ovirt, I've now added
>>>>>>>>>>>> the
>>>>>>>>>>>> second host h1 to ovirt-engine. Had to do the same as with h2 to
>>>>>>>>>>>> create a dummy ovirtmgmt network but configured access via the
>>>>>>>>>>>> public
>>>>>>>>>>>> IP. My firewall settings was replaced with iptables config and
>>>>>>>>>>>> vdsm.conf was overwritten when engine was set up, so those had
>>>>>>>>>>>> to be
>>>>>>>>>>>> manually restored. It would be preferable if it would be
>>>>>>>>>>>> possible to
>>>>>>>>>>>> configure ovirt-engine that it does not "own" the host and
>>>>>>>>>>>> instead
>>>>>>>>>>>> comply with the settings it has instead of enforcing it's own
>>>>>>>>>>>> view..
>>>>>>>>>>>>
>>>>>>>>>>>> Apart from that it seems the second host works, although I need
>>>>>>>>>>>> to
>>>>>>>>>>>> resolve the traffic issue over the OVS tunnel.
>>>>>>>>>>>> /Sverker
>>>>>>>>>>>>
>>>>>>>>>>>> Den 2017-01-02 kl. 01:13, skrev Sverker Abrahamsson:
>>>>>>>>>>>>
>>>>>>>>>>>>> 1. That is not possible as ovirt (or vdsm) will rewrite the
>>>>>>>>>>>>> network
>>>>>>>>>>>>> configuration to a non-working state. That is why I've set that
>>>>>>>>>>>>> if as
>>>>>>>>>>>>> hidden to vdsm and is why I'm keen on getting OVS/OVN to work
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. I've been reading the doc for OVN and starting to connect
>>>>>>>>>>>>> the
>>>>>>>>>>>>> dots, which is not trivial as it is complex. Some insights
>>>>>>>>>>>>> reached:
>>>>>>>>>>>>>
>>>>>>>>>>>>> First step is the OVN database, installed by
>>>>>>>>>>>>> openvswitch-ovn-central,
>>>>>>>>>>>>> which I currently have running on h2 host. The 'ovn-nbctl' and
>>>>>>>>>>>>> 'ovn-sbctl' commands are only possible to execute on a database
>>>>>>>>>>>>> node.
>>>>>>>>>>>>> Two ip's are given to 'vdsm-tool ovn-config <ip to database>
>>>>>>>>>>>>> <tunnel
>>>>>>>>>>>>> ip>' as arguments, where <ip to database> is how this OVN node
>>>>>>>>>>>>> reaches the database and <tunnel ip> is the ip to which other
>>>>>>>>>>>>> OVN
>>>>>>>>>>>>> nodes sets up a tunnel to this node. I.e. it is not for
>>>>>>>>>>>>> creating a
>>>>>>>>>>>>> tunnel to the database which I thought first from the
>>>>>>>>>>>>> description in
>>>>>>>>>>>>> blog post.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The tunnel between OVN nodes is of type geneve which is a UDP
>>>>>>>>>>>>> based
>>>>>>>>>>>>> protocol but I have not been able to find anywhere which port
>>>>>>>>>>>>> is used
>>>>>>>>>>>>> so that I can open it in firewalld. I have added OVN on another
>>>>>>>>>>>>> host,
>>>>>>>>>>>>> called h1, and connected it to the db. I see there is traffic
>>>>>>>>>>>>> to the
>>>>>>>>>>>>> db port, but I don't see any geneve traffic between the nodes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ovirt is now able to create it's vnet0 interface on the br-int
>>>>>>>>>>>>> ovs
>>>>>>>>>>>>> bridge, but then I run into the next issue. How do I create a
>>>>>>>>>>>>> connection from the logical switch to the physical host? I need
>>>>>>>>>>>>> that
>>>>>>>>>>>>> to a) get a connection out to the internet through a
>>>>>>>>>>>>> masqueraded if
>>>>>>>>>>>>> or ipv6 and b) be able to run a dhcp server to give ip's to the
>>>>>>>>>>>>> VM's.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Sverker
>>>>>>>>>>>>>
>>>>>>>>>>>>> Den 2016-12-30 kl. 18:05, skrev Marcin Mirecki:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Why not use your physical nic for ovirtmgmt then?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. "ovn-nbctl ls-add" does not add a bridge, but a logical
>>>>>>>>>>>>>> switch.
>>>>>>>>>>>>>> br-int is an internal OVN implementation detail, which
>>>>>>>>>>>>>> the user
>>>>>>>>>>>>>> should not care about. What you see in the ovirt UI are
>>>>>>>>>>>>>> logical
>>>>>>>>>>>>>> networks. They are implemented as OVN logical switches
>>>>>>>>>>>>>> in case
>>>>>>>>>>>>>> of the OVN provider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please look at:
>>>>>>>>>>>>>> http://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/
>>>>>>>>>>>>>> You can get the latest rpms from here:
>>>>>>>>>>>>>> http://resources.ovirt.org/repos/ovirt/experimental/master/o
>>>>>>>>>>>>>> virt-provider-ovn_fc24_46/rpm/fc24/noarch/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> From: "Sverker Abrahamsson"<sverker at abrahamsson.com>
>>>>>>>>>>>>>>> To: "Marcin Mirecki"<mmirecki at redhat.com>
>>>>>>>>>>>>>>> Cc: "Ovirt Users"<users at ovirt.org>
>>>>>>>>>>>>>>> Sent: Friday, December 30, 2016 4:25:58 PM
>>>>>>>>>>>>>>> Subject: Re: [ovirt-users] Issue with OVN/OVS and mandatory
>>>>>>>>>>>>>>> ovirtmgmt network
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. No, I did not want to put the ovirtmgmt bridge on my
>>>>>>>>>>>>>>> physical
>>>>>>>>>>>>>>> nic as
>>>>>>>>>>>>>>> it always messed up the network config making the host
>>>>>>>>>>>>>>> unreachable. I
>>>>>>>>>>>>>>> have put a ovs bridge on this nic which I will use to make
>>>>>>>>>>>>>>> tunnels
>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>> I add other hosts. Maybe br-int will be used for that
>>>>>>>>>>>>>>> instead, will
>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>> when I get that far.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As it is now I have a dummy if for ovirtmgmt bridge but this
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> probably not work when I add other hosts as that bridge
>>>>>>>>>>>>>>> cannot
>>>>>>>>>>>>>>> connect
>>>>>>>>>>>>>>> to the other hosts. I'm considering keeping this just as a
>>>>>>>>>>>>>>> dummy to
>>>>>>>>>>>>>>> keep
>>>>>>>>>>>>>>> ovirt engine satisfied while the actual communication will
>>>>>>>>>>>>>>> happen
>>>>>>>>>>>>>>> over
>>>>>>>>>>>>>>> OVN/OVS bridges and tunnels.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2. On
>>>>>>>>>>>>>>> https://www.ovirt.org//develop/release-management/features/o
>>>>>>>>>>>>>>> virt-ovn-provider/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> there is instructions how to add an OVS bridge to OVN with
>>>>>>>>>>>>>>> |ovn-nbctl
>>>>>>>>>>>>>>> ls-add <network name>|. If you want to use br-int then it
>>>>>>>>>>>>>>> makes
>>>>>>>>>>>>>>> sense to
>>>>>>>>>>>>>>> make that bridge visible in ovirt webui under networks so
>>>>>>>>>>>>>>> that it
>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>> selected for VM's.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It quite doesn't make sense to me that I can select other
>>>>>>>>>>>>>>> network
>>>>>>>>>>>>>>> for my
>>>>>>>>>>>>>>> VM but then that setting is not used when setting up the
>>>>>>>>>>>>>>> network.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Sverker
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Den 2016-12-30 kl. 15:34, skrev Marcin Mirecki:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The OVN provider does not require you to add any bridges
>>>>>>>>>>>>>>>> manually.
>>>>>>>>>>>>>>>> As I understand we were dealing with two problems:
>>>>>>>>>>>>>>>> 1. You only had one physical nic and wanted to put a bridge
>>>>>>>>>>>>>>>> on it,
>>>>>>>>>>>>>>>> attaching the management network to the bridge. This
>>>>>>>>>>>>>>>> was the
>>>>>>>>>>>>>>>> reason for
>>>>>>>>>>>>>>>> creating the bridge (the recommended setup would be
>>>>>>>>>>>>>>>> to used a
>>>>>>>>>>>>>>>> separate
>>>>>>>>>>>>>>>> physical nic for the management network). This
>>>>>>>>>>>>>>>> bridge
>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>> nothing to
>>>>>>>>>>>>>>>> do with the OVN bridge.
>>>>>>>>>>>>>>>> 2. OVN - you want to use OVN on this system. For this you
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> install
>>>>>>>>>>>>>>>> OVN on your hosts. This should create the br-int
>>>>>>>>>>>>>>>> bridge,
>>>>>>>>>>>>>>>> which are
>>>>>>>>>>>>>>>> then used by the OVN provider. This br-int bridge
>>>>>>>>>>>>>>>> must be
>>>>>>>>>>>>>>>> configured
>>>>>>>>>>>>>>>> to connect to other hosts using the geneve tunnels.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In both cases the systems will not be aware of any bridges
>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>> create.
>>>>>>>>>>>>>>>> They need a nic (be it physical or virtual) to connect to
>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>> system.
>>>>>>>>>>>>>>>> Usually this is the physical nic. In your case you decided
>>>>>>>>>>>>>>>> to put
>>>>>>>>>>>>>>>> a bridge
>>>>>>>>>>>>>>>> on the physical nic, and give oVirt a virtual nic attached
>>>>>>>>>>>>>>>> to this
>>>>>>>>>>>>>>>> bridge.
>>>>>>>>>>>>>>>> This works, but keep in mind that the bridge you have
>>>>>>>>>>>>>>>> introduced
>>>>>>>>>>>>>>>> is outside
>>>>>>>>>>>>>>>> of oVirt's (and OVN) control (and as such is not supported).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What is the purpose of
>>>>>>>>>>>>>>>>> adding my bridges to Ovirt through the external provider
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> configure
>>>>>>>>>>>>>>>>> them on my VM
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am not quite sure I understand.
>>>>>>>>>>>>>>>> The external provider (OVN provider to be specific), does
>>>>>>>>>>>>>>>> not add
>>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>> bridges
>>>>>>>>>>>>>>>> to the system. It is using the br-int bridge created by OVN.
>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>> networks
>>>>>>>>>>>>>>>> created by the OVN provider are purely logical entities,
>>>>>>>>>>>>>>>> implemented using
>>>>>>>>>>>>>>>> the OVN br-int bridge.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Marcin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> From: "Sverker Abrahamsson"<sverker at abrahamsson.com>
>>>>>>>>>>>>>>>>> To: "Marcin Mirecki"<mmirecki at redhat.com>
>>>>>>>>>>>>>>>>> Cc: "Ovirt Users"<users at ovirt.org>
>>>>>>>>>>>>>>>>> Sent: Friday, December 30, 2016 12:15:43 PM
>>>>>>>>>>>>>>>>> Subject: Re: [ovirt-users] Issue with OVN/OVS and mandatory
>>>>>>>>>>>>>>>>> ovirtmgmt
>>>>>>>>>>>>>>>>> network
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>> That is the logic I quite don't understand. What is the
>>>>>>>>>>>>>>>>> purpose of
>>>>>>>>>>>>>>>>> adding my bridges to Ovirt through the external provider
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> configure
>>>>>>>>>>>>>>>>> them on my VM if you are disregarding that and using br-int
>>>>>>>>>>>>>>>>> anyway?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Sverker
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Den 2016-12-30 kl. 10:53, skrev Marcin Mirecki:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Sverker,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> br-int is the integration bridge created by default in
>>>>>>>>>>>>>>>>>> OVN. This
>>>>>>>>>>>>>>>>>> is the
>>>>>>>>>>>>>>>>>> bridge we use for the OVN provider. As OVN is required to
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> installed,
>>>>>>>>>>>>>>>>>> we assume that this bridge is present.
>>>>>>>>>>>>>>>>>> Using any other ovs bridge is not supported, and will
>>>>>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>>>>> custom code
>>>>>>>>>>>>>>>>>> changes (such as the ones you created).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The proper setup in your case would probably be to create
>>>>>>>>>>>>>>>>>> br-int
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> connect
>>>>>>>>>>>>>>>>>> this to your ovirtbridge, although I don't know the
>>>>>>>>>>>>>>>>>> details of
>>>>>>>>>>>>>>>>>> your env,
>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>> this is just my best guess.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Marcin
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> From: "Sverker Abrahamsson"<sverker at abrahamsson.com>
>>>>>>>>>>>>>>>>>>> To: "Marcin Mirecki"<mmirecki at redhat.com>
>>>>>>>>>>>>>>>>>>> Cc: "Ovirt Users"<users at ovirt.org>, "Numan Siddique"
>>>>>>>>>>>>>>>>>>> <nusiddiq at redhat.com>
>>>>>>>>>>>>>>>>>>> Sent: Friday, December 30, 2016 1:14:50 AM
>>>>>>>>>>>>>>>>>>> Subject: Re: [ovirt-users] Issue with OVN/OVS and
>>>>>>>>>>>>>>>>>>> mandatory
>>>>>>>>>>>>>>>>>>> ovirtmgmt
>>>>>>>>>>>>>>>>>>> network
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Even better, if the value is not hardcoded then the
>>>>>>>>>>>>>>>>>>> configured
>>>>>>>>>>>>>>>>>>> value is
>>>>>>>>>>>>>>>>>>> used. Might be that I'm missunderstanding something but
>>>>>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> behaviour I expected instead of that it is using br-int.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Attached is a patch which properly sets up the xml, in
>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>>>>>> already a virtual port there + testcode of some variants
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Sverker
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Den 2016-12-29 kl. 22:55, skrev Sverker Abrahamsson:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When I change
>>>>>>>>>>>>>>>>>>>> /usr/libexec/vdsm/hooks/before
>>>>>>>>>>>>>>>>>>>> _device_create/ovirt_provider_ovn_hook
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> to instead of hardcoded to br-int use BRIDGE_NAME =
>>>>>>>>>>>>>>>>>>>> 'ovirtbridge' then
>>>>>>>>>>>>>>>>>>>> I get the expected behaviour and I get a working network
>>>>>>>>>>>>>>>>>>>> connectivity
>>>>>>>>>>>>>>>>>>>> in my VM with IP provided by dhcp.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Sverker
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Den 2016-12-29 kl. 22:07, skrev Sverker Abrahamsson:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> By default the vNic profile of my OVN bridge
>>>>>>>>>>>>>>>>>>>>> ovirtbridge gets a
>>>>>>>>>>>>>>>>>>>>> Network filter named vdsm-no-mac-spoofing. If I instead
>>>>>>>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>>>>>>> No filter
>>>>>>>>>>>>>>>>>>>>> then I don't get those ebtables / iptables messages. It
>>>>>>>>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> there is some issue between ovirt/vdsm and firewalld,
>>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>> we can
>>>>>>>>>>>>>>>>>>>>> put to the side for now.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It is not clear for me why the port is added on br-int
>>>>>>>>>>>>>>>>>>>>> instead of the
>>>>>>>>>>>>>>>>>>>>> bridge I've assigned to the VM, which is ovirtbridge??
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Sverker
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Den 2016-12-29 kl. 14:20, skrev Sverker Abrahamsson:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The specific command most likely fails because there
>>>>>>>>>>>>>>>>>>>>>> is no
>>>>>>>>>>>>>>>>>>>>>> chain
>>>>>>>>>>>>>>>>>>>>>> named libvirt-J-vnet0, but when should that have been
>>>>>>>>>>>>>>>>>>>>>> created?
>>>>>>>>>>>>>>>>>>>>>> /Sverker
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> -------- Vidarebefordrat meddelande --------
>>>>>>>>>>>>>>>>>>>>>> Ämne: Re: [ovirt-users] Issue with OVN/OVS and
>>>>>>>>>>>>>>>>>>>>>> mandatory
>>>>>>>>>>>>>>>>>>>>>> ovirtmgmt
>>>>>>>>>>>>>>>>>>>>>> network
>>>>>>>>>>>>>>>>>>>>>> Datum: Thu, 29 Dec 2016 08:06:29 -0500 (EST)
>>>>>>>>>>>>>>>>>>>>>> Från: Marcin Mirecki<mmirecki at redhat.com>
>>>>>>>>>>>>>>>>>>>>>> Till: Sverker Abrahamsson<sverker at abrahamsson.com
>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>> Kopia: Ovirt Users<users at ovirt.org>, Lance
>>>>>>>>>>>>>>>>>>>>>> Richardson
>>>>>>>>>>>>>>>>>>>>>> <lrichard at redhat.com>, Numan
>>>>>>>>>>>>>>>>>>>>>> Siddique<nusiddiq at redhat.com>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Let me add the OVN team.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Lance, Numan,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Can you please look at this?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Trying to plug a vNIC results in:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Dec 28 23:31:35 h2 ovs-vsctl:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ovs|00001|vsctl|INFO|Called as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ovs-vsctl
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --timeout=5 -- --if-exists del-port vnet0 --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> add-port
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> br-int
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> vnet0 --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> set Interface vnet0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "external-ids:attached-mac=\"0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 0:1a:4a:16:01:51\""
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- set Interface vnet0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "external-ids:iface-id=\"e8853
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aac-8a75-41b0-8010-e630017dcdd8\""
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> set Interface vnet0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "external-ids:vm-id=\"b9440d60
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -ef5a-4e2b-83cf-081df7c09e6f\""
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Interface vnet0 external-ids:iface-status=acti
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ve
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dec 28 23:31:35 h2 kernel: device vnet0 entered
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> promiscuous
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mode
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dec 28 23:31:35 h2 firewalld: WARNING:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> COMMAND_FAILED:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> '/usr/sbin/ebtables --concurrent -t nat -D
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PREROUTING
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -i vnet0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -j
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> libvirt-J-vnet0' failed:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dec 28 23:31:35 h2 firewalld: WARNING:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> COMMAND_FAILED:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> More details below
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> From: "Sverker Abrahamsson"<sverker at abrahamsson.com>
>>>>>>>>>>>>>>>>>>>>>>> To: "Marcin Mirecki"<mmirecki at redhat.com>
>>>>>>>>>>>>>>>>>>>>>>> Cc: "Ovirt Users"<users at ovirt.org>
>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, December 29, 2016 1:42:11 PM
>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: [ovirt-users] Issue with OVN/OVS and
>>>>>>>>>>>>>>>>>>>>>>> mandatory
>>>>>>>>>>>>>>>>>>>>>>> ovirtmgmt
>>>>>>>>>>>>>>>>>>>>>>> network
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>>>>>>>> Same problem still..
>>>>>>>>>>>>>>>>>>>>>>> /Sverker
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Den 2016-12-29 kl. 13:34, skrev Marcin Mirecki:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The tunnels are created to connect multiple OVN
>>>>>>>>>>>>>>>>>>>>>>>> controllers.
>>>>>>>>>>>>>>>>>>>>>>>> If there is only one, there is no need for the
>>>>>>>>>>>>>>>>>>>>>>>> tunnels, so
>>>>>>>>>>>>>>>>>>>>>>>> none
>>>>>>>>>>>>>>>>>>>>>>>> will be created, this is the correct behavior.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Does the problem still occur after setting
>>>>>>>>>>>>>>>>>>>>>>>> configuring the
>>>>>>>>>>>>>>>>>>>>>>>> OVN-controller?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Marcin
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> From: "Sverker Abrahamsson"<sverker at abrahamss
>>>>>>>>>>>>>>>>>>>>>>>>> on.com>
>>>>>>>>>>>>>>>>>>>>>>>>> To: "Marcin Mirecki"<mmirecki at redhat.com>
>>>>>>>>>>>>>>>>>>>>>>>>> Cc: "Ovirt Users"<users at ovirt.org>
>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, December 29, 2016 11:44:32 AM
>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: [ovirt-users] Iss
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> ...
>>
>> [Message clipped]
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170118/177e6124/attachment-0001.html>
More information about the Users
mailing list