[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