[ovirt-users] Re: OPNsense / FreeBSD 12.1

[Alex K]

On Fri, Dec 11, 2020, 20:39 Jorge Visentini 
wrote:

> Hi all.
>
> I tried to install OPNsense 20.7.6 (FreeBSD 12.1) and it was not possible
> to detect the NICs.
>
> I tried both the virtio driver and the e1000. Virtio does not detect and
> e1000 crashes at startup.
> In pure KVM, it works, so I believe there is some incompatibility with
> oVirt 4.4.4.
>
> Any tips?
>
Please check/share the error message you observe at vdsm logs when starting
the VM.

>
> --
> Att,
> Jorge Visentini
> +55 55 98432-9868
> ___
> 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/7EX6TQPUSZ5M6VUJO23W7FTE2XO23Y66/
>
___
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/J5FX4SOV5I5CDYWTR4VOGUK5HT4KIZFB/

[ovirt-users] OPNsense / FreeBSD 12.1

[Jorge Visentini]

Hi all.

I tried to install OPNsense 20.7.6 (FreeBSD 12.1) and it was not possible
to detect the NICs.

I tried both the virtio driver and the e1000. Virtio does not detect and
e1000 crashes at startup.
In pure KVM, it works, so I believe there is some incompatibility with
oVirt 4.4.4.

Any tips?

-- 
Att,
Jorge Visentini
+55 55 98432-9868
___
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/7EX6TQPUSZ5M6VUJO23W7FTE2XO23Y66/

[ovirt-users] Re: High performance VM cannot migrate due to TSC frequency

[Gianluca Cecchi]

On Fri, Dec 11, 2020 at 5:39 PM Milan Zamazal  wrote:

>
>
> TSC frequency is the frequency with which Time Stamp Counter register is
> updated, typically a nominal CPU frequency (see
> https://en.wikipedia.org/wiki/Time_Stamp_Counter for more details).
>
> You can check the value oVirt gets from libvirt by running
>
>   # virsh -r capabilities
>
> and looking at the line like
>
>   
>
> in the output.  Unless frequency scaling is available, the host
> frequencies must be almost the same in order to be able to migrate high
> performance VMs among them.
>
> Note there is a bug that may cause a migration failure for the VMs even
> between hosts with the same frequencies
> (https://bugzilla.redhat.com/1821199).  But this is apparently not your
> case, since the migration is prevented already by Engine.
>
> Regards,
> Milan
>
>
>
See here:

[root@ov200 ~]# virsh -r capabilities | grep "name='tsc'"
  
[root@ov200 ~]#

[root@ov300 ~]# virsh -r capabilities | grep "name='tsc'"
  
[root@ov300 ~]#

[root@ov301 ~]# virsh -r capabilities | grep "name='tsc'"
  
[root@ov301 ~]#

The three hosts have the same model cpu
Model name:  Intel(R) Xeon(R) CPU   X5690  @ 3.47GHz
and slightly different actual frequencies at a certain moment...

But what does it mean so the checkbox

Migrate only to hosts with the same TSC frequency

if even if I don't check it the migration is prevented?

BTW the command lscpu produces exactly the same output on the three hosts,
apart "CPU MHz" and corresponding "BogoMIPS" that slightly change each time
I run the command.

And the flags for all are:

Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl
vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes
lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid
dtherm ida arat flush_l1d

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/2ZCLAOXITG4UT55B5YMOH2G5WVUM4ZBB/

[ovirt-users] Re: High performance VM cannot migrate due to TSC frequency

[Milan Zamazal]

Gianluca Cecchi  writes:

> Hello,
> I'm in 4.4.3 and CentOS 8.3 with 3 hosts.
>
> I have a high performance VM that is running on ov300 and is configured to
> be run on any host.
>
> It seems that both if I set or not the option
>
> Migrate only to hosts with the same TSC frequency
>
> I always am unable to migrate the VM and inside engine.log I see this:
>
> 2020-12-11 15:56:03,424+01 INFO
>  [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (default task-36)
> [e4801b28-c832-4474-aa53-4ebfd7c6e2d0] Candidate host 'ov301'
> ('382bfc8f-60d5-4e06-8571-7dae1700574d') was filtered out by
> 'VAR__FILTERTYPE__INTERNAL' filter 'Migration-Tsc-Frequency' (correlation
> id: null)
>
> 2020-12-11 15:56:03,424+01 INFO
>  [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (default task-36)
> [e4801b28-c832-4474-aa53-4ebfd7c6e2d0] Candidate host 'ov200'
> ('949d0087-2c24-4759-8427-f9eade1dd2cc') was filtered out by
> 'VAR__FILTERTYPE__INTERNAL' filter 'Migration-Tsc-Frequency' (correlation
> id: null)
>
> Can you verify if it is only my problem?
>
> Apart from the problem itself, what is "TSC frequency" and how can I check
> if my 3 hosts are different or not indeed?

TSC frequency is the frequency with which Time Stamp Counter register is
updated, typically a nominal CPU frequency (see
https://en.wikipedia.org/wiki/Time_Stamp_Counter for more details).

You can check the value oVirt gets from libvirt by running

  # virsh -r capabilities

and looking at the line like

  

in the output.  Unless frequency scaling is available, the host
frequencies must be almost the same in order to be able to migrate high
performance VMs among them.

Note there is a bug that may cause a migration failure for the VMs even
between hosts with the same frequencies
(https://bugzilla.redhat.com/1821199).  But this is apparently not your
case, since the migration is prevented already by Engine.

Regards,
Milan

> Normal VMs are able to migrate without problems
>
> 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/2HYSCVHSVZS6KX5FF5MOXI6YTLQOJIK7/
___
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/SXQRJZAYTBFBHZJQVMRUL625NE3NPCZ6/

[ovirt-users] Re: Recent news & oVirt future

[Sandro Bonazzola]

Il giorno ven 11 dic 2020 alle ore 16:22 Charles Kozler <
char...@fixflyer.com> ha scritto:

> What goes in to oVirt goes in to RHV if I understand correctly, right? If
> so sorry, I meant upstream
>
> If I am understanding how all of this is changing correctly then this move
> to stream will only serve to benefit oVirt as it speeds up the pace of
> CentOS in the ecosystem and therefore potentially won't have breaking
> changes dependent and waiting on RHEL to release so CentOS can be built
>
> If I remember correctly (and I could be confusing this with another
> application), oVirt requires CentOS 7.3 or higher right?
>

oVirt 4.4.3 Requires CentOS 8.2 or higher but without 8.3 and Advanced
Virtualization 8.3 you're going to have cluster level 4.5 not available.




>
>
>
>
> On Fri, Dec 11, 2020 at 10:08 AM Sandro Bonazzola 
> wrote:
>
>>
>>
>> Il giorno ven 11 dic 2020 alle ore 15:49 Charles Kozler <
>> char...@fixflyer.com> ha scritto:
>>
>>> CentOS was the downstream of RHEL but has now become the upstream
>>>
>>> I guess oVirt was always downstream as well - yes?
>>>
>>
>> No. oVirt is oVirt. It's  downstream to nothing.
>> And it used to work and being used on Fedora which is upstream to RHEL
>> and to CentOS Stream.
>> Fedora moved just way too fast and we had to drop the effort trying to
>> keep the pace: https://blogs.ovirt.org/2020/05/ovirt-and-fedora/
>> With CentOS Stream we are just moving the point when CentOS breaks oVirt.
>> Instead to wait a couple of months after RHEL release (CentOS 8.3 just
>> broke oVirt: we can't build oVirt Node and oVirt appliance anymore due to a
>> bug in lorax package, it's preventing oVirt 4.4.4 to be released because
>> advanced virtualization build is missing a dependency which is in RHEL but
>> not in CentOS due to a bug in CentOS compose system) we'll have the fix in
>> oVirt a month before RHEL will be released.
>>
>>
>>
>>>
>>> If so then yes, I can't see much changing in the ways of oVirt
>>>
>>
>> As far as I can tell by looking at CentOS 8.3, it will change in
>> something better.
>>
>>
>>
>>>
>>>
>>>
>>>
>>> On Fri, Dec 11, 2020 at 2:59 AM Sandro Bonazzola 
>>> wrote:
>>>


 Il giorno gio 10 dic 2020 alle ore 21:51 Charles Kozler <
 char...@fixflyer.com> ha scritto:

> I guess this is probably a question for all current open source
> projects that red hat runs but -
>
> Does this mean oVirt will effectively become a rolling release type
> situation as well?
>

 There's no plan to make oVirt a rolling release.


>
> How exactly is oVirt going to stay open source and stay in cadence
> with all the other updates happening around it on packages/etc that it
> depends on if the streams are rolling release? Do they now need to fork
> every piece of dependency?
>

 We are going to test regularly oVirt on CentOS Stream, releasing oVirt
 Node and oVirt appliance after testing them, without any difference to what
 we are doing right now with CentOS Linux.
 Any raised issue will be handled as usual.

 What exactly does this mean for oVirt going forward and its overall
> stability?
>

 oVirt plans about CentOS Stream have been communicated one year ago
 here: https://blogs.ovirt.org/2019/09/ovirt-and-centos-stream/

 That said, please note that oVirt documentation mentions "Enterprise
 Linux" almost everywhere and not explicitly CentOS Linux.
 As far as I can tell any RHEL binary compatible rebuild should just
 work with oVirt despite I would recommend to follow what will be done
 within oVirt Node and oVirt Appliance.



>
> *Notice to Recipient*: https://www.fixflyer.com/disclaimer
> ___
> 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/7IUWGES2IG4BELLUPMYGEKN3GC6XVCHA/
>


 --

 Sandro Bonazzola

 MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

 Red Hat EMEA 

 sbona...@redhat.com
 

 *Red Hat respects your work life balance. Therefore there is no need to
 answer this email out of your office hours.*



>>> *Notice to Recipient*: https://www.fixflyer.com/disclaimer
>>
>>
>>
>> --
>>
>> Sandro Bonazzola
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>
>> Red Hat EMEA 
>>
>> sbona...@redhat.com
>> 
>>
>> *Red Hat respects your work life balance. Therefore there is no need to
>> answer this email out of your office hours.
>> *
>>

[ovirt-users] Re: Recent news & oVirt future

[Charles Kozler]

What goes in to oVirt goes in to RHV if I understand correctly, right? If
so sorry, I meant upstream

If I am understanding how all of this is changing correctly then this move
to stream will only serve to benefit oVirt as it speeds up the pace of
CentOS in the ecosystem and therefore potentially won't have breaking
changes dependent and waiting on RHEL to release so CentOS can be built

If I remember correctly (and I could be confusing this with another
application), oVirt requires CentOS 7.3 or higher right?




On Fri, Dec 11, 2020 at 10:08 AM Sandro Bonazzola 
wrote:

>
>
> Il giorno ven 11 dic 2020 alle ore 15:49 Charles Kozler <
> char...@fixflyer.com> ha scritto:
>
>> CentOS was the downstream of RHEL but has now become the upstream
>>
>> I guess oVirt was always downstream as well - yes?
>>
>
> No. oVirt is oVirt. It's  downstream to nothing.
> And it used to work and being used on Fedora which is upstream to RHEL and
> to CentOS Stream.
> Fedora moved just way too fast and we had to drop the effort trying to
> keep the pace: https://blogs.ovirt.org/2020/05/ovirt-and-fedora/
> With CentOS Stream we are just moving the point when CentOS breaks oVirt.
> Instead to wait a couple of months after RHEL release (CentOS 8.3 just
> broke oVirt: we can't build oVirt Node and oVirt appliance anymore due to a
> bug in lorax package, it's preventing oVirt 4.4.4 to be released because
> advanced virtualization build is missing a dependency which is in RHEL but
> not in CentOS due to a bug in CentOS compose system) we'll have the fix in
> oVirt a month before RHEL will be released.
>
>
>
>>
>> If so then yes, I can't see much changing in the ways of oVirt
>>
>
> As far as I can tell by looking at CentOS 8.3, it will change in something
> better.
>
>
>
>>
>>
>>
>>
>> On Fri, Dec 11, 2020 at 2:59 AM Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> Il giorno gio 10 dic 2020 alle ore 21:51 Charles Kozler <
>>> char...@fixflyer.com> ha scritto:
>>>
 I guess this is probably a question for all current open source
 projects that red hat runs but -

 Does this mean oVirt will effectively become a rolling release type
 situation as well?

>>>
>>> There's no plan to make oVirt a rolling release.
>>>
>>>

 How exactly is oVirt going to stay open source and stay in cadence with
 all the other updates happening around it on packages/etc that it depends
 on if the streams are rolling release? Do they now need to fork every piece
 of dependency?

>>>
>>> We are going to test regularly oVirt on CentOS Stream, releasing oVirt
>>> Node and oVirt appliance after testing them, without any difference to what
>>> we are doing right now with CentOS Linux.
>>> Any raised issue will be handled as usual.
>>>
>>> What exactly does this mean for oVirt going forward and its overall
 stability?

>>>
>>> oVirt plans about CentOS Stream have been communicated one year ago
>>> here: https://blogs.ovirt.org/2019/09/ovirt-and-centos-stream/
>>>
>>> That said, please note that oVirt documentation mentions "Enterprise
>>> Linux" almost everywhere and not explicitly CentOS Linux.
>>> As far as I can tell any RHEL binary compatible rebuild should just work
>>> with oVirt despite I would recommend to follow what will be done within
>>> oVirt Node and oVirt Appliance.
>>>
>>>
>>>

 *Notice to Recipient*: https://www.fixflyer.com/disclaimer
 ___
 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/7IUWGES2IG4BELLUPMYGEKN3GC6XVCHA/

>>>
>>>
>>> --
>>>
>>> Sandro Bonazzola
>>>
>>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>>
>>> Red Hat EMEA 
>>>
>>> sbona...@redhat.com
>>> 
>>>
>>> *Red Hat respects your work life balance. Therefore there is no need to
>>> answer this email out of your office hours.*
>>>
>>>
>>>
>> *Notice to Recipient*: https://www.fixflyer.com/disclaimer
>
>
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>
> *Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.
> *
>
>
>

-- 
*Notice to Recipient*: https://www.fixflyer.com/disclaimer 

___
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 Archi

[ovirt-users] High performance VM cannot migrate due to TSC frequency

[Gianluca Cecchi]

Hello,
I'm in 4.4.3 and CentOS 8.3 with 3 hosts.

I have a high performance VM that is running on ov300 and is configured to
be run on any host.

It seems that both if I set or not the option

Migrate only to hosts with the same TSC frequency

I always am unable to migrate the VM and inside engine.log I see this:

2020-12-11 15:56:03,424+01 INFO
 [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (default task-36)
[e4801b28-c832-4474-aa53-4ebfd7c6e2d0] Candidate host 'ov301'
('382bfc8f-60d5-4e06-8571-7dae1700574d') was filtered out by
'VAR__FILTERTYPE__INTERNAL' filter 'Migration-Tsc-Frequency' (correlation
id: null)

2020-12-11 15:56:03,424+01 INFO
 [org.ovirt.engine.core.bll.scheduling.SchedulingManager] (default task-36)
[e4801b28-c832-4474-aa53-4ebfd7c6e2d0] Candidate host 'ov200'
('949d0087-2c24-4759-8427-f9eade1dd2cc') was filtered out by
'VAR__FILTERTYPE__INTERNAL' filter 'Migration-Tsc-Frequency' (correlation
id: null)

Can you verify if it is only my problem?

Apart from the problem itself, what is "TSC frequency" and how can I check
if my 3 hosts are different or not indeed?

Normal VMs are able to migrate without problems

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/2HYSCVHSVZS6KX5FF5MOXI6YTLQOJIK7/

[ovirt-users] Re: Recent news & oVirt future

[Sandro Bonazzola]

Il giorno ven 11 dic 2020 alle ore 15:49 Charles Kozler <
char...@fixflyer.com> ha scritto:

> CentOS was the downstream of RHEL but has now become the upstream
>
> I guess oVirt was always downstream as well - yes?
>

No. oVirt is oVirt. It's  downstream to nothing.
And it used to work and being used on Fedora which is upstream to RHEL and
to CentOS Stream.
Fedora moved just way too fast and we had to drop the effort trying to keep
the pace: https://blogs.ovirt.org/2020/05/ovirt-and-fedora/
With CentOS Stream we are just moving the point when CentOS breaks oVirt.
Instead to wait a couple of months after RHEL release (CentOS 8.3 just
broke oVirt: we can't build oVirt Node and oVirt appliance anymore due to a
bug in lorax package, it's preventing oVirt 4.4.4 to be released because
advanced virtualization build is missing a dependency which is in RHEL but
not in CentOS due to a bug in CentOS compose system) we'll have the fix in
oVirt a month before RHEL will be released.



>
> If so then yes, I can't see much changing in the ways of oVirt
>

As far as I can tell by looking at CentOS 8.3, it will change in something
better.



>
>
>
>
> On Fri, Dec 11, 2020 at 2:59 AM Sandro Bonazzola 
> wrote:
>
>>
>>
>> Il giorno gio 10 dic 2020 alle ore 21:51 Charles Kozler <
>> char...@fixflyer.com> ha scritto:
>>
>>> I guess this is probably a question for all current open source projects
>>> that red hat runs but -
>>>
>>> Does this mean oVirt will effectively become a rolling release type
>>> situation as well?
>>>
>>
>> There's no plan to make oVirt a rolling release.
>>
>>
>>>
>>> How exactly is oVirt going to stay open source and stay in cadence with
>>> all the other updates happening around it on packages/etc that it depends
>>> on if the streams are rolling release? Do they now need to fork every piece
>>> of dependency?
>>>
>>
>> We are going to test regularly oVirt on CentOS Stream, releasing oVirt
>> Node and oVirt appliance after testing them, without any difference to what
>> we are doing right now with CentOS Linux.
>> Any raised issue will be handled as usual.
>>
>> What exactly does this mean for oVirt going forward and its overall
>>> stability?
>>>
>>
>> oVirt plans about CentOS Stream have been communicated one year ago here:
>> https://blogs.ovirt.org/2019/09/ovirt-and-centos-stream/
>>
>> That said, please note that oVirt documentation mentions "Enterprise
>> Linux" almost everywhere and not explicitly CentOS Linux.
>> As far as I can tell any RHEL binary compatible rebuild should just work
>> with oVirt despite I would recommend to follow what will be done within
>> oVirt Node and oVirt Appliance.
>>
>>
>>
>>>
>>> *Notice to Recipient*: https://www.fixflyer.com/disclaimer
>>> ___
>>> 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/7IUWGES2IG4BELLUPMYGEKN3GC6XVCHA/
>>>
>>
>>
>> --
>>
>> Sandro Bonazzola
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>
>> Red Hat EMEA 
>>
>> sbona...@redhat.com
>> 
>>
>> *Red Hat respects your work life balance. Therefore there is no need to
>> answer this email out of your office hours.*
>>
>>
>>
> *Notice to Recipient*: https://www.fixflyer.com/disclaimer



-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA 

sbona...@redhat.com


*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
*
___
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/2JCY6K2ZFML2VV6XUZK3UBA6CXUUIICW/

[ovirt-users] Re: [CFP] Virtualization & IaaS Devroom

[Piotr Kliczewski]

Friendly reminder that submission deadline for Virtualization & IaaS dev
room is on 20th of December. Please submit your talks!

On Tue, Dec 1, 2020 at 6:37 PM Piotr Kliczewski  wrote:

> We are excited to announce that the call for proposals is now open for the
> Virtualization & IaaS devroom at the upcoming FOSDEM 2021, to be hosted
> virtually on February 6th 2021.
>
> This year will mark FOSDEM’s 21th anniversary as one of the
> longest-running free and open source software developer events, attracting
> thousands of developers and users from all over the world. Due to Covid-19,
> FOSDEM will be held virtually this year on February 6th & 7th, 2021.
>
> About the Devroom
>
> The Virtualization & IaaS devroom will feature session topics such as
> open source hypervisors and virtual machine managers such as Xen Project,
> KVM, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such
> as KubeVirt, Apache CloudStack, Foreman, OpenStack, oVirt, QEMU and
> OpenNebula.
>
> This devroom will host presentations that focus on topics of shared
> interest, such as KVM; libvirt; shared storage; virtualized networking;
> cloud security; clustering and high availability; interfacing with multiple
> hypervisors; hyperconverged deployments; and scaling across hundreds or
> thousands of servers.
>
> Presentations in this devroom will be aimed at users or developers
> working on these platforms who are looking to collaborate and improve
> shared infrastructure or solve common problems. We seek topics that
> encourage dialog between projects and continued work post-FOSDEM.
>
> Important Dates
>
> Submission deadline: 20th of December
>
> Acceptance notifications: 25th of December
>
> Final schedule announcement: 31st of December
>
> Recorded presentations upload deadline: 15th of January
>
> Devroom: 6th February 2021
>
> Submit Your Proposal
>
> All submissions must be made via the Pentabarf event planning site[1]. If
> you have not used Pentabarf before, you will need to create an account. If
> you submitted proposals for FOSDEM in previous years, you can use your
> existing account.
>
> After creating the account, select Create Event to start the submission
> process. Make sure to select Virtualization and IaaS devroom from the
> Track list. Please fill out all the required fields, and provide a
> meaningful abstract and description of your proposed session.
>
> Submission Guidelines
>
> We expect more proposals than we can possibly accept, so it is vitally
> important that you submit your proposal on or before the deadline. Late
> submissions are unlikely to be considered.
>
> All presentation slots are 30 minutes, with 20 minutes planned for
> presentations, and 10 minutes for Q&A.
>
> All presentations will need to be pre-recorded and put into our system at
> least a couple of weeks before the event.
>
> The presentations should be uploaded by 15th of January and made
> available under Creative
>
> Commons licenses. In the Submission notes field, please indicate that you
> agree that your presentation will be licensed under the CC-By-SA-4.0 or
> CC-By-4.0 license and that you agree to have your presentation recorded.
> For example:
>
> "If my presentation is accepted for FOSDEM, I hereby agree to license all
> recordings, slides, and other associated materials under the Creative
> Commons Attribution Share-Alike 4.0 International License. Sincerely,
> ."
>
> In the Submission notes field, please also confirm that if your talk is
> accepted, you will be able to attend the virtual FOSDEM event for the
> Q&A. We will not consider proposals from prospective speakers who are
> unsure whether they will be able to attend the FOSDEM virtual event.
>
> If you are experiencing problems with Pentabarf, the proposal submission
> interface, or have other questions, you can email our devroom mailing
> list[2] and we will try to help you.
>
>
> Code of Conduct
>
> Following the release of the updated code of conduct for FOSDEM, we'd
> like to remind all speakers and attendees that all of the presentations and
> discussions in our devroom are held under the guidelines set in the CoC
> and we expect attendees, speakers, and volunteers to follow the CoC at all
> times.
>
> If you submit a proposal and it is accepted, you will be required to
> confirm that you accept the FOSDEM CoC. If you have any questions about
> the CoC or wish to have one of the devroom organizers review your
> presentation slides or any other content for CoC compliance, please email
> us and we will do our best to assist you.
>
> Call for Volunteers
>
> We are also looking for volunteers to help run the devroom. We need
> assistance with helping speakers to record the presentation as well as
> helping with streaming and chat moderation for the devroom. Please
> contact devroom mailing list [2] for more information.
>
> Questions?
>
> If you have any questions about this devroom, please send your questions
> to our devroom mailing list. You can also s

[ovirt-users] Re: Recent news & oVirt future

[Charles Kozler]

CentOS was the downstream of RHEL but has now become the upstream

I guess oVirt was always downstream as well - yes?

If so then yes, I can't see much changing in the ways of oVirt




On Fri, Dec 11, 2020 at 2:59 AM Sandro Bonazzola 
wrote:

>
>
> Il giorno gio 10 dic 2020 alle ore 21:51 Charles Kozler <
> char...@fixflyer.com> ha scritto:
>
>> I guess this is probably a question for all current open source projects
>> that red hat runs but -
>>
>> Does this mean oVirt will effectively become a rolling release type
>> situation as well?
>>
>
> There's no plan to make oVirt a rolling release.
>
>
>>
>> How exactly is oVirt going to stay open source and stay in cadence with
>> all the other updates happening around it on packages/etc that it depends
>> on if the streams are rolling release? Do they now need to fork every piece
>> of dependency?
>>
>
> We are going to test regularly oVirt on CentOS Stream, releasing oVirt
> Node and oVirt appliance after testing them, without any difference to what
> we are doing right now with CentOS Linux.
> Any raised issue will be handled as usual.
>
> What exactly does this mean for oVirt going forward and its overall
>> stability?
>>
>
> oVirt plans about CentOS Stream have been communicated one year ago here:
> https://blogs.ovirt.org/2019/09/ovirt-and-centos-stream/
>
> That said, please note that oVirt documentation mentions "Enterprise
> Linux" almost everywhere and not explicitly CentOS Linux.
> As far as I can tell any RHEL binary compatible rebuild should just work
> with oVirt despite I would recommend to follow what will be done within
> oVirt Node and oVirt Appliance.
>
>
>
>>
>> *Notice to Recipient*: https://www.fixflyer.com/disclaimer
>> ___
>> 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/7IUWGES2IG4BELLUPMYGEKN3GC6XVCHA/
>>
>
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>
> *Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.*
>
>
>

-- 
*Notice to Recipient*: https://www.fixflyer.com/disclaimer 

___
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/6SOQ5MT5DZTHWF76UYP2ZGED2EIPCQS2/

[ovirt-users] Re: CentOS 8 is dead

[Strahil Nikolov via Users]

Hi Thomas,

actually your expectations are a little bit high. Why I'm saying this ?
oVirt is the upstream of RedHat's and Oracle's paid solutions. As such , it's 
much more dynamic and we are a kind of testers of it. So, oVirt to RHV is like 
Fedora (and not CentOS) to RHEL.

Actually , you are looking for RHV fork (as CentOS is such) and not for oVirt.

In order to negate those stuff, you need to:
- Use patch management. You can't install packages{A,B,C} on your test 
environment and then install packages{D,E,F} on prod and pretend that 
everything is fine.
- Learn a little bit about oVirt & Gluster. Both softwares require some prior 
knowledge or you will have headaches. Gluster is simple to setup , but it's 
complex and not free of bugs (just like every upstream project).And of course, 
it is the upstream of RHGS - so you are in the same boat with oVirt.

If you really need stability , then you have the choice to evaluate RHEL + RHV 
+ Gluster and I can assure you it is more stable than the current setup.

I should admit that I got 2 cases where Gluster caused me headaches , but 
that's 2 issues for 2 years and compared to the multimillion Storages that we 
got (and failed 3 times till the vendor fixed the firmware) - is far less than 
expected.

My Lab is currently frozen to 4.3.10 and the only headaches are my old hardware.

Of course , if you feel much more confident with OpenVZ than oVirt, I think 
that it's quite natural to prefer it.

On the positive side, the community of oVirt is quite active and willing to 
assist (including RedHat engineers) and I have not seen a single issue not 
solved.

Best Regards,
Strahil Nikolov






В четвъртък, 10 декември 2020 г., 22:03:45 Гринуич+2, tho...@hoberg.net 
 написа: 





I came to oVirt thinking that it was like CentOS: There might be bugs, but 
given the mainline usage in home and coporate labs with light workloads and 
nothing special, chances to hit one should be pretty minor: I like looking for 
new fronteers atop of my OS, not inside.

I have been runing CentOS/OpenVZ for years in a previous job, mission critical 
24x7 stuff where minutes of outage meant being grilled for hours in meetings 
afterwards. And with PCI-DSS compliance certified. Never had an issue with 
OpenVZ/CentOS, all those minute goofs where human error or Oracle inventing 
execution plans.

Boy was I wrong about oVirt! Just setting it up took weeks. Ansible loves 
eating Gigahertz and I was running on Atoms. I had to learn how to switch from 
an i7 in mid-installation to have it finish at all. I the end I had learned 
tons of new things, but all I wanted was a cluster that would work as much out 
of the box as CentOS or OpenVZ.

Something as fundamental as exporting and importing a VM might simply not work 
and not even get fixed.

Migrating HCI from CentOS7/oVirt 4.3 to CentOS8/oVirt 4.4 is anything but 
smooth, a complete rebuild seems the lesser evil: Now if only exports and 
imports worked reliably!

Rebooting a HCI nodes seems to involve an "I am dying!" aria on the network, 
where the whole switch becomes unresponsive for 10 minutes and the fault 
tolerant cluster on it being 100% unresponsive (including all other machines on 
that switch). I has so much fun resynching gluster file systems and searching 
through all those log files for signs as to what was going on!
And the instructions on how to fix gluster issues seems so wonderfully detailed 
and vague, it seems one could spend days trying to fix things or rebuild and 
restore. It doesn't help that the fate of Gluster very much seems to hang in 
the air, when the scalable HCI aspect was the only reason I ever wanted oVirt.

Could just be an issue with RealTek adapters, because I never oberved something 
like that with Intel NICs or on (recycled old) enterprise hardware

I guess official support for a 3 node HCI cluster on passive Atoms isn't going 
to happen, unless I make happen 100% myself: It's open source after all!

Just think what 3/6/9 node HCI based on Raspberry PI would do for the project! 
The 9 node HCI should deliver better 10Gbit GlusterFS performance than most 
QNAP units at the same cost with a single 10Gbit interface even with 7:2 
erasure coding!

I really think the future of oVirt may be at the edge, not in the datacenter 
core.

In short: oVirt is very much beta software and quite simply a full-time job if 
you depend on it working over time.

I can't see that getting any better when one beta gets to run on top of another 
beta. At the moment my oVirt experience has me doubt RHV on RHEL would work any 
better, even if it's cheaper than VMware.

OpenVZ was simply the far better alternative than KVM for most of the things I 
needed from virtualization and it was mainly the hastle of trying to make that 
work with RHEL which had me switching to CentOS. CentOS with OpenVZ was the 
bedrock of that business for 15 years and proved to me that Redhat was 
hell-bent on making bad decisions on technological direc

[ovirt-users] Re: Nodes in CentOS 8.3 and oVirt 4.4.3.12-1.el8 but not able to update cluster version

[melnyksergii]

Dears, I have the same problem, but another one error:
On my pre-production stand with one node in cluster, I was set hode to 
maintenance, and after try update cluster to 4.5 i see: Error while executing 
action: Cannot change Cluster compatibility version where there are no hosts in 
the Cluster which support that version.

ENGINE LOG: 2020-12-11 15:48:26,338+02 INFO  
[org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-1) 
[383d1f09-039d-4737-9e8d-9b2490717bd8] Updating cluster CPU flags and verb 
according to the configuration of the Intel Westmere Family cpu
2020-12-11 15:48:26,347+02 INFO  
[org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-1) 
[383d1f09-039d-4737-9e8d-9b2490717bd8] Lock Acquired to object 
'EngineLock:{exclusiveLocks='[]', 
sharedLocks='[9abc1d61-829e-470b-b6c8-ad5aec769869=VM]'}'
2020-12-11 15:48:26,389+02 WARN  
[org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-1) 
[383d1f09-039d-4737-9e8d-9b2490717bd8] Validation of action 'UpdateCluster' 
failed for user smelnyk@internal-authz. Reasons: 
VAR__TYPE__CLUSTER,VAR__ACTION__UPDATE,CLUSTER_CANNOT_UPDATE_VERSION_WHEN_NO_HOST_SUPPORTS_THE_VERSION
2020-12-11 15:48:26,390+02 INFO  
[org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-1) 
[383d1f09-039d-4737-9e8d-9b2490717bd8] Lock freed to object 
'EngineLock:{exclusiveLocks='[]', 
sharedLocks='[9abc1d61-829e-470b-b6c8-ad5aec769869=VM]'}'


HOST:
OS Version:
RHEL - 8.3 - 1.2011.el8
OS Description:
CentOS Linux 8
Kernel Version:
4.18.0 - 240.1.1.el8_3.x86_64
KVM Version:
4.2.0 - 34.module_el8.3.0+555+a55c8938
LIBVIRT Version:
libvirt-6.0.0-28.module_el8.3.0+555+a55c8938
VDSM Version:
vdsm-4.40.35.1-1.el8
SPICE Version:
0.14.3 - 3.el8
GlusterFS Version:
[N/A]
CEPH Version:
librbd1-12.2.7-9.el8
Open vSwitch Version:
[N/A]
Nmstate Version:
nmstate-0.3.6-2.el8
Kernel Features:
MDS: (Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable), 
L1TF: (Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT 
vulnerable), SRBDS: (Not affected), MELTDOWN: (Mitigation: PTI), SPECTRE_V1: 
(Mitigation: usercopy/swapgs barriers and __user pointer sanitization), 
SPECTRE_V2: (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, 
STIBP: conditional, RSB filling), ITLB_MULTIHIT: (KVM: Mitigation: Split huge 
pages), TSX_ASYNC_ABORT: (Not affected), SPEC_STORE_BYPASS: (Mitigation: 
Speculative Store Bypass disabled via prctl and seccomp)
VNC Encryption:
Disabled
FIPS mode enabled:
Disabled 
___
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/EN3OFPDS4N2UAPHT2TT7MFT2EXHP4AUM/

[ovirt-users] Re: oVirt 4.4: Self-hosted engine deployment fails with backup restore from 4.3 engine

[Ilya Fedotov]

Hi Oliver

 How did you defeat this problem?

I have a similar problem

https://lists.ovirt.org/archives/list/users@ovirt.org/message/NTJHPQ5EBUEJ6UHS2UJMNFFDA6HHLMK4/
___
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/TWWTTPSAK2ZOLQROM6YKLC2GJEKIQYGU/

[ovirt-users] pgrade 4.3 to 4.4 with migration CentOS7 to CentOS8.3

[Ilya Fedotov]

Good day,

Encountered such a problem when migrating to ovirt 4.4
At
hosted-engine --deploy --restore-from-file=backup.bck

Getting, error below

Upgrading engine extension configuration:
/etc/ovirt-engine/extensions.d/xx-.properties", "[ INFO  ] Upgrading
CA", "[ INFO  ]
Creating CA: /etc/pki/ovirt-engine/qemu-ca.pem", "[ ERROR ] Failed to
execute stage 'Misc configuration': [Errno 17]
File exists: '/etc/pki/ovirt-engine/ca.pem' ->
'/etc/pki/ovirt-engine/apache-ca.pem'", "[ INFO  ]
DNF Performing DNF transaction rollback", "[ INFO  ] Stage: Clean up",

At setting of initial parameters I select "No" parameter in para

'Renew engine CA on restore if needed? Please notice ' 'that if you choose
Yes, all hosts will have to be ' 'later manually reinstalled from the
engine. ' '(@VALUES@)[@DEFAULT@]

Dosnt need to renew the .ca certificate, thats upgrade and dosnt need to
re-make connections with nodes!

Even with this item, he still tries to create a new certificate.
I found a similar question here:
https://www.mail-archive.com/users@ovirt.org/msg61114.html

Package Data:
ovirt-hosted-engine-setup-2.4.8-1.el8.noarch
ovirt-hosted-engine-ha-2.4.5-1.el8.noarch
ovirt-engine-appliance-4.4-20201110154142.1.el8.x86_64

CentOS Linux release 8.3.2011
4.18.0-240.1.1.el8_3.x86_64

 Pls, help programmers.


with br, Ilya Fedotov
___
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/NTJHPQ5EBUEJ6UHS2UJMNFFDA6HHLMK4/

[ovirt-users] Re: CentOS 8 is dead

[Sandro Bonazzola]

Il giorno mar 8 dic 2020 alle ore 20:39 Strahil Nikolov via Users <
users@ovirt.org> ha scritto:

> Hello All,
>
> I'm really worried about the following news:
> https://blog.centos.org/2020/12/future-is-centos-stream/


oVirt already defined plans about CentOS Stream one year ago:
https://blogs.ovirt.org/2019/09/ovirt-and-centos-stream/
There shouldn't be any worries about CentOS Stream.


> Did anyone tried to port oVirt to SLES/openSUSE or any Debian-based
> distro ?
>

Yes, we tried for Debian, Ubuntu, Gentoo, ArchLinux:
https://www.ovirt.org/develop/developer-guide/porting-ovirt.html
Someone tried on Suse as well: https://software.opensuse.org/package/vdsm
But I would rather look at CentOS Stream as it will be the one being tested
with oVirt or to alternative RHEL binary compatible rebuilds.



>
> Best Regards,
> Strahil Nikolov
> ___
> 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/HZC4D4OSYL64DX5VYXDJCHDNRZDRGIT6/
>


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA 

sbona...@redhat.com


*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.*
___
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/VRZE6MXI4A4XKJV2YLA52UJBXBGCY32M/

[ovirt-users] Re: oVirt and RHEV

[Sandro Bonazzola]

Il giorno ven 11 dic 2020 alle ore 06:28 tommy  ha
scritto:

> 1、 If oVirt can be used to manage RHEV ?
>
RHEV has been rebranded several years ago to RHV.
If you already have RHV I don't see why you would want to use oVirt to
manage it instead of using RHV-M (downstream of ovirt-engine) but from a
technical perspective it should work just fine.


> 2、 What relation between oVirt and RHEV?
>
RHV is downstream release of oVirt packaged by Red Hat.
oVirt  is a community project, RHV is a Red Hat product
with a defined lifecycle
 / support
 / documentation
.


>
>
> 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/RIDTSCC6EHHNQ577T2E74CFHCDTAVLRX/
>


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA 

sbona...@redhat.com


*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
*
___
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/ZK47BFRC7IX7GVV4AU5JAYLKCWLDTODV/