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

Host evacuation doesn't respect default migration network #7982

Open
chii0815 opened this issue Sep 10, 2024 · 7 comments
Open

Host evacuation doesn't respect default migration network #7982

chii0815 opened this issue Sep 10, 2024 · 7 comments

Comments

@chii0815
Copy link

Are you using XOA or XO from the sources?

both

Which release channel?

stable

Provide your commit number

7c31b

Describe the bug

Evacuation of a host in a ha pool doesn't respect the "default migration network" set on pool.
It was implementen in #5802
It uses the eth0 (Management Interface) instead the choosen bond0.

Works when migrating VMs manually via
VM > select VM > Migrate

Did check this on XOA 5.95.2 (stable) and upgraded to 5.98.0 (latest). I also tryed it on a fresh installed XO from Source.

Error message

no error message but traffic is not on choosen interface.

To reproduce

  1. Pools > select pool > Advanced
  2. scroll down to Misc
  3. select an "default migration network"
  4. Go to Hosts > select host with VMs on it > Advanced
  5. Click on "Enable maintenance mode"
  6. Go to Stats
  7. See traffic on wrong interface

Expected behavior

  1. Pools > select pool > Advanced
  2. scroll down to Misc
  3. select an "default migration network"
  4. Go to Hosts > select host with VMs on it > Advanced
  5. Click on "Enable maintenance mode"
  6. Go to Stats
  7. See traffic on choosen interface or if bond on member interface

Screenshots

configured bond of eth6 and eth7
bond

configured default migration network
def_mig_net

traffic graph after evacuation
evacuation

Node

18.20.2

Hypervisor

XCP-NG 8.2.1

Additional context

No response

@chii0815
Copy link
Author

Moved my management to an vlan on the bond0 and now it's using the bond... but i belive the "default migration network" should be used for evacuation.

@olivierlambert
Copy link
Member

olivierlambert commented Sep 10, 2024

Hi,

Host.evacuate isn't handled by Xen Orchestra but by XCP-ng API, the XAPI. I will check though how XO sets the migration and network and if XAPI is aware of it.

edit: OK got it. XO will set xo:migrationNetwork in the Other config of the pool. But host.evacuate is a XAPI function that's not aware of it. That explains the result you have. I don't know what would be the best approach for this.

@olivierlambert
Copy link
Member

We need to discuss the best approach:

  1. Is there a way to set a migration network by default for a XAPI
  2. If not, first option is to implement the migration network preference in XAPI
  3. Alternative is to get host.evacuate handled by XO and not XAPI.

@chii0815
Copy link
Author

We need to discuss the best approach:

1. Is there a way to set a migration network by default for a XAPI

2. If not, first option is to implement the migration network preference in XAPI

3. Alternative is to get host.evacuate handled by XO and not XAPI.

Didn't @benjamreis mentioned in #5802 that host.evacuate had a new method network? that's why it was implementet in #5851.

@benjamreis
Copy link
Contributor

Indeed but it'll be available for XCP-ng/XS 8.3 and later.

@chii0815
Copy link
Author

Indeed but it'll be available for XCP-ng/XS 8.3 and later.

ah ok thanks... but you also mentioned that it was in 8.2 testing repo in Jun 2021 so i believe that it is already in 8.2.1 repo. Maybe it should be mentioned in the documentation that this is not fully supported at the moment.

@julien-f
Copy link
Member

XO already pass the default migration network to host.evacuate when supported and fall back to not use it when it's not.

I agree that it should documented.

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

4 participants