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 at abrahamsson.com <mailto:sverker at abrahamsson.com>> wrote:
>
> I still had the window open where I did that step. This is how it
> looked like:
>
> [root at h2 ovirt-provider-ovn]# git push origin HEAD:refs/drafts/master
> Counting objects: 9, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (5/5), done.
> Writing objects: 100% (6/6), 1.79 KiB | 0 bytes/s, done.
> Total 6 (delta 2), reused 0 (delta 0)
> remote: Resolving deltas: 100% (2/2)
> remote: Processing changes: new: 1, refs: 1, done
> remote: (W) 16d5be4: commit subject >65 characters; use shorter
> first paragraph
> remote:
> remote: New Changes:
> remote: https://gerrit.ovirt.org/70588 Properly handle to set id
> when interface already has a virtualport element ... [DRAFT]
> remote:
> To gerrit.ovirt.org:ovirt-provider-ovn
> * [new branch] HEAD -> refs/drafts/master
>
> I see the difference is that I pushed to HEAD:refs/drafts/master
> as instructed at
> http://www.ovirt.org/develop/dev-process/working-with-gerrit/
> <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]
>> Iss
>>
> ...
>
> [Message clipped]
> _______________________________________________
> 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/20170118/eab0165d/attachment-0001.html>