XCP-ng 8.1 Release Candidate now available!

peder

@dariosplit I made a new 8.1-RC1 install and had the installer set up the Local SR as LVM.
After the installation I ran the commands in my previous example and afterwards 'mount' and 'file -sL' show that it's ext4.

HOWEVER; xsconsole still claims "Type : Ext3" so the console seems to have hard coded that "ext = ext3".
Something for RC2 sort out.

Andrew

Linux node2 4.19.102 #1 SMP Thu Mar 5 19:21:42 CET 2020 x86_64 x86_64 x86_64 GNU/Linux

I like XCP-ng better... but I use XO too. The both have different advantages and issues.

Using xen-cmdline --set-xen dom0_mem changes the grub.cfg entries EXCEPT the default (first) kernel-alt entry. So yes, it works, but not for the alt kernel install. Not the end of the world, I can edit the file and move on. But, should it modify all xen config lines or just the default/first one?

I am able to create the SMB ISO SR using XO. The big issue is the old one (that I deleted) worked in 8.0 but did not work after the upgrade. Not a big deal the recreate it, but not good for an upgrade. There is some compatibility issue behind the scenes that now fails where it did not before.

Mar 10 23:25:06 node2 SM: [4467] self.dconf['vers'] = 3.0
Mar 10 23:25:06 node2 SM: [4467] Exception while attempting to append mount options
Mar 10 23:25:06 node2 SM: [4467] ***** generic exception: sr_attach: EXCEPTION <type 'exceptions.KeyError'>, 'username'
Mar 10 23:25:06 node2 SM: [4467] File "/opt/xensource/sm/SRCommand.py", line 110, in run
Mar 10 23:25:06 node2 SM: [4467] return self._run_locked(sr)
Mar 10 23:25:06 node2 SM: [4467] File "/opt/xensource/sm/SRCommand.py", line 159, in _run_locked
Mar 10 23:25:06 node2 SM: [4467] rv = self._run(sr, target)
Mar 10 23:25:06 node2 SM: [4467] File "/opt/xensource/sm/SRCommand.py", line 349, in _run
Mar 10 23:25:06 node2 SM: [4467] return sr.attach(self.params['sr_uuid'])
Mar 10 23:25:06 node2 SM: [4467] File "/opt/xensource/sm/ISOSR", line 286, in attach
Mar 10 23:25:06 node2 SM: [4467] self.appendCIFSMountOptions(mountcmd)
Mar 10 23:25:06 node2 SM: [4467] File "/opt/xensource/sm/ISOSR", line 430, in appendCIFSMountOptions
Mar 10 23:25:06 node2 SM: [4467] cifutils.splitDomainAndUsername(self.dconf['username'])
Mar 10 23:25:06 node2 SM: [4467]
Mar 10 23:25:06 node2 SM: [4467] ***** ISO: EXCEPTION <type 'exceptions.KeyError'>, 'username'
Mar 10 23:25:06 node2 SM: [4467] File "/opt/xensource/sm/SRCommand.py", line 372, in run
Mar 10 23:25:06 node2 SM: [4467] ret = cmd.run(sr)
Mar 10 23:25:06 node2 SM: [4467] File "/opt/xensource/sm/SRCommand.py", line 110, in run
Mar 10 23:25:06 node2 SM: [4467] return self._run_locked(sr)
Mar 10 23:25:06 node2 SM: [4467] File "/opt/xensource/sm/SRCommand.py", line 159, in _run_locked
Mar 10 23:25:06 node2 SM: [4467] rv = self._run(sr, target)
Mar 10 23:25:06 node2 SM: [4467] File "/opt/xensource/sm/SRCommand.py", line 349, in _run
Mar 10 23:25:06 node2 SM: [4467] return sr.attach(self.params['sr_uuid'])
Mar 10 23:25:06 node2 SM: [4467] File "/opt/xensource/sm/ISOSR", line 286, in attach
Mar 10 23:25:06 node2 SM: [4467] self.appendCIFSMountOptions(mountcmd)
Mar 10 23:25:06 node2 SM: [4467] File "/opt/xensource/sm/ISOSR", line 430, in appendCIFSMountOptions
Mar 10 23:25:06 node2 SM: [4467] cifutils.splitDomainAndUsername(self.dconf['username'])
Mar 10 23:25:06 node2 SM: [4467]

It looks like XCP-ng Center created the SMB ISO SR as a guest login without a username/password (empty/blank). Adding "guest/guest" in XO seems to resolve the problem. The issue is it worked before in 8.0 but not in 8.1.

The errors at boot are seen in the console after boot and login prompt but before the XSConsole screen.

As for the disk problem... I have been messing around a LOT with everything (local storage, iscsi, 7.6, 8.0, and back). I'm would not be happy to see these strange these strange things in a production system but I have been messing with the hosts in the lab more than a normal setup.

I'm new to XCP and trying to help the community so I can benefit from improved software too.

stormi

@Andrew said in XCP-ng 8.1 Release Candidate now available!:

Linux node2 4.19.102 #1 SMP Thu Mar 5 19:21:42 CET 2020 x86_64 x86_64 x86_64 GNU/Linux

That is a very important information: you are using the alternate kernel (on purpose, I suppose? The installer is not supposed to make it the default kernel for you). Pinging @r1 to take your feedback into account and debug.

Andrew

Yes, I installed the alt kernel and made it the default entry in grub.
I was trying to solve an IOMMU problem on an AMD system (that is unsolvable).

Also, I hope the microcode firmware gets updated as there are new hypervisor attacks with AMD CPUs. Yes, I know I can manually install an update but it seems more important to update it in a VM environment than on a single host. Maybe, at least, add it to testing.

Andrew

Here's more from user.log:

Mar 11 02:50:24 node2 xsconsole: Data update failed:
Mar 11 02:50:24 node2 xsconsole: ['HOST_HAS_NO_MANAGEMENT_IP']
Mar 11 02:50:24 node2 xsconsole: SR data update failed:
Mar 11 02:50:24 node2 xsconsole: string indices must be integers, not str
Mar 11 02:50:24 node2 xsconsole: File "/usr/lib64/xsconsole/XSConsoleImporter.py", line 49, in ImportAbsDir#012 imp.load_module(importName, fileObj, pathName, description)
Mar 11 02:50:24 node2 xsconsole: File "/usr/lib64/xsconsole/plugins-base/XSMenuLayout.py", line 224, in <module>#012 XSMenuLayout().Register()
Mar 11 02:50:24 node2 xsconsole: File "/usr/lib64/xsconsole/plugins-base/XSMenuLayout.py", line 180, in Register#012 data = Data.Inst()
Mar 11 02:50:24 node2 xsconsole: File "/usr/lib64/xsconsole/XSConsoleData.py", line 52, in Inst#012 cls.instance.Create()
Mar 11 02:50:24 node2 xsconsole: File "/usr/lib64/xsconsole/XSConsoleData.py", line 145, in Create#012 self.Update()
Mar 11 02:50:24 node2 xsconsole: File "/usr/lib64/xsconsole/XSConsoleData.py", line 343, in Update#012 self.DeriveData()
Mar 11 02:50:24 node2 xsconsole: File "/usr/lib64/xsconsole/XSConsoleData.py", line 361, in DeriveData#012 name = " ".join(cpu['modelname'].split())
Mar 11 02:50:24 node2 xsconsole: *** PlugIn 'XSMenuLayout' failed to load: string indices must be integers, not str
Mar 11 02:50:24 node2 xsconsole: Data update connection failed - retrying. Exception was:
Mar 11 02:50:24 node2 xsconsole: ['HOST_STILL_BOOTING']
Mar 11 02:50:24 node2 xsconsole: XAPI Failed to logout exception was
Mar 11 02:50:24 node2 xsconsole: ['HOST_STILL_BOOTING']
Mar 11 02:50:24 node2 xsconsole: Data update failed:
Mar 11 02:50:24 node2 xsconsole: Could not connect to local xapi
Mar 11 02:50:24 node2 xsconsole: SR data update failed:
Mar 11 02:50:24 node2 xsconsole: 'NoneType' object has no attribute 'xenapi'
Mar 11 02:50:24 node2 xsconsole: Loaded initial xapi and system data in 0.235 seconds
Mar 11 02:50:25 node2 xsconsole: Exception: ("Unknown menu 'MENU_NETWORK'",)
Mar 11 02:50:25 node2 xsconsole: File "/usr/lib64/xsconsole/XSConsole.py", line 46, in <module>#012 main()
Mar 11 02:50:25 node2 xsconsole: File "/usr/lib64/xsconsole/XSConsole.py", line 40, in main#012 app.AssertScreenSize()
Mar 11 02:50:25 node2 xsconsole: File "/usr/lib64/xsconsole/XSConsoleTerm.py", line 47, in AssertScreenSize#012 self.layout.AssertScreenSize()
Mar 11 02:50:25 node2 xsconsole: File "/usr/lib64/xsconsole/XSConsoleLayout.py", line 41, in AssertScreenSize#012 ') too small for application size ('+str(self.APP_XSIZE)+', '+str(self.APP_YSIZE) +')')
Mar 11 02:50:25 node2 xsconsole: *** Exit caused by unhandled exception:
Mar 11 02:50:25 node2 xsconsole: Console size (80, 23) too small for application size (80, 24)

This systems does have a management IP.... it's setup on a VLAN attached to "Bond 0 + 1"

r1

@Andrew said in XCP-ng 8.1 Release Candidate now available!:

Using xen-cmdline --set-xen dom0_mem changes the grub.cfg entries EXCEPT the default (first) kernel-alt entry. So yes, it works, but not for the alt kernel install. Not the end of the world, I can edit the file and move on. But, should it modify all xen config lines or just the default/first one?

xen-cmdline utility will only update the base kernel XCP-NG and XCP-ng (Serial), all other including kernel-alt are for debug purpose hence not touched. The script is also inherited from Citrix so its kept as-is.

Regarding the SMB ISO SR, it looks like XAPI or XAPI DB might have lost username/password in upgrade, this can be checked further in relevant code base.

Regarding XSConsole, if you have ssh access to the host, try to run it manually by # xsconsole and share the full error stack to trace further.

Andrew

The errors seem to be a boot time issue. When I run xsconsole from a shell I don't see the same errors.

stormi

If you have an XOA (any version) installed and can open a support tunnel, I'm willing to have a look at the issues as part of the RC phase.

Danp

Upgraded my R620 to the RC. Noticed the following during the boot process, but it eventually loaded and seems to be functioning fine thus far --

stormi

@peder said in XCP-ng 8.1 Release Candidate now available!:

@dariosplit I made a new 8.1-RC1 install and had the installer set up the Local SR as LVM.
After the installation I ran the commands in my previous example and afterwards 'mount' and 'file -sL' show that it's ext4.

HOWEVER; xsconsole still claims "Type : Ext3" so the console seems to have hard coded that "ext = ext3".
Something for RC2 sort out.

Now solved. Just run yum update, restart the xsconsole service, and it will display 'Ext' instead of 'Ext3'.

peder

@stormi Yes, that did it.
I suppose there's currently no way to show the actual filesystem, instead of the generic "Ext", in the xsconsole?
You have to resort to a shell and 'mount' or 'file -sL' to see that?

stormi

@peder That would require more than just a simple fix indeed.

stormi

I have pushed three new updates: kernel-alt, xcp-python-libs and xapi(-*).

kernel-alt updated to 4.19.108 by @r1
xcp-python-libs updated as a requirements for handling the grub configuration update when kernel-alt will be updated, now and in future updates
xapi updated with code by @BenjiReis to handle export and restore of VMs in a suspended state. This is a foundation for a future XO feature related to that.

Please update and make sure that you notice no regression related to those updates.

dariosplit

@stormi is the server restart necessary and how do I know with future updates if a server restart necessary

olivierlambert

Rule of thumb:

if there's an update on a kernel you are using in the dom0, you must reboot to run on the updated kernel
if there's a Xen update, idem
if there's a XAPI update, in most case, toolstack restart is enough
for other thing, it's more variable and hard to predict. But let's say in general, no mandatory reboot. However I'd like to stress that rebooting is a good thing, especially for all security related updates.

stormi

I'd add: if you don't reboot, always restart the toolstack. It's better to restart it for nothing than to forget to restart it. Note that the above Rule of thumb is also written in the updates howto.

For precise instructions related to any update, refer to the blog post that announces them (until we can get them directly in XO). I try to always give such instructions. Forgot here because it's the RC.

stormi

Final release is really close. I have built "pre-final" ISOs that do not differ much from the RC except from the updated kernel-alt, xcp-python-libs, xapi and xsconsole (replaced ext3 with ext in the local SR display since it can be either ext3 or ext4 depending on when the SR was created). Another fix: the netinstall ISO now correctly detects that it is a netinstall ISO when started in UEFI mode. The only visible change is that it doesn't offer local media anymore, consistently with the behaviour it already had in BIOS mode.

Things to test:

booting and installing kernel-alt
netinstall in UEFI
installation, basic features, coalesce...

ISOs can be downloaded from https://updates.xcp-ng.org/isos/8.1/

Biggen

@stormi

I've been holding out moving to 8 until it was finalized since I'm running the experimental ext4 driver. Can you confirm the following steps for transition to 8 if running the experimental ext4 driver?

Update to 8 and reboot
Copy/Export VMs somewhere off ext4 experimental SR
Unplug via CLI old experimental SR
Forget via CLI old experimental SR
Create new SR via CLI
Reinstall XO
Copy VMs back to new SR

Will the below command specifically create the new SR on the host/disk of my choosing using the new ext4 driver?

xe sr-create type=ext name-label=mySR host-uuid=<host_UUID> device-config:device=/dev/sdX

So the above command would create the new SR using ext4 just by giving it the type of ext?

I'm running MDRAID on this host and it appears that when running xe pbd-list it shows my SR in question is at device /dev/md127p4. That's partition 4 of the mdraid array that is holding the old experimental ext4 SR partition. I'm assuming when I run the above xe sr-create command that I want to make sure that I feed it device-config:device=/dev/md127p4.

It looks pretty straight forward if I have the above logic right. I'll have to find out how to find my host UUID but I'm sure that is pretty easy. Copying the VMs somewhere may be a larger and more time consuming challenge.

dariosplit

@stormi Will the RC release with yum update become the final release

stormi

@dariosplit Yes