Re: Issues with libvirt after upgrading to RockyLinux 8.5

2021-12-18 Thread Jeremy Hansen 
Faking the releases file helped me get past this.

Thanks

> On Thursday, Dec 16, 2021 at 1:32 AM, Jeremy Hansen  (mailto:jer...@skidrow.la)> wrote:
> Thank you. I thought about trying that.
>
> If I upgrade everything to Rocky, and I’m on 4.16, should I expect it to 
> work? Will I have to re-add compute nodes to update the db with Rocky as the 
> OS?
>
> I expect a lot of people might want to transition to Rocky since CentOS is 
> going EOL after this month I believe. At this point, Rocky and CentOS are 
> mostly the same thing. This complicates things a bit.
>
> Thanks
> -jeremy
>
>
>
> > On Thursday, Dec 16, 2021 at 1:09 AM, Andrija Panic 
> > mailto:andrija.pa...@gmail.com)> wrote:
> > Can't add host: 192.168.30.54 with hostOS: Rocky into a cluster,in which
> > there are CentOS hosts added
> >
> >
> > Try changing the content of the /etc/*release file - to match the file of
> > the CentOS nodes - and then play with restarting agent, and observe if you
> > would hit the same error or not - I've seen this issue (RHEL inside CentOS
> > cluster, due to bad /etc/rhel-release file content), but I've not tested if
> > this "fix" works or not.
> >
> > Best,
> >
> > On Thu, 16 Dec 2021 at 08:39, Jeremy Hansen 
> > wrote:
> >
> > > But if I convert all the hosts to Rocky and upgrade to 4.16, I should be
> > > ok?
> > >
> > > Thanks
> > >
> > >
> > >
> > > On Wednesday, Dec 15, 2021 at 11:17 PM, Slavka Peleva <
> > > slav...@storpool.com.INVALID> wrote:
> > > Sorry, I didn't pay attention to your CS version. After the upgrade, I
> > > think you will have the same problem. Because in the DB, there is
> > > information about host/hosts on this cluster that is/are with CentOS.
> > >
> > > Best regards,
> > > Slavka
> > >
> > > On Thu, Dec 16, 2021 at 8:49 AM Jeremy Hansen 
> > > wrote:
> > >
> > > I noticed in the compatibility matrix that Rocky isn’t supported until
> > > 4.16.0.0. If I upgrade Cloudstack first, would this help or is it still
> > > going to complain about the centos/rocky mix? If I convert all my existing
> > > nodes to Rocky, which is the plan anyway, will this go away? Shouldn’t
> > > CentOS and Rocky be considered that same thing… sort of…?
> > >
> > > Thanks
> > > -jeremy
> > >
> > >
> > >
> > >
> > > On Wednesday, Dec 15, 2021 at 10:43 PM, Slavka Peleva <
> > > slav...@storpool.com.INVALID> wrote:
> > > Hi Jeremy,
> > >
> > > It will help if you have another cluster for Rocky Linux. Hosts need to be
> > > of the same OS, it's not possible to mix OSes in the same cluster.
> > >
> > > Best regards,
> > > Slavka
> > >
> > > On Thu, Dec 16, 2021 at 4:08 AM Jeremy Hansen 
> > > wrote:
> > >
> > > Any tips on how I would troubleshoot this? I’ve tried downgrading libvirt
> > > and qemu and ca-certificates to the same version as the other functional
> > > nodes. That didn’t seem to help. This is obviously an ssl issue but I
> > > don’t really know what to do about it.
> > >
> > > 2021-12-15 18:04:14,438 INFO [cloud.agent.AgentShell] (main:null)
> > > (logid:) Agent started
> > > 2021-12-15 18:04:14,444 INFO [cloud.agent.AgentShell] (main:null)
> > > (logid:) Implementation Version is 4.15.0.0
> > > 2021-12-15 18:04:14,447 INFO [cloud.agent.AgentShell] (main:null)
> > > (logid:) agent.properties found at /etc/cloudstack/agent/agent.properties
> > > 2021-12-15 18:04:14,466 INFO [cloud.agent.AgentShell] (main:null)
> > > (logid:) Defaulting to using properties file for storage
> > > 2021-12-15 18:04:14,467 INFO [cloud.agent.AgentShell] (main:null)
> > > (logid:) Defaulting to the constant time backoff algorithm
> > > 2021-12-15 18:04:14,471 INFO [cloud.utils.LogUtils] (main:null) (logid:)
> > > log4j configuration found at /etc/cloudstack/agent/log4j-cloud.xml
> > > 2021-12-15 18:04:14,485 INFO [cloud.agent.AgentShell] (main:null)
> > > (logid:) Using default Java settings for IPv6 preference for agent
> > > connection
> > > 2021-12-15 18:04:14,592 INFO [cloud.agent.Agent] (main:null) (logid:) id
> > > is 0
> > > 2021-12-15 18:04:14,606 ERROR [kvm.resource.LibvirtComputingResource]
> > > (main:null) (logid:) uefi properties file not found due to: Unable to find
> > > file uefi.properties.
> > > 2021-12-15 18:04:14,663 INFO [kvm.resource.LibvirtConnection] (main:null)
> > > (logid:) No existing libvirtd connection found. Opening a new one
> > > 2021-12-15 18:04:14,890 INFO [kvm.resource.LibvirtComputingResource]
> > > (main:null) (logid:) No libvirt.vif.driver specified. Defaults to
> > > BridgeVifDriver.
> > > 2021-12-15 18:04:15,086 INFO [kvm.resource.LibvirtComputingResource]
> > > (main:null) (logid:) iscsi session clean up is disabled
> > > 2021-12-15 18:04:15,129 INFO [cloud.agent.Agent] (main:null) (logid:)
> > > Agent [id = 0 : type = LibvirtComputingResource : zone = 1 : pod = 1 :
> > > workers = 5 : host = 192.168.30.59 : port = 8250
> > > 2021-12-15 18:04:15,139 INFO [utils.nio.NioClient] (main:null) (logid:)
> > > Connecting to 192.168.30.59:8250
> > > 2021-12-15 18:04:15,153 INFO

RE:  UEFI on KVM silently becomes BIOS mode

2021-12-18 Thread Piotr Pisz 
Hi Pieter,

 

I run it in CentOS 8:

 

Cloudstack:

 

i-4-46-VM

e9c33f2d-7237-4cc1-b466-5d85a04ed549

Other PV Virtio-SCSI (64-bit)





Apache Software Foundation

CloudStack KVM Hypervisor

e9c33f2d-7237-4cc1-b466-5d85a04ed549







hvm

/var/lib/libvirt/qemu/nvram/e9c33f2d-7237-4cc1-b466-5d85a04ed549.fd







 

Virsh dump:

 

  

   

  Apache Software Foundation

  CloudStack KVM Hypervisor

  e9c33f2d-7237-4cc1-b466-5d85a04ed549



  

  

hvm







  

 

Regards,

Piotr

 

 

From: Pieter Harvey  
Sent: Friday, December 17, 2021 5:46 PM
To: Pieter Harvey 
Cc: "users@cloudstack.apache.org" 
Subject: Re: UEFI on KVM silently becomes BIOS mode

 

Hi Piotr,

 

Is there any way to get this debug info (or xml dump) from CloudStack, what it 
is creating versus what ends up in virsh? 

 

I think I have configured everything correctly

1. cloudstack uefi enabled in database for host (host.uefi.enable)

2. host agent has uefi.properties with all paths configured (snippet below 
based Ubuntu 20.04.3)

3. instance is configured for UEFI (tried both legacy and secure boot)

 

uefi.properties

==

guest.nvram.template.secure=/usr/share/OVMF/OVMF_VARS.fd

guest.nvram.template.legacy=/usr/share/OVMF/OVMF_VARS.fd

guest.loader.secure=/usr/share/OVMF/OVMF_CODE.secboot.fd

guest.loader.legacy=/usr/share/OVMF/OVMF_CODE.fd

guest.nvram.path=/var/lib/libvirt/qemu/nvram/

 

sudo ls -lh /usr/share/OVMF/



-rw-r--r-- 1 root root 1.9M Sep 20 13:11 OVMF_CODE.fd

lrwxrwxrwx 1 root root   20 Sep 20 13:11 OVMF_CODE.ms.fd -> OVMF_CODE.secboot.fd

-rw-r--r-- 1 root root 1.9M Sep 20 13:11 OVMF_CODE.secboot.fd

-rw-r--r-- 1 root root 128K Sep 20 13:11 OVMF_VARS.fd

-rw-r--r-- 1 root root 128K Sep 20 13:11 OVMF_VARS.ms.fd

-rw-r--r-- 1 root root 128K Sep 20 13:11 OVMF_VARS.snakeoil.fd

 

syslog

=

java[47841]: INFO  [kvm.resource.LibvirtComputingResource] (main:) (logid:) 
uefi.properties file found at /etc/cloudstack/agent/uefi.properties 

java[47841]: INFO  [kvm.resource.LibvirtComputingResource] (main:) (logid:) 
guest.nvram.template.legacy = /usr/share/OVMF/OVMF_VARS.fd

java[47841]: INFO  [kvm.resource.LibvirtComputingResource] (main:) (logid:) 
guest.loader.legacy = /usr/share/OVMF/OVMF_CODE.fd

java[47841]: INFO  [kvm.resource.LibvirtComputingResource] (main:) (logid:) 
guest.nvram.template.secure = /usr/share/OVMF/OVMF_VARS.fd

java[47841]: INFO  [kvm.resource.LibvirtComputingResource] (main:) (logid:) 
guest.loader.secure =/usr/share/OVMF/OVMF_CODE.secboot.fd

java[47841]: INFO  [kvm.resource.LibvirtComputingResource] (main:) (logid:) 
guest.nvram.path = /var/lib/libvirt/qemu/nvram/

 

 

-

Pieter

 

On 17 Dec 2021, at 16:15, Piotr Pisz mailto:pi...@piszki.pl> 
> wrote:

 

 

Hi Pieter,

 

 

 

I have just checked, everything works as expected, maybe you have something 
wrongly configured, check according to this:

 

 

 

https://lab.piszki.pl/cloudstack-vm-with-vtpm-and-secure-boot-uefi/

 

 

 

Regards,

 

Piotr

 

 

 

 

 

From: Pieter Harvey mailto:pieter.har...@icloud.com.INVALID> > 

Sent: Friday, December 17, 2021 4:11 PM

To: "users@cloudstack.apache.org  " 
mailto:users@cloudstack.apache.org> >

Subject: UEFI on KVM silently becomes BIOS mode

 

 

 

Hello,

 

 

 

Maybe it's something wrong with CloudStack, maybe it's my brain but I have an 
issue regarding UEFI on CloudStack (4.16) + KVM (Ubuntu 20.04)

 

 

 

1. CloudStack Compute node is running, and can boot machines configured as UEFI 
in the GUI (secure or legacy).

 

 

 

2. When the machine is booted, I check the virsh xml config on the host and 
noticed that the machine is still in BIOS mode, even though CloudStack "thinks" 
it has deployed a fresh UEFI enabled instance.

 

 

 

I have configured uefi.properties on the agent and the host is UEFI enabled in 
CloudStack but this is the config snippet of a deployed machine

 

 

 



 

hvm

 



 



 



 



 

 

 

However what I am expecting to see is: 

 

 

 



 

hvm

 



 



 



 



 



 

 

 

So CloudStack has changed the default machine type from 440fx to q35 but no 
mention of UEFI or secureboot options in the output XML.

 

 

 

Any tips to get UEFI and possibly secure boot fully working?

 

 

 

- 

 

Pieter

Re: UEFI on KVM silently becomes BIOS mode

2021-12-18 Thread Pieter Harvey 

Hi Piotr,Is there any way to get this debug info (or xml dump) from CloudStack, what it is creating versus what ends up in virsh? I think I have configured everything correctly1. cloudstack uefi enabled in database for host 
(host.uefi.enable)2. host agent has uefi.properties with all paths configured (snippet below based Ubuntu 20.04.3)3. instance is configured for UEFI (tried both legacy and secure 
boot)uefi.properties==guest.nvram.template.secure=/usr/share/OVMF/OVMF_VARS.fdguest.nvram.template.legacy=/usr/share/OVMF/OVMF_VARS.fdguest.loader.secure=/usr/share/OVMF/OVMF_CODE.secboot.fdguest.loader.legacy=/usr/share/OVMF/OVMF_CODE.fdguest.nvram.path=/var/lib/libvirt/qemu/nvram/sudo
 ls -lh /usr/share/OVMF/-rw-r--r-- 1 root root 1.9M Sep 20 13:11 OVMF_CODE.fdlrwxrwxrwx 1 root root   20 Sep 20 13:11 OVMF_CODE.ms.fd -> OVMF_CODE.secboot.fd-rw-r--r-- 1 root root 1.9M Sep 20 13:11 
OVMF_CODE.secboot.fd-rw-r--r-- 1 root root 128K Sep 20 13:11 OVMF_VARS.fd-rw-r--r-- 1 root root 128K Sep 20 13:11 OVMF_VARS.ms.fd-rw-r--r-- 1 root root 128K Sep 20 13:11 OVMF_VARS.snakeoil.fdsyslog=java[47841]: INFO  
[kvm.resource.LibvirtComputingResource] (main:) (logid:) uefi.properties file found at /etc/cloudstack/agent/uefi.properties java[47841]: INFO  [kvm.resource.LibvirtComputingResource] (main:) (logid:) guest.nvram.template.legacy = 
/usr/share/OVMF/OVMF_VARS.fdjava[47841]: INFO  [kvm.resource.LibvirtComputingResource] (main:) (logid:) guest.loader.legacy = /usr/share/OVMF/OVMF_CODE.fdjava[47841]: INFO  [kvm.resource.LibvirtComputingResource] (main:) (logid:) 
guest.nvram.template.secure = /usr/share/OVMF/OVMF_VARS.fdjava[47841]: INFO  [kvm.resource.LibvirtComputingResource] (main:) (logid:) guest.loader.secure =/usr/share/OVMF/OVMF_CODE.secboot.fdjava[47841]: INFO  
[kvm.resource.LibvirtComputingResource] (main:) (logid:) guest.nvram.path = /var/lib/libvirt/qemu/nvram/-PieterOn 17 Dec 2021, at 16:15, Piotr Pisz  wrote:Hi Pieter,I have just checked, everything works as 
expected, maybe you have something wrongly configured, check according to this:https://lab.piszki.pl/cloudstack-vm-with-vtpm-and-secure-boot-uefi/Regards,PiotrFrom: Pieter Harvey  Sent: 
Friday, December 17, 2021 4:11 PMTo: "users@cloudstack.apache.org" Subject: UEFI on KVM silently becomes BIOS modeHello,Maybe it's something wrong with CloudStack, maybe it's my brain 
but I have an issue regarding UEFI on CloudStack (4.16) + KVM (Ubuntu 20.04)1. CloudStack Compute node is running, and can boot machines configured as UEFI in the GUI (secure or legacy).2. When the machine is booted, I check the 
virsh xml config on the host and noticed that the machine is still in BIOS mode, even though CloudStack "thinks" it has deployed a fresh UEFI enabled instance.I have configured uefi.properties on the agent and the host 
is UEFI enabled in CloudStack but this is the config snippet of a deployed machinehvmHowever what I am expecting to see is: hvmSo CloudStack has changed the default machine type from 440fx to q35 but no mention of UEFI or secureboot options in the output XML.Any tips to get 
UEFI and possibly secure boot fully working?- Pieter