XCP-ng 8.3 betas and RCs feedback 🚀

ThierryC01

@laurentm No, for some stupid reason, the LVM volume was 100% full and I could not write any disk configuration nor expand the volume until I got rid of some logs.gz. All this happened during an update of XOA, I think there should be some safeguard in Linux to avoid such situation.

I will install a new XOA VM somewhere else as a backup since the container does not update to the latest commit. I hope they could sync the backup configuration.

florent

@ThierryC01 said in XCP-ng 8.3 beta :

@florent That is the theory yes, but in reality, editing the password fails.

Does it work with a newly created remote ? i.e. you create a new samba, it connects, you edit the password, it still works ?

bufanda

@ThierryC01 What Container Image do you use. I personally use this container

https://github.com/Ezka77/xen-orchestra-ce

It builds weekly and follows the master of xen-orchestra. So latest version is always most updated one.

stormi

@bufanda Let's try to stay on the topic of XCP-ng 8.3 beta

bufanda

@stormi Yeah sure, just thought it may help with the issue that was reported if the container used is outdated.

But anyways to the topic of XPC-NG 8.3beta. Are there any updates planned in the near future it has been a while since I recieved Updates on my test cluster. And while I don't run an AMD Processor on my test cluster there were security fixes for 8.2 but they didn't made to my 8.3 or did the repo config change and I missed that?

stormi

@bufanda So, yes, we have a big update in the pipe, but we still have bits to tweak before we can push it to all testers.

Regarding security updates, we don't offer any guarantee regarding the update delay on the beta, until the final release.

bufanda

@stormi Thx for the info. And I understand that there is no guarantee, was just curious if I had a problem on my cluster or if there was really nothing inbetween. It's a test cluster in the end so no mission critical things running on it anyways.

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).