Dear Ryan Bullock,
Thank you for help with this issue. I will correlate accordingly.
With Best Regards.
Steven Rosenberg.
On Mon, Feb 18, 2019 at 5:46 AM Ryan Bullock wrote:
> Hey Steven,
>
> Including just the cpuFlags, since the output is pretty verbose. Let me
> know if you need anything e
Hey Steven,
Including just the cpuFlags, since the output is pretty verbose. Let me
know if you need anything else from the output.
Without avic=1 (Works Fine):
"cpuFlags":
"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,mmxext,
Dear Ryan Bullock,
I am currently looking at this issue:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/4Y4X7UGDEYSB5JK45TLDERNM7IMTHIYY/
We would like more information concerning the CPU Flags (even though you
included them in your engine log dump above).
Could you run the follo
So this looks like it is a bug in qemu/libvirtd
We had avic=1 set for kvm_amd, but when this is set the qemu capabilities
cache showed all EPYC/AMD Variants as unusable and blocking due to missing
'x2apic'. My guess is that it should probably be looking for the avic flag
instead. My other guess is
Thanks, Ryan.
I opened https://bugzilla.redhat.com/show_bug.cgi?id=1674265 to track this.
Greg
On Sat, Feb 9, 2019 at 5:50 PM Ryan Bullock wrote:
> Got a host activated!
>
> 1. Update host to 4.3
> 2. rm /var/cache/libvirt/qemu/capabilities/*.xml
> 3. systemctl restart libvirtd
> 4. Activate ho
Got a host activated!
1. Update host to 4.3
2. rm /var/cache/libvirt/qemu/capabilities/*.xml
3. systemctl restart libvirtd
4. Activate host
Seems like some kind of stuck state going from 4.2 -> 4.3
Hope this helps someone else.
On Sat, Feb 9, 2019 at 1:12 PM Ryan Bullock wrote:
> I tried that
I tried that too, but it still complains about an unsupported CPU in the
new cluster. Even if I leave the cluster level at 4.2, if I update the host
to 4.3 it can't activate under a 4.2 cluster.
Makes me think something changed in how it verifies the CPU support and for
some reason it is not liking
On Sat, Feb 9, 2019 at 7:43 PM Ryan Bullock wrote:
>
> So I tried making a new cluster with a 4.2 compatibility level and moving one
> of my EPYC hosts into it. I then updated the host to 4.3 and switched the
> cluster version 4.3 + set cluster cpu to the new AMD EPYC IBPD SSBD (also
> tried pl
So I tried making a new cluster with a 4.2 compatibility level and moving
one of my EPYC hosts into it. I then updated the host to 4.3 and switched
the cluster version 4.3 + set cluster cpu to the new AMD EPYC IBPD SSBD
(also tried plain AMD EPYC). It still fails to make the host operational
compla
This procedure worked for our HE, which is on Skylake.
I think I have a process that should work for moving our EPYC clusters to
4.3. If it works this weekend I will post it for others.
Ryan
On Thu, Feb 7, 2019 at 12:06 PM Simone Tiraboschi
wrote:
>
>
> On Thu, Feb 7, 2019 at 7:15 PM Juhani Ra
On Thu, Feb 7, 2019 at 7:15 PM Juhani Rautiainen <
juhani.rautiai...@gmail.com> wrote:
>
>
> On Thu, Feb 7, 2019 at 6:52 PM Simone Tiraboschi
> wrote:
>
>>
>>
>> For an hosted-engine cluster we have a manual workaround procedure
>> documented here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1
On Thu, Feb 7, 2019 at 6:52 PM Simone Tiraboschi
wrote:
>
>
> For an hosted-engine cluster we have a manual workaround procedure
> documented here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1672859#c1
>
>
I managed to upgrade my Epyc cluster with those steps. I made new cluster
with Epyc CPU
On Thu, Feb 7, 2019 at 5:46 PM Greg Sheremeta wrote:
>
> On Thu, Feb 7, 2019 at 11:31 AM Ryan Bullock wrote:
>
>> That would explain it.
>>
>> Would removing the host and then reinstalling it under a new 4.3 cluster
>> work without having to set the entire old cluster into maintenance to
>> chan
On Thu, Feb 7, 2019 at 11:31 AM Ryan Bullock wrote:
> That would explain it.
>
> Would removing the host and then reinstalling it under a new 4.3 cluster
> work without having to set the entire old cluster into maintenance to
> change the cpu? Then I could just restart VM's into the new cluster a
That would explain it.
Would removing the host and then reinstalling it under a new 4.3 cluster
work without having to set the entire old cluster into maintenance to
change the cpu? Then I could just restart VM's into the new cluster as we
transition to minimize downtime.
Thanks for the info!
Ry
AMD EPYC IBPB is deprecated in 4.3.
The deprecated CPUs (cpus variable, that entire list) are:
https://gerrit.ovirt.org/#/c/95310/7/frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/widget/table/column/ClusterAdditionalStatusColumn.java
So, *-IBRS [IBRS-SSBD is still ok
16 matches
Mail list logo
