Some sort of progress. - Restored the backup to a VMware cluster and made sure it worked. - Exported that as an OVA and manually converted using virt-v2v. The VM booted as expected on the system I used to perform the export, running just libvirt and qemu-kvm - Took that QCOW file, uploaded as a template to my cluster. Deployed a VM from that template. Back to only booting to the recovery console. - Verified that libvirt, qemu-kvm and edk2 packages are the same
I did do some additional backup / restore testing that leads me to believe that we have an issue that is specific to this VM. Curious. :) Steve On Wed, Mar 26, 2025 at 6:36 PM Nux <n...@li.nux.ro> wrote: > Hello, > > Ah, when restoring backups from VMWare.. Ok, this kind of makes sense, > although I do not know exactly what is going on. > so I think there could be a mismatch between VMWare UEFI implementation > and/or secure boot keys and KVM's. That's a possible topic you could > follow further. > Additionally, I would also try to import the VM straight from VMWare > using CloudStack's import tool. > If you are not using a CloudStack version that has that you can try to > convert VMWare VMs manually by means of virt-v2v (which is also what > CloudStack uses btw). > > HTH > > On 2025-03-26 19:22, S.Fuller wrote: > > Currently using Rocky Linux 8 > > > > guest.nvram.template.secure=/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd > > guest.nvram.template.legacy=/usr/share/edk2/ovmf/OVMF_VARS.fd > > guest.loader.secure=/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd > > guest.loader.legacy=/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd > > guest.nvram.path=/var/lib/libvirt/qemu/nvram/ > > > > We are not having any issues deploying new VMs via the API or UEFI > > enabled > > templates. Only when restoring backups from VMware based VMs into our > > system. > > > > On Wed, Mar 26, 2025 at 9:45 AM Nux <n...@li.nux.ro> wrote: > > > >> What Linux distro are you using and can you share your > >> agent.properties, > >> particularly the UEFI lines? > >> > >> For reference, on EL it should look something like this (make sure the > >> files exist!) > >> > >> guest.nvram.template.secure=/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd > >> guest.nvram.template.legacy=/usr/share/edk2/ovmf/OVMF_VARS.fd > >> guest.nvram.path=/var/lib/libvirt/qemu/nvram/ > >> guest.loader.secure=/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd > >> guest.loader.legacy=/usr/share/edk2/ovmf/OVMF_CODE.cc.fd > >> > >> On Debian/Ubuntu: > >> > >> guest.nvram.template.secure=/usr/share/OVMF/OVMF_VARS_4M.ms.fd > >> guest.nvram.template.legacy=/usr/share/OVMF/OVMF_VARS_4M.fd > >> guest.nvram.path=/var/lib/libvirt/qemu/nvram/ > >> guest.loader.secure=/usr/share/OVMF/OVMF_CODE_4M.secboot.fd > >> guest.loader.legacy=/usr/share/OVMF/OVMF_CODE_4M.fd > >> > >> AFAIK Windows Server does not require a TPM btw. > >> > >> > >> On 2025-03-26 14:09, S.Fuller wrote: > >> > Wei, > >> > > >> > Thanks for the reply. In this particular case, we have added that > >> > setting, > >> > along with the extraconfig settings for the tpm device and back end. > In > >> > this case, it's a Windows server, and while it will boot to recovery > >> > mode, > >> > it will not boot to the OS. I'm trying to figure out if there may be > >> > something we're missing in our restore process, or something other > >> > steps > >> > that we may need to follow to get this to work. > >> > > >> > - Steve > >> > > >> > On Wed, Mar 26, 2025 at 8:18 AM Wei ZHOU <ustcweiz...@gmail.com> > wrote: > >> > > >> >> Hi, > >> >> > >> >> You can stop the VM, add a vm setting UEFI=SECURE, then start the vm > >> >> > >> >> > >> >> -Wei > >> >> > >> >> On Wed, Mar 26, 2025 at 1:00 PM S.Fuller <steveful...@gmail.com> > >> >> wrote: > >> >> > >> >> > Is there anything to look out for or a process to follow when > >> migrating > >> >> > Secure boot VMs from other platforms to cloudstack? Having no > issues > >> >> > starting up new VMs within my environment, but for VMs moved from > >> other > >> >> > systems they start, but in the case of WIndows VMs, they fail to > boot > >> and > >> >> > then end up booting into the recovery system. > >> >> > > >> >> > -- > >> >> > Steve Fuller > >> >> > steveful...@gmail.com > >> >> > > >> >> > >> > -- Steve Fuller steveful...@gmail.com
