I believe your problem is similar to Mark’s, you need qemu-kvm’s virtualized
tsx-ctrl that was added to qemu 4.2 upstream and (I think) also the
corresponding kernel-4.18.0-147.4.1.el8_1
can you confirm your versions?
all of these issues should be addressed in 8.2, we’re just still waiting for
> On 28 May 2020, at 16:26, Mark R wrote:
>
> I should have also mentioned that I found an existing report for the issue
> I'm having on RedHat's Bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=1783180
And that is the one behind the problem
In el8 this has been fixed by
Thank you Lucia, that's good news to hear. Is this something that might be
fixed up in the 4.4.1 release whenever it comes along, and/or something simple
to patch to get a clean deploy using 4.4.0? I have the servers and time to
experiment with for now. If I can somehow edit that
'4:Secure
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 <
>>>
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.
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
On Thu, May 28, 2020 at 11:56 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
Based on my vague memories from Dec 2018, I think I got a similar situation
where I had to delete that external Engine.
Of course that was on 4.2.7 and the story here can be different. If you use
gluster, you can power off the engine (Global Maintenance) and then create a
gluster snapshot
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
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)
I should have also mentioned that I found an existing report for the issue I'm
having on RedHat's Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1783180
Mark
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to
Oof, I butchered his last name, but the quote I found was this:
"Details: Tom Lendacky from AMD writes[4] -- "The idea behind
'virt-ssbd' was to provide an architectural method for a guest to do
SSBD when 'amd-ssbd' isn't present. The 'amd-ssbd' feature will use
SPEC_CTRL which
Hi Lucia,
>>> the cluster is set to use the
secure variant of the CPU type but your host does not support all the
necessary flags.
For my deployments the system is auto-detecting and using the 'Secure AMD EPYC'
CPU type. Note that the HostedEngineLocal VM does run with 'amd-ssbd' and
works
On Thu, May 28, 2020 at 3:01 PM Lucia Jelinkova wrote:
> 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
>
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,
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
On Thu, May 28, 2020 at 12:02 PM Lucia Jelinkova
wrote:
> 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
>
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
On Thu, May 28, 2020 at 11:00 AM Gianluca Cecchi
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
On Thu, May 28, 2020 at 10:22 AM Lucia Jelinkova
wrote:
> This might help:
> https://lists.ovirt.org/pipermail/users/2017-January/079157.html
>
> On Thu, May 28, 2020 at 10:17 AM Gianluca Cecchi <
> gianluca.cec...@gmail.com> wrote:
>
>>
>>
>> On Wed, May 27, 2020 at 4:13 PM Mark R
>> wrote:
>>
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
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
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
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
Thank you for the suggestion, Ryan it looks like AVIC is disabled by
default though (/sys/module/kvm_amd/parameters/avic is 0).
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement:
Does 8.1 enable AVIC by default?
May be related to this:
https://bugzilla.redhat.com/show_bug.cgi?id=1694170
Can try disabling avic in the kvm module on the hosts and see if that
allows them to activate.
Regards,
Ryan
On Tue, May 26, 2020 at 9:11 AM Mark R wrote:
> Hello all,
>
> I have
26 matches
Mail list logo
