[ovirt-users] Issue with OVN/OVS and mandatory ovirtmgmt network

Fred Rolland frolland at redhat.com
Wed Jan 18 09:14:45 UTC 2017


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/dev-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-241fa5c0a1f3
>>>>>>>> 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 abrahamsson.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/7e5b5f85/attachment-0001.html>


More information about the Users mailing list