XCP-ng 8.3 betas and RCs feedback 🚀

ThierryC01

@florent on the 8.3 beta1 with the latest XOA available I have tested the creation of a new NFS remote with success.

I tried to create a new SMB connection with a wrong password to test the edit and it worked perfectly, the only thing is that the alert that showed up during the wrong password connection does not disappear once the connection is established with a correct password even after multiple page refresh, disable, enable, refresh.

Xcp-ng 8.3 remote.png

archw

As part of the learning process, I've now upgraded three machines from 8.3 to 8.3 beta 1. In each case, it did not upgrade the host. Instead it overwrote what was there and I had to reinstall the VM's from backup. Not the end of the world, just thought y'all might want to know.

archw

I'm trying to migrate an esxi VM to XCP-ng.

The VM is turned off.
"Thin mode" is off
"Stop the source VM" is off
"Stop on error" is on.

I have tried doing this:
A. through vcenter
B. drive to the esxi host
C. using the IP address in lieu of the dns name.

In each case, as soon as I click "Import" I get the message below.

vm.importMultipleFromEsxi
{
  "concurrency": 2,
  "host": "vcenter.internal.local",
  "network": "ca618529-000b-0c6e-52ba-f6c985134163",
  "password": "* obfuscated *",
  "sr": "b3b03de1-f7d1-92ca-68a4-40370e7649d3",
  "sslVerify": false,
  "stopOnError": true,
  "stopSource": false,
  "thin": false,
  "user": "adminname@vspehere.locall",
  "vms": [
    "vm-2215"
  ]
}
{
  "succeeded": {},
  "message": "Cannot read properties of undefined (reading 'startsWith')",
  "name": "TypeError",
  "stack": "TypeError: Cannot read properties of undefined (reading 'startsWith')
    at Esxi.#inspectVmdk (file:///opt/xo/xo-builds/xen-orchestra-202312090402/@xen-orchestra/vmware-explorer/esxi.mjs:209:18)
    at Esxi.getTransferableVmMetadata (file:///opt/xo/xo-builds/xen-orchestra-202312090402/@xen-orchestra/vmware-explorer/esxi.mjs:293:40)
    at Task.runInside (/opt/xo/xo-builds/xen-orchestra-202312090402/@vates/task/index.js:158:22)
    at Task.run (/opt/xo/xo-builds/xen-orchestra-202312090402/@vates/task/index.js:141:20)
    at MigrateVm.migrationfromEsxi (file:///opt/xo/xo-builds/xen-orchestra-202312090402/packages/xo-server/src/xo-mixins/migrate-vm.mjs:177:28)
    at file:///opt/xo/xo-builds/xen-orchestra-202312090402/packages/xo-server/src/api/vm.mjs:1415:30
    at Task.runInside (/opt/xo/xo-builds/xen-orchestra-202312090402/@vates/task/index.js:158:22)
    at Task.run (/opt/xo/xo-builds/xen-orchestra-202312090402/@vates/task/index.js:141:20)
    at asyncEach.concurrency.concurrency (file:///opt/xo/xo-builds/xen-orchestra-202312090402/packages/xo-server/src/api/vm.mjs:1413:11)"
}

stormi

@archw As far as I can tell, this is related to Xen Orchestra (which handles the import from VMware), rather than to XCP-ng 8.3. Maybe you can open a dedicated thread for your issue?

Danp

@archw said in XCP-ng 8.3 beta :

As part of the learning process, I've now upgraded three machines from 8.3 to 8.3 beta 1. In each case, it did not upgrade the host. Instead it overwrote what was there and I had to reinstall the VM's from backup.

I assume that's a typo and you were upgrading from 8.2 to 8.3 beta. Your feedback would be more beneficial if you shared some additional details, such as --

Were these hosts in separate pools or a shared pool?
Explain the process you followed to perform each upgrade
etc

archw

@Danp

oops...yes...that's a typo and I was upgrading from 8.2 to 8.3 beta.

"Were these hosts in separate pools or a shared pool?"
They were on separate pools (I'm I understand you correctly). Its just one XCP-NG machine.

"Explain the process you followed to perform each upgrade"

I booted from the 8.3 DVD then just followed the instructions on the install screens accepting the defaults as I went along.

archw

@stormi

OK! I wasn't sure if it was ok to post that over there since this is on a beta machine.

Thanks!

john.c

When performing a reboot during the installation of XCP-ng 8.3 beta its currently not ejecting the installation media at the appropriate point.

This needs to occur so that the system will not attempt to do another boot from the installation media. This is especially important when the installation has completed, so that it can be ensured that the system will not boot from it again.

stormi

@john-c Thanks for the feedback. This is not new behaviour, in fact, though I agree it could be better. In the end, the installer tells you everything is ok and that you should eject the medium before rebooting.

john.c

@stormi said in XCP-ng 8.3 beta :

@john-c Thanks for the feedback. This is not new behaviour, in fact, though I agree it could be better. In the end, the installer tells you everything is ok and that you should eject the medium before rebooting.

It may not be new behaviour but there's KVM client software and/or hardware which give messages if you try an unmount (eject) through them, rather than the using console commands ("eject"). Also it would help when doing the installation through SSH remotely.

If XCP-ng were to do it automatically itself it can then be sure that it was done at the right point, as some installation ISO sessions don't do well when ejected (unmounted) manually by the user at the wrong point. As CentOS 7 when using its installation ISO needs to do some actions during shutdown or preparations for reboot.

So at the very end of those preparations just before the reboot the installation media could automatically eject itself.

archw

Last night, a bunch of new updates came out for the beta of 8.3. After rebooting none of my VM‘s that have the boot firmware set to UEFI will boot.

Even if I try to create a new VM, if I set it to UEFI, a very quick black screen goes by (and it looks like it starts with the words “Guest has not initialized” but it goes by so fast you can’t see the rest of the words).

If you change it from UEFI back to bios it boots.

Any ideas?

stormi

@archw Are your VMs set to enable Secure Boot?

wilsonqanda

@archw Glad this is not only me I just add a post regarding this as well.

But this occur on my VMs as well on all my host and any new host i update to the latest revision in 8.3b (update 12/21/2023 note the previous 8.3b without the new patch work fine).

All i know is that when changing to UEFI to bios or default bios will work. It is stuck on boot loader count down instead. When i play with the boot loader and change the time to 0 PFSense boot fine. But if i change it to any # it will get stuck until i manually hit "enter". I haven't test it with all FreeBSD to see if this is the case but PFSense is a FreeBSD. But pretty sure something change in XCP-ng to cause this issue for the uefi setting in the lastest update.

(FYI none of them have secure boot so shouldn't matter i believe).

stormi

It's concerning that our internal CI didn't show any such issue. Can any of you open a support tunnel from XOA and open a support ticket so that I may have a direct look?

stormi

So, on a 8.3 alpha 2 where I imported UEFI VMs and then updated up to beta 2, the UEFI VMs still work.

I'll now try starting from 8.2.1, upgrading to alpha2 and then updating to beta2.

archw

@stormi
No...but, last night, for the heck of it, I tried turning it on, trying to boot, then turned it off. Nothing worked.

archw

@stormi
nopie!

stormi

@archw I'd like to understand what happens, before the end of the day and the winter holidays. Do you have an XOA VM where you could open a support tunnel?

archw

@john-c
BTW...I was finally able to see the entire message. The very quick black screen goes by and it says “Guest has not initialized the display (yet)"

stormi

@archw Otherwise, the contents of /var/log/xensource.log and /var/log/daemon.log would already be something useful.