...I still had the window open where I did that step. This is how it looked like:
[root@h2 ovirt-provider-ovn]# git push origin HEAD:refs/drafts/master
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 1.79 KiB | 0 bytes/s, done.
Total 6 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2)
remote: Processing changes: new: 1, refs: 1, done
remote: (W) 16d5be4: commit subject >65 characters; use shorter first paragraph
remote:
remote: New Changes:
remote: https://gerrit.ovirt.org/70588 Properly handle to set id when interface already has a virtualport element ... [DRAFT]
remote:
To gerrit.ovirt.org:ovirt-provider-ovn
* [new branch] HEAD -> refs/drafts/master
I see the difference is that I pushed to HEAD:refs/drafts/master as instructed at http://www.ovirt.org/develop/
dev-process/working-with- gerrit/ Should I push it to HEAD:refs/for/master instead?
/Sverker
Den 2017-01-17 kl. 12:09, skrev Marcin Mirecki:
Also, please let me know if you need any other help on with gerrit.Please check for any errors after you issue:Sverker,I can see you as a user in gerrit (sverker@abrahamsson.com), but there are no patches for your name.
git push gerrit.ovirt.org:ovirt-provider-ovn HEAD:refs/for/master
On Mon, Jan 16, 2017 at 8:49 PM, Sverker Abrahamsson <sverker@abrahamsson.com> wrote:
I've followed the instructions to best effort, so hopefully it's right..
Den 2017-01-13 kl. 10:31, skrev Marcin Mirecki:
Please push the patch into: https://gerrit.ovirt.org/ovirt-provider-ovn
(let me know if you need some directions)
----- Original Message -----
From: "Sverker Abrahamsson" <sverker@abrahamsson.com>
To: "Marcin Mirecki" <mmirecki@redhat.com>
Cc: "Ovirt Users" <users@ovirt.org>
Sent: Monday, January 9, 2017 1:45:37 PM
Subject: Re: [ovirt-users] Issue with OVN/OVS and mandatory ovirtmgmt network
Ok, found it. The issue is right here:
<interface type="bridge">
<mac address="00:1a:4a:16:01:54" />
<model type="virtio" />
<source bridge="br-int" />
<virtualport type="openvswitch" />
<link state="up" />
<boot order="2" />
<bandwidth />
<virtualport type="openvswitch">
<parameters
interfaceid="912cba79-982e-4a87-868e-241fedccb59a" />
</virtualport>
</interface>
There are two elements for virtualport, the first without id and the
second with. On h2 I had fixed this which was the patch I posted earlier
although I switched back to use br-int after understanding that was the
correct way. When that hook was copied to h1 the port gets attached fine.
Patch with updated testcase attached.
/Sverker
Den 2017-01-09 kl. 10:41, skrev Sverker Abrahamsson:
This is the content of vdsm.log on h1 at this time:
2017-01-06 20:54:12,636 INFO (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC
call VM.create succeeded in 0.01 seconds (__init__:515)
2017-01-06 20:54:12,636 INFO (vm/6dd5291e) [virt.vm]
(vmId='6dd5291e-6556-4d29-8b4e-ea896e627645') VM wrapper has started
(vm:1901)
2017-01-06 20:54:12,636 INFO (vm/6dd5291e) [vds] prepared volume
path:
/rhev/data-center/mnt/h2-int.limetransit.com:_var_lib_export s_iso/1d49c4bc-0fec-4503-a583- d476fa3a370d/images/11111111-1 111-1111-1111-111111111111/Cen tOS-7-x86_64-NetInstall-1611. iso
(clientIF:374)
2017-01-06 20:54:12,743 INFO (vm/6dd5291e) [root] (hooks:108)
2017-01-06 20:54:12,847 INFO (vm/6dd5291e) [root] (hooks:108)
2017-01-06 20:54:12,863 INFO (vm/6dd5291e) [virt.vm]
(vmId='6dd5291e-6556-4d29-8b4e-ea896e627645') <?xml version='1.0'
encoding='UTF-8'?>
<domain xmlns:ovirt="http://ovirt.org/vm/tune/1.0 " type="kvm">
<name>CentOS7_3</name>
<uuid>6dd5291e-6556-4d29-8b4e-ea896e627645</uuid>
<memory>1048576</memory>
<currentMemory>1048576</currentMemory>
<maxMemory slots="16">4294967296</maxMemory>
<vcpu current="1">16</vcpu>
<devices>
<channel type="unix">
<target name="com.redhat.rhevm.vdsm" type="virtio" />
<source mode="bind"
path="/var/lib/libvirt/qemu/channels/6dd5291e-6556-4d29-8b4e -ea896e627645.com.redhat.rhevm .vdsm"
/>
</channel>
<channel type="unix">
<target name="org.qemu.guest_agent.0" type="virtio" />
<source mode="bind"
path="/var/lib/libvirt/qemu/channels/6dd5291e-6556-4d29-8b4e -ea896e627645.org.qemu.guest_a gent.0"
/>
</channel>
<input bus="ps2" type="mouse" />
<memballoon model="virtio" />
<controller index="0" model="virtio-scsi" type="scsi" />
<controller index="0" ports="16" type="virtio-serial" />
<video>
<model heads="1" ram="65536" type="qxl" vgamem="16384"
vram="32768" />
</video>
<graphics autoport="yes" defaultMode="secure" passwd="*****"
passwdValidTo="1970-01-01T00:00:01" port="-1" tlsPort="-1" type="spice">
<channel mode="secure" name="main" />
<channel mode="secure" name="inputs" />
<channel mode="secure" name="cursor" />
<channel mode="secure" name="playback" />
<channel mode="secure" name="record" />
<channel mode="secure" name="display" />
<channel mode="secure" name="smartcard" />
<channel mode="secure" name="usbredir" />
<listen network="vdsm-ovirtmgmt" type="network" />
</graphics>
<interface type="bridge">
<mac address="00:1a:4a:16:01:54" />
<model type="virtio" />
<source bridge="br-int" />
<virtualport type="openvswitch" />
<link state="up" />
<boot order="2" />
<bandwidth />
<virtualport type="openvswitch">
<parameters
interfaceid="912cba79-982e-4a87-868e-241fedccb59a" />
</virtualport>
</interface>
<disk device="cdrom" snapshot="no" type="file">
<source
file="/rhev/data-center/mnt/h2-int.limetransit.com:_var_lib_ exports_iso/1d49c4bc-0fec-4503 -a583-d476fa3a370d/images/1111 1111-1111-1111-1111-1111111111 11/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@abrahamsson.com>
To: "Marcin Mirecki" <mmirecki@redhat.com>
Cc: "Ovirt Users" <users@ovirt.org>
Sent: Friday, January 6, 2017 9:00:26 PM
Subject: Re: [ovirt-users] Issue with OVN/OVS and mandatory
ovirtmgmt network
I created a new VM in the ui and assigned it to host h1. In
/var/log/ovirt-provider-ovn.log I get the following:
2017-01-06 20:54:11,940 Request: GET : /v2.0/ports
2017-01-06 20:54:11,940 Connecting to remote ovn database:
tcp:127.0.0.1:6641
2017-01-06 20:54:12,157 Connected (number of retries: 2)
2017-01-06 20:54:12,158 Response code: 200
2017-01-06 20:54:12,158 Response body: {"ports": [{"name":
"4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873", "network_id":
"e53554cf-e553-40a1-8d22-9c8d95ec0601", "device_owner": "oVirt",
"mac_address": "00:1a:4a:16:01:51", "id":
"4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873", "device_id":
"40cd7328-d575-4c3d-b656-9ef9bacc0078"}, {"name":
"92f6d3c8-68b3-4986-9c09-60bee04644b5", "network_id":
"e53554cf-e553-40a1-8d22-9c8d95ec0601", "device_owner": "oVirt",
"mac_address": "00:1a:4a:16:01:52", "id":
"92f6d3c8-68b3-4986-9c09-60bee04644b5", "device_id":
"4baefa8c-3822-4de0-9cd0-1d025bab7844"}]}
2017-01-06 20:54:12,160 Request: SHOW :
/v2.0/networks/e53554cf-e553-40a1-8d22-9c8d95ec0601
2017-01-06 20:54:12,160 Connecting to remote ovn database:
tcp:127.0.0.1:6641
2017-01-06 20:54:12,377 Connected (number of retries: 2)
2017-01-06 20:54:12,378 Response code: 200
2017-01-06 20:54:12,378 Response body: {"network": {"id":
"e53554cf-e553-40a1-8d22-9c8d95ec0601", "name": "ovirtbridge"}}
2017-01-06 20:54:12,380 Request: POST : /v2.0/ports
2017-01-06 20:54:12,380 Request body:
{
"port" : {
"name" : "nic1",
"binding:host_id" : "h1.limetransit.com",
"admin_state_up" : true,
"device_id" : "e8553a88-05f0-401d-8b9b-5fff77f7bbbe",
"device_owner" : "oVirt",
"mac_address" : "00:1a:4a:16:01:54",
"network_id" : "e53554cf-e553-40a1-8d22-9c8d95ec0601"
}
}
2017-01-06 20:54:12,380 Connecting to remote ovn database:
tcp:127.0.0.1:6641
2017-01-06 20:54:12,610 Connected (number of retries: 2)
2017-01-06 20:54:12,614 Response code: 200
2017-01-06 20:54:12,614 Response body: {"port": {"name":
"912cba79-982e-4a87-868e-241fedccb59a", "network_id":
"e53554cf-e553-40a1-8d22-9c8d95ec0601", "device_owner": "oVirt",
"mac_address": "00:1a:4a:16:01:54", "id":
"912cba79-982e-4a87-868e-241fedccb59a", "device_id":
"e8553a88-05f0-401d-8b9b-5fff77f7bbbe"}}
h1:/var/log/messages
Jan 6 20:54:12 h1 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl
--timeout=5 -- --if-exists del-port vnet1 -- add-port br-int vnet1 --
set Interface vnet1
"external-ids:attached-mac=\"00:1a:4a:16:01:54\"" --
set Interface vnet1
"external-ids:iface-id=\"20388407-0f76-41d8-97aa-8e2b5978f90 8\"" -- set
Interface vnet1
"external-ids:vm-id=\"6dd5291e-6556-4d29-8b4e-ea896e627645\" " -- set
Interface vnet1 external-ids:iface-status=active
[root@h2 ~]# ovn-nbctl show
switch e53554cf-e553-40a1-8d22-9c8d95ec0601 (ovirtbridge)
port 4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873
addresses: ["00:1a:4a:16:01:51"]
port 912cba79-982e-4a87-868e-241fedccb59a
addresses: ["00:1a:4a:16:01:54"]
port 92f6d3c8-68b3-4986-9c09-60bee04644b5
addresses: ["00:1a:4a:16:01:52"]
port ovirtbridge-port2
addresses: ["unknown"]
port ovirtbridge-port1
addresses: ["unknown"]
[root@h2 ~]# ovn-sbctl show
Chassis "6e4dd29f-7607-48d7-8e5a-eef4c6aeefb5"
hostname: "h2.limetransit.com"
Encap geneve
ip: "148.251.126.50"
options: {csum="true"}
Port_Binding "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873"
Port_Binding "ovirtbridge-port1"
Chassis "4f10fb04-8fb2-48d7-8a3f-ea6444c02cf9"
hostname: "h1.limetransit.com"
Encap geneve
ip: "144.76.84.73"
options: {csum="true"}
Port_Binding "ovirtbridge-port2"
Port_Binding "92f6d3c8-68b3-4986-9c09-60bee04644b5"
I.e. same issue
/Sverker
Den 2017-01-06 kl. 20:49, skrev Sverker Abrahamsson:
The port is created from Ovirt UI, the ovs-vsctl command below is
executed when VM is started. In /var/log/ovirt-provider-ovn.log on h2
I get the following:
2017-01-06 20:19:25,452 Request: GET : /v2.0/ports
2017-01-06 20:19:25,452 Connecting to remote ovn database:
tcp:127.0.0.1:6641
2017-01-06 20:19:25,670 Connected (number of retries: 2)
2017-01-06 20:19:25,670 Response code: 200
2017-01-06 20:19:25,670 Response body: {"ports": [{"name":
"4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873", "network_id":
"e53554cf-e553-40a1-8d22-9c8d95ec0601", "device_owner": "oVirt",
"mac_address": "00:1a:4a:16:01:51", "id":
"4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873", "device_id":
"40cd7328-d575-4c3d-b656-9ef9bacc0078"}, {"name":
"92f6d3c8-68b3-4986-9c09-60bee04644b5", "network_id":
"e53554cf-e553-40a1-8d22-9c8d95ec0601", "device_owner": "oVirt",
"mac_address": "00:1a:4a:16:01:52", "id":
"92f6d3c8-68b3-4986-9c09-60bee04644b5", "device_id":
"4baefa8c-3822-4de0-9cd0-1d025bab7844"}]}
2017-01-06 20:19:25,673 Request: PUT :
/v2.0/ports/92f6d3c8-68b3-4986-9c09-60bee04644b5
2017-01-06 20:19:25,673 Request body:
{
"port" : {
"binding:host_id" : "h1.limetransit.com",
"security_groups" : null
}
}
2017-01-06 20:19:25,673 Connecting to remote ovn database:
tcp:127.0.0.1:6641
2017-01-06 20:19:25,890 Connected (number of retries: 2)
2017-01-06 20:19:25,891 Response code: 200
2017-01-06 20:19:25,891 Response body: {"port": {"name":
"92f6d3c8-68b3-4986-9c09-60bee04644b5", "network_id":
"e53554cf-e553-40a1-8d22-9c8d95ec0601", "device_owner": "oVirt",
"mac_address": "00:1a:4a:16:01:52", "id":
"92f6d3c8-68b3-4986-9c09-60bee04644b5", "device_id":
"4baefa8c-3822-4de0-9cd0-1d025bab7844"}}
In /var/log/messages on h1 I get the following:
Jan 6 20:18:56 h1 dbus-daemon: dbus[1339]: [system] Successfully
activated service 'org.freedesktop.problems'
Jan 6 20:19:26 h1 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl
--timeout=5 -- --if-exists del-port vnet0 -- add-port br-int vnet0 --
set Interface vnet0 "external-ids:attached-mac=\"00:1a:4a:16:01:52\""
-- set Interface vnet0
"external-ids:iface-id=\"72dafda5-03c2-4bb6-bcb6-241fa5c0a1f 3\"" --
set Interface vnet0
"external-ids:vm-id=\"4d0c134a-11a0-40f4-b2fb-c13c17c7251c\" " -- set
Interface vnet0 external-ids:iface-status=active
Jan 6 20:19:26 h1 kernel: device vnet0 entered promiscuous mode
Jan 6 20:19:26 h1 avahi-daemon[1391]: Registering new address record
for fe80::fc1a:4aff:fe16:152 on vnet0.*.
Jan 6 20:19:26 h1 systemd-machined: New machine qemu-4-CentOS72.
Jan 6 20:19:26 h1 systemd: Started Virtual Machine qemu-4-CentOS72.
Jan 6 20:19:26 h1 systemd: Starting Virtual Machine qemu-4-CentOS72.
[root@h2 ~]# ovn-nbctl show
switch e53554cf-e553-40a1-8d22-9c8d95ec0601 (ovirtbridge)
port 4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873
addresses: ["00:1a:4a:16:01:51"]
port 92f6d3c8-68b3-4986-9c09-60bee04644b5
addresses: ["00:1a:4a:16:01:52"]
port ovirtbridge-port2
addresses: ["unknown"]
port ovirtbridge-port1
addresses: ["unknown"]
[root@h2 ~]# ovn-sbctl show
Chassis "6e4dd29f-7607-48d7-8e5a-eef4c6aeefb5"
hostname: "h2.limetransit.com"
Encap geneve
ip: "148.251.126.50"
options: {csum="true"}
Port_Binding "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873"
Port_Binding "ovirtbridge-port1"
Chassis "4f10fb04-8fb2-48d7-8a3f-ea6444c02cf9"
hostname: "h1.limetransit.com"
Encap geneve
ip: "144.76.84.73"
options: {csum="true"}
Port_Binding "ovirtbridge-port2"
I.e. the port is set up with the wrong ID and not attached to OVN.
If I correct external-ids:iface-id like this:
[root@h1 ~]# ovs-vsctl set Interface vnet0
"external-ids:iface-id=\"92f6d3c8-68b3-4986-9c09-60bee04644b 5\""
then sb is correct:
[root@h2 ~]# ovn-sbctl show
Chassis "6e4dd29f-7607-48d7-8e5a-eef4c6aeefb5"
hostname: "h2.limetransit.com"
Encap geneve
ip: "148.251.126.50"
options: {csum="true"}
Port_Binding "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873"
Port_Binding "ovirtbridge-port1"
Chassis "4f10fb04-8fb2-48d7-8a3f-ea6444c02cf9"
hostname: "h1.limetransit.com"
Encap geneve
ip: "144.76.84.73"
options: {csum="true"}
Port_Binding "ovirtbridge-port2"
Port_Binding "92f6d3c8-68b3-4986-9c09-60bee04644b5"
I don't know from where the ID 72dafda5-03c2-4bb6-bcb6-241fa5c0a1f3
comes from, doesn't show in any log other than /var/log/messages.
If I do the same exercise on the same host as engine is running on
then the port for the VM gets the right id and is working from
beginning.
/Sverker
Den 2017-01-03 kl. 10:23, skrev Marcin Mirecki:
How did you create this port?
From the oVirt engine UI?
The OVN provider creates the port when you add the port in the
engine UI,
it is then plugged into the ovs bridge by the VIF driver.
Please attach /var/log/ovirt-provider-ovn.log
----- Original Message -----
From: "Sverker Abrahamsson"<sverker@abrahamsson.com >
To: "Marcin Mirecki"<mmirecki@redhat.com>
Cc: "Ovirt Users"<users@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@h2 env3]# ovn-nbctl show
switch e53554cf-e553-40a1-8d22-9c8d95ec0601 (ovirtbridge)
port 4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873
addresses: ["00:1a:4a:16:01:51"]
port 92f6d3c8-68b3-4986-9c09-60bee04644b5
addresses: ["00:1a:4a:16:01:52"]
port ovirtbridge-port2
addresses: ["unknown"]
port ovirtbridge-port1
addresses: ["unknown"]
[root@h2 env3]# ovn-sbctl show
Chassis "6e4dd29f-7607-48d7-8e5a-eef4c6aeefb5"
hostname: "h2.limetransit.com"
Encap geneve
ip: "148.251.126.50"
options: {csum="true"}
Port_Binding "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873"
Port_Binding "ovirtbridge-port1"
Chassis "4f10fb04-8fb2-48d7-8a3f-ea6444c02cf9"
hostname: "h1.limetransit.com"
Encap geneve
ip: "144.76.84.73"
options: {csum="true"}
Port_Binding "ovirtbridge-port2"
Port 92f6d3c8-68b3-4986-9c09-60bee04644b5 is for the new VM which is
started on h1, but it is not assigned to that chassis. The reason is
that on h1 the port on br-int is created like this:
ovs-vsctl --timeout=5 -- --if-exists del-port vnet0 -- add-port
br-int
vnet0 -- set Interface vnet0
"external-ids:attached-mac=\"00:1a:4a:16:01:52\"" -- set
Interface vnet0
"external-ids:iface-id=\"35bcbe31-2c7e-4d97-add9-ce150eeb2f1 1\""
-- 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-60bee04644b 5\""
-- set
Interface vnet0
"external-ids:vm-id=\"4d0c134a-11a0-40f4-b2fb-c13c17c7251c\" " -- set
Interface vnet0 external-ids:iface-status=active
sb db after correcting the port:
Chassis "6e4dd29f-7607-48d7-8e5a-eef4c6aeefb5"
hostname: "h2.limetransit.com"
Encap geneve
ip: "148.251.126.50"
options: {csum="true"}
Port_Binding "4981ee5f-6e15-4bd5-a1cf-7ead9bdd5873"
Port_Binding "ovirtbridge-port1"
Chassis "4f10fb04-8fb2-48d7-8a3f-ea6444c02cf9"
hostname: "h1.limetransit.com"
Encap geneve
ip: "144.76.84.73"
options: {csum="true"}
Port_Binding "ovirtbridge-port2"
Port_Binding "92f6d3c8-68b3-4986-9c09-60bee04644b5"
I don't know from where the faulty id comes from, it's not in any
logs.
In the domain xml as printed in vdsm.log the id is correct:
<interface type="bridge">
<mac address="00:1a:4a:16:01:52" />
<model type="virtio" />
<source bridge="br-int" />
<virtualport type="openvswitch" />
<link state="up" />
<boot order="2" />
<bandwidth />
<virtualport type="openvswitch">
<parameters
interfaceid="92f6d3c8-68b3-4986-9c09-60bee04644b5" />
</virtualport>
</interface>
Where is the ovs-vsctl command line built for this call?
/Sverker
Den 2017-01-02 kl. 13:40, skrev Sverker Abrahamsson:
Got it to work now by following the env8 example in OVN tutorial,
where a port is added with type l2gateway. Not sure how that is
different from the localnet variant, but didn't suceed in
getting that
one working. Now I'm able to ping and telnet over the tunnel,
but not
ssh even when the port is answering on telnet. Neither does nfs
traffic work even though mount did. Suspecting MTU issue. I did
notice
that ovn-controller starts too early, before network interfaces are
established and hence can't reach the db. As these is a purely
OVS/OVN
issue I'll ask about it on their mailing list.
Getting back to the original issue with Ovirt, I've now added the
second host h1 to ovirt-engine. Had to do the same as with h2 to
create a dummy ovirtmgmt network but configured access via the
public
IP. My firewall settings was replaced with iptables config and
vdsm.conf was overwritten when engine was set up, so those had
to be
manually restored. It would be preferable if it would be
possible to
configure ovirt-engine that it does not "own" the host and instead
comply with the settings it has instead of enforcing it's own
view..
Apart from that it seems the second host works, although I need to
resolve the traffic issue over the OVS tunnel.
/Sverker
Den 2017-01-02 kl. 01:13, skrev Sverker Abrahamsson:
1. That is not possible as ovirt (or vdsm) will rewrite the
network
configuration to a non-working state. That is why I've set that
if as
hidden to vdsm and is why I'm keen on getting OVS/OVN to work
2. I've been reading the doc for OVN and starting to connect the
dots, which is not trivial as it is complex. Some insights
reached:
First step is the OVN database, installed by
openvswitch-ovn-central,
which I currently have running on h2 host. The 'ovn-nbctl' and
'ovn-sbctl' commands are only possible to execute on a database
node.
Two ip's are given to 'vdsm-tool ovn-config <ip to database>
<tunnel
ip>' as arguments, where <ip to database> is how this OVN node
reaches the database and <tunnel ip> is the ip to which other OVN
nodes sets up a tunnel to this node. I.e. it is not for creating a
tunnel to the database which I thought first from the
description in
blog post.
The tunnel between OVN nodes is of type geneve which is a UDP
based
protocol but I have not been able to find anywhere which port
is used
so that I can open it in firewalld. I have added OVN on another
host,
called h1, and connected it to the db. I see there is traffic
to the
db port, but I don't see any geneve traffic between the nodes.
Ovirt is now able to create it's vnet0 interface on the br-int ovs
bridge, but then I run into the next issue. How do I create a
connection from the logical switch to the physical host? I need
that
to a) get a connection out to the internet through a
masqueraded if
or ipv6 and b) be able to run a dhcp server to give ip's to the
VM's.
/Sverker
Den 2016-12-30 kl. 18:05, skrev Marcin Mirecki:
1. Why not use your physical nic for ovirtmgmt then?
2. "ovn-nbctl ls-add" does not add a bridge, but a logical
switch.
br-int is an internal OVN implementation detail, which
the user
should not care about. What you see in the ovirt UI are
logical
networks. They are implemented as OVN logical switches
in case
of the OVN provider.
Please look at:
http://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/
You can get the latest rpms from here:
http://resources.ovirt.org/repos/ovirt/experimental/master/o virt-provider-ovn_fc24_46/rpm/ fc24/noarch/
----- Original Message -----
From: "Sverker Abrahamsson"<sverker@abrahamsson.com >
To: "Marcin Mirecki"<mmirecki@redhat.com>
Cc: "Ovirt Users"<users@ovirt.org>
Sent: Friday, December 30, 2016 4:25:58 PM
Subject: Re: [ovirt-users] Issue with OVN/OVS and mandatory
ovirtmgmt network
1. No, I did not want to put the ovirtmgmt bridge on my physical
nic as
it always messed up the network config making the host
unreachable. I
have put a ovs bridge on this nic which I will use to make
tunnels
when
I add other hosts. Maybe br-int will be used for that
instead, will
see
when I get that far.
As it is now I have a dummy if for ovirtmgmt bridge but this
will
probably not work when I add other hosts as that bridge cannot
connect
to the other hosts. I'm considering keeping this just as a
dummy to
keep
ovirt engine satisfied while the actual communication will
happen
over
OVN/OVS bridges and tunnels.
2. On
https://www.ovirt.org//develop/release-management/features/o virt-ovn-provider/
there is instructions how to add an OVS bridge to OVN with
|ovn-nbctl
ls-add <network name>|. If you want to use br-int then it makes
sense to
make that bridge visible in ovirt webui under networks so
that it
can be
selected for VM's.
It quite doesn't make sense to me that I can select other
network
for my
VM but then that setting is not used when setting up the
network.
/Sverker
Den 2016-12-30 kl. 15:34, skrev Marcin Mirecki:
Hi,
The OVN provider does not require you to add any bridges
manually.
As I understand we were dealing with two problems:
1. You only had one physical nic and wanted to put a bridge
on it,
attaching the management network to the bridge. This
was the
reason for
creating the bridge (the recommended setup would be
to used a
separate
physical nic for the management network). This bridge
has
nothing to
do with the OVN bridge.
2. OVN - you want to use OVN on this system. For this you
have to
install
OVN on your hosts. This should create the br-int bridge,
which are
then used by the OVN provider. This br-int bridge
must be
configured
to connect to other hosts using the geneve tunnels.
In both cases the systems will not be aware of any bridges you
create.
They need a nic (be it physical or virtual) to connect to other
system.
Usually this is the physical nic. In your case you decided
to put
a bridge
on the physical nic, and give oVirt a virtual nic attached
to this
bridge.
This works, but keep in mind that the bridge you have
introduced
is outside
of oVirt's (and OVN) control (and as such is not supported).
What is the purpose ofI am not quite sure I understand.
adding my bridges to Ovirt through the external provider and
configure
them on my VM
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@abrahamsson.com >
To: "Marcin Mirecki"<mmirecki@redhat.com>
Cc: "Ovirt Users"<users@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@abrahamsson.com >
To: "Marcin Mirecki"<mmirecki@redhat.com>
Cc: "Ovirt Users"<users@ovirt.org>, "Numan Siddique"
<nusiddiq@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@redhat.com>
Till: Sverker Abrahamsson<sverker@abrahamsson.com >
Kopia: Ovirt Users<users@ovirt.org>, Lance Richardson
<lrichard@redhat.com>, Numan
Siddique<nusiddiq@redhat.com>
Let me add the OVN team.
Lance, Numan,
Can you please look at this?
Trying to plug a vNIC results in:
More details belowDec 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-e630017dcdd 8\""
--
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:
----- Original Message -----
From: "Sverker Abrahamsson"<sverker@abrahamsson.com >
To: "Marcin Mirecki"<mmirecki@redhat.com>
Cc: "Ovirt Users"<users@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@abrahamsson.com >
To: "Marcin Mirecki"<mmirecki@redhat.com>
Cc: "Ovirt Users"<users@ovirt.org>
Sent: Thursday, December 29, 2016 11:44:32 AM
Subject: Re: [ovirt-users] Iss
[Message clipped]
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users