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
> <mailto: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 <mailto: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
> <https://gerrit.ovirt.org/ovirt-provider-ovn>
> (let me know if you need some directions)
>
>
>
> ----- Original Message -----
>
> From: "Sverker Abrahamsson" <sverker at abrahamsson.com
> <mailto:sverker at abrahamsson.com>>
> To: "Marcin Mirecki" <mmirecki at redhat.com
> <mailto:mmirecki at redhat.com>>
> Cc: "Ovirt Users" <users at ovirt.org <mailto: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_exports_iso/1d49c4bc-0fec-4503-a583-d476fa3a370d/images/11111111-1111-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
> <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/11111111-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
> <mailto:sverker at abrahamsson.com>>
> To: "Marcin Mirecki" <mmirecki at redhat.com
> <mailto:mmirecki at redhat.com>>
> Cc: "Ovirt Users" <users at ovirt.org
> <mailto: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 <http://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 <http://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
> <http://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 <http://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
> <http://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
> <http://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 <http://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
> <http://h1.limetransit.com>",
> "security_groups" : null
> }
> }
> 2017-01-06 20:19:25,673 Connecting to
> remote ovn database:
> tcp:127.0.0.1:6641 <http://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=\"00: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
> <http://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
> <http://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
> <http://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
> <http://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
> <mailto:sverker at abrahamsson.com>>
> To: "Marcin
> Mirecki"<mmirecki at redhat.com
> <mailto:mmirecki at redhat.com>>
> Cc: "Ovirt Users"<users at ovirt.org
> <mailto: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
> <http://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
> <http://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
> <http://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
> <http://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/
> <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/ovirt-provider-ovn_fc24_46/rpm/fc24/noarch/
> <http://resources.ovirt.org/repos/ovirt/experimental/master/ovirt-provider-ovn_fc24_46/rpm/fc24/noarch/>
>
>
>
> ----- Original Message
> -----
>
> From: "Sverker
> Abrahamsson"<sverker at abrahamsson.com
> <mailto:sverker at abrahamsson.com>>
> To: "Marcin
> Mirecki"<mmirecki at redhat.com
> <mailto:mmirecki at redhat.com>>
> Cc: "Ovirt
> Users"<users at ovirt.org
> <mailto: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/ovirt-ovn-provider/
> <https://www.ovirt.org//develop/release-management/features/ovirt-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
> <mailto:sverker at abrahamsson.com>>
> To:
> "Marcin
> Mirecki"<mmirecki at redhat.com
> <mailto:mmirecki at redhat.com>>
> Cc: "Ovirt
> Users"<users at ovirt.org
> <mailto: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
> <mailto:sverker at abrahamsson.com>>
> To:
> "Marcin
> Mirecki"<mmirecki at redhat.com
> <mailto:mmirecki at redhat.com>>
> Cc:
> "Ovirt
> Users"<users at ovirt.org
> <mailto:users at ovirt.org>>,
> "Numan
> Siddique"
> <nusiddiq at redhat.com
> <mailto: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
> <mailto:mmirecki at redhat.com>>
> Till:
>
> Sverker
> Abrahamsson<sverker at abrahamsson.com
> <mailto:sverker at abrahamsson.com>>
> Kopia:
>
> Ovirt
> Users<users at ovirt.org
> <mailto:users at ovirt.org>>,
> Lance
> Richardson
> <lrichard at redhat.com
> <mailto:lrichard at redhat.com>>,
> Numan
> Siddique<nusiddiq at redhat.com
> <mailto: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=\"00:1a:4a:16:01:51\""
> --
> set
> Interface
> vnet0
> "external-ids:iface-id=\"e8853aac-8a75-41b0-8010-e630017dcdd8\""
>
>
> --
> set
> Interface
> vnet0
> "external-ids:vm-id=\"b9440d60-ef5a-4e2b-83cf-081df7c09e6f\""
>
>
> --
> set
> Interface
> vnet0
> external-ids:iface-status=active
> 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
> <mailto:sverker at abrahamsson.com>>
> To:
> "Marcin
> Mirecki"<mmirecki at redhat.com
> <mailto:mmirecki at redhat.com>>
> Cc:
> "Ovirt
> Users"<users at ovirt.org
> <mailto: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
> <mailto:sverker at abrahamsson.com>>
> To:
> "Marcin
> Mirecki"<mmirecki at redhat.com
> <mailto:mmirecki at redhat.com>>
> Cc:
> "Ovirt
> Users"<users at ovirt.org
> <mailto:users at ovirt.org>>
> Sent:
> Thursday,
> December
> 29,
> 2016
> 11:44:32
> AM
> Subject:
> Re:
> [ovirt-users]
> Issue
> with
> OVN/OVS
> and
> mandatory
> ovirtmgmt
> network
>
> Hi
> The
> rpm
> packages
> you
> listed
> in
> the
> other
> mail
> are
> installed
> but
> I
> had
> not
> run
> vdsm-tool
> ovn-config
> to
> create
> tunnel
> as
> the
> OVN
> controller
> is
> on
> the
> same
> host.
>
> [root at h2
> ~]#
> rpm
> -q
> openvswitch-ovn-common
> openvswitch-ovn-common-2.6.90-1.el7.centos.x86_64
> [root at h2
> ~]#
> rpm
> -q
> openvswitch-ovn-host
> openvswitch-ovn-host-2.6.90-1.el7.centos.x86_64
> [root at h2
> ~]#
> rpm
> -q
> python-openvswitch
> python-openvswitch-2.6.90-1.el7.centos.noarch
>
> After
> removing
> my
> manually
> created
> br-int
> and
> run
>
> vdsm-tool
> ovn-config
> 127.0.0.1
> 172.27.1.1
>
> then
> I
> have
> the
> br-int
> but
> 'ip
> link
> show'
> does
> not
> show
> any
> link
> 'genev_sys_'
> nor
> does
> 'ovs-vsctl
> show'
> any
> port
> for
> ovn.
> I
> assume
> these
> are
> when
> there
> is
> an
> actual
> tunnel?
>
> [root at h2
> ~]#
> ovs-vsctl
> show
> ebb6aede-cbbc-4f4f-a88a-a9cd72b2bd23
> Bridge
> br-int
> fail_mode:
> secure
> Port
> br-int
>
>
> Interface
> br-int
>
>
>
>
> type:
> internal
> Bridge
> ovirtbridge
> Port
> ovirtbridge
>
>
> Interface
> ovirtbridge
>
>
>
>
> type:
> internal
> Bridge
> "ovsbridge0"
> Port
> "ovsbridge0"
>
>
> Interface
> "ovsbridge0"
>
>
>
>
> type:
> internal
> Port
> "eth0"
>
>
> Interface
> "eth0"
> ovs_version:
> "2.6.90"
>
> [root at h2
> ~]#
> ip
> link
> show
> 1:
> lo:
> <LOOPBACK,UP,LOWER_UP>
> mtu
> 65536
> qdisc
> noqueue
> state
> UNKNOWN
> mode
> DEFAULT
> qlen
> 1
> link/loopback
> 00:00:00:00:00:00
> brd
> 00:00:00:00:00:00
> 2:
> eth0:
> <BROADCAST,MULTICAST,UP,LOWER_UP>
> mtu
> 1500
> qdisc
> pfifo_fast
> master
> ovs-system
> state
> UP
> mode
> DEFAULT
> qlen
> 1000
> link/ether
> 44:8a:5b:84:7d:b3
> brd
> ff:ff:ff:ff:ff:ff
> 3:
> ovs-system:
> <BROADCAST,MULTICAST>
> mtu
> 1500
> qdisc
> noop
> state
> DOWN
> mode
> DEFAULT
> qlen
> 1000
> link/ether
> 5a:14:cf:28:47:e2
> brd
> ff:ff:ff:ff:ff:ff
> 4:
> ovsbridge0:
> <BROADCAST,MULTICAST,UP,LOWER_UP>
> mtu
> 1500
> qdisc
> noqueue
> state
> UNKNOWN
> mode
> DEFAULT
> qlen
> 1000
> link/ether
> 44:8a:5b:84:7d:b3
> brd
> ff:ff:ff:ff:ff:ff
> 5:
> br-int:
> <BROADCAST,MULTICAST>
> mtu
> 1500
> qdisc
> noop
> state
> DOWN
> mode
> DEFAULT
> qlen
> 1000
> link/ether
> 9e:b0:3a:9d:f2:4b
> brd
> ff:ff:ff:ff:ff:ff
> 6:
> ovirtbridge:
> <BROADCAST,MULTICAST,UP,LOWER_UP>
> mtu
> 1500
> qdisc
> noqueue
> state
> UNKNOWN
> mode
> DEFAULT
> qlen
> 1000
> link/ether
> a6:f6:e5:a4:5b:45
> brd
> ff:ff:ff:ff:ff:ff
> 7:
> dummy0:
> <BROADCAST,NOARP,UP,LOWER_UP>
> mtu
> 1500
> qdisc
> noqueue
> master
> ovirtmgmt
> state
> UNKNOWN
> mode
> DEFAULT
> qlen
> 1000
> link/ether
> 66:e0:1c:c3:a9:d8
> brd
> ff:ff:ff:ff:ff:ff
> 8:
> ovirtmgmt:
> <BROADCAST,MULTICAST,UP,LOWER_UP>
> mtu
> 1500
> qdisc
> noqueue
> state
> UP
> mode
> DEFAULT
> qlen
> 1000
> link/ether
> 66:e0:1c:c3:a9:d8
> brd
> ff:ff:ff:ff:ff:ff
>
> Firewall
> settings:
> [root at h2
> ~]#
> firewall-cmd
> --list-all-zones
> work
> target:
> default
> icmp-block-inversion:
> no
> interfaces:
> sources:
> services:
> dhcpv6-client
> ssh
>
>
>
>
>
> ports:
> protocols:
> masquerade:
> no
> forward-ports:
> sourceports:
> icmp-blocks:
>
>
>
>
>
> rich
> rules:
>
>
> drop
> target:
> DROP
> icmp-block-inversion:
> no
> interfaces:
> sources:
> services:
>
>
>
>
>
> ports:
> protocols:
> masquerade:
> no
> forward-ports:
> sourceports:
> icmp-blocks:
>
>
>
>
>
> rich
> rules:
>
>
> internal
> target:
> default
> icmp-block-inversion:
> no
> interfaces:
> sources:
> services:
> dhcpv6-client
> mdns
> samba-client
> ssh
>
>
>
>
>
> ports:
> protocols:
> masquerade:
> no
> forward-ports:
> sourceports:
> icmp-blocks:
>
>
>
>
>
> rich
> rules:
>
>
> external
> target:
> default
> icmp-block-inversion:
> no
> interfaces:
> sources:
> services:
> ssh
>
>
>
>
>
> ports:
> protocols:
> masquerade:
> yes
> forward-ports:
> sourceports:
> icmp-blocks:
>
>
>
>
>
> rich
> rules:
>
>
> trusted
> target:
> ACCEPT
> icmp-block-inversion:
> no
> interfaces:
> sources:
> services:
>
>
>
>
>
> ports:
> protocols:
> masquerade:
> no
> forward-ports:
> sourceports:
> icmp-blocks:
>
>
>
>
>
> rich
> rules:
>
>
> home
> target:
> default
> icmp-block-inversion:
> no
> interfaces:
> sources:
> services:
> dhcpv6-client
> mdns
> samba-client
> ssh
>
>
>
>
>
> ports:
> protocols:
> masquerade:
> no
> forward-ports:
> sourceports:
> icmp-blocks:
>
>
>
>
>
> rich
> rules:
>
>
> dmz
> target:
> default
> icmp-block-inversion:
> no
> interfaces:
> sources:
> services:
> ssh
>
>
>
>
>
> ports:
> protocols:
> masquerade:
> no
> forward-ports:
> sourceports:
> icmp-blocks:
>
>
>
>
>
> rich
> rules:
>
>
> public
> (active)
> target:
> default
> icmp-block-inversion:
> no
> interfaces:
> eth0
> ovsbridge0
> sources:
> services:
> dhcpv6-client
> ssh
>
>
>
>
>
> ports:
> protocols:
> masquerade:
> no
> forward-ports:
> sourceports:
> icmp-blocks:
>
>
>
>
>
> rich
> rules:
>
>
> block
> target:
> %%REJECT%%
> icmp-block-inversion:
> no
> interfaces:
> sources:
> services:
>
>
>
>
>
> ports:
> protocols:
> masquerade:
> no
> forward-ports:
> sourceports:
> icmp-blocks:
>
>
>
>
>
> rich
> rules:
>
>
> ovirt
> (active)
> target:
> default
> icmp-block-inversion:
> no
> interfaces:
> ovirtbridge
> ovirtmgmt
> sources:
> services:
> dhcp
> ovirt-fence-kdump-listener
> ovirt-http
> ovirt-https
> ovirt-imageio-proxy
> ovirt-postgres
> ovirt-provider-ovn
> ovirt-vmconsole-proxy
> ovirt-websocket-proxy
> ssh
> vdsm
>
>
>
>
>
> ports:
> protocols:
> masquerade:
> yes
> forward-ports:
> sourceports:
> icmp-blocks:
>
>
>
>
>
> rich
> rules:
> rule
> family="ipv4"
> port
> port="6641"
> protocol="tcp"
> accept
> rule
> family="ipv4"
> port
> port="6642"
> protocol="tcp"
> accept
>
> The
> db
> dump
> is
> attached
> /Sverker
> Den
> 2016-12-29
> kl.
> 09:50,
> skrev
> Marcin
> Mirecki:
>
> Hi,
>
> Can
> you
> please
> do:
> "sudo
> ovsdb-client
> dump"
> on
> the
> host
> and
> send
> me
> the
> output?
>
> Have
> you
> configured
> the
> ovn
> controller
> to
> connect
> to
> the
> OVN
> north?
> You
> can
> do
> it
> using
> "vdsm-tool
> ovn-config"
> or
> using
> the
> OVN
> tools
> directly.
> Please
> check
> out:https://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/
> <https://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/>
>
> for
> details.
>
> Also
> please
> note
> that
> the
> OVN
> provider
> is
> completely
> different
> from
> the
> neutron-openvswitch
> plugin.
> Please
> don't
> mix
> the
> two.
>
> Marcin
>
>
> -----
> Original
> Message
> -----
>
> From:
> "Marcin
> Mirecki"<mmirecki at redhat.com
> <mailto:mmirecki at redhat.com>>
> To:
> "Sverker
> Abrahamsson"<sverker at abrahamsson.com
> <mailto:sverker at abrahamsson.com>>
> Cc:
> "Ovirt
> Users"<users at ovirt.org
> <mailto:users at ovirt.org>>
> Sent:
> Thursday,
> December
> 29,
> 2016
> 9:27:19
> AM
> Subject:
> Re:
> [ovirt-users]
> Issue
> with
> OVN/OVS
> and
> mandatory
> ovirtmgmt
> network
>
> Hi,
>
> br-int
> is
> the
> OVN
> integration
> bridge,
> it
> should
> have
> been
> created
> when
> installing
> OVN.
> I
> assume
> you
> have
> the
> following
> packages
> installed
> on
> the
> host:
> openvswitch-ovn-common
> openvswitch-ovn-host
> python-openvswitch
>
> Please
> give
> me
> some
> time
> to
> look
> at
> the
> connectivity
> problem.
>
> Marcin
>
>
>
> -----
> Original
> Message
> -----
>
> From:
> "Sverker
> Abrahamsson"<sverker at abrahamsson.com
> <mailto:sverker at abrahamsson.com>>
> To:
> "Marcin
> Mirecki"<mmirecki at redhat.com
> <mailto:mmirecki at redhat.com>>
> Cc:
> "Ovirt
> Users"<users at ovirt.org
> <mailto:users at ovirt.org>>
> Sent:
> Thursday,
> December
> 29,
> 2016
> 12:47:04
> AM
> Subject:
> Re:
> [ovirt-users]
> Issue
> with
> OVN/OVS
> and
> mandatory
> ovirtmgmt
> network
>
> From
> /usr/libexec/vdsm/hooks/before_device_create/ovirt_provider_ovn_hook
>
>
> (installed
> by
> ovirt-provider-ovn-driver
> rpm):
>
> BRIDGE_NAME
> =
> 'br-int'
>
>
> Den
> 2016-12-28
> kl.
> 23:56,
> skrev
> Sverker
> Abrahamsson:
>
> Googling
> on
> the
> message
> about
> br-int
> suggested
> adding
> that
> bridge
> to
> ovs:
>
> ovs-vsctl
> add-br
> br-int
>
> Then
> the
> VM
> is
> able
> to
> boot,
> but
> it
> fails
> to
> get
> network
> connectivity.
> Output
> in
> /var/log/messages:
>
> 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=\"00:1a:4a:16:01:51\""
> --
> set
> Interface
> vnet0
> "external-ids:iface-id=\"e8853aac-8a75-41b0-8010-e630017dcdd8\""
>
>
> --
> set
> Interface
> vnet0
> "external-ids:vm-id=\"b9440d60-ef5a-4e2b-83cf-081df7c09e6f\""
>
>
> --
> set
> Interface
> vnet0
> external-ids:iface-status=active
> 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:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -D
> POSTROUTING
> -o
> vnet0
> -j
> libvirt-P-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -L
> libvirt-J-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -L
> libvirt-P-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -F
> libvirt-J-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -X
> libvirt-J-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -F
> libvirt-P-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -X
> libvirt-P-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -F
> J-vnet0-mac'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -X
> J-vnet0-mac'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -F
> J-vnet0-arp-mac'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -X
> J-vnet0-arp-mac'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -D
> libvirt-out
> -m
> physdev
> --physdev-is-bridged
> --physdev-out
> vnet0
> -g
> FO-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -D
> libvirt-out
> -m
> physdev
> --physdev-out
> vnet0
> -g
> FO-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -D
> libvirt-in
> -m
> physdev
> --physdev-in
> vnet0
> -g
> FI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -D
> libvirt-host-in
> -m
> physdev
> --physdev-in
> vnet0
> -g
> HI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -F
> FO-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -X
> FO-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -F
> FI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -X
> FI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -F
> HI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -X
> HI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -E
> FP-vnet0
> FO-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -E
> FJ-vnet0
> FI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/iptables
> -w2
> -w
> -E
> HJ-vnet0
> HI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -D
> libvirt-out
> -m
> physdev
> --physdev-is-bridged
> --physdev-out
> vnet0
> -g
> FO-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -D
> libvirt-out
> -m
> physdev
> --physdev-out
> vnet0
> -g
> FO-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -D
> libvirt-in
> -m
> physdev
> --physdev-in
> vnet0
> -g
> FI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -D
> libvirt-host-in
> -m
> physdev
> --physdev-in
> vnet0
> -g
> HI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -F
> FO-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -X
> FO-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -F
> FI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -X
> FI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -F
> HI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -X
> HI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -E
> FP-vnet0
> FO-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -E
> FJ-vnet0
> FI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ip6tables
> -w2
> -w
> -E
> HJ-vnet0
> HI-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -D
> PREROUTING
> -i
> vnet0
> -j
> libvirt-I-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -D
> POSTROUTING
> -o
> vnet0
> -j
> libvirt-O-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -L
> libvirt-I-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -L
> libvirt-O-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -F
> libvirt-I-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -X
> libvirt-I-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -F
> libvirt-O-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -X
> libvirt-O-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -L
> libvirt-P-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -E
> libvirt-P-vnet0
> libvirt-O-vnet0'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -F
> I-vnet0-mac'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -X
> I-vnet0-mac'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -F
> I-vnet0-arp-mac'
> failed:
> Dec
> 28
> 23:31:35
> h2
> firewalld:
> WARNING:
> COMMAND_FAILED:
> '/usr/sbin/ebtables
> --concurrent
> -t
> nat
> -X
> I-vnet0-arp-mac'
> failed:
>
>
> [root at h2
> etc]#
> ovs-vsctl
> show
> ebb6aede-cbbc-4f4f-a88a-a9cd72b2bd23
> Bridge
> ovirtbridge
>
> Port
> "ovirtport0"
> Interface
> "ovirtport0"
> type:
> internal
>
> Port
> ovirtbridge
> Interface
> ovirtbridge
> type:
> internal
> Bridge
> "ovsbridge0"
>
> Port
> "ovsbridge0"
> Interface
> "ovsbridge0"
> type:
> internal
>
> Port
> "eth0"
> Interface
> "eth0"
> Bridge
> br-int
>
> Port
> br-int
> Interface
> br-int
> type:
> internal
>
> Port
> "vnet0"
> Interface
> "vnet0"
> ovs_version:
> "2.6.90"
>
> Searching
> through
> the
> code
> it
> appears
> that
> br-int
> comes
> from
> neutron-openvswitch
> plugin
> ??
>
> [root at h2
> share]#
> rpm
> -qf
> /usr/share/otopi/plugins/ovirt-host-deploy/openstack/neutron_openvswitch.py
>
>
> ovirt-host-deploy-1.6.0-0.0.ma
> <http://ovirt-host-deploy-1.6.0-0.0.ma>ster.20161215101008.gitb76ad50.el7.centos.noarch
>
>
>
>
> /Sverker
>
> Den
> 2016-12-28
> kl.
> 23:24,
> skrev
> Sverker
> Abrahamsson:
>
> In
> addition
> I
> had
> to
> add
> an
> alias
> to
> modprobe:
>
> [root at h2
> modprobe.d]#
> cat
> dummy.conf
> alias
> dummy0
> dummy
>
>
> Den
> 2016-12-28
> kl.
> 23:03,
> skrev
> Sverker
> Abrahamsson:
>
> Hi
> I
> first
> tried
> to
> set
> device
> name
> to
> dummy_0,
> but
> then
> ifup
> did
> not
> succeed
> in
> creating
> the
> device
> unless
> I
> first
> did
> 'ip
> link
> add
> dummy_0
> type
> dummy'
> but
> then
> it
> would
> not
> suceed
> to
> establish
> the
> if
> on
> reboot.
>
> Setting
> fake_nics
> =
> dummy0
> would
> not
> work
> neither,
> but
> this
> works:
>
> fake_nics
> =
> dummy*
>
> The
> engine
> is
> now
> able
> to
> find
> the
> if
> and
> assign
> bridge
> ovirtmgmt
> to
> it.
>
> However,
> I
> then
> run
> into
> the
> next
> issue
> when
> starting
> a
> VM:
>
> 2016-12-28
> 22:28:23,897
> ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>
>
> (ForkJoinPool-1-worker-2)
> []
> Correlation
> ID:
> null,
> Call
> Stack:
> null,
> Custom
> Event
> ID:
> -1,
> Message:
> VM
> CentOS7
> is
> down
> with
> error.
> Exit
> message:
> Cannot
> get
> interface
> MTU
> on
> 'br-int':
> No
> such
> device.
>
> This
> VM
> has
> a
> nic
> on
> ovirtbridge,
> which
> comes
> from
> the
> OVN
> provider.
>
> /Sverker
>
> Den
> 2016-12-28
> kl.
> 14:38,
> skrev
> Marcin
> Mirecki:
>
> Sverker,
>
> Can
> you
> try
> adding
> a
> vnic
> named
> veth_*
> or
> dummy_*,
> (or
> alternatively
> add
> the
> name
> of
> the
> vnic
> to
> vdsm.config
> fake_nics),
> and
> setup
> the
> management
> network
> using
> this
> vnic?
> I
> suppose
> adding
> the
> vnic
> you
> use
> for
> connecting
> to
> the
> engine
> to
> fake_nics
> should
> make
> it
> visible
> to
> the
> engine,
> and
> you
> should
> be
> able
> to
> use
> it
> for
> the
> setup.
>
> Marcin
>
>
>
> -----
> Original
> Message
> -----
>
> From:
> "Marcin
> Mirecki"<mmirecki at redhat.com
> <mailto:mmirecki at redhat.com>>
> To:
> "Sverker
> Abrahamsson"<sverker at abrahamsson.com
> <mailto:sverker at abrahamsson.com>>
> Cc:
> "Ovirt
> Users"<users at ovirt.org
> <mailto:users at ovirt.org>>
> Sent:
> Wednesday,
> December
> 28,
> 2016
> 12:06:26
> PM
> Subject:
> Re:
> [ovirt-users]
> Issue
> with
> OVN/OVS
> and
> mandatory
> ovirtmgmt
> network
>
> I
> have
> an
> internal
> OVS
> bridge
> called
> ovirtbridge
> which
> has
> a
> port
> with
> IP
> address,
> but
> in
> the
> host
> network
> settings
> that
> port
> is
> not
> visible.
>
> I
> just
> verified
> and
> unfortunately
> the
> virtual
> ports
> are
> not
> visible
> in
> engine
> to
> assign
> a
> network
> to
> :(
> I'm
> afraid
> that
> the
> engine
> is
> not
> ready
> for
> such
> a
> scenario
> (even
> if
> it
> works).
> Please
> give
> me
> some
> time
> to
> look
> for
> a
> solution.
>
> -----
> Original
> Message
> -----
>
> From:
> "Sverker
> Abrahamsson"<sverker at abrahamsson.com
> <mailto:sverker at abrahamsson.com>>
> To:
> "Marcin
> Mirecki"<mmirecki at redhat.com
> <mailto:mmirecki at redhat.com>>
> Cc:
> "Ovirt
> Users"<users at ovirt.org
> <mailto:users at ovirt.org>>
> Sent:
> Wednesday,
> December
> 28,
> 2016
> 11:48:24
> AM
> Subject:
> Re:
> [ovirt-users]
> Issue
> with
> OVN/OVS
> and
> mandatory
> ovirtmgmt
> network
>
> Hi
> Marcin
> Yes,
> that
> is
> my
> issue.
> I
> don't
> want
> to
> let
> ovirt/vdsm
> see
> eth0
> nor
> ovsbridge0
> since
> as
> soon
> as
> it
> sees
> them
> it
> messes
> up
> the
> network
> config
> so
> that
> the
> host
> will
> be
> unreachable.
>
> I
> have
> an
> internal
> OVS
> bridge
> called
> ovirtbridge
> which
> has
> a
> port
> with
> IP
> address,
> but
> in
> the
> host
> network
> settings
> that
> port
> is
> not
> visible.
> It
> doesn't
> help
> to
> name
> it
> ovirtmgmt.
>
> The
> engine
> is
> able
> to
> communicate
> with
> the
> host
> on
> the
> ip
> it
> has
> been
> given,
> it's
> just
> that
> it
> believes
> that
> it
> HAS
> to
> have
> a
> ovirtmgmt
> network
> which
> can't
> be
> on
> OVN.
>
> /Sverker
>
>
> Den
> 2016-12-28
> kl.
> 10:45,
> skrev
> Marcin
> Mirecki:
>
> Hi
> Sverker,
>
> The
> management
> network
> is
> mandatory
> on
> each
> host.
> It's
> used
> by
> the
> engine
> to
> communicate
> with
> the
> host.
> Looking
> at
> your
> description
> and
> the
> exception
> it
> looks
> like
> it
> is
> missing.
> The
> error
> is
> caused
> by
> not
> having
> any
> network
> for
> the
> host
> (network
> list
> retrieved
> in
> InterfaceDaoImpl.getHostNetworksByCluster
> -
> which
> gets
> all
> the
> networks
> on
> nics
> for
> a
> host
> from
> vds_interface
> table
> in
> the
> DB).
>
> Could
> you
> maybe
> create
> a
> virtual
> nic
> connected
> to
> ovsbridge0
> (as
> I
> understand
> you
> have
> no
> physical
> nic
> available)
> and
> use
> this
> for
> the
> management
> network?
>
> I
> then
> create
> a
> bridge
> for
> use
> with
> ovirt,
> with
> a
> private
> address.
>
> I'm
> not
> quite
> sure
> I
> understand.
> Is
> this
> yet
> another
> bridge
> connected
> to
> ovsbridge0?
> You
> could
> also
> attach
> the
> vnic
> for
> the
> management
> network
> here
> if
> need
> be.
>
> Please
> keep
> in
> mind
> that
> OVN
> has
> no
> use
> in
> setting
> up
> the
> management
> network.
> The
> OVN
> provider
> can
> only
> handle
> external
> networks,
> which
> can
> not
> be
> used
> for
> a
> management
> network.
>
> Marcin
>
>
> -----
> Original
> Message
> -----
>
> From:
> "Sverker
> Abrahamsson"<sverker at abrahamsson.com
> <mailto:sverker at abrahamsson.com>>
> To:users at ovirt.org
> <mailto:To%3Ausers at ovirt.org>
> Sent:
> Wednesday,
> December
> 28,
> 2016
> 12:39:59
> AM
> Subject:
> [ovirt-users]
> Issue
> with
> OVN/OVS
> and
> mandatory
> ovirtmgmt
> network
>
>
>
> Hi
> For
> long
> time
> I've
> been
> looking
> for
> proper
> support
> in
> ovirt
> for
> Open
> vSwitch
> so
> I'm
> happy
> that
> it
> is
> moving
> in
> the
> right
> direction.
> However,
> there
> seems
> to
> still
> be
> a
> dependency
> on
> a
> ovirtmgmt
> bridge
> and
> I'm
> unable
> to
> move
> that
> to
> the
> OVN
> provider.
>
> The
> hosting
> center
> where
> I
> rent
> hw
> instances
> has
> a
> bit
> special
> network
> setup,
> so
> I
> have
> one
> physical
> network
> port
> with
> a
> /32
> netmask
> and
> point-to-point
> config
> to
> router.
> The
> physical
> port
> I
> connect
> to
> a
> ovs
> bridge
> which
> has
> the
> public
> ip.
> Since
> ovirt
> always
> messes
> up
> the
> network
> config
> when
> I've
> tried
> to
> let
> it
> have
> access
> to
> the
> network
> config
> for
> the
> physical
> port,
> I've
> set
> eht0
> and
> ovsbridge0
> as
> hidden
> in
> vdsm.conf.
>
>
> I
> then
> create
> a
> bridge
> for
> use
> with
> ovirt,
> with
> a
> private
> address.
> With
> the
> OVN
> provider
> I
> am
> now
> able
> to
> import
> these
> into
> the
> engine
> and
> it
> looks
> good.
> When
> creating
> a
> VM
> I
> can
> select
> that
> it
> will
> have
> a
> vNic
> on
> my
> OVS
> bridge.
>
> However,
> I
> can't
> start
> the
> VM
> as
> an
> exception
> is
> thrown
> in
> the
> log:
>
> 2016-12-28
> 00:13:33,350
> ERROR
> [org.ovirt.engine.core.bll.RunVmCommand]
> (default
> task-5)
> [3c882d53]
> Error
> during
> ValidateFailure.:
> java.lang.NullPointerException
> at
> org.ovirt.engine.core.bll.scheduling.policyunits.NetworkPolicyUnit.validateRequiredNetworksAvailable(NetworkPolicyUnit.java:140)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.scheduling.policyunits.NetworkPolicyUnit.filter(NetworkPolicyUnit.java:69)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.scheduling.SchedulingManager.runInternalFilters(SchedulingManager.java:597)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.scheduling.SchedulingManager.runFilters(SchedulingManager.java:564)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.scheduling.SchedulingManager.canSchedule(SchedulingManager.java:494)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.validator.RunVmValidator.canRunVm(RunVmValidator.java:133)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.RunVmCommand.validate(RunVmCommand.java:940)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.CommandBase.internalValidate(CommandBase.java:886)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.CommandBase.validateOnly(CommandBase.java:366)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner.canRunActions(PrevalidatingMultipleActionsRunner.java:113)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner.invokeCommands(PrevalidatingMultipleActionsRunner.java:99)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner.execute(PrevalidatingMultipleActionsRunner.java:76)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.Backend.runMultipleActionsImpl(Backend.java:613)
>
>
>
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.Backend.runMultipleActions(Backend.java:583)
>
>
>
> [bll.jar:]
>
>
> Looking
> at
> that
> section
> of
> code
> where
> the
> exception
> is
> thrown,
> I
> see
> that
> it
> iterates
> over
> host
> networks
> to
> find
> required
> networks,
> which
> I
> assume
> is
> ovirtmgmt.
> In
> the
> host
> network
> setup
> dialog
> I
> don't
> see
> any
> networks
> at
> all
> but
> it
> lists
> ovirtmgmt
> as
> required.
> It
> also
> list
> the
> OVN
> networks
> but
> these
> can't
> be
> statically
> assigned
> as
> they
> are
> added
> dynamically
> when
> needed,
> which
> is
> fine.
>
> I
> believe
> that
> I
> either
> need
> to
> remove
> ovirtmgmt
> network
> or
> configure
> that
> it
> is
> provided
> by
> the
> OVN
> provider,
> but
> neither
> is
> possible.
> Preferably
> it
> shouldn't
> be
> hardcoded
> which
> network
> is
> management
> and
> mandatory
> but
> be
> possible
> to
> configure.
>
> /Sverker
> Den
> 2016-12-27
> kl.
> 17:10,
> skrev
> Marcin
> Mirecki:
>
>
> _______________________________________________
>
> Users
> mailing
> list
> Users at ovirt.org
> <mailto:Users at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
> _______________________________________________
> Users
> mailing
> list
> Users at ovirt.org
> <mailto:Users at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
> _______________________________________________
> Users
> mailing
> list
> Users at ovirt.org
> <mailto:Users at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
> _______________________________________________
> Users
> mailing
> list
> Users at ovirt.org
> <mailto:Users at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
> _______________________________________________
> Users
> mailing
> list
> Users at ovirt.org
> <mailto:Users at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
> _______________________________________________
> Users
> mailing
> list
> Users at ovirt.org
> <mailto:Users at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
> _______________________________________________
> Users
> mailing
> list
> Users at ovirt.org
> <mailto:Users at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
> _______________________________________________
> Users
> mailing
> list
> Users at ovirt.org
> <mailto:Users at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> <mailto:Users at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> <mailto:Users at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org <mailto:Users at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170117/9ee119fa/attachment-0001.html>