Posts made by JeffBerntsen

@stormi Seems to be working well for me too.

@stormi Some quick testing of the alternate kernel on my test systems seems to be working fine with the not-unexpected issue that the XOSTOR test does not come up and run on it.

@stormi Thanks, I'll give the test script a try on my test Alpine installation and see if it works for me.

My OpenSUSE Leap 15.3 installation works just fine via secure boot with one warning/error message at boot. It's complaining that it can't generate a temporary hibernation key because of a missing EFI_RNG_PROTOCOL. Except for that, it works great under secure boot. If not being able to have hibernation support in the VM's operating system is the only issue, that's definitely minor and something I don't use and won't miss.

EDIT: I'm also going to try a fresh installation of Alpine into a VM set for secure boot and see how that works out. My test was trying to convert an existing VM that was successfully booting under UEFI without secure boot enabled.

EDIT 2: I've managed to get Alpine working as well. It appears that their Wiki entry on setting up secure boot isn't quite right yet. They have a utility which generates keys and creates a signed unified boot image. My best guess is that there is some problem with the signature on the boot image. I was able to get things working by enrolling the generated auth files for the VM uuid on the host system then booting the VM with secure boot disabled and using the sbsign utility to sign the boot image with the generated db key and certificate. It adds a second signature to the boot image which appears to be identical to the first one. Switching to secure boot mode and rebooting works on the re-signed boot image.

@stormi That worked to get the auth files generated using Alpine's instructions enrolled as far as I can tell but switching the VM to secure boot after that still fails, dropping me into a UEFI shell. Alpine 3.15 is the first version with secure boot support and it's possible there are still some glitches there.

Instead of that, I'm now trying to set up a secure boot with a fresh install of OpenSUSE leap 15.3 which I know does support secure boot and will see if that works out.

@stormi

Testing UEFI VMs. So far working fine without secure boot. Having a problem with secure boot under Alpine Linux. They don't use MS certificates and a shim as a lot of distros do but instead have you generate a set of keys for your installation and then enroll them. It looks like this is a problem with enrolling the generated keys in the TianoCore boot firmware. I'll try with a different distro and see if it's any better with something different.

@stormi said in XCP-ng 8.2.1 (maintenance update) - ready for testing:

@jeffberntsen probably not. We'll need to rebuild some packages, like sm on top of the latest versions else you will lose needed specific patches that are not merged in the main branch yet.

CC @ronan-a

That's what I thought but figured it wouldn't hurt to ask.

@stormi
Is it safe to install this on a machine where I'm already testing XOSTOR?

@danp said in CH8.2.1:

Found this -- https://support.citrix.com/article/CTX335564

Yes, that's how I found it as well. It's still not up on their blog as of this morning. I wonder if that's intentional.

It looks like Citrix has released their latest CU version (CU 1) for Citrix Hypervisor 8.2. No announcement yet on their blog about it but it's available for download as of now. Looks like it's mostly a patch roll-up though they indicate there are other fixes as well.

@stormi So far, so good for my systems with the re-updated kernel.

@stormi
Working well for me so far.

@stormi Running well for me. I've tested startup, shutdown, and migration of Windows and Linux VMs with no obvious regressions.

@stormi
I'll use this one to test the 8.2-to-8.2 upgrade we talked about on the software RAID thread.

@stormi No regressions so far on my test pool with both sets of test updates installed.

@chrisarzu

You're very welcome. My solution to the similar problem I'd had was to set up a couple of internal systems as NTP servers so that I always had something with the right time and static IP addresses and pointed everything needing NTP at them.

@chrisarzu

I ran into something like this once. I noticed you've got NTP set to use host names. You could see if it's maybe DNS lookups being slow to respond at that point in the boot by setting NTP to use IP addresses instead and seeing if that's much faster or not.

@olivierlambert

So much for my memory.....

XCP-ng center always exports a snapshot as a template. The menu item is called that and the xva files made always re-import as templates. The equivalent xe function is xe snapshot-export-to-template which does the same thing. The only way to export the snapshot as a VM is to set the is-a-template parameter to false then export with xe vm-export. Once that's been done it looks impossible to set is-a-template back to true. Using either xe vm-param-set or xe snapshot-param-set and trying to set is-a-template back to true gives an error "VM_IS_SNAPSHOT"

I remember one of the backup scripts, NAUBackup/VMBackup if you're familiar with it, doing this and was never quite sure why until now. Looking through its code, it's creating a snapshot, setting is-a-template to false, exporting it as a VM, then deleting the snapshot in order to make an xva file backup while keeping the VM live. I'm not familiar with backups made by XO but I'm guessing you must be doing them in a similar fashion.

Edit: I just did some more testing and discovered that as soon as I set the is-a-template parameter to false on a snapshot made by XCP-ng Center or xe vm-snapshot, it starts showing up in the xsconsole "All VMs" list and in xe vm-list commands just as snapshots created by XO do. In addition, they're showing up both on xe vm-list and xe snapshot-list. Fresh snapshots made with is-a-template still set to true show up in xe snapshot-list but do not show up in xe vm-list or xe template-list. They do show up in the list of templates available in XCP-ng Center when creating a new VM but those with is-a-template set to false do not.

This is starting to smell to me more like a bug in xe or XAPI and possibly XCP-ng center as well but definitely in xe or XAPI. Is there any way to look into what's going on there?

@olivierlambert

Based on my experience with earlier versions, it always shows up as a VM after import, not a template, but I haven't tested this with 8.2 or the corresponding version of XCP-ng Center.

I'll test and let you know. Is there anything more specific you need as part of the test? Exporting snapshots created by XO vs. snapshots created by xe vm-snapshot? Importing using one vs. the other? All combinations?

@olivierlambert

I agree with you about the logic; That's why I'm thinking this might be more of a problem in XAPI or xe than what you're doing in XO. By my logic, if something is tagged as a snapshot, it shouldn't be getting returned on a list of normal VMs. XO is definitely tagging snapshots as snapshots just as I'd expect it to. I just wanted to let you know I'm not trying to point fingers at XO here, just mentioning what's happening and what kind of effects it's having elsewhere. (As well as having it mentioned somewhere others can search for it in case it's causing issues for anyone else.) Should we be looking at this as an XCP problem and not an XO problem?

@olivierlambert

The problem seems to be that snapshots created by XO show up in a list of available VMs on a server (by getting a list of all VMs at a server's console) while snapshots created by XCP-ng Center or the xe vm-snapshot command do not. The xe vm-list command also lists snapshots created by XO but not other snapshots.

This really causes problems for any kind of processing using xe (or, I assume, the equivalent XAPI) that gets a list of VMs from a server and does something with them as it will also try to affect the snapshots created by XO as though they're normal VMs. It's also confusing to see what should be snapshots showing up in a list of available VMs on a server and could lead to an operator at the console trying to start what's supposed to be a snapshot as though it's a VM.

I've traced the difference in snapshots down to the is-a-template parameter on the snapshot; snapshots created by the xe vm-snapshot command or anything that uses it or the equivalent XAPI (which I assume is what XCP-ng Center does) have the is-a-template parameter set to true while snapshots created by XO do not.

I'm not sure if this is a bug in how XO creates its snapshots or possibly some bug in XAPI which lists snapshots as VMs when it shouldn't. I suspect the latter but don't know for certain as I don't know what the intended design was there. I'd think that the expected behavior for xe vn-list (or it's XAPI equivalent) shouldn't show anything with is-a-snapshot true OR is-a-template true while it currently seems to be just basing visibility on the is-a-template parameter.

My biggest problem at the moment is that I have some shell scripts using xe commands for various functions and they're trying to act on XO snapshots as well. I'm working around it at the moment by modifying the scripts to work with an exclusion list (i.e. don't operate on VMs with names in a specific list) but that's not really maintainable and certainly not a good solution to the problem.

Thanks in advance for any help you can give me for this.