XCP-ng 8.1 Release Candidate now available!

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

stormi

@Biggen It's on my TODO list to write detailed instructions for that migration before the release. I'll follow the procedure myself and see what happens. Others can comment too and help making it perfect.

stormi

New updates are available for those who have installed the beta, the RC or from the pre-final ISOs. They fix an issue that no one had seen yet but very important: the chronyd service was not enabled when updating via yum, nor chrony-wait.service, vm.slice and sm-mpath-root.service (Citrix Hypervisor's update from 8.0 to 8.1 exhibits the same issue).

They also modify the tty console welcome message to mention Xen Orchestra as the official graphical client.

I have also built new ISOs ("prefinal2") with the updated packages. I hope those will be the final ones. Download from https://updates.xcp-ng.org/isos/8.1/

stormi

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

@Biggen It's on my TODO list to write detailed instructions for that migration before the release. I'll follow the procedure myself and see what happens. Others can comment too and help making it perfect.

Done: https://github.com/xcp-ng/xcp/wiki/XCP-ng-8.1-Release-Notes#migrate-from-experimental-ext4-storage-repositories

Biggen

@stormi

Can you export and import VMs with xcp-ng Center? I have a single host pool so I'm not sure what the best method is of exporting them and then importing them once the new SR is created.

My XO Community Edition resides on the experimental SR . So I can use that to move/export my other VMs first but I'm not sure how to move the actual XO CE last. I may have to simply reinstall it from scratch which isn't a big deal.

Danp

@Biggen Not sure if this will work for you, but I temporarily migrated my VDIs to my backup source (I created an NFS SR) and then deleted / recreated my local storage.

Biggen

@Danp

I think that is what I'll do.

Its the import that I'm not quite sure how to handle. If I backup everything to a NFS and delete the old SR, then I have no controlling XO any longer to begin the import. So I either have to manually reinstall XO CE or use xcp-ng Center.

Danp

@Biggen To be clear, I didn't export / import. Here's what I did --

Created a new NFS SR on my backup device
Migrated the existing VDIs to the NFS SR
Removed the existing local storage (was LVM)
Recreated the local storage as Ext4
Migrated the disks back to local storage

IIRC, I had to restart a few of the VMs post migration but otherwise the process worked fine for me

Biggen

@Danp

What did you use to migrate with? Did you have another host where you could run XO(A) from?

Danp

@Biggen No, the host doesn't change at all. You are just moving all disks to different storage so that you can recreate your local storage. I believe the latest version of XO lets you do this from the SR > Disks tab.

If you run into issues with moving your XO instance, you could always spin up a 2nd instance or use XOA.

Biggen

@Danp

Oh, I see. You are talking about migrating everything including XOA to NFS and running it from there while I'm destroying/recreating the SR, and then moving everything back.

Yeah I get it now.

Biggen

Upgrading to 8.1 from 8.0 went just fine. Thanks for the help @Danp. Moving everything to a temporary NFS share worked easy (although one stubborn VM couldn't be migrated for some reason. I had to perform a copy instead).

Just be aware if you pass through any disks or have a local ISO SR setup in dom0, you will have to set it back up again. The pass through disks are easy since the data itself on the drives isn't touched. You just have to pass them back through and reattach to the appropriate VM. The local ISO SR is another story since it gets wiped if it resides in dom0. Not a big deal. Just have to copy back into it the installation ISOs required and add it back in the storage menu.

Danp

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

local ISO SR

Why not just setup an NFS one?

Biggen

@Danp I should but I use it so seldom that I just have never got around to it. Might as well now so I only have to build it again from scratch just this once!

jmccoy555

Import (in XO and XCP-ng center) / restore from back up is broken. It works with 8.1 RC1 but with latest patches applied or prefinal 3 it fails.

Think this is the relevant bit of the log,

"message": "VM_BAD_POWER_STATE(Plugged VBD creation only allowed for suspended VM)",
"name": "XapiError",
"stack": "XapiError: VM_BAD_POWER_STATE(Plugged VBD creation only allowed for suspended VM)
  at Function.wrap (/home/node/xen-orchestra/packages/xen-api/src/_XapiError.js:16:12)
  at _default (/home/node/xen-orchestra/packages/xen-api/src/_getTaskResult.js:11:29)
  at Xapi._addRecordToCache (/home/node/xen-orchestra/packages/xen-api/src/index.js:831:24)
  at forEach (/home/node/xen-orchestra/packages/xen-api/src/index.js:852:14)
  at Array.forEach (<anonymous>)
  at Xapi._processEvents (/home/node/xen-orchestra/packages/xen-api/src/index.js:842:12)
  at /home/node/xen-orchestra/packages/xen-api/src/index.js:1003:14
  at Generator.next (<anonymous>)
  at asyncGeneratorStep (/home/node/xen-orchestra/packages/xen-api/dist/index.js:62:103)
  at _next (/home/node/xen-orchestra/packages/xen-api/dist/index.js:64:194)
  at tryCatcher (/home/node/xen-orchestra/node_modules/bluebird/js/release/util.js:16:23)
  at Promise._settlePromiseFromHandler (/home/node/xen-orchestra/node_modules/bluebird/js/release/promise.js:547:31)
  at Promise._settlePromise (/home/node/xen-orchestra/node_modules/bluebird/js/release/promise.js:604:18)
  at Promise._settlePromise0 (/home/node/xen-orchestra/node_modules/bluebird/js/release/promise.js:649:10)
  at Promise._settlePromises (/home/node/xen-orchestra/node_modules/bluebird/js/release/promise.js:729:18)
  at _drainQueueStep (/home/node/xen-orchestra/node_modules/bluebird/js/release/async.js:93:12)
  at _drainQueue (/home/node/xen-orchestra/node_modules/bluebird/js/release/async.js:86:9)
  at Async._drainQueues (/home/node/xen-orchestra/node_modules/bluebird/js/release/async.js:102:5)
  at Immediate.Async.drainQueues [as _onImmediate] (/home/node/xen-orchestra/node_modules/bluebird/js/release/async.js:15:14)
  at processImmediate (internal/timers.js:456:21)"

}