[ovirt-users] Re: Can't start VM because host has insufficient amount of CPU cores

2022-06-29 Thread Lucia Jelinkova
Hi Ramon,

Could you please share the following details?

   - what is the cluster's countThreadsAsCores setting (Edit Cluster dialog
   -> Optimization tab)
   - what is the VM's CPU topology for both VMs - running and failed (Edit
   VM -> System tab -> Advanced parameters)
   - a screenshot of the host's CPU topology (Host detail -> Host devices
   tab -> View CPU Pinning button)
   - what is in the engine.log (you need to enable DEBUG messages to see
   details why the host was filtered out)

Thank you,

Lucia

On Tue, Jun 28, 2022 at 11:35 PM Arik Hadas  wrote:

> On Tue, Jun 28, 2022 at 8:29 PM Ramon Clematide 
> wrote:
> >
> > Hi
> >
> > I just upgraded my oVirt installation from 4.4.10 to 4.5.1.2. The
> upgrade went through without any errors and most things seem to work but i
> have one critical problem now. Somehow it does not evaluate the correct
> number of CPU available on the hypervisor and blocks the start of a VM
> (except for the engine). The problem I only have on the hypervisor which
> has the engine deployed. I have three hypervisors, but only one has the
> engine installed. This hypervisor is also in a seperate cluster.
> >
> > After the upgrade, on the hypervisor which has the engine installed, I
> can't start a VM via the oVirt Manager. I can start the engine via
> "hosted-engine --vm-start" but if I try to start any other VM it fails with
> this Error:
> >
> > https://imgur.com/7lbGb8v
> >
> >
> 
> > Operation Canceled
> > Error while executing action:
> >
> > Razor:
> > Cannot run VM. There is no host that satisfies current scheduling
> constraints. See below for details:
> > The host venge did not satisfy internal filter CPU because it has an
> insufficient amount of CPU cores to run the VM.
> >
> 
> >
> > I did not change any specs for the VM and even if I reduce the VM to
> only use 1 core it fails with the error above.
> >
> > This are the specs of my hypervisor, it has 2 cores with 2 threads:
> >
> > https://imgur.com/rbJnqP3
> >
> > This is the ovirt version installed
> >
> > https://imgur.com/4LLTVFN
> >
> > Does someone know how to fix this?
>
> Sounds like https://bugzilla.redhat.com/2095259 but since the fix for
> that one is included in the version you use, I assume that's a
> different issue
> Lucia, can you please follow up on this?
>
>
> >
> > Regards
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/privacy-policy.html
> > oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> > List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/E3LAOVNSKKCLCP2KC7PNFPSUNVW5R7VD/
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MQDDDI5JKKR2BVWFTIK5AKQGH5P2FN65/


[ovirt-users] Re: New Template dialog, clicking OK in one environment results in template creation, the other environment does nothing.

2022-06-01 Thread Lucia Jelinkova
Hi,

What version are you using? We had a bug with creating a new template that
has been fixed in 4.5.0.8 [1]. It appeared only if there was no other
template except for the Blank template. Please try upgrading to that
version.

Regards,

Lucia

1: https://github.com/oVirt/ovirt-engine/pull/360


On Wed, Jun 1, 2022 at 6:37 AM  wrote:

> We have two oVirt environments configured, one for our Lab and one for
> Production.
>
> In the Lab, we can create templates. Clicking OK results in the New
> Template dialog disappearing and the VM's disk becomes locked and template
> creation begins.
>
> In the production environment, we cannot create templates. Clicking OK
> results in nothing, the dialog box remains. Nothing indicates
> missing/incorrect information.
>
> Both environments are on hosted engines, and oVirt Engine version 4.5. I
> have monitored the logs in the production environment and nothing comes up
> when the OK button is clicked.
>
> I have tested both environments in both Firefox and Chrome, and the
> behavior is also the same, our lab will progress, but production will
> simply not budge.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/7IQOK664QEGQ6JIT5EP3MTCNAHP23V6K/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/I5T4WKQZZS7VHMTVJ7KGZSL6B63WADQJ/


[ovirt-users] Re: Power Saving Schedule

2022-05-19 Thread Lucia Jelinkova
Hi,

Could you please try to set the HostsInReserve parameter of the
power_saving policy to 1? This should always keep 1 empty host (with no
running vms) to be ready in case the others are over utilized. If there are
more empty hosts, they should be put into maintenance or shut down, if
there is no empty host, a host should be put back online from maintenance
or down state.

Regards,

Lucia

On Thu, May 19, 2022 at 9:10 AM Maton, Brett 
wrote:

> Hi List,
>
>   I'm using the power_saving schedule to minimise the number of physical
> hosts which works as expected when scaling in, however it doesn't appear to
> ever scale out.
>
>   I've tried setting the minimum and maximum RAM and lowering the
> HighUsage (Utilization in American) percentage but it never starts another
> host.
>
>   If I don't change the scheduling policy and manually start another host,
> it gets powered off by the scheduler before any resources get allocated to
> it.
>
>   Am I missing a setting or is it just a MASSIVE flaw in the scheduler?
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/Q2JP52XA4GC4OSAIQ4ZKGTB2VLZ7EBVR/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/EEN2WY5QTLYEL7YLQYIXE5IQWUA5FINQ/


[ovirt-users] Re: Ignore CPU_TYPE_UNSUPPORTED_IN_THIS_CLUSTER_VERSION ?

2022-02-02 Thread Lucia Jelinkova
Hi,

The list should contain more items. Could you please try to create a new
cluster using UI, set the compatibility level to 4.6, architecture to
x86_64 and check the CPU Type dropdown again? Please try to scroll down the
dropdown and if there are no more values than you've already mentioned,
please try a different browser to rule out the possibility it is some kind
of UI issue.

If the UI looks fine, you may try to check the configuration values in the
database by running this DB query:

select option_value from vdc_options where option_name = 'ServerCPUList'
and version = '4.6';

The returned configuration should contain the AMD CPUs.

Please, share your findings.

Regards,

Lucia

On Wed, Feb 2, 2022 at 12:30 PM Martin Perina  wrote:

>
>
> On Wed, Feb 2, 2022 at 12:11 PM Richard W.M. Jones 
> wrote:
>
>> On Wed, Feb 02, 2022 at 11:07:21AM +0100, Martin Perina wrote:
>> > You cannot mix AMD and Intel processors in a cluster. So if you have an
>> AMD
>> > based host, then you need to add it to AMD cluster only
>>
>> I have two VMs - one for engine and one for node.  They are both
>> running on the same physical host (using KVM).
>>
>> > AMD EPYC support is available from 4.3 cluster level, so it should
>> definitely
>> > be available in the latest 4.6 CL
>>
>> I'm more confused here.  I'm running what I believe to be the latest
>> oVirt engine (4.4.10.6-1.el8).
>>
>> There are no AMD CPUs offered for cluster CPU type, only Intel CPUs:
>>
>> Intel Nehalem Family
>> Secure Intel Nehalem Family
>> Intel Westmere Family
>> Secure Intel Westmere Family
>> Intel Sandybridge Family
>>
>> (that's the complete list)
>>
>
> Lucia, any ideas?
>
>>
>> Rich.
>>
>> --
>> Richard Jones, Virtualization Group, Red Hat
>> http://people.redhat.com/~rjones
>> Read my programming and virtualization blog: http://rwmj.wordpress.com
>> virt-p2v converts physical machines to virtual machines.  Boot with a
>> live CD or over the network (PXE) and turn machines into KVM guests.
>> http://libguestfs.org/virt-v2v
>>
>>
>
> --
> Martin Perina
> Manager, Software Engineering
> Red Hat Czech s.r.o.
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XSURKJFMUDQY4MRQBIKMNXIHF5P43NOA/


[ovirt-users] Re: Unable to install OVirt 4.4.6 on IvyBridge

2021-11-15 Thread Lucia Jelinkova
Hi,

could you please run the following command on the non responsive host and
post the output here?

virsh domcapabilities

Also, could you please go to the Webadmin UI and check the warning signs on
the host list and host detail to see, what flags is the host missing? You
can also check the CPU Type on the host's detail page + all available cpus
in the info icon next to it.

Regards,

Lucia

On Mon, Nov 15, 2021 at 6:30 AM  wrote:

> Hi, I'm attempting to build an oVirt node on a server. The host is an RHEL
> 8.4, I'm attempting to install OVirt 4.4.6 as per  instructions at
> https://www.ovirt.org/documentation/installing_ovirt_as_a_self-hosted_engine_using_the_command_line/index.html.
> I'm receiving the following error:
>
> [ INFO  ] The host has been set in non_operational status, deployment
> errors:   code 156: Host redacted.com moved to Non-Operational state as
> host CPU type is not supported in this cluster compatibility version or is
> not supported at all,code 9000: Failed to verify Power Management
> configuration for Host redacted.com.,
> [ INFO  ] skipping: [localhost]
> [ INFO  ] You can now connect to https://redacted.com:6900/ovirt-engine/
> and check the status of this host and eventually remediate it, please
> continue only when the host is listed as 'up'
>
> Now, I note that initially lm_sensors was unable to detect CPU
> temperatures, which was subsequently resolved (I don't recall how), however
> the issue still remains.
>
> The CPU is an Xeon E5-2630 (IvyBridge). I cannot see any definitive CPU
> support catalog, so I'm unsure if this is no longer supported.
>
> Within engine-logs-2021-11-13T12:22:10Z/log/ovirt-engine/engine.log, there
> were occurrences of `IvyBridge-IBRS`. From
> what I can tell, spectre/meltdown bugs have been mitigated:
>
> ```
> egrep -e "model|cpu family|stepping|microcode" /proc/cpuinfo | sort | uniq
> cpu family  : 6
> microcode   : 0x42e
> model   : 62
> model name  : Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz
> stepping: 4
> ```
>
> In the installation documents, IvyBridge seems supported but the evidence
> above suggests it may not be. Can anyone advise on if this processor is
> _actually_ supported, and if so how I can remediate the issue? Thanks!
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/GJS4GPYH7WG2YE444VQPYTWUYTX66JXM/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VC4VK5H7J6EQX2F6CSWZEJNV5MLWCABF/


[ovirt-users] Re: Change Cluster CPU type

2021-09-06 Thread Lucia Jelinkova
Please check the engine.log, there should be details of what went wrong
with the HostedEngine update.

Thanks,

Lucia

On Thu, Sep 2, 2021 at 9:02 PM Andrey Rusakov  wrote:

> Exact Error
>
> Error while executing action: Cannot update cluster because the update
> triggered update of the VMs/Templates and it failed for the following:
> HostedEngine. To fix the issue, please go to each of them, edit, change the
> Custom Compatibility Version (or other fields changed previously in the
> cluster dialog) and press OK
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/IS5I437F72CAU3F4IUYWELLQDUP5RAXK/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CYO4ZOIUXHAFL3LO42XIMKYIDTTWZFOH/


[ovirt-users] Re: Update to 4.4.8 leaves cluster in a circular error-state

2021-09-06 Thread Lucia Jelinkova
Hi,

I think you're hitting the same issue with the edk2-ovmf package as some
users before [1], please check the version of that package. If it is
20200602gitca407c7246bf-5.el8 it is a broken version and you should
downgrade to 20200602gitca407c7246bf-4.el8_4.1.

1:
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/ZTOZO4DO6F6LKHEJLY4HI7GSSZ2T54ZL/#VQC7OCVHXEMRIUR26YXMZMKS5SKWURH7

Regards,

Lucia

On Fri, Sep 3, 2021 at 6:58 PM Paul-Erik Törrönen  wrote:

> On 9/2/21 9:16 AM, Lucia Jelinkova wrote:
> > Could you please share more details about the CPU problem you're facing?
> > There shouldn't be any breaking change in that CPU definition in 4.4+
> > compatibility version.
>
> Unfortunately not, I've already made irreversible changes to the cluster
> so that I can no longer reproduce the error which I got when I tried to
> activate one of the Dell hosts and which resulted in an error about the
> CPU family.
>
> After having wiped out most of the configurations I still do get a
> related error:
>
> "The host CPU does not match the Cluster CPU Type and is running in a
> degraded mode. It is missing the following CPU flags: vmx, nx,
> model_Westmere, aes. Please update the host CPU microcode or change the
> Cluster CPU Type."
>
> This error is not quite accurate since lscpu does list all of the flags
> mentioned above, except for the model_Westmere.
>
> IIRC there were some comments in the mailing list earlier this year WRT
> this flag-mismatch and being related to incompatible linux-firmware
> package. Currently the host that generates this error has this package
> installed:
>
> Name: linux-firmware
> Version : 20210702
> Release : 103.gitd79c2677.el8
>
> Will need to dig through the mailing list archives.
>
> Poltsi
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/SUGLF3ON72DBZCE3Z4BEJDSBYPHFX6GU/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/IY26UE6P7PIZI7HOIJ5PKWT3B3P252FS/


[ovirt-users] Re: Update to 4.4.8 leaves cluster in a circular error-state

2021-09-02 Thread Lucia Jelinkova
Hi,

Could you please share more details about the CPU problem you're facing?
There shouldn't be any breaking change in that CPU definition in 4.4+
compatibility version.

Regards,

Lucia

On Wed, Sep 1, 2021 at 7:15 PM Paul-Erik Törrönen  wrote:

> Having updated rpm-packages for a DC with a cluster containing 2 hosts
> (and executed the engine-setup on the engine machine), I now face the
> following issue:
>
> One of the VMs had a couple of snapshots and apparently this interferes
> with the upgrade of the cluster version, which currently is 4.4.
>
> The 4.4 has become incompatible with the chosen CPU architecture (Intel
> Westmere Family, the hosts are both Dell x10-series with Xeon X56xx
> CPUs) and requires an upgrade to newer compatibility version, 4.6
> presumably, so the DC/Cluster state is "unknown". However I can't do
> this because the snapshots exists. I get the "Cannot change cluster
> version since following VMs are previewing snapshots:" listing a VM with
> snapshots. The snapshots in turn can not be Commit/Undo because: "Cannot
> revert to Snapshot. Unknown Data Center status.".
>
> So how do I break this circular error? The VM itself is not essential,
> it can be removed if that solves the case. However this can not be
> completed from the UI because: "Cannot remove VM. Unknown Data Center
> status.".
>
> Poltsi
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/MVFQJJNEXVR74HFB3VQ4UC5ZTFH7YDNZ/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/P22UF5RB7BXRSUPVUMMTHU5GATFQYXY7/


[ovirt-users] Re: adding new host failed with error "CPU does not match the Cluster CPU Type"

2021-08-09 Thread Lucia Jelinkova
It might be that the host is not reporting the host capabilities correctly.
You can see all host's supported CPUs in the host detail screen, just roll
over the info icon next to the CPU  Type.

You can check if the data are in the database like this:
select cpu_flags from vds where vds_name = 'your-host-name';

And you can check what the host reports by running the following command on
the host (search for cpuFlags key):
sudo vdsm-client Host getCapabilities

Make sure the capabilities contain all required flags - vmx,
model_Haswell-noTSX and nx.

Regards,

Lucia







On Mon, Aug 2, 2021 at 4:00 PM jimod4--- via Users  wrote:

> If I run lscpu it shows the vmx and nx flags are there. Virtualization is
> enabled in bios.  I have vms running on the kvm  host
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/SIYJ6X3DSZSMPZSW3C2AG6NPIWBVMJXC/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/D7Z36D5YDFUQKZXXQQFU7APIRZH6HRCN/


[ovirt-users] Re: CPU Compatibility Problem after Upgrading Centos 8 Stream Host

2021-07-28 Thread Lucia Jelinkova
Hi Christoph,

The 20200602gitca407c7246bf-5.el8 is the "broken" one [1], try downgrading
to the older version (I have 20200602gitca407c7246bf-4.el8_4.1).

1: https://bugzilla.redhat.com/show_bug.cgi?id=1961558#c6

Regards,

Lucia

On Wed, Jul 28, 2021 at 9:40 AM Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

>
>
> On 26. 7. 2021, at 15:06, Christoph Timm  wrote:
>
> Hi all,
>
> please note that I also tried to migrate one of my hosts from CentOS 8 to
> CentOS Stream 8.
> After the reboot I received the following message:
> The host CPU does not match the Cluster CPU Type and is running in a
> degraded mode. It is missing the following CPU flags: model_IvyBridge,
> spec_ctrl. Please update the host CPU microcode or change the Cluster CPU
> Type.
>
> I downgraded the edk2-ovmf package to the following version:
> 20200602gitca407c7246bf-5.el8
>
>
> upgraded. that’s a newer version than the one below
>
> The following version was installed before:  20210527gite1999b264f1f-1.el8
>
> But still the issue is present for me.
>
>
> I’m not aware of any issue with the virt stack packages in Stream, that
> edk2-ovmf issue has been fixed few weeks back, the new version is the right
> one, but maybe you have other outdated packages?
> Also please refresh host capabilities after each such package change.
>
> There also could be a microcode change for IvyBridge that you’ve missed
> (or intel didn’t fix for your particular cpu)…perhaps it’s good enough to
> just change the Cluster CPU to SandyBridge instead.
>
>
> I'm running latest 4.4.7 and my cluster version is 4.6.
>
> Best regards
> Christoph
>
>
> Am 27.05.21 um 16:26 schrieb Gunasekhar Kothapalli via Users:
>
> The issue was with edk2-ovmf package update, rolling that package back and
> it started recognizing the CPU and host coming up... tested on one host and
> worked fine.
>
>
>
> Thanks & Regards,
> *Gunasekhar Kothapalli*
>
>
> *From:* Nur Imam Febrianto  
> *Sent:* Wednesday, May 26, 2021 9:54 PM
> *To:* k.gunasek...@non.keysight.com; users@ovirt.org
> *Subject:* RE: [ovirt-users] Re: CPU Compatibility Problem after
> Upgrading Centos 8 Stream Host
>
>
> *CAUTION:* This message originates from an external sender.
> Already trying several things, seem kernel update doesn’t make this
> problem happen. Already tried to yum update exclude kernel, the issue still
> happened.
>
> Thanks.
>
> Regards,
> Nur Imam Febrianto
>
> *From: *k.gunasekhar--- via Users 
> *Sent: *26 May 2021 12:27
> *To: *users@ovirt.org
> *Subject: *[ovirt-users] Re: CPU Compatibility Problem after Upgrading
> Centos 8 Stream Host
>
> I also end up with the same problem today. How did rollback yum i see many
> yum updates in the yum history.
>
> Here is what the error says.
>
> The host CPU does not match the Cluster CPU Type and is running in a
> degraded mode. It is missing the following CPU flags: model_IvyBridge,
> spec_ctrl. Please update the host CPU microcode or change the Cluster CPU
> Type.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement:
> https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fprivacy-policy.htmldata=04%7C01%7C%7Ccdfdf3baa30a417b631a08d92006eeac%7C84df9e7fe9f640afb435%7C1%7C0%7C637576036430558160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ioM1ZSkM2q7CNvInAJQdg0n%2BZdUNSMG%2BpmapvHi%2FFKo%3Dreserved=0
> 
> oVirt Code of Conduct:
> https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunity%2Fabout%2Fcommunity-guidelines%2Fdata=04%7C01%7C%7Ccdfdf3baa30a417b631a08d92006eeac%7C84df9e7fe9f640afb435%7C1%7C0%7C637576036430558160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=6pxtmPuppncwbn6Q3sRxYq%2BdpbK68bZ1HV28qnxAf0w%3Dreserved=0
> 

[ovirt-users] Re: Q: Node host becomes non-operational after upgrade

2021-07-07 Thread Lucia Jelinkova
Hi,

The issue has already been discussed in this thread [1]. Please check the
version of edk2-ovmf package and downgrade to
20200602gitca407c7246bf-4.el8_4.1 if necessary.

Lucia


1:
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/D47YYGMGJZIOM3QTDRVNBMRDEPK4ZMCQ/

On Tue, Jul 6, 2021 at 8:35 PM Andrei Verovski  wrote:

> Hi,
>
>
> Today I upgraded oVirt Engine to 4.4.7.6, and then one of the nodes
> (running Centos Stream).
> After upgrade node (node14) becomes non-operational. Same after
> “Reinstall”.
>
> Additionally, there are MANY error messages:
> Host node14 moved to Non-Operational state as host CPU type is not
> supported in this cluster compatibility version or is not supported at all
> Quite strange, before upgrade problem with CPU host type didn't exist.
> vdsm-networking service is running fine on node14.
> vdsmd running but have this error message:
> Jul 06 21:19:23 node14.xxx sudo[3565]: pam_systemd(sudo:session): Failed
> to create session: Start job for unit user-0.slice failed with 'canceled'
>
> I suspect that there are unnecessary repos enabled in my CentOS stream
> node, which leads to this kind of errors.
> Please can anyone check? Thanks in advance.
>
> 
>
> [root@node14 ~]# yum repolist enabled
>
> repo id repo name
> appstream CentOS Stream 8 - AppStream
> baseos CentOS Stream 8 - BaseOS
> epel-next Extra Packages for Enterprise Linux 8 - Next - x86_64
> extras CentOS Stream 8 - Extras
> ovirt-4.4 Latest oVirt 4.4 Release
> ovirt-4.4-centos-ceph-pacific Ceph packages for x86_64
> ovirt-4.4-centos-gluster8 CentOS-8 - Gluster 8
> ovirt-4.4-centos-opstools CentOS-8 - OpsTools - collectd
> ovirt-4.4-centos-stream-advanced-virtualization Advanced Virtualization
> CentOS Stream packages for x86_64
> ovirt-4.4-centos-stream-nfv-openvswitch CentOS-8 - NFV OpenvSwitch
> ovirt-4.4-centos-stream-ovirt44 CentOS-8 Stream - oVirt 4.4
> ovirt-4.4-copr:copr.fedorainfracloud.org:mdbarroso:ovsdbapp Copr repo
> for ovsdbapp owned by mdbarroso
> ovirt-4.4-copr:copr.fedorainfracloud.org:sac:gluster-ansible Copr repo
> for gluster-ansible owned by sac
> ovirt-4.4-copr:copr.fedorainfracloud.org:sbonazzo:EL8_collection Copr
> repo for EL8_collection owned by sbonazzo
> ovirt-4.4-epel Extra Packages for Enterprise Linux 8 - x86_64
> ovirt-4.4-openstack-train OpenStack Train Repository
> ovirt-4.4-virtio-win-latest virtio-win builds roughly matching what will
> be shipped in upcoming RHEL
> powertools CentOS Stream 8 - PowerTools
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/MUEX3WZJBT77RYU5XAZKJA5ZGPCYDB6U/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BLD2IFMREOYYQO2OIXAV5Q7Z7HRPLHR6/


[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

2020-12-15 Thread Lucia Jelinkova
Hi Lionel,

if you managed to remove the host (or move it to a different cluster) so
that all hosts in your cluster are UP - you could try to put one of your
running hosts to the maintenance and then back to active - the cluster
settings should be updated on the host activation. You can look for the log
"Updating cluster CPU flags and verb according to the configuration of the
[cluster name]".

If that does not help, you can try to restart the engine.

Please let me know if that helps.

Lucia

On Tue, Dec 15, 2020 at 12:53 PM Lionel Caignec  wrote:

> Thank you i understand now.
>
> I double checked all my 8.2 host about cababilities and they seems ok.
>
> I think i foudn the source of this "bug".
>
> For this time i've updated one host in 8.3 (the non operative one), and
> then i update engine and run engine-setup (with all host up and activated
> except the 8.3 one). Maybe this is why the cluster table is not updated?
>
> What do you think, if y remove the 8.3 host, rerun "engine-setup" an
> re-add the 8.3 host?
>
>
> Lionel.
>
> --
> *De: *"Lucia Jelinkova" 
> *À: *"Lionel Caignec" 
> *Cc: *"thomas" , "users" 
> *Envoyé: *Mardi 15 Décembre 2020 11:31:47
> *Objet: *Re: [ovirt-users] Re: Bad CPU TYPE after Centos 8.3
>
> Hi Lionel,
>
> in oVirt 4.4.2 the Secure Intel Cascadelake Server Family was configured
> to use the Cascadelake-Server libvirt/qemu CPU. In oVirt 4.4.3, this has
> been changed to Cascadelake-Server-noTSX libvirt/qemu CPU (since the TSX
> was dropped in 8.3).
>
> The problem you're facing is caused by this transition. In the cluster
> table you can see that the running hosts still use the old configuration -
> Cascadelake-Server. That is why the new 8.3 host is non operative.
>
> Now the question is why the configuration in the cluster table was not
> updated. This should be the correct workflow:
> 1. engine update from 4.4.2 to 4.4.3
> 2. during engine-setup, the configuration values should be updated in the
> vdc_table in the database
> 3. during engine startup, the cluster value should be updated IF all hosts
> are UP AND all hosts comply to the new configuration
>
> Could anything from the below cause the configuration in the cluster table
> not to be updated?
> a) engine-setup was not performed
> b) not all hosts in the cluster were UP
> c) some of the 8.2 hosts do not support the Cascadelake-Server-noTSX (I
> can see that the 8.2 you've checked does support it, maybe it would be
> worth checking the others as well).
>
> Based on your answer we can try a workaround in the Webadmin before
> changing the kernel values.
>
> Regards,
>
> Lucia
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MTMD7EHO3MDTYKTVVCK7VTCYNH2LHDVD/


[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

2020-12-15 Thread Lucia Jelinkova
Hi Lionel,

in oVirt 4.4.2 the Secure Intel Cascadelake Server Family was configured to
use the Cascadelake-Server libvirt/qemu CPU. In oVirt 4.4.3, this has been
changed to Cascadelake-Server-noTSX libvirt/qemu CPU (since the TSX was
dropped in 8.3).

The problem you're facing is caused by this transition. In the cluster
table you can see that the running hosts still use the old configuration -
Cascadelake-Server. That is why the new 8.3 host is non operative.

Now the question is why the configuration in the cluster table was not
updated. This should be the correct workflow:
1. engine update from 4.4.2 to 4.4.3
2. during engine-setup, the configuration values should be updated in the
vdc_table in the database
3. during engine startup, the cluster value should be updated IF all hosts
are UP AND all hosts comply to the new configuration

Could anything from the below cause the configuration in the cluster table
not to be updated?
a) engine-setup was not performed
b) not all hosts in the cluster were UP
c) some of the 8.2 hosts do not support the Cascadelake-Server-noTSX (I can
see that the 8.2 you've checked does support it, maybe it would be worth
checking the others as well).

Based on your answer we can try a workaround in the Webadmin before
changing the kernel values.

Regards,

Lucia

On Tue, Dec 15, 2020 at 11:01 AM Lionel Caignec  wrote:

> Hi All,
> and thanks for helping me
>
> So if i does not mistakte, we cannot use anymore cascadelake Server in
> centos 8.3?
> Cluster configuration is Secure CascadeLake Server Family
>
>
>
> Here is output of the sql query :
>
> name|cpu_name|
> cpu_flags   |
> cpu_verb
>
> ++--+-
>  moria | Secure Intel Cascadelake Server Family |
> vmx,mds-no,md-clear,model_Cascadelake-Server |
> Cascadelake-Server,+md-clear,+mds-no,-hle,-rtm,+tsx-ctrl,+arch-capabilities
>
>
> So in your link they said TSX is disabled by default, may i enable it? or
> the best option is to change cluster cpu type to lower value?
>
> Sorry for all my question i'm quite lost
>
>
> Regards,
> Lionel.
> --
> *De: *"Lucia Jelinkova" 
> *À: *tho...@hoberg.net
> *Cc: *"users" 
> *Envoyé: *Mardi 15 Décembre 2020 10:20:08
> *Objet: *[ovirt-users] Re: Bad CPU TYPE after Centos 8.3
>
> Hi Lionel,
>
> Thank you for the output from the virsh command. The interesting part is
> this:
>
> Cascadelake-Server-noTSX
> Cascadelake-Server
>
> The Cascadelake-Server is not usable any more in 8.3 [1] yet that is what the 
> cluster is probably configured with.
>
> Could you please run the following query for your cluster to be sure?
>
> select name, cpu_name, cpu_flags, cpu_verb from cluster;
>
> Could you please also run the virsh domcapabilities command on one of your 
> active and running 8.2 hosts to see if they support Cascadelake-Server-noTSX?
>
> 1: https://www.phoronix.com/scan.php?page=news_item=Red-Hat-RHEL-8.3
>
> Thank you,
>
> Lucia
>
>
>
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/PWYZH3SK2WALLMWYS45EDAENP4IJQLSZ/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/4QUDRL6NMRVNAZ2KO52THOJLOK2IZFJT/


[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

2020-12-15 Thread Lucia Jelinkova
Hi Lionel,

Thank you for the output from the virsh command. The interesting part is
this:

Cascadelake-Server-noTSX
Cascadelake-Server

The Cascadelake-Server is not usable any more in 8.3 [1] yet that is
what the cluster is probably configured with.

Could you please run the following query for your cluster to be sure?

select name, cpu_name, cpu_flags, cpu_verb from cluster;

Could you please also run the virsh domcapabilities command on one of
your active and running 8.2 hosts to see if they support
Cascadelake-Server-noTSX?

1: https://www.phoronix.com/scan.php?page=news_item=Red-Hat-RHEL-8.3

Thank you,

Lucia





On Mon, Dec 14, 2020 at 7:37 PM  wrote:

> Hi, that CPU looks rather good to me: KVM/oVirt should love it (as would
> I)!
>
> I am actually more inclined to believe that it may be a side channel
> mitigation issue: KVM is distingiuishing between base CPUs and CPUs with
> enabled mitigations to ensure that you won't accidentally migrate a VM from
> a 'safe' CPU to one that's vulnerable.
>
> So I suggest you have a look at that, seen what's enabled in BIOS and via
> microcode updates and check that against what the cluster wants. Perhaps it
> may involve as little as ensuring all current patches are in (with reboots)
> after the update to 8.3.
>
> E.g. you might see this when the cluster was previously running on a
> system with mitigations active, but now mitigations are off (e.g. because
> the latest microcode updates are not loaded yet).
>
> My personal impression is that it wasn't a terribly good idea to mix
> mitigations and CPU capabilities, but that they didn't have time/means for
> a full redesign to what they might have hoped was a singular/one shot
> issue, before it developed into a whole family of cancers.
>
>
> Bonne chance!
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/OHLWLUG23QST3NJCVIX57RR6ZRMSY6VM/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PWYZH3SK2WALLMWYS45EDAENP4IJQLSZ/


[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

2020-12-14 Thread Lucia Jelinkova
Hi Lionel,

could you please run the following command on the non responsive host?

virsh domcapabilities

Also, could you please go to the Webadmin UI and check the warning signs on
the host list and host detail to see, what flags is the host missing? You
can also check the CPU Type on the host's detail page + all available cpus
in the info icon next to it.

Regards,

Lucia


On Mon, Dec 14, 2020 at 10:02 AM Lionel Caignec  wrote:

> Hi,
>
> i've just upgraded one host to latest centos release. And after reboot
> ovirt said "Host CPU type is not compatible with Cluster Properties."
> Looking on server i can see cpu is detected as skylake (cat
> /sys/devices/cpu/caps/pmu_name).
>
> My CPU is Intel(R) Xeon(R) Gold 5220R CPU @ 2.20GHz so according to ark
> cascade lake server.
> When i installed my new ovirt environment month agos, i configure cluster
> to be "secure Intel Cascade lake server family" and all sound goods.
>
>
> So anyone can help me?
>
>
> Environment :
> OS : Centos 8.3 (for manager and host in error)
> ovirt-engine 4.4.3.12-1.el8
> Host with error : vdsm.x86_64  4.40.35.1-1.el8
>
> Working Host : vdsm.x86_64  .40.26.3-1.el8
>
>
> Maybe someone can help me? I don't know what to do, and does not want to
> try update another host  if it fail...
>
>  Sorry if i post my message at wrong place.
>
> Lionel Caignec.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/N3PPT34GBRLPLTSWS6MLBBE2FSPXUCVI/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UWGNTM3ITY3CRAB45LREKBX43KVK3GL7/


[ovirt-users] Re: EPYC CPU not being detected correctly on cluster

2020-11-26 Thread Lucia Jelinkova
Hi Vinícius,

I am glad you've managed to solve it and thanks for sharing your findings.

Lucia

On Wed, Nov 25, 2020 at 9:07 PM Vinícius Ferrão 
wrote:

> Lucia, I ended figuring out.
>
>
>
> The culprit is that I was pinned with the wrong virt module; after running
> this commands I was able to have the CPU properly detected:
>
>
>
> # dnf module reset virt
>
> # dnf module enable virt:8.3
>
> # dnf upgrade –nobest
>
>
>
> I think virt was in 8.2.
>
>
>
> Thank you!
>
>
>
> *From:* Lucia Jelinkova 
> *Sent:* Monday, November 23, 2020 6:25 AM
> *To:* Vinícius Ferrão 
> *Cc:* users 
> *Subject:* Re: [ovirt-users] EPYC CPU not being detected correctly on
> cluster
>
>
>
> Hi Vinícius,
>
>
>
> Thank you for the libvirt output - libvirt marked the EPYC CPU as not
> usable. Let's query qemu why that is.  You do not need an oVirt VM to do
> that, just any VM running on qemu, e.g. created by Virtual Machines Manager
> or you can follow the command from the answer here:
>
>
>
>
> https://unix.stackexchange.com/questions/309788/how-to-create-a-vm-from-scratch-with-virsh
>
>
>
> Then you can use the following commands:
>
> sudo virsh list --all
>
> sudo virsh qemu-monitor-command [your-vm's-name] --pretty
> '{"execute":"query-cpu-definitions"}'
>
>
>
> I do not know if this could be related to UEFI Firmware, lets check the
> qemu output first.
>
>
>
> Regards,
>
>
>
> Lucia
>
>
>
>
>
> On Fri, Nov 20, 2020 at 4:07 PM Vinícius Ferrão 
> wrote:
>
> Hi Lucia,
>
>
>
> I had to create an user for virsh:
>
> # saslpasswd2 -a libvirt test
>
> Password:
>
> Again (for verification):
>
>
>
> With that in mind, here’s the outputs:
>
>
>
> 
>
>   /usr/libexec/qemu-kvm
>
>   kvm
>
>   pc-i440fx-rhel7.6.0
>
>   x86_64
>
>   
>
>   
>
>   
>
> 
>
> 
>
>   /usr/share/OVMF/OVMF_CODE.secboot.fd
>
>   
>
> rom
>
> pflash
>
>   
>
>   
>
> yes
>
> no
>
>   
>
>   
>
> no
>
>   
>
> 
>
>   
>
>   
>
> 
>
> 
>
>   EPYC-IBPB
>
>   AMD
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
> 
>
> 
>
>   qemu64
>
>   qemu32
>
>   phenom
>
>   pentium3
>
>   pentium2
>
>   pentium
>
>   n270
>
>   kvm64
>
>   kvm32
>
>   coreduo
>
>   core2duo
>
>   athlon
>
>   Westmere-IBRS
>
>   Westmere
>
>   Skylake-Server-noTSX-IBRS
>
>   Skylake-Server-IBRS
>
>   Skylake-Server
>
>   Skylake-Client-noTSX-IBRS
>
>   Skylake-Client-IBRS
>
>   Skylake-Client
>
>   SandyBridge-IBRS
>
>   SandyBridge
>
>   Penryn
>
>   Opteron_G5
>
>   Opteron_G4
>
>   Opteron_G3
>
>   Opteron_G2
>
>   Opteron_G1
>
>   Nehalem-IBRS
>
>   Nehalem
>
>   IvyBridge-IBRS
>
>   IvyBridge
>
>   Icelake-Server-noTSX
>
>   Icelake-Server
>
>   Icelake-Client-noTSX
>
>   Icelake-Client
>
>   Haswell-noTSX-IBRS
>
>   Haswell-noTSX
>
>   Haswell-IBRS
>
>   Haswell
>
>   EPYC-IBPB
>
>   EPYC
>
>   Dhyana
>
>  Cooperlake
>
>   Conroe
>
>   Cascadelake-Server-noTSX
>
>   Cascadelake-Server
>
>   Broadwell-noTSX-IBRS
>
>   Broadwell-noTSX
>
>   Broadwell-IBRS
>
>   Broadwell
>
>   486
>
> 
>
>   
>
>   
>
> 
>
>   
>
> disk
>
> cdrom
>
> floppy
>
> lun
>
>   
>
>   
>
> ide
>
> fdc
>
> scsi
>
> virtio
>
> usb
>
> sata
>
>   
>
>   
>
> virtio
>
> virtio-transitional
>
> virtio-non-transitional
>
>   
>
> 
>
> 
>
>   
>
> sdl
>

[ovirt-users] Re: Intel Cascade Lake Family supported

2020-11-23 Thread Lucia Jelinkova
Hi Ramon,

yes, it is. However, you should know that if you disabled tsx in the system
(or it simply would not be reported in /proc/cpuinfo) you'd need to use the
secure variant of the CPU [1].

1: https://gerrit.ovirt.org/#/c/111242/

Regards,

Lucia

On Mon, Nov 23, 2020 at 2:29 PM Gianluca Cecchi 
wrote:

> On Mon, Nov 23, 2020 at 2:23 PM Ramon Sierra  wrote:
>
>> Hi,
>>
>> We are planning to upgrade our cluster hardware. We would like to know
>> if Intel Cascade Lake CPUs are supported on ovirt 4.4.3. Any
>> recommendation is very welcome.
>>
>> Regards,
>>
>> Ramon
>>
>>
> I think this could be a good starting point also for oVirt 4.4.x,
> confirming your cpu as supported;
>
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/planning_and_prerequisites_guide/rhv_requirements#CPU_Requirements_RHV_planning
>
> Gianluca
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/WP3XF3KKIQAGWZTI5TD2XLBXBCZJCQG3/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/V5VU5GCB5FZZ2AEJ37RWFPSD3BLPXXE3/


[ovirt-users] Re: EPYC CPU not being detected correctly on cluster

2020-11-23 Thread Lucia Jelinkova
Hi Vinícius,

Thank you for the libvirt output - libvirt marked the EPYC CPU as not
usable. Let's query qemu why that is.  You do not need an oVirt VM to do
that, just any VM running on qemu, e.g. created by Virtual Machines Manager
or you can follow the command from the answer here:

https://unix.stackexchange.com/questions/309788/how-to-create-a-vm-from-scratch-with-virsh

Then you can use the following commands:
sudo virsh list --all
sudo virsh qemu-monitor-command [your-vm's-name] --pretty
'{"execute":"query-cpu-definitions"}'

I do not know if this could be related to UEFI Firmware, lets check the
qemu output first.

Regards,

Lucia


On Fri, Nov 20, 2020 at 4:07 PM Vinícius Ferrão 
wrote:

> Hi Lucia,
>
>
>
> I had to create an user for virsh:
>
> # saslpasswd2 -a libvirt test
>
> Password:
>
> Again (for verification):
>
>
>
> With that in mind, here’s the outputs:
>
>
>
> 
>
>   /usr/libexec/qemu-kvm
>
>   kvm
>
>   pc-i440fx-rhel7.6.0
>
>   x86_64
>
>   
>
>   
>
>   
>
> 
>
> 
>
>   /usr/share/OVMF/OVMF_CODE.secboot.fd
>
>   
>
> rom
>
> pflash
>
>   
>
>   
>
> yes
>
> no
>
>   
>
>   
>
> no
>
>   
>
> 
>
>   
>
>   
>
> 
>
> 
>
>   EPYC-IBPB
>
>   AMD
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
> 
>
> 
>
>   qemu64
>
>   qemu32
>
>   phenom
>
>   pentium3
>
>   pentium2
>
>   pentium
>
>   n270
>
>   kvm64
>
>   kvm32
>
>   coreduo
>
>   core2duo
>
>   athlon
>
>   Westmere-IBRS
>
>   Westmere
>
>   Skylake-Server-noTSX-IBRS
>
>   Skylake-Server-IBRS
>
>   Skylake-Server
>
>   Skylake-Client-noTSX-IBRS
>
>   Skylake-Client-IBRS
>
>   Skylake-Client
>
>   SandyBridge-IBRS
>
>   SandyBridge
>
>   Penryn
>
>   Opteron_G5
>
>   Opteron_G4
>
>   Opteron_G3
>
>   Opteron_G2
>
>   Opteron_G1
>
>   Nehalem-IBRS
>
>   Nehalem
>
>   IvyBridge-IBRS
>
>   IvyBridge
>
>   Icelake-Server-noTSX
>
>   Icelake-Server
>
>   Icelake-Client-noTSX
>
>   Icelake-Client
>
>   Haswell-noTSX-IBRS
>
>   Haswell-noTSX
>
>   Haswell-IBRS
>
>   Haswell
>
>   EPYC-IBPB
>
>   EPYC
>
>   Dhyana
>
>  Cooperlake
>
>   Conroe
>
>   Cascadelake-Server-noTSX
>
>   Cascadelake-Server
>
>   Broadwell-noTSX-IBRS
>
>   Broadwell-noTSX
>
>   Broadwell-IBRS
>
>   Broadwell
>
>   486
>
> 
>
>   
>
>   
>
> 
>
>   
>
> disk
>
> cdrom
>
> floppy
>
> lun
>
>   
>
>   
>
> ide
>
> fdc
>
> scsi
>
> virtio
>
> usb
>
> sata
>
>   
>
>   
>
> virtio
>
> virtio-transitional
>
> virtio-non-transitional
>
>   
>
> 
>
> 
>
>   
>
> sdl
>
> vnc
>
> spice
>
>   
>
> 
>
> 
>
>   
>
> vga
>
> cirrus
>
> qxl
>
> virtio
>
> none
>
> bochs
>
> ramfb
>
>   
>
> 
>
> 
>
>   
>
> subsystem
>
>   
>
>   
>
> default
>
> mandatory
>
> requisite
>
> optional
>
>   
>
>   
>
> usb
>
> pci
>
> scsi
>
>   
>
>   
>
>   
>
> default
>
> vfio
>
>   
>
> 
>
> 
>
>   
>
> virtio
>
> virtio-transitional
>
> virtio-non-transitional
>
>   
>
>   
>
> random
>
> egd
>
>   
>
>

[ovirt-users] Re: Can't use ovirt web interface (500 error)

2020-11-20 Thread Lucia Jelinkova
Hi,

it seems that the config values in your database are not correct or up to
date - it might be worth trying to run the engine-setup again (it should
insert the correct values).

Lucia

On Wed, Nov 18, 2020 at 10:07 AM  wrote:

> Hi,
> After updating to the latest version of ovirt (standalone installed with
> engine-setup) I am no longer able to use the web ui. After I log in, in
> fact, I get a modal error entitled "operation canceled" and with content "a
> request to the server failed, error 500"
> Looking at the requests it actually receives an error 500 when it goes to
> make a request to "/ovirt-engine/webadmin/GenericApiGWTService" which
> replies "The call failed on the server; see server log for details"
>
> These are the last lines of the engine.log: https://pastebin.com/uFgZASuW
>
> Is anyone experiencing the same problem or know how to fix it?
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/WBNIEQ6LCFXSBRK45X3ISAUQSL7RJ3DQ/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3EGCZ2BJFSLBNUYOWD46H5AYYZGNOHRB/


[ovirt-users] Re: EPYC CPU not being detected correctly on cluster

2020-11-20 Thread Lucia Jelinkova
Hi,

oVirt CPU detection depends on libvirt (and that depends on qemu) CPU
models. Could you please run the following command to see what libvirt
reports?

virsh domcapabilities

That should give you the list of CPUs known to libvirt with a usability
flag for each CPU.

If you find out that the CPU is not usable by libvirt, you might want to
dig deeper by querying quemu directly.

Locate any VM running on the system by
sudo virsh list --all

Use the name of a VM in the following command:
sudo virsh qemu-monitor-command [your-vm's-name] --pretty
'{"execute":"query-cpu-definitions"}'

That would give you the list of all CPUs supported by qemu and it will list
all cpu's features that are not available on your system.

Regards,

Lucia

On Thu, Nov 19, 2020 at 9:38 PM Vinícius Ferrão via Users 
wrote:

> Hi
>
>
>
> I’ve an strange issue with two hosts (not using the hypervisor image) with
> EPYC CPUs, on the engine I got this message:
>
>
>
> The host CPU does not match the Cluster CPU Type and is running in a
> degraded mode. It is missing the following CPU flags: model_EPYC. Please
> update the host CPU microcode or change the Cluster CPU Type.
>
>
>
> But it is an EPYC CPU, the firmware is updated to the latest versions, but
> for some reason oVirt does not like it.
>
>
>
> Here’s the relevant output from VDSM:
>
> "cpuCores": "128",
>
> "cpuFlags":
> "ibs,vme,abm,sep,ssse3,perfctr_core,sse4_2,skip-l1dfl-vmentry,cx16,pae,misalignsse,avx2,smap,movbe,vgif,rdctl-no,extapic,clflushopt,de,sse4_1,xsaveerptr,perfctr_llc,fma,mca,sse,rdtscp,monitor,umip,mwaitx,cr8_legacy,mtrr,stibp,bmi2,pclmulqdq,amd-ssbd,lbrv,pdpe1gb,constant_tsc,vmmcall,f16c,ibrs,fsgsbase,invtsc,nopl,lm,3dnowprefetch,smca,ht,tsc_adjust,popcnt,cpb,bmi1,mmx,arat,aperfmperf,bpext,cqm_occup_llc,virt-ssbd,tce,pse,xsave,xgetbv1,topoext,sha_ni,amd_ppin,rdrand,cpuid,tsc_scale,extd_apicid,cqm,rep_good,tsc,sse4a,flushbyasid,pschange-mc-no,mds-no,ibpb,smep,clflush,tsc-deadline,fxsr,pat,avx,pfthreshold,v_vmsave_vmload,osvw,xsavec,cdp_l3,clzero,svm_lock,nonstop_tsc,adx,hw_pstate,spec-ctrl,arch-capabilities,xsaveopt,skinit,rdt_a,svm,rdpid,lahf_lm,fpu,rdseed,fxsr_opt,sse2,nrip_save,vmcb_clean,sme,cat_l3,cqm_mbm_local,irperf,overflow_recov,avic,mce,mmxext,msr,cx8,hypervisor,wdt,mba,nx,decodeassists,cmp_legacy,x2apic,perfctr_nb,succor,pni,xsaves,clwb,cqm_llc,syscall,apic,pge,npt,pse36,cmov,ssbd,pausefilter,sev,aes,wbnoinvd,cqm_mbm_total,spec_ctrl,model_qemu32,model_Opteron_G3,model_Nehalem-IBRS,model_qemu64,model_Conroe,model_kvm64,model_Penryn,model_SandyBridge,model_pentium,model_pentium2,model_kvm32,model_Nehalem,model_Opteron_G2,model_pentium3,model_Opteron_G1,model_SandyBridge-IBRS,model_486,model_Westmere-IBRS,model_Westmere",
>
> "cpuModel": "AMD EPYC 7H12 64-Core Processor",
>
> "cpuSockets": "2",
>
> "cpuSpeed": "3293.405",
>
> "cpuThreads": "256",
>
>
>
> Any ideia on why ou what to do to fix it?
>
>
>
> Thanks,
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/WP6XL6ODTLJVB46MAXKCOA34PEFN576Q/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OOLJHQDNC4KY4O4B3SJ3PORDKQU6BQM7/


[ovirt-users] Re: which cpu type should I chose ??

2020-07-22 Thread Lucia Jelinkova
Hi,

when you go to the Host details, General tab, there is a CPU Type field.
The info icon should list all CPU types supported by the host.
[image: Screenshot from 2020-07-22 14-25-36.png]
Hope that helps.

Lucia

On Tue, Jul 21, 2020 at 11:05 AM tommy  wrote:

> Hi:
>
>
>
> 1.My server using as ovirt host is built on virtualbox and the cpu info
> is:
>
>
>
> vendor_id   : GenuineIntel
>
> cpu family  : 6
>
> model   : 142
>
> model name  : Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
>
> stepping: 10
>
> cpu MHz : 1992.002
>
> cache size  : 8192 KB
>
> physical id : 0
>
> siblings: 3
>
> core id : 2
>
> cpu cores   : 3
>
> apicid  : 2
>
> initial apicid  : 2
>
> fpu : yes
>
> fpu_exception   : yes
>
> cpuid level : 22
>
> wp  : yes
>
> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm
> constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni
> pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave
> avx rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti
> tpr_shadow flexpriority fsgsbase avx2 invpcid rdseed clflushopt md_clear
> flush_l1d
>
> bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
> l1tf mds swapgs itlb_multihit srbds
>
> bogomips: 3984.00
>
> clflush size: 64
>
> cache_alignment : 64
>
> address sizes   : 39 bits physical, 48 bits virtual
>
> power management:
>
>
>
> 2.On the ovirt host page it appears that the host is unusable.The log info
> is: Host ohost3 moved to Non-Operational state as host does not meet the
> cluster's minimum CPU level. Missing CPU features : model_IvyBridge, ssbd,
> spec_ctrl
>
>
>
> 3.I think the problem is on cluster’s cpu type setting, but which one
> should I chose to fit for the host?
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/MN43IHE7V3YAAT6FWHGTWZJKQOQ4MSL4/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/AGXNYKDTD24KY63FVHCYTS464HGDT3WU/


[ovirt-users] Re: Change Hosted engine VM cluster compatibility version throws error

2020-06-23 Thread Lucia Jelinkova
Ritesh, is this error occurring on master? There was a similar issue some
time ago and was fixed. As for the blank compatibility version combo box,
are you talking about the field in edit VM or is it blank in edit cluster?

Michal, I agree, the patch is awaiting your response to clarify what the
new error message should look like :-)

On Fri, Jun 19, 2020 at 7:20 PM Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

>
>
> On 19 Jun 2020, at 16:40, Ritesh Chikatwar  wrote:
>
> 
>
>
> On Fri, Jun 19, 2020, 7:26 PM Michal Skrivanek <
> michal.skriva...@redhat.com> wrote:
>
>>
>>
>> On 19 Jun 2020, at 13:41, Ritesh Chikatwar  wrote:
>>
>>
>>
>> On Thu, Jun 18, 2020 at 11:59 PM Michal Skrivanek <
>> michal.skriva...@redhat.com> wrote:
>>
>>>
>>>
>>> On 18 Jun 2020, at 08:59, Ritesh Chikatwar  wrote:
>>>
>>> Hello Team,
>>>
>>>
>>> When i try to change Cluster compatible version HE it throws error As
>>>
>>>
>>> what exactly are you changing where?
>>>
>>
>> I am trying to change the cluster compatible version for the Hosted
>> engine in Ui. The drop down did not set any value and I am trying to set to
>> 4.4.
>>
>>
>> which drop down?
>> Why are you changing cluster compatibility level of HE?
>>
>> maybe that’s the best question for starts - what’s the current situation
>> and what are you trying to get to?:)
>>
>
> Yeah correct Michal I should have explained that in the beginning of mail
> itself. Apologize for that.
>
> I have 4.4 rhhi setup with storage as gluster. But in this setup gluster
> service is not enable by default. I can make it enable from the UI by
> editing cluster and when try the same I get the error as
>
>  Error while executing action: Update of cluster compatibility version
> failed because there are VMs/Templates [HostedEngine]
>
>
> Ah ok, that explains a lot. The message is misleading, it has nothing to
> do with cluster version.
> Can you please share your engine.log with that failure to check what
> exactly failed there?
>
> Lucia, the message is definitely confusing and your patch should be
> finalized and merged:)
>
> Thanks,
> michal
>
> with incorrect configuration. To fix the issue, please go to each of them,
> edit, change the Custom Compatibility Version of the VM/Template to the
> cluster level you want to update the cluster to and press OK. If the save
> does not pass, fix the dialog validation. After successful cluster update,
> you can revert your Custom Compatibility Version change.
>
> This is the reason I am changing vm's compatibility version.
>
>
> I also have one doubt here when vm got created , why vm's not settled the
> value for cluster compatible version.
>
>
>
>
>> Thanks,
>> michal
>>
>>
>>>
>>> Error while executing action:
>>>
>>> HostedEngine:
>>>
>>>- There was an attempt to change Hosted Engine VM values that are
>>>locked.
>>>
>>> I am trying to change the version to 4.4 it was showing blank.
>>>
>>> Any suggestions on how I can edit.
>>>
>>> The VM other than HE is able to editi.
>>>
>>>
>>>
>>> *Ritesh*
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/3EBGCBFDUBHNI6G5E3NG4DCD7RQJLUNC/
>>>
>>>
>>>
>>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5B6QEIZLR6WGZUNEQSACVOPYNLAUCIYO/


[ovirt-users] Re: Issues deploying 4.4 with HE on new EPYC hosts

2020-05-29 Thread Lucia Jelinkova
Hi,

I think I found the problem - our definition of CPU types in the database
is not correct. We do autodetection of the CPU type based on the CPU flags
but they are not in sync with what we send to the VDSM.

https://github.com/oVirt/ovirt-engine/blob/874e390a40ee2f23ea108955e2946c7c419f067e/packaging/dbscripts/upgrade/pre_upgrade/_config.sql#L1067

And yes, it happened for both your servers, Secure Intel Cascadelake Server
Family and Secure AMD EPYC.

As for the he_cluster_cpu_type option, I think those are taken from the DB
configuration as well. In your case it should be "Intel Cascadelake Server
Family".

Regards,

Lucia

On Fri, May 29, 2020 at 11:39 AM Gianluca Cecchi 
wrote:

> On Fri, May 29, 2020 at 9:34 AM Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Thu, May 28, 2020 at 11:56 PM Gianluca Cecchi <
>> gianluca.cec...@gmail.com> wrote:
>>
>>> On Thu, May 28, 2020 at 3:09 PM Gianluca Cecchi <
>>> gianluca.cec...@gmail.com> wrote:
>>>
>>> [snip]
>>>


 for the cluster type in the mean time I was able to change it to "Intel
 Cascadelake Server Family" from web admin gui and now I have to try
 these steps and see if engine starts automatically without manual 
 operations

 1) set global maintenance
 2) shutdown engine
 3) exit maintenance
 4) see if the engine vm starts without the cpu flag


>>> I confirm that point 4) was successful and engine vm was able to
>>> autostart, after changing cluster type.
>>>
>>
>> As expected,
>> in my opinion now the point is just about understanding why the engine
>> detected your host with the wrong CPU features set.
>>
>> To be fully honest, as you can see in
>> https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/README.md#L46
>> , we already have a variable (he_cluster_cpu_type) to force a cluster CPU
>> type from the ansible role but I don't think is exposed in the interactive
>> installer.
>>
>>
>
> Can I artificially set it into a playbook, just to verify correct
> completion of setup workflow or do you think that it will be any way
> overwritten at run time by what detected?
> It is not clear in my opinion what does it mean the sentence: "cluster CPU
> type to be used in hosted-engine cluster (the same as HE host or lower)"
> With "as HE host" does it mean what gotten from vdsm capabilities or what?
>
>
>> That one is just a leftover from the install process.
>> It's normally automatically cleaned up as one of the latest actions in
>> the ansible role used for the deployment.
>> I suspect that, due to the wrongly detected CPU type, in your case
>> something failed really close to the end of the deployment and so
>> the leftover: you can safely manually delete it.
>>
>>
>> Yes, the deploy failed because it was not anle to detected final engine
> as up
>
> As asked by Lucia, the Origin of the VM was "External"
> The VM had no disks and no network interfaces. I was able to remove it
> without problems at the moment.
> Thanks,
> Gianluca
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/A3BFRB3G6QUJA4TGZOUA72Y55B5ATT52/


[ovirt-users] Re: Issues deploying 4.4 with HE on new EPYC hosts

2020-05-29 Thread Lucia Jelinkova
When you look into the detail of external-HostedEngineLocal, Genral tab,
what is its Origin?

On Thu, May 28, 2020 at 11:53 PM Gianluca Cecchi 
wrote:

> On Thu, May 28, 2020 at 3:09 PM Gianluca Cecchi 
> wrote:
>
> [snip]
>
>>
>>
>> for the cluster type in the mean time I was able to change it to "Intel
>> Cascadelake Server Family" from web admin gui and now I have to try
>> these steps and see if engine starts automatically without manual operations
>>
>> 1) set global maintenance
>> 2) shutdown engine
>> 3) exit maintenance
>> 4) see if the engine vm starts without the cpu flag
>>
>>
> I confirm that point 4) was successful and engine vm was able to
> autostart, after changing cluster type.
> I'm also able to connect to its console from web admin gui
>
> The command line generated now is:
>
> qemu 29450 1 43 23:38 ?00:03:09 /usr/libexec/qemu-kvm
> -name guest=HostedEngine,debug-threads=on -S -object
> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-10-HostedEngine/master-key.aes
> -machine pc-q35-rhel8.1.0,accel=kvm,usb=off,dump-guest-core=off -cpu
> Cascadelake-Server,hle=off,rtm=off,arch-capabilities=on -m
> size=16777216k,slots=16,maxmem=67108864k -overcommit mem-lock=off -smp
> 2,maxcpus=32,sockets=16,cores=2,threads=1 -object iothread,id=iothread1
> -numa node,nodeid=0,cpus=0-31,mem=16384 -uuid
> b572d924-b278-41c7-a9da-52c4f590aac1 -smbios
> type=1,manufacturer=oVirt,product=RHEL,version=8-1.1911.0.9.el8,serial=d584e962-5461-4fa5-affa-db413e17590c,uuid=b572d924-b278-41c7-a9da-52c4f590aac1,family=oVirt
> -no-user-config -nodefaults -device sga -chardev
> socket,id=charmonitor,fd=40,server,nowait -mon
> chardev=charmonitor,id=monitor,mode=control -rtc
> base=2020-05-28T21:38:21,driftfix=slew -global
> kvm-pit.lost_tick_policy=delay -no-hpet -no-reboot -global
> ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device
> pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
> -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1
> -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2
> -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3
> -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4
> -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5
> -device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6
> -device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7
> -device
> pcie-root-port,port=0x18,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x3
> -device
> pcie-root-port,port=0x19,chassis=10,id=pci.10,bus=pcie.0,addr=0x3.0x1
> -device
> pcie-root-port,port=0x1a,chassis=11,id=pci.11,bus=pcie.0,addr=0x3.0x2
> -device
> pcie-root-port,port=0x1b,chassis=12,id=pci.12,bus=pcie.0,addr=0x3.0x3
> -device
> pcie-root-port,port=0x1c,chassis=13,id=pci.13,bus=pcie.0,addr=0x3.0x4
> -device
> pcie-root-port,port=0x1d,chassis=14,id=pci.14,bus=pcie.0,addr=0x3.0x5
> -device
> pcie-root-port,port=0x1e,chassis=15,id=pci.15,bus=pcie.0,addr=0x3.0x6
> -device
> pcie-root-port,port=0x1f,chassis=16,id=pci.16,bus=pcie.0,addr=0x3.0x7
> -device pcie-root-port,port=0x20,chassis=17,id=pci.17,bus=pcie.0,addr=0x4
> -device pcie-pci-bridge,id=pci.18,bus=pci.1,addr=0x0 -device
> qemu-xhci,p2=8,p3=8,id=ua-b630a65c-8156-4542-b8e8-98b4d2c48f67,bus=pci.4,addr=0x0
> -device
> virtio-scsi-pci,iothread=iothread1,id=ua-b7696ce2-fd8c-4856-8c38-197fc520271b,bus=pci.5,addr=0x0
> -device
> virtio-serial-pci,id=ua-608f9599-30b2-4ee6-a0d3-d5fb588583ad,max_ports=16,bus=pci.3,addr=0x0
> -drive if=none,id=drive-ua-fa671f6c-dc42-4c59-a66d-ccfa3d5d422b,readonly=on
> -device
> ide-cd,bus=ide.2,drive=drive-ua-fa671f6c-dc42-4c59-a66d-ccfa3d5d422b,id=ua-fa671f6c-dc42-4c59-a66d-ccfa3d5d422b,werror=report,rerror=report
> -drive
> file=/var/run/vdsm/storage/3df8f6d4-d572-4d2b-9ab2-8abc456a396f/df02bff9-2c4b-4e14-a0a3-591a84ccaed9/bf435645-2999-4fb2-8d0e-5becab5cf389,format=raw,if=none,id=drive-ua-df02bff9-2c4b-4e14-a0a3-591a84ccaed9,cache=none,aio=threads
> -device
> virtio-blk-pci,iothread=iothread1,scsi=off,bus=pci.6,addr=0x0,drive=drive-ua-df02bff9-2c4b-4e14-a0a3-591a84ccaed9,id=ua-df02bff9-2c4b-4e14-a0a3-591a84ccaed9,bootindex=1,write-cache=on,serial=df02bff9-2c4b-4e14-a0a3-591a84ccaed9,werror=stop,rerror=stop
> -netdev
> tap,fds=43:44,id=hostua-b29ca99f-a53e-4de7-8655-b65ef4ba5dc4,vhost=on,vhostfds=45:46
> -device
> virtio-net-pci,mq=on,vectors=6,host_mtu=1500,netdev=hostua-b29ca99f-a53e-4de7-8655-b65ef4ba5dc4,id=ua-b29ca99f-a53e-4de7-8655-b65ef4ba5dc4,mac=00:16:3e:0a:96:80,bus=pci.2,addr=0x0
> -chardev socket,id=charserial0,fd=47,server,nowait -device
> isa-serial,chardev=charserial0,id=serial0 -chardev
> socket,id=charchannel0,fd=48,server,nowait -device
> virtserialport,bus=ua-608f9599-30b2-4ee6-a0d3-d5fb588583ad.0,nr=1,chardev=charchannel0,id=channel0,name=ovirt-guest-agent.0
> -chardev 

[ovirt-users] Re: Issues deploying 4.4 with HE on new EPYC hosts

2020-05-28 Thread Lucia Jelinkova
It is really strange, the host should not even be in UP state if it does
not comply with the cluster cpu type settings.

Would you mind sharing the engine.log?

And if that's not much of a trouble, could you have a look into the
database?

select cpu_flags from vds_dynamic;
select name, cpu_name, cpu_flags, cpu_verb from cluster;

Thanks,

Lucia

On Thu, May 28, 2020 at 12:10 PM Gianluca Cecchi 
wrote:

>
> Il Gio 28 Mag 2020, 11:59 Lucia Jelinkova  ha
> scritto:
>
>
>> The cluster should be set to Intel Cascadelake Server Family. I am not
>> familiar with the HE setup process - have you specified the cluster CPU
>> type manually or is it auto-assigned?
>>
>> Lucia
>>
>
>
> Autoassigned. In fact in another thread I asked if possible to get option
> to choose during hosted engine wizard...
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GFDPRZ5NHFS2PNFABVVQ5XDUUZRREXAU/


[ovirt-users] Re: Issues deploying 4.4 with HE on new EPYC hosts

2020-05-28 Thread Lucia Jelinkova
I think you have the same problem as Mark - the cluster is set to use the
secure variant of the CPU type but your host does not support all the
necessary flags.

Intel Cascadelake Server Family - the VM is run with
Cascadelake-Server,-hle,-rtm,+arch-capabilities
Secure Intel Cascadelake Server Family - the VM is run with
Cascadelake-Server,+md-clear,+mds-no,-hle,-rtm,+tsx-ctrl,+arch-capabilities

The cluster should be set to Intel Cascadelake Server Family. I am not
familiar with the HE setup process - have you specified the cluster CPU
type manually or is it auto-assigned?

Lucia

On Thu, May 28, 2020 at 11:32 AM Gianluca Cecchi 
wrote:

> On Thu, May 28, 2020 at 11:00 AM Gianluca Cecchi <
> gianluca.cec...@gmail.com> wrote:
>
>>
>>
>> any input to solve and at least try some features of 4.4 on this hw env?
>>
>> Thanks,
>> Gianluca
>>
>>
> it seems I was able to have it recognized this way:
>
> strip these lines from he.xml
>
> > 1
> > unsupported configuration: unknown CPU
> feature: tsx-ctrl
> > 1
> 13a17
> >  type="float">1590653346.0201075
> 246a251,264
> >  passwdValidTo='1970-01-01T00:00:01'>
> >   
> > 
> >  passwdValidTo='1970-01-01T00:00:01'>
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> > 
>
> I have to understand what to use for graphics but it is not important at
> the moment
> After failure of deployment the link to the engine storage domain under
> /var/run/vdsm/storage/3df8f6d4-d572-4d2b-9ab2-8abc456a396f/ has been
> deleted.
> So I go there and create it:
>
> [root@novirt2 ~]# cd
> /var/run/vdsm/storage/3df8f6d4-d572-4d2b-9ab2-8abc456a396f/
>
> [root@novirt2 ~]# ln -s
> /rhev/data-center/mnt/glusterSD/novirt2st.storage.local\:_engine/3df8f6d4-d572-4d2b-9ab2-8abc456a396f/images/df02bff9-2c4b-4e14-a0a3-591a84ccaed9
> df02bff9-2c4b-4e14-a0a3-591a84ccaed9
>
> Start VM
> [root@novirt2 ~]# virsh -c
> qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf create
> he.xml
> Domain HostedEngine created from he.xml
>
> Access its webadmin gui and now all is as expected, with only one engine
> vm...
> Volumes for data and vmstore are there, but not the storage domains, but I
> can create them without problems
>
> Also if I exit the global maintenance the state passes from
> ReinitializeFSM to EngineUp
>
> [root@novirt2 ~]# hosted-engine --vm-status
>
>
> --== Host novirt2.example.net (id: 1) status ==--
>
> Host ID: 1
> Host timestamp : 38553
> Score  : 3400
> Engine status  : {"vm": "up", "health": "good",
> "detail": "Up"}
> Hostname   : novirt2.example.net
> Local maintenance  : False
> stopped: False
> crc32  : 5a3b40e1
> conf_on_shared_storage : True
> local_conf_timestamp   : 38553
> Status up-to-date  : True
> Extra metadata (valid at timestamp):
> metadata_parse_version=1
> metadata_feature_version=1
> timestamp=38553 (Thu May 28 11:30:51 2020)
> host-id=1
> score=3400
> vm_conf_refresh_time=38553 (Thu May 28 11:30:51 2020)
> conf_on_shared_storage=True
> maintenance=False
> state=EngineUp
> stopped=False
> [root@novirt2 ~]#
>
> Now go to test further functionalities.
>
>
> Gianluca
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5OC6B4AF52T4T4NRWEPPNFO6MJKOE2L4/


[ovirt-users] Re: Issues deploying 4.4 with HE on new EPYC hosts

2020-05-28 Thread Lucia Jelinkova
This might help:
https://lists.ovirt.org/pipermail/users/2017-January/079157.html

On Thu, May 28, 2020 at 10:17 AM Gianluca Cecchi 
wrote:

>
>
> On Wed, May 27, 2020 at 4:13 PM Mark R  wrote:
>
>> Replying to my own post here, I've verified that it's currently not
>> possible to do a greenfield deploy of oVirt 4.4.0 w/ hosted engine on EPYC
>> CPUs due to the system setting a requirement of 'virt-ssbd' for the final
>> HE definition after the move to shared storage. The local HE runs perfectly
>> through the setup process because it correctly uses 'amd-ssbd' but
>> unfortunately that doesn't stick after the disks are moved.
>>
>> You can work around it via 'virsh -r dumpxml HostedEngine > /tmp/he.xml',
>> then editing that file to simply change 'virt-ssbd' to 'amd-ssbd'. Start it
>> via 'virsh create /tmp/he.xml' and now it runs fine. You can get into the
>> admin interface and if you want to run something hacky could at this point
>> change the cluster CPU type from 'Secure AMD EPYC' to just 'AMD EPYC', take
>> everything down and bring it back up cleanly... hosted engine will now work
>> because the requirement for virt-ssbd (not available on EPYC when using
>> CentOS 8.1 or presumably RHEL 8, amd-ssbd is needed) is gone.
>>
>>
> I would like to test it during final stage of deployment, but the "virsh
> create" command requires a password.
>
> [root@novirt2 log]# virsh create /tmp/he.xml
> Please enter your authentication name:
>
> I don't remember how to setup a user so that I can run it on oVirt host..
> any input?
>
> Just for my testing lab in 4.4. obviously...
> Thans,
> Gianluca
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/BOOXPB5BR73D6MY2C6VFFY2TJUK2VVFL/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/6GCGLS7HH6F5UVDD4BXFS4PZPJQBVV3S/


[ovirt-users] Re: Issues deploying 4.4 with HE on new EPYC hosts

2020-05-28 Thread Lucia Jelinkova
Hi,

The cluster CPU type should be set to AMD EPYC, because your system does
not support Secure AMD EPYC type (it requires the virt-ssbd). Did you by
any chance specify the Secure variant during HE setup?

Lucia

On Wed, May 27, 2020 at 4:13 PM Mark R  wrote:

> Replying to my own post here, I've verified that it's currently not
> possible to do a greenfield deploy of oVirt 4.4.0 w/ hosted engine on EPYC
> CPUs due to the system setting a requirement of 'virt-ssbd' for the final
> HE definition after the move to shared storage. The local HE runs perfectly
> through the setup process because it correctly uses 'amd-ssbd' but
> unfortunately that doesn't stick after the disks are moved.
>
> You can work around it via 'virsh -r dumpxml HostedEngine > /tmp/he.xml',
> then editing that file to simply change 'virt-ssbd' to 'amd-ssbd'. Start it
> via 'virsh create /tmp/he.xml' and now it runs fine. You can get into the
> admin interface and if you want to run something hacky could at this point
> change the cluster CPU type from 'Secure AMD EPYC' to just 'AMD EPYC', take
> everything down and bring it back up cleanly... hosted engine will now work
> because the requirement for virt-ssbd (not available on EPYC when using
> CentOS 8.1 or presumably RHEL 8, amd-ssbd is needed) is gone.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/VFZT6QCQLEDHCRL75LL4TJWOLV7F43GG/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PBQBNKL42UG7JIY43HNWHK3VSDAT32UL/


[ovirt-users] Re: oVirt 4.4 pending VM changes on HostedEngine VM

2020-05-28 Thread Lucia Jelinkova
Hi,

it is a bug and it is discussed here:
https://bugzilla.redhat.com/show_bug.cgi?id=1830872

Note that it is a UI issue and it does not affect the system.
Unfortunately, there is no workaround I know of.

Lucia

On Wed, May 27, 2020 at 2:45 PM Radoslav Milanov 
wrote:

> Hello
>
> I'm not sure how but I've got pending changes on the HostedEngine VM on
> a 3 node 4.4 cluster and those changes are never applied. Is there a way
> to cancel pending VM changes in general ?
>
> Thanks.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/CRD2NENSLVGYENCKZFFAY2E3CDKG7B2L/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/P4FWEAYWJSXANATIKEOZQP5Q3TKJHQX6/


[ovirt-users] Re: NUMA Pinning bug with Hugepages?

2020-04-15 Thread Lucia Jelinkova
Hi,

I think you've hit similar issue as reported here:

https://bugzilla.redhat.com/show_bug.cgi?id=1812316

You're right, the hugepages are considered as allocated memory and it is a
bug. I am working on a fix right now.

Regards,

Lucia

On Wed, Apr 15, 2020 at 1:21 PM Alan G  wrote:

> Hi,
>
> I seem to have found an issue when trying to setup a high performance VM
> utilising hugepages and NUMA pinning.
>
> The VM is configured for 32GB RAM and uses hugepages of size 1G.
>
> The host has two NUMA nodes each having 64GB RAM (for 128GB total system
> RAM).
>
> No other VMs are running or otherwise pinned to the host.
>
> The VM is pinned to node 0. And the required hugepages are allocated with
>
> echo 32 >
> /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages
>
> I then attempt to start the VM and get a pop-up error saying "cannot
> accommodate memory of VM's pinned virtual NUMA nodes within host's physical
> NUMA nodes".
>
> However, if I remove the hugepages from node 0
>
> echo 0 >
> /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages
>
> Start the VM and then immediately re-create the hugepqages then everything
> works as expected.
>
> It seems to me that oVirt is considering the hugepages as allocated memory
> even if they are not in use.
>
> Is this correct?
>
> Thanks,
>
> Alan
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/32QKZ2EQ5OKTMPJD4M6W7QK2FKFDFK2E/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LYFCAAVSZMGHY2LKR54EH2NTNIMOP3F5/


[ovirt-users] Re: UI lockup

2020-04-08 Thread Lucia Jelinkova
Hi,

NS_ERROR_STORAGE_BUSY is an error coming from Mozilla [1] so it is possible
it is a problem with your Firefox. You could try steps suggested in [2] to
check your local storage integrity (in short: navigate to about:support and
click Verify integrity button).

[1] https://james-ross.co.uk/mozilla/misc/nserror?0x80630001
[2] https://support.mozilla.org/si/questions/1267362

Regards,

Lucia

On Tue, Apr 7, 2020 at 6:00 PM Shareef Jalloq  wrote:

> Hi,
>
> when browsing to the admin portal of the Engine, I get a popup:
>
> Uncaught exception occurred.  Please try reloading the page.  Details:
> (NS_ERROR_STORAGE_BUSY).
>
> And the ui.log has the error at the end of the mail.
>
> What gives?
>
> Shareef.
>
>
> 2020-04-07 15:54:12,255Z ERROR
> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
> (default task-66) [] Permutation name: 1AD871380C0F85A90CBF764A6CF6663F
> 2020-04-07 15:54:12,255Z ERROR
> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
> (default task-66) [] Uncaught exception:
> com.google.gwt.core.client.JavaScriptException: (NS_ERROR_STORAGE_BUSY) :
> at Unknown.loadFromLocalStorage(
> https://ovirt-engine.phoelex.com/ovirt-engine/webadmin/theme/00-ovirt.brand/patternfly-functions-vertical-nav-custom-3.26.1.js
> )
> at Unknown.init(
> https://ovirt-engine.phoelex.com/ovirt-engine/webadmin/theme/00-ovirt.brand/patternfly-functions-vertical-nav-custom-3.26.1.js
> )
> at Unknown.fn.setupVerticalNavigation(
> https://ovirt-engine.phoelex.com/ovirt-engine/webadmin/theme/00-ovirt.brand/patternfly-functions-vertical-nav-custom-3.26.1.js
> )
> at
> org.ovirt.engine.ui.webadmin.section.main.view.MainSectionView$lambda$0$Type.execute(MainSectionView.java:48)
> at
> com.google.gwt.core.client.impl.SchedulerImpl.runScheduledTasks(SchedulerImpl.java:167)
> [gwt-servlet.jar:]
> at
> com.google.gwt.core.client.impl.SchedulerImpl.$flushPostEventPumpCommands(SchedulerImpl.java:338)
> [gwt-servlet.jar:]
> at
> com.google.gwt.core.client.impl.SchedulerImpl$Flusher.execute(SchedulerImpl.java:76)
> [gwt-servlet.jar:]
> at
> com.google.gwt.core.client.impl.SchedulerImpl.execute(SchedulerImpl.java:140)
> [gwt-servlet.jar:]
> at com.google.gwt.core.client.impl.Impl.apply(Impl.java:236)
> [gwt-servlet.jar:]
> at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:275)
> [gwt-servlet.jar:]
> at Unknown.Tu/<(
> https://ovirt-engine.phoelex.com/ovirt-engine/webadmin/?locale=en_US line
> 9 > scriptElement)
> at Unknown.d(
> https://ovirt-engine.phoelex.com/ovirt-engine/webadmin/?locale=en_US line
> 9 > scriptElement)
> at Unknown.anonymous(Unknown)
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/G2ABEINWHDTE2ANSYESEM4MJYPHDKAK2/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZE3EGES562XNAWMC6ZLKKUMUXQJVARKZ/