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

I still had the window open where I did that step. This is how it looked like: [root@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(a)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(a)abrahamsson.com&gt; 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(a)abrahamsson.com&gt; >>> To: "Marcin Mirecki" <mmirecki(a)redhat.com&gt; >>> Cc: "Ovirt Users" <users(a)ovirt.org&gt; >>> 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(a)abrahamsson.com&gt; >>>>>> To: "Marcin Mirecki" <mmirecki(a)redhat.com&gt; >>>>>> Cc: "Ovirt Users" <users(a)ovirt.org&gt; >>>>>> 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@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@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@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@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@h1 ~]# ovs-vsctl set Interface vnet0 >>>>>>> "external-ids:iface-id=\"92f6d3c8-68b3-4986-9c09-60bee04644b5\"" >>>>>>> >>>>>>> then sb is correct: >>>>>>> [root@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&quot;&lt;sverker(a)abrahamsson.com&gt; >>>>>>>>> To: "Marcin Mirecki&quot;&lt;mmirecki(a)redhat.com&gt; >>>>>>>>> Cc: "Ovirt Users&quot;&lt;users(a)ovirt.org&gt; >>>>>>>>> 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@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@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&quot;&lt;sverker(a)abrahamsson.com&gt; >>>>>>>>>>>>> To: "Marcin Mirecki&quot;&lt;mmirecki(a)redhat.com&gt; >>>>>>>>>>>>> Cc: "Ovirt Users&quot;&lt;users(a)ovirt.org&gt; >>>>>>>>>>>>> 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&quot;&lt;sverker(a)abrahamsson.com&gt; >>>>>>>>>>>>>>> To: "Marcin Mirecki&quot;&lt;mmirecki(a)redhat.com&gt; >>>>>>>>>>>>>>> Cc: "Ovirt Users&quot;&lt;users(a)ovirt.org&gt; >>>>>>>>>>>>>>> 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&quot;&lt;sverker(a)abrahamsson.com&gt; >>>>>>>>>>>>>>>>> To: "Marcin Mirecki&quot;&lt;mmirecki(a)redhat.com&gt; >>>>>>>>>>>>>>>>> Cc: "Ovirt Users&quot;&lt;users(a)ovirt.org&gt;, "Numan Siddique" >>>>>>>>>>>>>>>>> <nusiddiq(a)redhat.com&gt; >>>>>>>>>>>>>>>>> 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&lt;mmirecki(a)redhat.com&gt; >>>>>>>>>>>>>>>>>>>> Till: Sverker Abrahamsson&lt;sverker(a)abrahamsson.com&gt; >>>>>>>>>>>>>>>>>>>> Kopia: Ovirt Users&lt;users(a)ovirt.org&gt;, Lance >>>>>>>>>>>>>>>>>>>> Richardson >>>>>>>>>>>>>>>>>>>> <lrichard(a)redhat.com&gt;, Numan >>>>>>>>>>>>>>>>>>>> Siddique&lt;nusiddiq(a)redhat.com&gt; >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 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&quot;&lt;sverker(a)abrahamsson.com&gt; >>>>>>>>>>>>>>>>>>>>> To: "Marcin Mirecki&quot;&lt;mmirecki(a)redhat.com&gt; >>>>>>>>>>>>>>>>>>>>> Cc: "Ovirt Users&quot;&lt;users(a)ovirt.org&gt; >>>>>>>>>>>>>>>>>>>>> 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&quot;&lt;sverker(a)abrahamsson.com >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> To: "Marcin Mirecki&quot;&lt;mmirecki(a)redhat.com&gt; >>>>>>>>>>>>>>>>>>>>>>> Cc: "Ovirt Users&quot;&lt;users(a)ovirt.org&gt; >>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, December 29, 2016 11:44:32 AM >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: [ovirt-users] Iss >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> ... [Message clipped] _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users