I will create a card for this feature request to discuss with the whole XO team. I will keep you updated here

Hi @Andrew.
This PR should fix your issue https://github.com/vatesfr/xen-orchestra/pull/8854

MathieuRA opened this pull request in vatesfr/xen-orchestra

closed fix(xo-server): fix incorrect state when remove server #8854

Hi @irtaza9
You have a typo in your vm-templates URL.
fields instead of field

Hi @irtaza9
FYI, for about 2 years, VMs expose a creation field:

"creation": {
    "date": string,
    "template": string,
    "user": string
  },

With this you can filter VMs by creation.user to list only VMs created by a user.
/rest/v0/vms?filter=creation:user:<user-id>

Hi.
The IPMI plugin is only used to display hardware information if you are using mona_1.44gg.

To display if a BIOS update is available, we mainly fetch this endpoint: https://pictures.2cr.si/Images_site_web_Odoo/Pages_produit/VATES-BIOS_BMC_last-version.json

Does your host have access to this endpoint?
What is the ouput of xo-cli host.getBiosInfo id=<host-id>

Hi,
Since XO is a client, I don't think it's a good idea to have this kind of feature. In this case, a VM could be restarted from sources other than XO, and would not apply the new VDI size.

However, I believe we can handle this situation by implementing a modal that appears when editing the VDI size of a running VM. This modal can offer the option to restart the VM immediately and apply the changes. In my opinion, removing the "pending" state will prevent confusion

@MajorP93 can you try this branch? mra-fix-redirect-https It should fix your issue with redirectToHttps=true

Thank you all for your feedback!

@ashinobi Several bug fixes related to VM migration are on the xo5/fix-bulk-migration branch. Could you please test to see if they solve your issue?

While investigating the code, I found something unexpected. We don't have exactly the same behavior for migrating from the Home/VM view and from the VM view itself.
I will try to fix this and it might solve your problem.
I will come back to you when I have opened the branch to allow you to do some tests on it.

@fcgo Hi.
The OTP field is in the preferences property

E.g.

  {
    "email": "foo",
    "permission": "none",
    "pw_hash": "***obfuscated***",
    "preferences": {
      "otp": "<value>"
    },
    "groups": [],
    "id": "694e8856-04c9-448b-90ef-2beb96d119cb",
    "name": "foo",
    "href": "/rest/v0/users/694e8856-04c9-448b-90ef-2beb96d119cb"
  }

@MajorP93 can you try this branch? mra-fix-redirect-https It should fix your issue with redirectToHttps=true

@MajorP93 I think I am finally able to reproduce the bug. I will try to fix it

@acebmxer
Perfect.
Thank you all as well! Early testing and feedback are very precious to us.

@acebmxer I want logs from the journalctl.
sudo systemctl restart xo-server
sudo journalctl -fu xo-server

@MajorP93 various fixes have been performed on master.

Your config file should look like this

[http.mounts]
# Uncomment to setup a default version.
# Otherwise, XO5 will be the default for stable channel and XO6 for latest and source
# '/' = '../xo-web/dist/'

'/v5' = '../xo-web/dist/'
'/v6' = '../../@xen-orchestra/web/dist/'

[http.proxies]
# [port] is used to reuse the same port declared in [http.listen.0]
'/v5/api' = '[protocol]//localhost:[port]/api'
'/v5/api/updater' = 'ws://localhost:9001'
'/v5/rest' = 'http://localhost:[port]/rest'

If you are using a different configuration file that overrides the default configuration, please verify that the paths to xo-5 and xo-6 are correct. You can use absolute paths if necessary.

@acebmxer Can you provide me with the logs from xo-server at its launch?

@acebmxer
Just update your config as bellow

[http.mounts]
164 # Uncomment to setup a default version.
165 # Otherwise, XO5 will be the default for stable channel and XO6 for latest and source
166 # '/' = '../xo-web/dist/'
167 
168 '/v5' = '../xo-web/dist/'  
169 '/' = '../../@xen-orchestra/web/dist/'
170 
171 [http.proxies]
172 # [port] is used to reuse the same port declared in [http.listen.0]
173 '/v5/api' = '[protocol]//localhost:[port]/api'
174 '/v5/api/updater' = 'ws://localhost:9001'
175 '/v5/rest' = 'http://localhost:[port]/rest'

@acebmxer
The first configuration file you show exposes XO5 by default and exposes XO6 on the v6 endpoint
The second configuration file doesn't work because you expose XO5 on the v6 endpoint, but your proxies still point to v5 (changing your proxies to /v6/api, /v6/api/updater and /v6/rest should work, but it seems weird to expose XO5 on a v6 endpoint)
The original config exposes XO5 on v5, XO6 on v6 and /

@Kptainflintt Please provide us the XO-server log that concerns the connection error, authentication is supposed to work as before.