Best posts made by Andrew

@stormi Microcode updated on affected Gen11 i7. Running normally.

@gduperrey I jumped in all the way by mistake... I updated a wrong host, so I just did them all. Older AMD, Intel E3/E5, NUC11, etc. So far, so good. Add/migrate/backup/etc VMs are working as usual. Good for guest tools too, but mine are mostly Debian 7-11. Stuff is as usual so far.

I agree and I'll say it again, Thanks! It's not just Linux/Xen stuff. It is XCP-ng and XO that make everything work as a cohesive vertical open-source solution (some nice buzz words). Thanks to the Vates team and community that have built and support it. I look forward to ongoing continuous improvement and innovation!

@bleader Installed and running.

@bleader Updates running on several old and new intel machines (including microcode update). Working fine so far. Rolling Pool Reboot is a helpful feature.

@bleader I installed it on a bunch of busy hosts. All are fine, but none used PCI passthrough. The Rolling Pool Reboot in XO was very helpful.

@julien-f @olivierlambert

Thanks for the ability to delete XO task logs feature! (XO commit f6e6e)

@stormi Installed on several test and pre-production machines.

@bleader I installed it on many 8.2 machines. On one I did get a warning:

  Cleanup    : xen-libs-4.13.5-9.40.3.xcpng8.2.x86_64                     14/14
warning: %posttrans(microcode_ctl-2:2.1-26.xs29.5.xcpng8.2.x86_64) scriptlet failed, exit status 1
Non-fatal POSTTRANS scriptlet failure in rpm package 2:microcode_ctl-2.1-26.xs29.5.xcpng8.2.x86_64
  Verifying  : xcp-ng-release-8.2.1-13.x86_64                              1/14

But it did not seem to have any effect. Nothing extra in the yum.log

@bleader Updated an running on newer and older Intel machines. Running normally so far.

@stormi Updated all my normal 8.2 systems updated. All working normally.

@stormi Thanks! 4.17 Installed and running on a NUC10. Things seem to be working, but it's just a test... And for everyone who will ask... No, Windows Hyper-V server does not work (as expected).

@stormi New update version edk2-20220801-1.7.3.xcpng8.3.x86_64 fixed my FreeBSD UEFI boot problem (stuck on boot countdown). XCP reboot NOT required after install. Windows 10 and Ubuntu boot correctly also (but did before too). I did not test secure boot or bitlocker.

@gduperrey XO (current source) rolling pool update did its job.

@gduperrey Installed on several old and new Intel machines. Working as expected.

@gduperrey So far, so good with normal operations.... I'm not affected by the issues but updated everything anyway (15 hosts). Intel Xeon, E5, Core 7th/10th/11th, AMD Opteron, AMD Zen3...

@Bane I got it to boot...

In the console, as the VM starts, press ESC during the splash screen.

You should get a GRUB type menu with a few lines of what to boot. Select e to edit the first line and delete the root=/dev/sda near the end of the linux16 line.

Press Control-X to start the OS. It will take several seconds to finish booting.

I don't know why they added /dev/sda in there as it does not exist (at least in Xen). So booting pauses waiting for it (but it will never be there).

As root, you can edit /etc/default/grub and remove the root=/dev/sda and then update the boot file grub2-mkconfig -o /boot/grub2/grub.cfg and reboot.

@stevewest15 I would build two homogeneous pools... A high performance production Gold pool and a second Old E5 pool for testing, development, and backup..... unless power and space are a concern then just dump the old E5 monsters since one Gold machine is faster than ALL the old E5 machines combined.

You can warm/cold migrate VMs between pools. If you have a large external dataset then the VM could directly mount NFS storage and use that from any pool/host. That external storage would not be managed by XO (ie. no backups).

While they would be two different pools they can still share backend storage and networks for both SR and NFS storage. You can separate out VMs using VLANs.

@MrNaz It merges the past delta backup into the past full backup. Then it does a delta backup..... then you repeat.... Since you only keep one copy it just keeps merging the delta into the full backup. The delta backup depends on the old full backup existing and being correct.

When it does a "full backup", it does a full backup of the data not just a delta (the changes). That way it does not merge the new full backup into the old full backup (or depend upon any old backups). Doing a full backup is a good checkpoint in case the old data (full or deltas) is corrupted.

So having the retention set to 1 basically means you only have the most current backup saved. With backups every 12 hours you might want to set the retention to 20 so you have about 10 days of backups and every 5 days (10 backups) it will do a full backup. Or set it higher if you have more backup space.

@julien-f Working again. Thanks.