Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No way to use Floating IP with BRIDGE interfaces #2607

Closed
7 tasks
kvaps opened this issue Nov 16, 2018 · 3 comments
Closed
7 tasks

No way to use Floating IP with BRIDGE interfaces #2607

kvaps opened this issue Nov 16, 2018 · 3 comments

Comments

@kvaps
Copy link
Contributor

kvaps commented Nov 16, 2018

Description
There is still issues with Floating IP, no way to use it with bridged networks as non privileged user.

To Reproduce
Steps to reproduce the behavior.

Make sure that you have this option on your oned.conf:

VM_RESTRICTED_ATTR = "NIC/BRIDGE"

Create network with BRIDGE attribute

Login as user without admin rights

Create new Virtual Router

Attach NIC to Virtual Router (Mark Floating IP checkbox)

You will see how new NIC appears, but you will get this message:

[one.vrouter.attachnic] NIC includes a restricted attribute BRIDGE

Ok, try to remove this adapter, no, another error:

[one.vrouter.detachnic] Could not detach NIC with NIC_ID 0, it does not exist.

You should remove whole VR then

Expected behavior
Working Floating IP

Details

  • Affected Component: Core
  • Hypervisor: KVM
  • Version: 5.6.0

Progress Status

  • Branch created
  • Code committed to development branch
  • Testing - QA
  • Documentation
  • Release notes - resolved issues, compatibility, known issues
  • Code committed to upstream release/hotfix branches
  • Documentation committed to upstream release/hotfix branches
@kvaps kvaps changed the title NIC includes a restricted attribute BRIDGE when using Floting IP No way to use Floting IP with BRIDGE interfaces Nov 16, 2018
@kvaps kvaps changed the title No way to use Floting IP with BRIDGE interfaces No way to use Floating IP with BRIDGE interfaces Nov 16, 2018
@kvaps
Copy link
Contributor Author

kvaps commented Nov 28, 2018

@juanmont can you assign labels for this bug please?

@al3xhh
Copy link
Contributor

al3xhh commented Nov 29, 2018

Hi @kvaps, I follow your steps to reproduce the issue, but I was able to add the nic, here you have the output of the log and the rest of the commands. Could you give me more information about the issue, to try to reproduce it?

Thu Nov 29 11:31:26 2018 [Z0][ReM][D]: Req:7520 UID:2 one.vrouter.attachnic result SUCCESS, 0
Thu Nov 29 11:31:26 2018 [Z0][ReM][D]: Req:7584 UID:2 one.vrouter.info invoked , 0
Thu Nov 29 11:31:26 2018 [Z0][ReM][D]: Req:7584 UID:2 one.vrouter.info result SUCCESS, "0<..."

VM NICS
ID NETWORK BRIDGE IP MAC PCI_ID
0 testing_net virbr0 192.168.122.3 02:00:c0:a8:7a:03
192.168.122.2 (VRouter)

$ oneuser show testing_user
USER 2 INFORMATION
ID : 2
NAME : testing_user
GROUP : users
PASSWORD : 975840c5f7301446b158a4b3d1444cc855995f7e
AUTH_DRIVER : core
ENABLED : Yes

@kvaps
Copy link
Contributor Author

kvaps commented Nov 29, 2018

Hi, just checked that, problem occurs only when bridge is set as variable to AR, try that:

cat > /tmp/test_network.conf <<EOT
NAME="test"
BRIDGE="vmbr0"
DNS="8.8.8.8 8.8.4.4"
FILTER_IP_SPOOFING="YES"
FILTER_MAC_SPOOFING="YES"
OUTER_VLAN_ID=""
PHYDEV="bond0"
SECURITY_GROUPS="0"
VLAN_ID="100"
VN_MAD="802.1Q"
AR=[
  BRIDGE="vmbr0v100",
  GATEWAY="172.16.100.1",
  IP="172.16.100.200",
  SIZE="50",
  TYPE="IP4",
  VLAN_ID="100" ]
AR=[
  BRIDGE="vmbr0v100",
  GATEWAY="172.16.101.1",
  IP="172.16.101.200",
  SIZE="50",
  TYPE="IP4",
  VLAN_ID="101" ]
EOT
onevnet create /tmp/test_network.conf

rsmontero pushed a commit that referenced this issue Dec 3, 2018
rsmontero pushed a commit that referenced this issue Dec 3, 2018
Co-authored-by: Alejandro Huertas <[email protected]>
(cherry picked from commit 11523ef)
rsmontero pushed a commit that referenced this issue Dec 4, 2018
Co-authored-by: Alejandro Huertas <[email protected]>
(cherry picked from commit 11523ef)
rsmontero pushed a commit that referenced this issue May 17, 2023
When cloned rbd is moved to the CEPH_TRASH, the
clone snapshot (@snap) could not be deleted which
can lead to data loss when switching the image to
persistent and back. Flattening rbd before moving
to trash should fix it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants