XCP-ng 8.3 betas and RCs feedback 🚀

Dennis 0

@john-c Are you certain that the IPv6 address+DNS configuration obtained on your laptop + CentOS-machine is actually from DHCP and not from SLAAC?

Can you send the the IPv6-address you got on your laptop? (Possibly only the last 64 bits if not comfortable sending the entire IP)

john.c

@Dennis-0 Yes I can be certain. As the laptop OS (Windows 10) though later to go Linux. It allows you to configure the automatic IP assignment protocol used. In this case it was set to "Automatic (DHCP)", the option can be set to that or manual. The manual option is another way of saying Static IP address.

39b5:5b18:bfa2

Dennis 0

@john-c
I'm not entirely sure I understand your writing correctly, but be aware that "Automatic (DHCP)" can mean both SLAAC and DHCP. DHCP can't stand alone on the network - SLAAC is also needed for route announcement, so you either get defaultroute/address/DNS from SLAAC only or SLAAC+DHCP. Never DHCP alone.

Although it is by no means a bulletproof "method", the address part of the last bits of your IP seems a bit too "random" compared to a DHCP-based address - at least from my experience. In the networks I've seen it looks more like DHCP tends to give out more sequential addresses like ::1000:1044.

You've posted a screenshot further up which has two IPv6-addresses assigned. Both a ULA and a GUA. They are almost definitely SLAAC-based as they both have the last 64-bits in common and looks like EUI64-based. Do you get addresses from both subnets on your laptop too?

What kind of router do you have on your network? Is it some Busiess-grade Cisco, Juniper etc. or i.e OpenWRT which defaults to announcing a ULA-network (not that others can't, but not that typical AFAIK).

alex821982

Please tell me, is it true that machines from 8.3 are not copied to 8.2 ?
Copied some machines from 8.2 to 8.3, but does not copy back.

stormi

@alex821982 Yes, migration to a lower release is not possible. However you can replicate them using Xen Orchestra's replication feature, which is a way to workaround this constraint.

alex821982

@stormi Thanks, it works that way)

olivierlambert

Replication or warm migration will work, indeed

alex821982

Copied, I get the following error when starting up

FAILED_TO_START_EMULATOR(OpaqueRef:1286de32-6c5a-4e51-b85c-794e66b4d3f7, varstored, Daemon exited unexpectedly)

stormi

@alex821982 Interesting. There have been changes in UEFI handling in 8.3, but the daemon failing to start when copied back to 8.2 is unexpected. We'll try to replicate this in our lab. If we can't, we'll ask you for more logs.

stormi

@alex821982 Is Secure Boot enabled for this VM in Xen Orchestra? If so, can you try disabling it?

alex821982

@stormi
No is not enabled. I don 't use this option on any machines at all )

stormi

@alex821982 What's the operating system on the VM?

alex821982

@stormi
This is a XOA machine on Ubuntu 22.04

seanmcg182

Went to restart my Server to test my vApp loading, and it didn't actually reboot. The Splash screen cam up as if it was shutting down, and then just stood there.

I was able to access XO Lite, and saw this task just stuck there, obviously for 13 minutes.

Had to hard reboot, and will check to see if any updates available (probably been a couple days since I checked). If so, I'll try again and report back.

UPDATE: No Updates Found. Attempted another reboot. This time it worked. Not sure what locked it up the previous time.

bufanda

@seanmcg182 I know I am a bit late but have you tried to press ESC on the spalsh screen, usually you should then see kernel/systemd messages and see which task may have hung there. Just for the next time when it occurs.

olivierlambert

Yes, that's the usual thing, especially if you have a VM on the same host that is hosting your ISO SR for example (in NFS). The VM will be shutdown, and the NFS will stop answering, and the reboot will be stuck until the timeout is reach (10 minutes?). That might explain why it takes so long to reboot

seanmcg182

@bufanda I appreciate the response. I did not know/try that, but I will keep it in mind if it happens again.

seanmcg182

@olivierlambert Not the case for me. my ISO SR is a local LVM, and my VM SR is a locally mounted HBA... IE, all my VM's can be shut off, and I can still access all my VMDK/VHDs.

The only NFS Storage the XCP-ng is using is for my Backup Schedule, which was not running at that time.

As my edit says though, it worked fine afterwards, and i still havent seen an issues in the last few days since. It was a one-off that I can't reproduce

BenjiReis

@alex821982 Hi!

We reproduced and find a temporary workaround: on your 8.2 host you can run
xe vm-param-remove uuid=<uuid> param-name=NVRAM param-key=EFI-variables

this will clear the UEFI variables of the NVRAM and so the VM should start after that.
HOWEVER: This does not work on Debian VMs, and on other distro you should make sure to save your VM before in case something goes wrong.

We suspect a change in the auth file format between 8.2 and 8.3 is responsible for this issue.

BR

alex821982

@BenjiReis
Thanks )
But we really have already put 8.2 from iso on it with included fixes, which we gave in another topic.
Therefore, there is no way to check now.
While it was 8.3, I managed to conduct some tests.
Did I understand something wrong or is it quite possible that in some tasks 8.3 is significantly faster on the same hardware than 8.2?