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

Ok, thank you. Done that now /Sverker Den 2017-01-18 kl. 10:14, skrev Fred Rolland: Go to https://gerrit.ovirt.org/70588 and click on the publish button. Drafts are not visible to everybody. Or you can push to master directly. On Tue, Jan 17, 2017 at 7:39 PM, Sverker Abrahamsson < sverker(a)abrahamsson.com&gt; wrote: > 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/d > ev-process/working-with-gerrit/ > > Should I push it to HEAD:refs/for/master instead? > > /Sverker > Den 2017-01-17 kl. 12:09, skrev Marcin Mirecki: > > Sverker, > I can see you as a user in gerrit (sverker(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-241fa5 >>>>>>>> c0a1f3 >>>>>>>> comes from, doesn't show in any log other than /var/log/messages. >>>>>>>> >>>>>>>> If I do the same exercise on the same host as engine is running on >>>>>>>> then the port for the VM gets the right id and is working from >>>>>>>> beginning. >>>>>>>> /Sverker >>>>>>>> >>>>>>>> Den 2017-01-03 kl. 10:23, skrev Marcin Mirecki: >>>>>>>> >>>>>>>>> How did you create this port? >>>>>>>>> From the oVirt engine UI? >>>>>>>>> The OVN provider creates the port when you add the port in the >>>>>>>>> engine UI, >>>>>>>>> it is then plugged into the ovs bridge by the VIF driver. >>>>>>>>> Please attach /var/log/ovirt-provider-ovn.log >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>> >>>>>>>>>> From: "Sverker Abrahamsson&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 >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> 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"<sverker@abrahamss >>>>>>>>>>>>>>>>>>>>>>>> on.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 > >