[ovirt-users] Re: Ovirt installation, deployment failed..

[Michal Skrivanek]

> On 19. 4. 2023, at 19:48, John Bnet  wrote:
> 
> Hi,
> 
> I'm new to ovirt.  I'm trying to get it up and running but I stuck at the 
> deployement point.
> 
> Can someone have any idea of what is going on?
> 
> this is what i did to install on cent0s8

if you mean CentOS Stream 8...

> -->
> 
> 
> hostnamectl set-hostname node1.local.net
> 
> vi /etc/hosts
> 
> dnf install -y centos-release-ovirt45

https://www.ovirt.org/develop/dev-process/install-nightly-snapshot.html could 
work better. The nightly repo has a few crucial fixes around ansible. Ansible 
2.14 created quite a mess recently.

HTH,
michal

> dnf module enable -y javapackages-tools pki-deps postgresql:12 389-ds 
> mod_auth_openidc  
> dnf update
> dnf install ovirt-engine
> engine-setup
> 
> dnf install cockpit-ovirt-dashboard vdsm-gluster ovirt-host 
> systemctl enable cockpit.socket
> systemctl start cockpit.socket
> firewall-cmd --list-services
> firewall-cmd --permanent --add-service=cockpit
> 
> hosted-engine --deploy
> 
> an here is a part of the log output:  
> 
> 
> 2023-04-19 09:32:36,628-0400 DEBUG otopi.context context.dumpEnvironment:765 
> ENVIRONMENT DUMP - BEGIN
> 2023-04-19 09:32:36,628-0400 DEBUG otopi.context context.dumpEnvironment:775 
> ENV CORE/internalPackageTransaction=Transaction:'[DNF Transaction]'
> 2023-04-19 09:32:36,628-0400 DEBUG otopi.context context.dumpEnvironment:775 
> ENV CORE/mainTransaction=Transaction:'[DNF Transaction]'
> 2023-04-19 09:32:36,629-0400 DEBUG otopi.context context.dumpEnvironment:779 
> ENVIRONMENT DUMP - END
> 2023-04-19 09:32:36,629-0400 DEBUG otopi.context context._executeMethod:127 
> Stage setup METHOD otopi.plugins.otopi.packagers.yumpackager.Plugin._setup
> 2023-04-19 09:32:36,629-0400 DEBUG otopi.context context._executeMethod:136 
> otopi.plugins.otopi.packagers.yumpackager.Plugin._setup condition False
> 2023-04-19 09:32:36,630-0400 DEBUG otopi.context context._executeMethod:127 
> Stage setup METHOD otopi.plugins.gr_he_common.engine.fqdn.Plugin._setup
> 2023-04-19 09:32:36,631-0400 DEBUG otopi.context context.dumpEnvironment:765 
> ENVIRONMENT DUMP - BEGIN
> 2023-04-19 09:32:36,631-0400 DEBUG otopi.context context.dumpEnvironment:775 
> ENV COMMAND/dig=NoneType:'None'
> 2023-04-19 09:32:36,631-0400 DEBUG otopi.context context.dumpEnvironment:775 
> ENV COMMAND/ip=NoneType:'None'
> 2023-04-19 09:32:36,631-0400 DEBUG otopi.context context.dumpEnvironment:779 
> ENVIRONMENT DUMP - END
> 2023-04-19 09:32:36,632-0400 DEBUG otopi.context context._executeMethod:127 
> Stage setup METHOD otopi.plugins.gr_he_common.network.bridge.Plugin._setup
> 2023-04-19 09:32:36,633-0400 DEBUG otopi.context context._executeMethod:127 
> Stage setup METHOD otopi.plugins.gr_he_common.network.gateway.Plugin._setup
> 2023-04-19 09:32:36,634-0400 DEBUG otopi.context context._executeMethod:127 
> Stage setup METHOD 
> otopi.plugins.gr_he_common.network.network_check.Plugin._setup
> 2023-04-19 09:32:36,634-0400 DEBUG otopi.context context.dumpEnvironment:765 
> ENVIRONMENT DUMP - BEGIN
> 2023-04-19 09:32:36,634-0400 DEBUG otopi.context context.dumpEnvironment:775 
> ENV COMMAND/nc=NoneType:'None'
> 2023-04-19 09:32:36,634-0400 DEBUG otopi.context context.dumpEnvironment:775 
> ENV COMMAND/ping=NoneType:'None'
> 2023-04-19 09:32:36,635-0400 DEBUG otopi.context context.dumpEnvironment:779 
> ENVIRONMENT DUMP - END
> 2023-04-19 09:32:36,635-0400 DEBUG otopi.context context._executeMethod:127 
> Stage setup METHOD otopi.plugins.gr_he_common.vm.cloud_init.Plugin._setup
> 2023-04-19 09:32:36,636-0400 DEBUG otopi.context context.dumpEnvironment:765 
> ENVIRONMENT DUMP - BEGIN
> 2023-04-19 09:32:36,636-0400 DEBUG otopi.context context.dumpEnvironment:775 
> ENV COMMAND/ssh-keygen=NoneType:'None'
> 2023-04-19 09:32:36,636-0400 DEBUG otopi.context context.dumpEnvironment:779 
> ENVIRONMENT DUMP - END
> 2023-04-19 09:32:36,637-0400 DEBUG otopi.context context._executeMethod:127 
> Stage setup METHOD otopi.plugins.otopi.network.firewalld.Plugin._setup
> 2023-04-19 09:32:36,637-0400 DEBUG otopi.context context.dumpEnvironment:765 
> ENVIRONMENT DUMP - BEGIN
> 2023-04-19 09:32:36,637-0400 DEBUG otopi.context context.dumpEnvironment:775 
> ENV COMMAND/firewall-cmd=NoneType:'None'
> 2023-04-19 09:32:36,637-0400 DEBUG otopi.context context.dumpEnvironment:775 
> ENV COMMAND/python3=NoneType:'None'
> 2023-04-19 09:32:36,638-0400 DEBUG otopi.context context.dumpEnvironment:779 
> ENVIRONMENT DUMP - END
> 2023-04-19 09:32:36,638-0400 DEBUG otopi.context context._executeMethod:127 
> Stage setup METHOD otopi.plugins.otopi.network.hostname.Plugin._setup
> 2023-04-19 09:32:36,639-0400 DEBUG otopi.context context._executeMethod:127 
> Stage setup METHOD otopi.plugins.otopi.services.openrc.Plugin._setup
> 2023-04-19 09:32:36,639-0400 DEBUG otopi.context context.dumpEnvironment:765 
> ENVIRONMENT DUMP - BEGIN
> 2023-04-19 09:32:36,639-0400 DEBUG otopi.context context.dumpEnvironment:775 
> ENV COMMAND/rc=NoneType:'None'
> 

[ovirt-users] Re: Renewing certificates - How it affects running vms?

[Michal Skrivanek]

> On 4. 4. 2023, at 18:14, markec...@gmail.com wrote:
> 
> Hi!
> 
> Simple question - does procedure to renew certificates affects running 
> virtual machines?
> 
> I have a question regarding renewing certificates that are about to expire. I 
> have a cluster with 5 hosts and a self-hosted engine. I have already updated 
> the host certificates by logging in to each host, migrating virtual machines 
> from that host to another, putting it into maintenance mode, and enrolling 
> certificates via the web interface.
> 
> Now, I have a question regarding renewing Engine certificates (self signed). 
> I know the procedure is to log in to the host where the hosted engine is 
> running (Host1 in my case), put it into global maintenance mode via the 
> command "hosted-engine --set-maintenance --mode=global," and then log in to 
> the Engine and run the command "engine-setup --offline" to renew it.
> 
> My question is, will these two commands affect the running virtual machines 
> on Host1 (where the hosted-engine is also hosted) and virtual machines on 
> other hosts? Will they be shut down? Should I migrate virtual machines first 
> from Host1 to some other host and then run the commands?

no, it won't affect the VMs in any way

> 
> I have a lot of virtual machines that i can't shut down or restart, any way 
> to do it without that?
> 
> 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/EKRHS4JBZ3I65MOZWVLVLEFJPMKRDKYQ/
___
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/ZXGAHMYPUF774P76RAGXQDQ3QOQ4Y363/

[ovirt-users] Re: Zanata account

[Michal Skrivanek]

> On 20. 2. 2023, at 1:52, Ben De Luca  wrote:
> 
> Hi, I thought Redhat did not work with Russians or provide services to 
> Russians at this time? Red Hat’s response to the war in Ukraine 
>  

Hi Ben,
yes, that's indeed the case, it's a company policy regarding Red Hat products 
and services.

Thanks,
michal

> 
> Maybe this would be better to continue after hostilities end?
> 
> On Sun, 19 Feb 2023 at 16:35, Sharon Gratch  > wrote:
>> Hi Denis,
>> 
>> Sure. Please provide the following details:
>> 1. What is your preferable username and email to be used for that account? 
>> 2. Is there a specific language that you would like to help with translating 
>> to? Is it Russian? We want to add you to the relevant Zanata's translation 
>> groups as well.
>> 
>> Thanks,
>> Sharon
>> 
>> 
>> 
>> On Sun, Feb 19, 2023 at 3:28 PM Денис Квист > > wrote:
>>> Hello everyone!
>>>  
>>> I would like to have a Zanata account to join the translation group.
>>>  
>>> Kind regards,
>>> Denis
>>> ___
>>> 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/V625RU7VD3ZBAPA2GAHLWRHFGLAG3M4T/
>> ___
>> 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/F3TKDLN4X5VYIHM3RX2TZ5VWLWMNKQTU/
> ___
> 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/VSWQ25EIK3FWO2P7BKXYSIKNX32GRJ2C/

___
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/ARXPPPUEQPKJBFG7Z73JPAQAIBMWTZ66/

[ovirt-users] Re: Host kernel command line incorrectly quoted in oVirt 4.5.3.2

[Michal Skrivanek]

> On 8. 12. 2022, at 13:05, Gianluca Amato  wrote:
> 
> Hi all.
> I recently changed the kernel command line of one of my hosts using oVirt 
> Manager (I use a custom kernel command line, not one obtained by selecting 
> the standard features). This did not work as expected. The entire kernel 
> command line was saved in /boot/loader/entries surrounded by single quotes, 
> making it useless for the kernel. I may later fix the problem by connecting 
> to the host and removing the single quotes by the files in 
> /boot/loader/entries. I am sure the same procedure used to work in previous 
> versions of oVirt.
> 
> Has someone else encountered this problem ?
> 
> I would be glad to submit a bug on bugzilla, but submitting bugs for oVirt 
> seems to be blocked.

Hi Gianluca,
the right place to report this issue would be at 
https://github.com/oVirt/ovirt-engine/issues

It's not a very...popular feature, I'm not sure if many people use that. It 
doesn't really provide any benefit over doing it outside of oVirt these days.

Thanks,
michal
> ___
> 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/OY3OCNJ4EW54L7SMUZ7L5PQ2WDKJ6W4I/
___
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/LYW7VNLS7DM6SA4MMM3WYMLHR7QBVA27/

[ovirt-users] Re: el9 official use?

[Michal Skrivanek]

> On 6. 12. 2022, at 17:29, Nathanaël Blanchet via Users  
> wrote:
> 
> Hello,
> Until 4.5.4, el9 ovirt-node was for testing. Following 4.5.4 releases note, 
> it seems to be officially supported but there is no information about el9 
> engine support.
> What about it? 

all the packages are released for both el8 and el9 at the moment.

Thanks,
michal

> ___
> 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/25BKPHSXS4VJN3NLXHOOZZNPXIQIB5XZ/
>  
> 
___
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/Q6D2UKNOHWGVQ3EMJNYZI6XB6QML3QMH/

[ovirt-users] Re: EL8.6 to EL8.7

[Michal Skrivanek]

> On 28. 11. 2022, at 0:34, eshwa...@gmail.com wrote:
> 
> I upgraded to 8.5.3, and did a nobest upgrade to EL8.7.  There are two 
> un-resolved issues:
> 
> Problem 1: installed package centos-stream-release-8.6-1.el8.noarch obsoletes 
> redhat-release < 9 provided by redhat-release-8.7-0.3.el8.x86_64
>  - cannot install the best update candidate for package 
> redhat-release-8.6-0.1.el8.x86_64
>  - problem with installed package centos-stream-release-8.6-1.el8.noarch
> 
> I can't find an stream 8.7 stream file, and the oVirt files depend on the 
> existing 8.6 package.
> 
> And as has been noted by others, ansible:
> 
> Problem 2: package ovirt-engine-4.5.3.2-1.el8.noarch conflicts with 
> ansible-core >= 2.13.0 provided by ansible-core-2.13.3-1.el8.x86_64
>  - cannot install the best update candidate for package 
> ovirt-engine-4.5.3.2-1.el8.noarch
>  - cannot install the best update candidate for package 
> ansible-core-2.12.2-4.el8_6.x86_64
> 
> Will there be a future upgrade that allows this upgrade to go through?

yeah, changes for 2.13 have been merged already, pending release

> ___
> 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/ZGPZG2WZCBIPJKHEAIDNSYJJIT3KS5M6/
___
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/FL7LBB7MUHEQWB4DF57GK6UTVGAG4BGG/

[ovirt-users]Re: About oVirt’s future

[Michal Skrivanek]

Hi Alex,

> On 21. 11. 2022, at 19:56, Alex McWhirter  wrote:
> 
> I have some manpower im willing to throw at oVirt, but i somewhat need to 
> know if what the community wants and what we want are in line.
> 

I don't think anyone would oppose adding a new features. Removing is 
challenging, but we did went through quite a few removals too. Maintenance of 
all the various features has become a major burden to our team and things that 
were promising and useful can turn useless in few years and they need to be 
removed.
> 
> 1. We'd bring back spice and maybe qxl. We are already maintaining forks of 
> the ovirt and RH kernels for this. We use ovirt currently for a lot of VDI 
> solutions paired with nvidia grid. Not usable over VNC.
> 

SPICE has little development these days, and it's completely dropped from EL9. 
But other than that it's easy to keep in oVirt of course.
> 
> 2. Hyperconverged storage is important. I'd suggest integrations with 
> linstor. Seems well aligned with ovirt. Bringing back gluster is likely the 
> wrong move.
> 

We got decently far with managed storage using cinderlib. Repeating that with 
other implementation might be now easier, but it's still likely a big 
undertaking. Even teh cinderlib implementation is not really on par with the 
"native" vdsm storage code.
> 
> 3. oVirt desperately needs vxlan support. Ideally integrating with FRR on the 
> backend so an ovirt node can just plug into an exiting EVPN VXLAN setup. 
> 
> 4. some things need cut from ovirt, namely hosted engine and maybe the 
> grafana stuff. Not that these aren't nice to have, but hosted engine rarely 
> actually works reliable in it's current state (compare mailing list 
> complaints of hosted engine vs other issues) and the grafana stuff can be 
> pushed into a sub project.
> 

grafana is mostly its own thing, there's some common setup code but that's it. 
And TBH the most of the complexity around DWH and setup is the support for 
remote deployment...and that would indeed be the first thing to drop as 
something that doesn't bring any benefit anymore. It was originally introduced 
to reduce overload of ovirt-engine machine but over the time we got much more 
efficient and hw got so much better that it's not worth it anymore

As for HE the problem is it's the most prevalent mode of deployment. It's 
complex, that's true, but mostly the deployment, not the "runtime". It's a lot 
of code and it's fair to consider dropping all of it, but OTOH we don't have 
any other high availability solution for engine host then.
> 
> 5. It needs to do containers. Doesn't need to be the behemoth of OKD, but 
> something more along the lines of what k3s does, for now.
> 

We had some experimental code in vdsm for container management from 
pre-kubernetes times. Ultimately it was removed in favor of doing it the other 
way around with Kubevirt.
A simple management is probably not hard to add, but k8s features would 
probably require a full blown k8s distribution, even if "just" k3s and then you 
are again likely better off with adding Kubevirt to it.

> 
> These are the thing's i'd like to see done, and maybe also cut back some of 
> the RHEL specific stuff to allow debian deployments (would massively help 
> with userbase). Basically for the past year i've been tasked with figuring 
> out if we are going to fork ovirt internally or move to OpenNebula. I prefer 
> the ovirt option if the opportunity now exists to take things in another 
> direction.
> 

Rocky/Alma are almost there. Basically just the CI is missing and few small 
things here or there. Debian...we've tried that in early years, and besides 
limited capacity the major problem we had was with bugs. It's a mine field. We 
could influence RHEL to include the right fixes and depend on the right 
versions but with other distros it became too much to track.
I guess it depends on resources, I think just switching to e.g. Debian wouldn't 
be too hard, there's no RHEL-specific code anywhere really.

Overall I don't find any of the proposed directions problematic except for the 
Hosted Engine, that might need - at the very least - some transition plan.
I believe a fresh blood in the project would be highly appreciated by everyone!

Thanks,
michal
> 
> 
> On 2022-11-15 03:31, Sandro Bonazzola wrote:
> 
>>  
>> 
>> Il giorno lun 14 nov 2022 alle ore 23:40 Frank Wall > > ha scritto:
>> Hi Didi,
>> 
>> thanks for keeping us updated. However, I'm concerned...
>> 
>> > Ultimately, the future of oVirt lies in the hands of the community. If
>> > you, as a community member, use and like oVirt, and want to see it
>> > thrive, now is the best time to help with this!
>> 
>> I don't want to be rude, but this sounds to me like no developers
>> have shown interest in keeping oVirt alive. Is this true? Is no other
>> company actively developing oVirt anymore?
>>  
>> I've contacted directly all the companies with oVirt downstreams I was aware 
>> of.
>> I also 

[ovirt-users] Re: ovirt-node 4.5 and engine 4.4

[Michal Skrivanek]

> On 8. 11. 2022, at 12:58, Nathanaël Blanchet via Users  
> wrote:
> 
> Hello,
> 
> I'm planning to upgrade ovirt engine to 4.5, but I need now to install 
> additionnal hosts. Is it safe to directly install my new hosts with 
> ovirt-node 4.5 and attach them to 4.4 engine?

generally yes
we keep compatibility with 4.2 though but we do not test older engines really. 
but if it manages to deploy then it should be all good...and with hopefully 
less bugs than old 4.4. node.

> 
> Thank you
> 
> -- 
> Nathanaël Blanchet
> 
> Supervision réseau
> SIRE
> 227 avenue Professeur-Jean-Louis-Viala
> 34193 MONTPELLIER CEDEX 5 
> Tél. 33 (0)4 67 54 84 55
> Fax  33 (0)4 67 54 84 14
> blanc...@abes.fr
> 
> ___
> 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/C2XMBGPBAFI5YNTEQ4AWDWQLCKXOJMPD/
___
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/4JZSDCFXJREOUXFJBD4EVKRCPZXPZFJF/

[ovirt-users] Re: vdsm 4.50.3.4 and qemu-kvm update problem

[Michal Skrivanek]

> On 10. 11. 2022, at 1:16, Erkan E via Users  wrote:
> 
> Hello,
> 
> I have the same issue issue with my oVirt v4.5.x system installed by 
> following the oVirt official installation document at 
> https://www.ovirt.org/download/install_on_rhel.html
> 
> The oVirt hosts are Rocky Linux v8.6. When trying to upgrade the oVirt hosts 
> using oVirt's webadmin GUI or by executing the "yum upgrade" command on the 
> oVirt hosts, it fails due to a dependency issue. 
> 
> "Problem 1: cannot install the best update candidate for package 
> vdsm-4.50.2.2-1.el8.x86_64
>  - nothing provides qemu-kvm >= 15:6.2.0-11.module+el8.6.0+16360+9e5d914e.4 
> needed by vdsm-4.50.3.4-1.el8.x86_64"
> 
> The oVirt package vdsm-4.50.3.4-1.el8.x86_64 requires 
> qemu-kvm-6.2.0-11.module+el8.6.0+16360+9e5d914e.4 or newer, whereas Rocky 
> Linux provides  qemu-kvm-6.2.0-11.module+el8.6.0+1052+ff61d164.6.
> 
> For the qemu-kvm package, even though their version numbers are exactly the 
> same (6.2.0-11.module+el8.6.0), dnf/yum thinks that the "1052" build number 
> for RockyLinux is older than the 16360 build number required for 
> vdsm-4.50.3.4-1.el8.x86_64.

And rightly, because 1050 is "older" than 16360. Unfortunately for virt module 
builds we need to match the whole thing, all of the 8.6.z builds are based on 
qemu-kvm 6.2.0-11 and we need a zerocopy migration change that has been 
introduced(backported) only into later builds

> 
> When I chatted with Rocky Linux developers, they've explained me that this 
> issue's caused by how the vendor (oVirt) developers pack their software and 
> setting out build requirements. OVirt packages uses the exact version 
> numbers, including the build numbers, which increment on each module build. 
> Unfortunately, Red Hat has a higher increment than all the EL8 derivatives.

I have no idea why rocky is building the modules with different series than 
RHEL. This way we would indeed have to have a different requirement than rocky, 
and alma too. We do not test on rocky, but feel free to post a patch for that. 
Note we're moving away from EL8 entirely and in EL9 the module is (fortunately) 
gone and the versioning is straightforward again.

Thanks,
michal

> 
> Is it possible to solve this issue if you (oVirt developers) are able to 
> re-set the requirements without using any build numbers (by only saying 
> BuildRequires: qemu-kvm >= 6.2.0-11) to increase the compatibility with the 
> other Enterprise Linux operating systems?
> 
> Thank you
> Erkan E
> ___
> 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/RGMDHPXA6DH2FHNHQBJUQ74OXRL56CUZ/
___
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/ZSVRP6TMJM7BAXMOJBKK72YL4AFUY34A/

[ovirt-users] Re: vdsm 4.50.3.4 and qemu-kvm update problem

[Michal Skrivanek]

> On 8. 11. 2022, at 12:29, Kapetanakis Giannis  
> wrote:
> 
> It seems that vdsm 4.50.3.4-1.el8 has been pushed to centos-ovirt45 which 
> according to
> https://github.com/oVirt/vdsm/blob/master/vdsm.spec.in
> 
> # Zero-copy migrations, https://bugzilla.redhat.com/2089434
> Requires: qemu-kvm >= 15:6.2.0-11.module+el8.6.0+16360+9e5d914e.4
> 
> This is not available in Rocky 8.6, probably not backported from Redhat 8.7?

that's still from 8.6, but indeed rocky doesn't seem to contain it. No idea 
why, maybe just a delay? You'd have to ask Rocky guys.
Latest qemu-kvm is 6.2.0-11.module+el8.6.0+16538+01ea313d.6 that was released 
15 days ago via https://access.redhat.com/errata/RHBA-2022:7122 


Thanks,
michal

> 
> # dnf update
> Last metadata expiration check: 0:02:15 ago on Tue 08 Nov 2022 13:24:14 EET.
> Error:
>  Problem 1: cannot install the best update candidate for package 
> vdsm-4.50.2.2-1.el8.x86_64
>   - nothing provides qemu-kvm >= 15:6.2.0-11.module+el8.6.0+16360+9e5d914e.4 
> needed by vdsm-4.50.3.4-1.el8.x86_64
> 
> G
> 
> ___
> 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/4WHSVV7LKLORWBOGGOVCV7BLBNWAH5ZG/

___
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/XYYK33XYEHJVCSWRS7O7J6GZXESWCDDL/

[ovirt-users] Re: expired host certificate

[Michal Skrivanek]

> On 4. 11. 2022, at 23:13, Diggy Mc  wrote:
> 
> Nevermind.  I found "Enroll Certificate"  I had looked under "Management", 
> but not "Installation".  **sigh**  Sorry for wasting your time.  :/

I'm glad that it worked!
We adjusted the validity period in 4.5, once you upgrade the whole system you 
shouldn't get into this situation that often.

> The host is back up and running.
> ___
> 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/YZF46LXOSMGPURAW43FE47FZEROKZNGH/
___
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/BYEVZVSHLFGSSCAPEBOYN3H5XS7GSRQN/

[ovirt-users] Re: infrastructure boostrap. (i.e engine start / autostart).

[Michal Skrivanek]

> On 4. 11. 2022, at 15:03, dupar...@esrf.fr wrote:
> 
> Thanks for your reply
> 
>> with oVirt or elsewhere?
> 
> That was with XEN,  OCFS2 cluster context, which is more prone to 
> instabilities.
> Anyway, loosing the manager/engine when things start going wrong is just 
> worsening the situation.

Yes, but oVirt does that quite differently. Despite the challenges around 
deployment I believe it's a way safer solution than trying to run this 
independently/manually.

Thanks,
michal

> ___
> 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/MR72VXWOPYNSNKBT2DUCKRYUOQWGHMTJ/
___
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/QKB35ICYTF24W7GCFZH6IGN4L34QZR4C/

[ovirt-users] Re: Please, Please Help - New oVirt Install/Deployment Failing - "Host is not up..."

[Michal Skrivanek]

> On 2. 11. 2022, at 11:01, Matthew J Black  wrote:
> 
> OK, so as I said I was going to do I've now gone through the logs.
> 
> I've place the log files into DropBox 
> (https://www.dropbox.com/sh/eymwdy8hzn3sa7z/AACscSP2eaFfoiN-QzyeEVfaa?dl=0)
> 
> There was only one significant part of the logs (at least that what it 
> appears to me) and I've included that extract below:
> 
> ovirt-hosted-engine-setup-ansible-bootstrap_local_vm-...log Extract
> 
> ~~~
> 2022-11-01 21:34:57,395+1100 INFO ansible task start {'status': 'OK', 
> 'ansible_type': 'task', 'ansible_playbook': 
> '/usr/share/ovirt-hosted-engine-setup/he_ansible/trigger_role.yml', 
> 'ansible_task': 'ovirt.ovirt.hosted_engine_setup : Notify the user about a 
> failure'}
> 2022-11-01 21:34:57,395+1100 DEBUG ansible on_any args TASK: 
> ovirt.ovirt.hosted_engine_setup : Notify the user about a failure  kwargs 
> is_conditional:False 
> 2022-11-01 21:34:57,396+1100 DEBUG ansible on_any args localhost TASK: 
> ovirt.ovirt.hosted_engine_setup : Notify the user about a failure  kwargs 
> 2022-11-01 21:34:57,875+1100 INFO ansible skipped {'status': 'SKIPPED', 
> 'ansible_type': 'task', 'ansible_playbook': 
> '/usr/share/ovirt-hosted-engine-setup/he_ansible/trigger_role.yml', 
> 'ansible_task': 'Notify the user about a failure', 'ansible_host': 
> 'localhost'}
> 2022-11-01 21:34:57,876+1100 DEBUG ansible on_any args 
>   kwargs 
> 2022-11-01 21:34:58,359+1100 INFO ansible task start {'status': 'OK', 
> 'ansible_type': 'task', 'ansible_playbook': 
> '/usr/share/ovirt-hosted-engine-setup/he_ansible/trigger_role.yml', 
> 'ansible_task': 'ovirt.ovirt.hosted_engine_setup : Set host_id'}
> 2022-11-01 21:34:58,359+1100 DEBUG ansible on_any args TASK: 
> ovirt.ovirt.hosted_engine_setup : Set host_id  kwargs is_conditional:False 
> 2022-11-01 21:34:58,360+1100 DEBUG ansible on_any args localhost TASK: 
> ovirt.ovirt.hosted_engine_setup : Set host_id  kwargs 
> 2022-11-01 21:34:58,844+1100 DEBUG var changed: host "localhost" var 
> "host_id" type "" 
> value: ""eb33e62a-2929-499f-80de-b7ac38a075f5""
> 2022-11-01 21:34:58,844+1100 INFO ansible ok {'status': 'OK', 'ansible_type': 
> 'task', 'ansible_playbook': 
> '/usr/share/ovirt-hosted-engine-setup/he_ansible/trigger_role.yml', 
> 'ansible_host': 'localhost', 'ansible_task': 'Set host_id', 'task_duration': 
> 0}
> 2022-11-01 21:34:58,844+1100 DEBUG ansible on_any args 
>   kwargs 
> 2022-11-01 21:34:59,288+1100 INFO ansible task start {'status': 'OK', 
> 'ansible_type': 'task', 'ansible_playbook': 
> '/usr/share/ovirt-hosted-engine-setup/he_ansible/trigger_role.yml', 
> 'ansible_task': 'ovirt.ovirt.hosted_engine_setup : Collect error events from 
> the Engine'}
> 2022-11-01 21:34:59,289+1100 DEBUG ansible on_any args TASK: 
> ovirt.ovirt.hosted_engine_setup : Collect error events from the Engine  
> kwargs is_conditional:False 
> 2022-11-01 21:34:59,290+1100 DEBUG ansible on_any args localhost TASK: 
> ovirt.ovirt.hosted_engine_setup : Collect error events from the Engine  
> kwargs 
> 2022-11-01 21:35:00,157+1100 INFO ansible ok {'status': 'OK', 'ansible_type': 
> 'task', 'ansible_playbook': 
> '/usr/share/ovirt-hosted-engine-setup/he_ansible/trigger_role.yml', 
> 'ansible_host': 'localhost', 'ansible_task': 'Collect error events from the 
> Engine', 'task_duration': 1}
> 2022-11-01 21:35:00,157+1100 DEBUG ansible on_any args 
>   kwargs 
> 2022-11-01 21:35:00,625+1100 DEBUG var changed: host "localhost" var 
> "error_events" type "" value: "{
>"changed": false,
>"failed": false,
>"ovirt_events": [
>{
>"cluster": {
>"href": 
> "/ovirt-engine/api/clusters/c44e2594-989d-4f1e-8308-feec46918d67",
>"id": "c44e2594-989d-4f1e-8308-feec46918d67",
>"name": "my_cluster_1"
>},
>"code": 532,
>"custom_id": -1,
>"description": "Used memory of host ovirt_node_1.mynet.local in 
> cluster my_cluster_1 [100%] exceeded defined threshold [95%].",
>"flood_rate": 0,
>"host": {
>"href": 
> "/ovirt-engine/api/hosts/eb33e62a-2929-499f-80de-b7ac38a075f5",
>"id": "eb33e62a-2929-499f-80de-b7ac38a075f5",
>"name": "ovirt_node_1.mynet.local"
>},
>"href": "/ovirt-engine/api/events/142",
>"id": "142",
>"index": 142,
>"origin": "oVirt",
>"severity": "warning",
>"time": "2022-11-01 21:34:57.64+11:00"
>},
>{
>"cluster": {
>"href": 
> "/ovirt-engine/api/clusters/c44e2594-989d-4f1e-8308-feec46918d67",
>"id": "c44e2594-989d-4f1e-8308-feec46918d67",
>"name": "my_cluster_1"
>},
>"code": 519,
>"correlation_id": "65a04e79",
>"custom_id": -1,
>"description": "Host ovirt_node_1.mynet.local does not comply with 
> the cluster my_cluster_1 

[ovirt-users] Re: expired host certificate

[Michal Skrivanek]

> On 2. 11. 2022, at 22:13, Diggy Mc  wrote:
> 
> I'm running oVirt 4.4.  The "libvirtd" service won't start and it appears to 
> be because of an expired certificate.
> 
> How do I create and install a new certificate on the host.  Your help is much 
> appreciated.

run Enroll Certificate for the host, if it is in Maintenance state.
There's been quite a few fixes around certificate expiration/renewal in 4.5, 
you really should upgrade

Thanks,
michal

> 
> -- Diggy
> 
> ---
> ___
> 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/YH72ACVXJJSIMJ3VSO4FEWBT6RU3J4TA/
___
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/5LJ4SURNDM5QGRM324NZO52YWPOWLK2G/

[ovirt-users] Re: infrastructure boostrap. (i.e engine start / autostart).

[Michal Skrivanek]

> On 4. 11. 2022, at 10:49, dupar...@esrf.fr wrote:
> 
> Hi, 
> 
> We decided to run the oVirt engine (Oracle flavor) outside the 
> infrastructure. (Medium infrastructure, 10 Hosts, iSCSI storage arrays)
> We created a second, smaller infrastructure (Single host, local storage) for 
> management (engine) and monitoring (nagios, Dell storage manager etc..) . . 
> This secondary infrastructure's engine runs in the first infrastructure.
> 
> So, If you picture it, we're facing a "bootstrap" cross-dependency problem 
> where each engine need the other one to start.
> 
> This is actually a design we had when we were using Xen (Oracle's). 
> Xen provides the "xen create" command to start a VM, even w/o a manager. 
> Bootstrap problem solved. 
> 
> We're moving to oVirt and I understand that oVirt does not support 
> out-of-the-box starting a VM w/o the engine.
> 
> I've found a workaround that seems to work and would like your advice :
> 
> -  keep a dump of XML of the engine VM
> # virsh -r dumpxml prodEngine > prodEngine.xml
> 
> - When necessary use virsh to start the engine
> # virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf 
> create prodEngine.xml


there' libvirt where you can do anything as you wish. The complexity is with 
network and storage preparation, that's why we need ovirt-engine because all 
the configuration and logic is there. You can run suff manually but then you 
have to handle all that yourself too. E.g. what happens if the VM dies, what 
happens if storage becomes disconnected, how do you connect it after host boot, 
etc.
That's what self-hosted engine feature does. It's not without its own issues, 
but it's there to care of all these cases

> 
> The only visible problem is a warning at the VM that was started manually 
> saying "Newer configuration for next run". A restart clears the warning and 
> there's does not seem to be consequences with the VM that had been started 
> from a dump xml.
> 
> Note : I understand that there is the "self-hosted" engine architecture that 
> solves that "bootstrap" problem. We're no into that for now. We had bad 
> experience with that design in the past. 

with oVirt or elsewhere?

Thanks,
michal

> ___
> 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/E2WM2N7G5VVIXI7M7VQEALSE7XO6RHUC/
___
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/7DLK4FBNOO35IOFL2UXW5K6OEJLXBA55/

[ovirt-users] Re: VNC console connection fails [ovirt 4.5.3.1-1.el8]

[Michal Skrivanek]

> On 27. 10. 2022, at 11:33, andre.li...@gematik.de wrote:
> 
> Hello list,
> 
> is there anybody else out there having problems to connect to a vm console 
> via vnc or is it just me?
> 
> We are running ovirt-engine 4.5.3.1-1.el8 on up to date ovirt-nodes. I can 
> connect to every virtual machine by spice, but am unable to connect via vnc 
> due to a tls handshake error.
> Remote-viever just shows "Failed to complete handshake Error in the pull 
> function" (on windows and linux clients).
> Wireshark tls handshake capture looks supicious to me, server hello message 
> is just 182 bytes long and doesn't coantain a server certificate. Is this 
> normal?

doesn't ring any bell, but did you try any other VNC client? 
tls handshake...so is that secured vnc? host running in FIPS mode?

for RHV there's a procedure in admin guide appendix E.3[1], strangely it's 
missing from [2]. No idea why, but it should be easy to follow on oVirt too.

Thanks,
michal

[1] 
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/administration_guide/enabling-encrypted-vnc-consoles-for-fips
[2] https://www.ovirt.org/documentation/administration_guide/

> 
> sincerely
> André
> ___
> 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/RVGVP7E3KRR2BZCY5XLTZIMOS3COLRIC/
___
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/Z4HU2QNOXWZWMRXROFF74JT3LRLHH6TJ/

[ovirt-users] Re: Please, Please Help - New oVirt Install/Deployment Failing - "Host is not up..."

[Michal Skrivanek]

> On 1. 11. 2022, at 11:46, Matthew J Black  wrote:
> 
> Hi All,
> 
> Long story short, I just tried to do a `hosted-engine --deploy` on a brand, 
> new "out-of-the-box box", following the oVirt doco *exactly*, and while I got 
> past my "Host is not up" issue, but almost exactly afterwards got this in my 
> console (I've included the couple of lines leading up to the "Host is no up" 
> step):
> 
> ~~~
> [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Obtain SSO token using 
> username/password credentials]
> [ INFO  ] ok: [localhost]
> [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Wait for the host to be up]
> [ INFO  ] ok: [localhost]
> [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Notify the user about a 
> failure]
> [ INFO  ] skipping: [localhost]
> [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Set host_id]
> [ INFO  ] ok: [localhost]
> [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Collect error events from 
> the Engine]
> [ INFO  ] ok: [localhost]
> [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Generate the error message 
> from the engine events]
> [ INFO  ] ok: [localhost]
> [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Notify with error 
> description]
> [ INFO  ] ok: [localhost]
> [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Notify with generic error]
> [ INFO  ] skipping: [localhost]
> [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Let the user connect to the 
> bootstrap engine to manually fix host configuration]
> [ INFO  ] ok: [localhost]
> [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks]
> [ INFO  ] ok: [localhost]
> [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file]
> [ INFO  ] changed: [localhost -> localhost]
> [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until 
> /tmp/ansible.volt5pvv_he_setup_lock is removed, delete it once ready to 
> proceed]
> ~~~
> 
> I didn't ask for script to pause, so I need to ask: Is this normal?

No. I guess you did ask for that, maybe by mistake. The default is not to pause.
can you get to webadmin now and confirm th host state?
and/or just remove that file and let it continue...

Thanks,
michal

> 
> I'm about to have a look at the logs, but its late here at the moment so I 
> wanted to get this up on the mailing lists so I don't loose too much time 
> while I'm asleep and everyone else is awake (& vice-versa).
> 
> Cheers
> 
> Dulux-Oz
> ___
> 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/AZ7W7J6ANA3MELNTQBRACNCDFQXOUEXU/
___
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/K65LOFFTREYJ2AAQ6Y437AERROOTC6CL/

[ovirt-users] Re: Question: How does ovirt storage domain differ from VMFS?

[Michal Skrivanek]

> On 3. 10. 2022, at 2:13, jstk...@gmail.com wrote:
> 
> Hello,
> 
> I was asked the other day what file system oVirt uses to store virtual 
> machine images and how it differed from VMware VMFS. I had to admit that I 
> didn't quite understand this aspect of oVirt. I've had a look around but 
> haven't found an answer. I was wondering if someone could explain at a high 
> level, how the underlying oVirt VM storage domain differs from VMFS? What 
> file system is used? Does it use a file system at all? 

oVirt supports three types of storage
file-based where there are ordinary files on a posix filesystem, NFS, etc..
block storage domains are using LVM volumes for disks, there's no filesystem, 
VM disks are LVs.
managed domains - storage operations are offloaded to Cinderlib with Ceph 
backend.

Thanks,
michal

> 
> Thank you.
> ___
> 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/IK74O6MBFY2VGFJPDSQYNAK74JLZLNU4/
___
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/OZ3SQXNRT54M5XFDI3VPKLLLRKXJ2RHD/

[ovirt-users] Re: noVNC console doesn't work.

[Michal Skrivanek]

There's been no interesting change between these versions. I would rather 
suspect certificates...can you try in brand new browser sessions and make sure 
the engine CA is imported?


> On 3. 10. 2022, at 13:40, Jirka Simon  wrote:
> 
> Hello there, 
> 
> after update from 4.5.2.4 to 4.5.2.5  stopped to work noVNC client within 
> browser,  it writes  Something went wrong, connection is closed in browser 
> and then i th engine log is this message.
> 
> 2022-10-03 13:34:55,772+02 INFO  
> [org.ovirt.engine.core.utils.servlet.ServletUtils] (default task-13) [] Can't 
> read file '/usr/share/ovirt-engine/files/novnc/vendor/promise.js' for request 
> '/ovirt-engine/services/files/novnc/vendor/promise.js' -- 404
> 
> thank k you for any advice.
> 
> 
> 
> Jirka
> 
> ___
> 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/Y325XTSQAEEYR7C3NNWR32TJ4DMYQDBQ/

___
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/K3CKDHAZKCJGAGQANF3KRLB3BHJNKS2U/

[ovirt-users] Re: QXL vs VGA

[Michal Skrivanek]

> On 23. 9. 2022, at 11:48, Andrea Chierici  
> wrote:
> 
> Hi,
> I've done some investigation and discovered that the problem seems related to 
> the engine ca not installed in my windows machine keychain.
> Anyway even if I installed the cert, the classic console.vv file continue to 
> complain with failed handshake; on the other hand, on the browser I can open 
> novnc consoles, if I install the engine ca on it.
> I can survive with novnc, but a recipe for remote-viewer + windows systems 
> could be useful, I bet, not only for me.

spice was able to use CA passed within the .vv file, but VNC implementation in 
remote-viewer does not understand it. 
You need to import the correct CA into your client's keystore. Wherever it is 
in Windows

Thanks,
michal

> Thanks,
> 
> Andrea
> 
> On 21/09/2022 12:43, Andrea Chierici wrote:
>> Dear all,
>> on latest 4.5, as many others have noticed, default is to use video type VGA 
>> and VNC as graphics protocol.
>> Problem is, in my current environments, I can't seem to make this to work.
>> When the machine power ups I get the "usual" error from virt-viewer:
>> 
>> 
>> 
>> I found some docs on the web, like this from redhat: 
>> https://access.redhat.com/solutions/5695951 
>> 
>> but it does not seem to work. Indeed I reinstalled a host and forced the 
>> creation of the vm on it, but the console is still unreachable.
>> Any hint how I can solve this? I am quite surprised I could not find 
>> anything on standard documentation.
>> Thanks,
>> 
>> Andrea
>> 
>> -- 
>> Andrea Chierici - INFN-CNAF  
>> Viale Berti Pichat 6/2, 40127 BOLOGNA
>> Office Tel: +39 051 2095463  
>> SkypeID ataruz
>> --
>> 
>> 
>> ___
>> 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/ENND7DOL6R3JVZSFUQYLCWAE5ZNL2JMY/
>>  
>> 
> 
> -- 
> Andrea Chierici - INFN-CNAF   
> Viale Berti Pichat 6/2, 40127 BOLOGNA
> Office Tel: +39 051 2095463   
> SkypeID ataruz
> --
> ___
> 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/MGWSBOFY4RIDNEHK6SYTZJWGDDRMZ5AJ/

___
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/F6X5DZL34GRKAORXSTTUQXJLAEYJZ4FF/

[ovirt-users] Re: oVirt bug reports to move from bugzilla to github issues in future

[Michal Skrivanek]

Hi all,
I'm planning to close bugzilla for new submissions today. Please use GitHub 
issues (even if a README says otherwise, until we update all of them:)
Existing bugs are not affected

Thanks,
michal

> On 6. 9. 2022, at 15:56, Michal Skrivanek  wrote:
> 
> Hi all,
> as a final stage of out gerrit to github transition that started ~9 months 
> ago we are planning to eliminate the use of bugzilla.redhat.com for all oVirt 
> projects (bugs with Classification: "oVirt") and use the native issue 
> tracking in github as well. We used to have integrations with gerrit and 
> bugzilla that we moved to github actions instead, and the overhead (and 
> notorious slowness) of bugzilla.redhat.com becomes the only "benefit" of 
> using it these days.
> There's about 50 bugs total left in oVirt bugzilla so it's not that much to 
> move, the biggest change would be that the new bugs are to be filed elsewhere.
> 
> This is just a heads up for now, we haven't set a cut off date just yet, but 
> you can expect this change in the coming weeks.
> 
> Thanks,
> michal
___
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/K6TAON66Y56QSZ4OLD357PYGCDKBWUCX/

[ovirt-users] oVirt bug reports to move from bugzilla to github issues in future

[Michal Skrivanek]

Hi all,
as a final stage of out gerrit to github transition that started ~9 months ago 
we are planning to eliminate the use of bugzilla.redhat.com for all oVirt 
projects (bugs with Classification: "oVirt") and use the native issue tracking 
in github as well. We used to have integrations with gerrit and bugzilla that 
we moved to github actions instead, and the overhead (and notorious slowness) 
of bugzilla.redhat.com becomes the only "benefit" of using it these days.
There's about 50 bugs total left in oVirt bugzilla so it's not that much to 
move, the biggest change would be that the new bugs are to be filed elsewhere.

This is just a heads up for now, we haven't set a cut off date just yet, but 
you can expect this change in the coming weeks.

Thanks,
michal
___
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/BF7EU23GWOZSLKBTXEYQFLGHZHL6WSAN/

[ovirt-users] Re: Q: Engione 4.4.10 and New Host on CentOS Stream 9

[Michal Skrivanek]

> On 28. 8. 2022, at 18:52, Andrei Verovski  wrote:
> 
> Hi,
> 
> I have engine version 4.4.10.7-1.el8, is it possible to set up new node host 
> on CentOS Stream 9, or I need to upgrade engine to version 4.5 first (which 
> is not right now possible because of some quite old nodes) ?

yes, you generally need the latest version
You can keep your old nodes old, 4.2 based nodes are still working with 4.5

> 
> Thanks
> Andrei
> ___
> 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/IC3ZW2XY7BAEAU3H72P4VA76Y63F32XU/
___
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/RMZIFKMW2EKY2YLAWR2LUMURGEXJD4VZ/

[ovirt-users] Re: (no subject)

[Michal Skrivanek]

> On 26. 8. 2022, at 17:37, parallax  wrote:
> 
> I need to switch the host into maintenance mode but without stopping VMs

why? you shouldn't do that, it's not that easy to make sure everything picks up 
the new certificates.
in 4.5.1+ you can re-enroll certificates in unresponsive state too, but ^^.

> VM is not checked as "HA available" and selected "manual migration only" in 
> options
> If I do manual fencing to the host (confirm host has been rebooted) will the 
> VM automatically start on another host ?

if they are not HA they won't.

> 
> ср, 24 авг. 2022 г. в 14:15, parallax  >:
> I had to add a new server into the datacenter and the StorageDomains status 
> back to normal and the error is gone
> but I still have hosts that haven't valid certificates
> putting host into maintenance mode is the only way to update the certificate ?
> 
> пн, 22 авг. 2022 г. в 13:31, Strahil Nikolov  >:
> Are you able to set a host into maintenance?
> If yes, then you should be able to Hosts -> select host -> Installation -> 
> Enroll Certificate
> 
> Best Regards,
> Strahil Nikolov 
> 
> On Mon, Aug 22, 2022 at 10:30, parallax
> mailto:dd432...@gmail.com>> wrote:
> no vdsm errors on hosts side 
> but I see vdsmcert.pem has expired on each hosts in the datacenter 
> and there were no warning to me about certs expiration beginning
> 
> it is possible to update the certificate without stopping the server ?
> 
> сб, 20 авг. 2022 г. в 18:27, Strahil Nikolov  >:
> Check the vdsm logs on all hosts to get a clue why this is happening.
> 
> P.S.: Next time consider adding a subject.
> 
> Best Regards,
> Strahil Nikolov 
> 
> On Sat, Aug 20, 2022 at 17:23, parallax
> mailto:dd432...@gmail.com>> wrote:
> oVirt version:4.4.4.7-1.el8
> 
> I have several servers in cluster and I got this error:
> 
> Data Center is being initialized, please wait for initialization to complete.
> VDSM command GetStoragePoolInfoVDS failed: PKIX path validation failed: 
> java.security.cert.CertPathValidatorException: validity check failed
> 
> the SPM role is constantly being transferred to the servers and I can't do 
> anything
> 
> in StorageDomains storages are in inactive status but virtual machines are 
> runnig
> 
> how ti 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/P6MGHC2NU3BDQ7DJSER2VH757C2Y5YKJ/
>  
> 
> ___
> 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/WOVV6HJLSIRDLUTCYBLJCWCNMBMK73LF/
>  
> 
___
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/EFN27PE3CYWHQAFBY3AJ3NFTAHFJCYUO/

[ovirt-users] Re: oVirt 4.5.2 new ISO uploads are not usable

[Michal Skrivanek]

> On 23. 8. 2022, at 17:42, Christoph Timm  wrote:
> 
> Hi Michal,
> 
> yes this is the issue I'm facing.
> Do you require any information from my setup for the ticket?

no, I think it's clear, just needs to be fixed:)

> 
> The download is also behaving differently between old and newly uploaded ISOs 
> on the data domain.
> 
> old: filename.iso.raw
> new: filename.iso.qcow2
> 
> Best regards
> Christoph
> 
> Am 23.08.22 um 17:34 schrieb Michal Skrivanek:
>> 
>> 
>>> On 23. 8. 2022, at 15:38, Christoph Timm >> <mailto:ov...@timmi.org>> wrote:
>>> 
>>> Hi list,
>>> 
>>> we have uploaded new ISO files to our data domain which we are using for 
>>> ISO images and found out that we cannot boot from these ISO.
>>> Older ISOs are still working but no new one.
>>> 
>>> I have not really any idea what to check and where to look so any kind of 
>>> help would be really appreciated.
>> 
>> Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=2120228 
>> <https://bugzilla.redhat.com/show_bug.cgi?id=2120228>
>> 
>> i don't know if there's any easy workaround. What I ended up doing was 
>> create ISO domain instead and place the files into the NFS directory manually
>> 
>> Thanks,
>> michal
>> 
>>> 
>>> Best regards
>>> Christoph
>>> ___
>>> Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
>>> To unsubscribe send an email to users-le...@ovirt.org 
>>> <mailto:users-le...@ovirt.org>
>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html 
>>> <https://www.ovirt.org/privacy-policy.html>
>>> oVirt Code of Conduct: 
>>> https://www.ovirt.org/community/about/community-guidelines/ 
>>> <https://www.ovirt.org/community/about/community-guidelines/>
>>> List Archives: 
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/5MPQNCFRW3PFPNB252DP5M34XRSLG2A2/
>>>  
>>> <https://lists.ovirt.org/archives/list/users@ovirt.org/message/5MPQNCFRW3PFPNB252DP5M34XRSLG2A2/>
>> 
> 

___
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/HVOTIXMAXFHYHV6H4SPRPJ5LDUHSWZOU/

[ovirt-users] Re: oVirt 4.5.2 new ISO uploads are not usable

[Michal Skrivanek]

> On 23. 8. 2022, at 15:38, Christoph Timm  wrote:
> 
> Hi list,
> 
> we have uploaded new ISO files to our data domain which we are using for ISO 
> images and found out that we cannot boot from these ISO.
> Older ISOs are still working but no new one.
> 
> I have not really any idea what to check and where to look so any kind of 
> help would be really appreciated.

Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=2120228 


i don't know if there's any easy workaround. What I ended up doing was create 
ISO domain instead and place the files into the NFS directory manually

Thanks,
michal

> 
> Best regards
> Christoph
> ___
> 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/5MPQNCFRW3PFPNB252DP5M34XRSLG2A2/

___
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/2ENDOUPDKF5XKS4SOOBSDXJ7IFBRUBGP/

[ovirt-users] Re: Failed to delete snapshot

[Michal Skrivanek]

> On 23. 8. 2022, at 10:53, Andrei Verovski  wrote:
> 
> Hi,
> 
> I had same problem with VM of our accounting / stock control system, which is 
> a top priority which can’t be down no matter what.
> 
> Solution: Make a new snapshot on problematic VM, then make a new VM from that 
> snapshot. This is only a workaround I found so far.

Make sure you run latest version, there were plenty of live merge bugs solved 
in the last months.
Also if you're using vProtect you can likely use the new incremental 
backup(CBT) feature, that avoids all the snapshotting in the first place.

> 
> 
> 
>> On 23 Aug 2022, at 10:50, Jirka Simon > > wrote:
>> 
>> Hello there. 
>> 
>> we have troubles with one VM ad it's snapshot 
>> 
>> here is  short log  from engine.log
>> 
>> 2022-08-23 09:02:38,735+02 INFO  
>> [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] 
>> (EE-ManagedThreadFactory-engine-Thread-1265784) 
>> [4d79272b-ffac-4b2b-a987-8c19577cd8c4] CommandAsyncTask::
>> HandleEndActionResult [within thread]: Removing CommandMultiAsyncTasks 
>> object for entity '5842cafc-60d4-4131-8da1-8a909123f08c' 
>> 2022-08-23 09:02:41,435+02 ERROR 
>> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand] 
>> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-68) 
>> [4d79272b
>> -ffac-4b2b-a987-8c19577cd8c4] Command id: 
>> 'ead3fbba-7439-4337-8aaf-1d6cf65bbb15 failed child command status for step 
>> 'REDUCE_IMAGE' 
>> 2022-08-23 09:02:41,435+02 INFO  
>> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommandCallback]
>>  (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-68) [
>> 4d79272b-ffac-4b2b-a987-8c19577cd8c4] Command 'RemoveSnapshotSingleDiskLive' 
>> id: 'ead3fbba-7439-4337-8aaf-1d6cf65bbb15' child commands 
>> '[5b33d970-6ea0-4b8b-bc31-607afd8af1ca, 185d3fec-8c76-
>> 44d3-a0a1-fe8fff331354, 308baf9d-1fc5-43a1-a624-b5f08f7bec1b, 
>> f11f3550-4356-417e-af10-a3afb2051dec, 5842cafc-60d4-4131-8da1-8a909123f08c]' 
>> executions were completed, status 'FAILED' 
>> 2022-08-23 09:02:42,445+02 ERROR 
>> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand] 
>> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-79) 
>> [4d79272b
>> -ffac-4b2b-a987-8c19577cd8c4] Merging of snapshot 
>> '6634db4e-23d8-4849-a008-864f15d28c3d' images 
>> 'd24a9199-741b-49cb-96d2-0d76fcd21f48'..'48af3301-0cbb-4a6e-97d1-7299e7de883f'
>>  failed. Images
>> have been marked illegal and can no longer be previewed or reverted to. 
>> Please retry Live Merge on the snapshot to complete the operation. 
>> 2022-08-23 09:02:42,451+02 ERROR 
>> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand] 
>> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-79) 
>> [4d79272b
>> -ffac-4b2b-a987-8c19577cd8c4] Ending command 
>> 'org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand' 
>> with failure. 
>> 2022-08-23 09:02:42,457+02 INFO  
>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] 
>> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-79) 
>> [4d79272b-ffac
>> -4b2b-a987-8c19577cd8c4] Command 'RemoveSnapshot' id: 
>> '73340ac8-07d7-4de2-bfeb-8062fa1e8cfd' child commands 
>> '[ead3fbba-7439-4337-8aaf-1d6cf65bbb15]' executions were completed, status 
>> 'FAILE
>> D' 
>> 2022-08-23 09:02:43,470+02 ERROR 
>> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand] 
>> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-22) 
>> [4d79272b-ffac-4b2b-a98
>> 7-8c19577cd8c4] Ending command 
>> 'org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand' with failure. 
>> 2022-08-23 09:02:43,490+02 ERROR 
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-22) 
>> [4d79272b-ff
>> ac-4b2b-a987-8c19577cd8c4] EVENT_ID: 
>> USER_REMOVE_SNAPSHOT_FINISHED_FAILURE(357), Failed to delete snapshot 
>> 'vProtect 2022-08-05 22:33:44.088143' for VM 'web1.wiki.prod.hq.sldev.cz 
>> -2'.
>> 
>> 
>> 
>> Snapshot can't be deleted, and VM is not possible to clone. 
>> 
>> 
>> 
>> thank you for any help. 
>> 
>> 
>> 
>> Jirka
>> 
>> ___
>> 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/ZOVL22OGZKEG6BXPEB5JQUXX2GXDA2GD/
>>  
>> 
> 

[ovirt-users] Re: oVirt 4.5.1 is now generally available

[Michal Skrivanek]

> On 1. 7. 2022, at 15:38, Diego Ercolani  wrote:
> 
> In data venerdì 1 luglio 2022 15:36:34 CEST, Michal Skrivanek ha scritto:
>> yes, but beware el9 host support is still experimental, there might be repo
>> or dependency issues from time to time . Feature-wise it's complete and
>> entirely on par with el8, except for SPICE support that's been dropped in
>> el9.
> also kvdo tools aren't present I rolled back to el8

which tools, on what OS?

> 
> 
> -- 
> Ing. Diego Ercolani
> S.S.I.S. s.p.a.
> T. 0549-875910
> 
___
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/HNCNOVBNAKWRF5IRQOWDXE242VPUPJ62/

[ovirt-users] Re: oVirt 4.5.1 is now generally available

[Michal Skrivanek]

> On 30. 6. 2022, at 7:54, Yedidyah Bar David  wrote:
> 
> On Wed, Jun 29, 2022 at 10:26 PM Diego Ercolani  
> wrote:
>> 
>> As there is Centos8 and Centos9 4.5.1 is it possible to mix centos8 and 
>> Centos9 in a single cluster?

yes, but beware el9 host support is still experimental, there might be repo or 
dependency issues from time to time . Feature-wise it's complete and entirely 
on par with el8, except for SPICE support that's been dropped in el9.

> 
> Not sure about the status of 9 support, adding Martin.
> 
> Best regards,
> -- 
> Didi
> ___
> 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/MFN3J454HYCVEX7TBWQJOWHUFPJ5T6ND/
___
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/X32IQXW3GCYLNBSZR4C4KER5BZAFYRBO/

[ovirt-users] Re: Need to transfer a VM from oVirt to vSphere

[Michal Skrivanek]

> On 24. 6. 2022, at 11:58, Gianluca Cecchi  wrote:
> 
> Hello,
> I need to transfer a VM from oVirt 4.4 to vSphere.
> I see that the "Export as OVA" in the GUI exports in a format compatible with 
> oVirt but not vSphere.
> Any hint? 
> Any way to easily convert the oVirt generated OVA to a vSPhere compatible one?

not that i know of. it depends on how resilient is vmware's ova import ... but 
if it is a single or a few vms then you can give up on settings and just import 
raw disks?

> 
> 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/PPRS47O346Q3THFPEWYOJFPWEXN6P2R2/
___
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/YHMDBEVB6ONHRNYFBJ7KA7JOUQURZLVV/

[ovirt-users] Re: can't use vmconsole anymore

[Michal Skrivanek]

> On 13. 6. 2022, at 11:42, Guillaume Pavese 
>  wrote:
> 
> I think that I am progressing in troubleshooting.
> it seems like the certificates for the vmconsole-proxy were not renewed like 
> the other certificates during engine-setup --upgrade
> 
> [root@vs-inf-prd-ovt-fr-501 ~]# openssl x509 -in 
> /etc/pki/ovirt-engine/certs/vmconsole-proxy-helper.cer -noout -text | grep Not
> Not Before: Mar 30 04:48:40 2021 GMT
> Not After : May  3 04:48:40 2022 GMT
> [root@vs-inf-prd-ovt-fr-501 ~]# openssl x509 -in 
> /etc/pki/ovirt-engine/certs/vmconsole-proxy-host.cer -noout -text | grep Not
> Not Before: Mar 30 04:48:41 2021 GMT
> Not After : May  3 04:48:41 2022 GMT
> [root@vs-inf-prd-ovt-fr-501 ~]# openssl x509 -in 
> /etc/pki/ovirt-engine/certs/vmconsole-proxy-user.cer -noout -text | grep Not
> Not Before: Mar 30 04:48:41 2021 GMT
> Not After : May  3 04:48:41 2022 GMT
> 
> What is the proper procedure to renew these certificates?

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

remove them and rerun engine-setup it should recreate them


> 
> Guillaume Pavese
> Ingénieur Système et Réseau
> Interactiv-Group
> 
> 
> On Mon, Jun 13, 2022 at 6:23 PM Guillaume Pavese 
>  > wrote:
> Thanks for your answer, I checked but I am still stuck :
> 
> I confirm that the servlet can be reached, according to your recommended test 
> (Method Not Allowed.):
> 
> [root@vs-inf-prd-ovt-fr-501 ~]# wget 
> https://localhost:443/ovirt-engine/services/vmconsole-proxy 
>  
> --no-check-certificate
> --2022-06-13 10:30:11--  
> https://localhost/ovirt-engine/services/vmconsole-proxy 
> 
> Resolving localhost (localhost)... ::1, 127.0.0.1
> Connecting to localhost (localhost)|::1|:443... connected.
> The certificate's owner does not match hostname 'localhost'
> HTTP request sent, awaiting response... 405 Method Not Allowed
> 2022-06-13 10:30:11 ERROR 405: Method Not Allowed.
> 
> I retried ovirt-vmconsole-list.py with "--debug", and looked at the logs : 
> 
> [root@vs-inf-prd-ovt-fr-501 ~]# 
> /usr/libexec/ovirt-vmconsole-proxy-helper/ovirt-vmconsole-list.py --debug 
> --version "1" keys
> [root@vs-inf-prd-ovt-fr-501 ~]# 
> [root@vs-inf-prd-ovt-fr-501 ~]# grep vmconsole /var/log/messages
> Jun 13 10:35:41 vs-inf-prd-ovt-fr-501 journal[3112274]: 2022-06-13 
> 10:35:41,222+0200 ovirt-vmconsole-list: ERROR main:265 Error: HTTP Error 403: 
> Forbidden
> 
> To be noted,
> We did change the engine's CA certificate at some point by following this 
> procedure 
> https://ovirt.org/documentation/administration_guide/index.html#Replacing_the_Manager_CA_Certificate
>  
> 
> We also renewed the certificates during a standard engine --setup upgrade to 
> 4.4.10
> 
> 
> 
> Guillaume Pavese
> Ingénieur Système et Réseau
> Interactiv-Group
> 
> 
> On Mon, Jun 13, 2022 at 4:47 PM Radoslaw Szwajkowski  > wrote:
> Hi,
> the first thing to check is the firewall:  check with wget if the
> servlet can be reached (method not allow error means you have
> connected)
> 
> wget localhost:8080/ovirt-engine/services/vmconsole-proxy
> HTTP request sent, awaiting response... 405 Method Not Allowed
> 2022-06-13 09:36:48 ERROR 405: Method Not Allowed.
> 
> When using the ovirt-vmconsole-list you can also check system log[1]
> i.e. if the server cannot be reached you should see sth like this
> 
> grep vmconsole  /var/log/messages
> Jun 13 08:58:02 developer journal[2972]: 2022-06-13 08:58:02,992+0200
> ovirt-vmconsole-list: ERROR main:265 Error:  Connection refused>
> 
> Note also that you can increase the log level by passing "--debug"
> param or just look inside the script.
> 
> best regards,
> radek
> 
> [1] https://github.com/oVirt/ovirt-vmconsole#problem-determination 
> 
> 
> On Mon, Jun 13, 2022 at 8:22 AM Guillaume Pavese
>  > wrote:
> >
> > Hello everyone,
> >
> > We have the same problem on our oVirt 4.4.10 Production server.
> > ssh connection to vmconsole@engine was previously working in 4.4.6. but it 
> > stopped working at some point, maybe since upgraded to 4.4.10
> >
> > contrary to a working test environment that was directly installed on 
> > 4.4.10,
> > And as for Nathanaël,
> > the following returns nothing : ovirt-vmconsole-list.py --version "1" keys
> >
> > [root@vs-inf-prd-ovt-fr-501 ~]# 
> > /usr/libexec/ovirt-vmconsole-proxy-helper/ovirt-vmconsole-list.py --version 
> > "1" keys
> > [root@vs-inf-prd-ovt-fr-501 ~]#
> >
> > I have verified that the keys stills appear on users' Option -> "User's 
> > Public Key" in the engine's UI
> >
> > What can I try to fix this?
> >
> >
> 

[ovirt-users] Re: can't use vmconsole anymore

[Michal Skrivanek]

> On 13. 6. 2022, at 11:23, Guillaume Pavese 
>  wrote:
> 
> Thanks for your answer, I checked but I am still stuck :
> 
> I confirm that the servlet can be reached, according to your recommended test 
> (Method Not Allowed.):
> 
> [root@vs-inf-prd-ovt-fr-501 ~]# wget 
> https://localhost:443/ovirt-engine/services/vmconsole-proxy 
>  
> --no-check-certificate
> --2022-06-13 10:30:11--  
> https://localhost/ovirt-engine/services/vmconsole-proxy 
> 
> Resolving localhost (localhost)... ::1, 127.0.0.1
> Connecting to localhost (localhost)|::1|:443... connected.
> The certificate's owner does not match hostname 'localhost'
> HTTP request sent, awaiting response... 405 Method Not Allowed
> 2022-06-13 10:30:11 ERROR 405: Method Not Allowed.
> 
> I retried ovirt-vmconsole-list.py with "--debug", and looked at the logs : 
> 
> [root@vs-inf-prd-ovt-fr-501 ~]# 
> /usr/libexec/ovirt-vmconsole-proxy-helper/ovirt-vmconsole-list.py --debug 
> --version "1" keys
> [root@vs-inf-prd-ovt-fr-501 ~]# 
> [root@vs-inf-prd-ovt-fr-501 ~]# grep vmconsole /var/log/messages
> Jun 13 10:35:41 vs-inf-prd-ovt-fr-501 journal[3112274]: 2022-06-13 
> 10:35:41,222+0200 ovirt-vmconsole-list: ERROR main:265 Error: HTTP Error 403: 
> Forbidden
> 
> To be noted,
> We did change the engine's CA certificate at some point by following this 
> procedure 
> https://ovirt.org/documentation/administration_guide/index.html#Replacing_the_Manager_CA_Certificate
>  
> 
> We also renewed the certificates during a standard engine --setup upgrade to 
> 4.4.10

hm, that might be related

the helpwer needs to work first before trying to see about user keys...
IIRC what it's supposed to do is to connect to engine' servlet at 
ENGINE_BASE_URL using ENGINE_CA from 
/etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf

Normally it should point to apache-ca.pem that's the same one used for web ui. 
And it's the one you replace with your own. Maybe permissions are wrong that 
vmconsole can't read it or something?
Can you check that?

Thanks,
michal
> 
> 
> 
> Guillaume Pavese
> Ingénieur Système et Réseau
> Interactiv-Group
> 
> 
> On Mon, Jun 13, 2022 at 4:47 PM Radoslaw Szwajkowski  > wrote:
> Hi,
> the first thing to check is the firewall:  check with wget if the
> servlet can be reached (method not allow error means you have
> connected)
> 
> wget localhost:8080/ovirt-engine/services/vmconsole-proxy
> HTTP request sent, awaiting response... 405 Method Not Allowed
> 2022-06-13 09:36:48 ERROR 405: Method Not Allowed.
> 
> When using the ovirt-vmconsole-list you can also check system log[1]
> i.e. if the server cannot be reached you should see sth like this
> 
> grep vmconsole  /var/log/messages
> Jun 13 08:58:02 developer journal[2972]: 2022-06-13 08:58:02,992+0200
> ovirt-vmconsole-list: ERROR main:265 Error:  Connection refused>
> 
> Note also that you can increase the log level by passing "--debug"
> param or just look inside the script.
> 
> best regards,
> radek
> 
> [1] https://github.com/oVirt/ovirt-vmconsole#problem-determination 
> 
> 
> On Mon, Jun 13, 2022 at 8:22 AM Guillaume Pavese
>  > wrote:
> >
> > Hello everyone,
> >
> > We have the same problem on our oVirt 4.4.10 Production server.
> > ssh connection to vmconsole@engine was previously working in 4.4.6. but it 
> > stopped working at some point, maybe since upgraded to 4.4.10
> >
> > contrary to a working test environment that was directly installed on 
> > 4.4.10,
> > And as for Nathanaël,
> > the following returns nothing : ovirt-vmconsole-list.py --version "1" keys
> >
> > [root@vs-inf-prd-ovt-fr-501 ~]# 
> > /usr/libexec/ovirt-vmconsole-proxy-helper/ovirt-vmconsole-list.py --version 
> > "1" keys
> > [root@vs-inf-prd-ovt-fr-501 ~]#
> >
> > I have verified that the keys stills appear on users' Option -> "User's 
> > Public Key" in the engine's UI
> >
> > What can I try to fix this?
> >
> >
> > Guillaume Pavese
> > Ingénieur Système et Réseau
> > Interactiv-Group
> >
> >
> > On Mon, May 10, 2021 at 9:47 PM Nathanaël Blanchet  > > wrote:
> >>
> >> Hi,
> >>
> >> I can't still connect to my vms with vmconsole proxy on my production 
> >> engine (other test and dev engine are OK).
> >>
> >> the ssh key for the wanted user is available in the the API:
> >>
> >> 
> >>  >> href="/ovirt-engine/api/users/64b7f3bf-9d43-4508-af93-63ad77652be3/sshpublickeys/aaace8d4-08d3-4452-ac91-df4b491bd899"
> >>  id="aaace8d4-08d3-4452-ac91-df4b491bd899">
> >> 
> >> ssh-rsa 
> >> 

[ovirt-users] Re: Cluster CPU Type

[Michal Skrivanek]

> On 18. 5. 2022, at 1:11, Colin Coe  wrote:
> 
> Hi all
> 
> I'm just putting in some new servers to be used as hosts in RHV 4.3 (soon to 
> go to v4.4 or v4.5) but I'm having problems with the cluster CPU.
> 
> These are HPE DL360 Gen10 with "Xeon Gold 6338N".  Google tells me these are 
> "Ice Lake" but RHV complains unless I set the cluster CPU type to 
> "SandyBridge".
> 
> Is this expected?  What do I need to do to get these recognised as the corect 
> CPU type?

Hi,
4.3 doesn't support Ice Lake, you'd need oVirt/RHV 4.4 and a 4.5 cluster level.
You may also be missing microcode updates for some of the security 
vulnerabilities

Thanks,
michal
> 
> Thanks
> 
> CC
> ___
> 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/MVARZPDJABDS7OPOX3KP6ZRGPMAVTAMA/
___
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/MYBZONN5BLM7LRHECDM2ANYSNBTN4OFA/

[ovirt-users] Re: [ovirt-announce] Async release for ovirt-engine (4.5.0.7) is now available

[Michal Skrivanek]

> On 10. 5. 2022, at 13:04, Lev Veyde  wrote:
> 
> The oVirt Team has just released a new version of ovirt-engine package
> (4.5.0.7) that fixes a few important bugs:

It's worth mentioning that 4.5.0.8 should follow shortly and should fix the 
compatibility with new postgresql-jdbc so that people don't have to downgrade

> 
> - Bug 2066084  > - vmconsole-proxy-user certificate 
> expired - cannot access serial console
> 
> - Bug 2079799  > - issue the internal Certificate 
> Authority for 20 years
> 
> - Bug 2079835  > - Separate validity length of Apache 
> and internal certificates
> 
> - Bug 2079890  > - renew certificates sooner before 
> they expire
> 
> - Bug 2079901  > - allow Enroll Certificate action when 
> host is Non Responsive
> 
> 
> The update is already available on resources.ovirt.org 
>  and should land on
> oVirt mirrors within 24 hours.
> 
> Thanks in advance,
> -- 
> 
> LEV VEYDE
> SENIOR SOFTWARE ENGINEER, RHCE | RHCVA | MCITP
> Red Hat Israel
> 
>  
> l...@redhat.com  | lve...@redhat.com 
>   
> TRIED. TESTED. TRUSTED. 
> ___
> Announce mailing list -- annou...@ovirt.org
> To unsubscribe send an email to announce-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/annou...@ovirt.org/message/FXUKS4J2YF6E2QJPFDWVZV5XFMEYX7X7/

___
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/3A6TRFCXEHF3D2CNPWWYO7OVGAWVUZIJ/

[ovirt-users] Re: ovirt 4.5.0 - template Issue

[Michal Skrivanek]

> On 22. 4. 2022, at 12:18, Winfried de Heiden  wrote:
> 
> Hi all,
> 
> For some reason, I am not able to create or import tempates. Creating a 
> template from an existing VM (using the UI) will result in the ui.log:
> 
> 2022-04-22 10:45:30,273+02 ERROR 
> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default 
> task-13) [] Permutation name: 1EBF700FBD4B5CDF0BCDABD7F03C4FA9
> 2022-04-22 10:45:30,273+02 ERROR 
> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default 
> task-13) [] Uncaught exception: 
> com.google.gwt.core.client.JavaScriptException: (TypeError) : Cannot read 
> properties of undefined (reading 'a')
> 
> Trying to import a template will result in ui.log:
> 
> 2022-04-22 12:17:02,383+02 ERROR 
> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default 
> task-20) [] Permutation name: 45A889347BD114EA48B9B9409FF70ADC
> 2022-04-22 12:17:02,383+02 ERROR 
> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default 
> task-20) [] Uncaught exception: 
> com.google.gwt.core.client.JavaScriptException: (TypeError) : e is null
> 
> New bug? Anyone?
> 

could be, but it would help to include more logs. 
feel free to open one and add full engine.log and describe the hostory of that 
setup and VM, upgrade, from which versions, etc.

> Winfried
> 
> 
> 
> 
> 
> 
> 
> ___
> 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/EJC6WWUKMMN2GMI32J2CBPHF5OH7XHHV/

___
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/OOFUPWMDAECS6PJMAD6MPXVQBLIYUX2H/

[ovirt-users] Re: Big problem on Ovirt 4.4

[Michal Skrivanek]

> On 24. 3. 2022, at 18:38, Nenhum de Nos via Users  wrote:
> 
> Hi,
> 
> I run a small test node and engine of ovirt since 4.3. Its in my home, but I 
> kind messed up and now I can't use or reinstall it without loosing all my 
> vm's data (at least this is the point my knowledge of ovirt is).
> 
> I got the issue where I could not update yum since CentOS 8 mirrors would not 
> answer. And I tried some solution I found in the list archives, and got 
> really bad here.

Hi,
well, CentOS 8 doesn't exist anymore, you would have to switch to 8-stream

> 
> I had a power outage last Saturday and my node got to nonresponsive. No 
> matter what I did, never left this state. Kept complaining about the CPU 
> Type, I run it on Ryzen 3400G (used to run on Intel i5, also desktop CPU, and 
> never had an issue, when I changed to Ryzen, every outage from power here is 
> a problem), and the node wouldn't come back. So I tried to upgrade my cluster 
> to 4.4 level (was 4.3) and it didn't help. So I tried to get back to 4.3 and 
> a message said just empty clusters could do that. I then removed my ryzen 
> node from it and it got back to 4.3.
> But now I could not install the node. I tried changing its name, no good. 
> Failed on how to get packages from GLuster8 repo.
> That is where my story got sad. I tried to update my repo using the steps in 
> the last post from 
> https://lists.ovirt.org/archives/list/users@ovirt.org/thread/D3FEXQ5KOLN3SST3MPGIHSCEF52IBTKY/
>  
> .
>  Bad idea, and another one was I didn't do a backup of the engine.
> 
> Now my engine won't start, the backup won't run:
> 
> engine-backup --mode=backup --file=/root/backup_deuruim 
> --log=/root/backup_deuruim.log
> Start of engine-backup with mode 'backup'
> scope: all
> archive file: /root/backup_deuruim
> log file: /root/backup_deuruim.log
> Backing up:
> Notifying engine
> Notifying engine
> FATAL: Failed notifying engine
> 
> pg_dump: error: Dumping the contents of table "audit_log" failed: 
> PQgetResult() failed.
> pg_dump: error: Error message from server: ERROR:  MultiXactId 1076887572 has 
> not been created yet -- apparent wraparound
> pg_dump: error: The command was: COPY public.audit_log (audit_log_id, 
> user_id, user_name, vm_id, vm_name, vm_template_id, vm_template_name, vds_id, 
> vds_name, log_time, log_type_name, log_type, severity, message, processed, 
> storage_pool_id, storage_pool_name, storage_domain_id, storage_domain_name, 
> cluster_id, cluster_name, correlation_id, job_id, quota_id, quota_name, 
> gluster_volume_id, gluster_volume_name, origin, custom_event_id, 
> event_flood_in_sec, custom_data, deleted, call_stack, brick_id, brick_path, 
> custom_id) TO stdout;
> 2022-03-24 13:16:10 3461: FATAL: Database engine backup failed
> 
> the Admin portal won't work, and I get a message on the login screen from 
> engine saying I have a web console at port 9090. I don't get it.

I don't get it either, it all sounds too confusing.

> 
> As my last resort I am here, trying at least to know a way I could backup it 
> and install the engine elsewhere. All vm data is fine, but as the names are 
> cryptographic, import them would have me guessing things, right?
> 
> The number of VM's is low, 6 or 7, so if there is a way to do it manually, I 
> would try. Installing it again would be my nightmare here.

with just a few VMs it's indeed best to just reinstall from scratch and 
importing the storage domain back. You would only be missing the other non-VM 
configuration in oVirt that you have to do again, but the VMs should have the 
right name and all after import. Assuming you still have the storage domain 
somewhere safe.

Thanks,
michal
> 
> thanks,
> 
> matheus
> 
> ps: if needed, I can provide more info.
> 
> ___
> 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/PVFGIOV6KKG3BPAJMRFNXG2W6QYYFDK4/

___
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/KW6NQOM2JOBFXKK236H3K5UUR7ZFF24S/

[ovirt-users] Re: oVirt alternatives

[Michal Skrivanek]

> On 22. 2. 2022, at 14:16, Roman Mohr  wrote:
> 
> 
> 
> On Tue, Feb 22, 2022 at 1:25 PM Thomas Hoberg  > wrote:
> > On Tue, Feb 22, 2022 at 9:48 AM Simone Tiraboschi  > 
> > wrote:
> > 
> > 
> > Just to clarify the state of things a little: It is not only technically
> > there. KubeVirt supports pci passthrough, GPU passthrough and
> > SRIOV (including live-migration for SRIOV). I can't say if the OpenShift UI
> > can compete with oVirt at this stage.
> > 
> > 
> > Best regards,
> > Roman
> 
> Well, I guess it's there, mostly because they didn't have to do anything new, 
> it's part of KVM/libvirt and more inherited than added.

That you can say about oVirt and Openstack and basically anyone else as well. 
The foundation for basically every virtualization features is always in qemu-kvm

> 
> The main reason I "don't see it coming" is that may create more problems than 
> it solves.
> 
> To my understanding K8 is all about truly elastic workloads, including 
> "mobility" to avoid constraints (including memory overcommit). Mobility in 
> quotes, because I don't even know if it migrates containers or just shuts 
> instances down in one place and launches them in another: migration itself 
> has a significant cost after all.
> 
> We implemented live migrations for VMs quite some time ago. In practice that 
> means that we are migrating qemu processes between pods on different nodes.
> k8s does not dictate anything regarding the workload. There is just a 
> scheduler which can or can not schedule your workload to nodes.
>  
> 
> But if it were to migrate them (e.g. via CRIU for containers and "vMotion" 
> for VMs) it would then to also have to understand (via KubeVirt), which 
> devices are tied,
> 
> As far as I know pci passthrough and live migration do not mix well in 
> general because neither oVirt nor OpenStack or other platforms can migrate 
> the pci device state, since it is not in a place where it can be copied. Only 
> SRIOV allows that via explicit unplug and re-plug.

Slowly but surely it is coming for other devices as well, it's in development 
for couple years now, and a topic for every KVMForum in the past ~5 years.

>  
> because they use a device that has too big a state (e.g. a multi-gig CUDA 
> workloads), a hard physical dependence (e.g. USB with connected devices) or 
> something that could move with the VM (e.g. SR-IOV FC/NIC/INF with a fabric 
> that can be re-configured to match or is also virtualized).
> 
> A proper negotiation between the not-so-dynamic physically available assets 
> of the DC and the much more dynamic resources required by the application are 
> the full scope of a virt-stack/k8 hybrid, encompassing a DC/Cloud-OS 
> (infrastructure) and K8 (platform) aspects.
> 
> While KubeVirt does not offer everything which oVirt has at the moment, like 
> Sandro indicated, the cases you mentioned are mostly solved and considered 
> stable.

indeed!
When speaking of kubevirt itself I really think it's "just" the lack of 
virt-specific UI that makes it look like a too low level tool compared to the 
oVirt experience. Openshift/OKD UI is fixing this gap...and there's always a 
long way towards more maturity and more niche features and use cases to add, 
sure, but it is getting better and better every day. 

Thanks,
michal
>  
> 
> While I'd love to have that, I can see how that won't be maintained by anyone 
> as a full free-to-use open-souce turn-key solution.
> 
> There are nice projects to install k8s easily, for installing kubevirt with 
> its operator you just apply some manifests on the  (bare-metal) cluster and 
> you can start right away.
> 
> I can understand that a new system like k8s may look intimidating.
> 
> Best regards,
> Roman
>  
> ___
> 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/OPAKEXBS4LZSG2HIU3AWGJJCLT22FFGF/
>  
> 
> ___
> 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/RXSWPU5MQHNRXBKOPWSDMJR4C6S2DPP5/

___
Users mailing list -- users@ovirt.org
To unsubscribe send 

[ovirt-users] Re: RHGS and RHV closing down: could you please put that on the home page?

[Michal Skrivanek]

> On 8. 2. 2022, at 6:14, Guillaume Pavese 
>  wrote:
> 
> To replicate HCI without Gluster, 
> is there a way to set up a Managed Block Storage (I think that means Ceph?) 
> cluster hosted on the hypervisors, in a similar way as a Gluster Replica 3 ?

oVirt's MBS (CEPH) support is targeted for external CEPH clusters, I'm not 
aware of any effort to colocate the services like with gluster. With gluster we 
tried to ignore the impact of one affecting the other, with CEPH being more 
demanding it would be even more difficult.

> Is that possible/recommended or discouraged?

it might work in the ideal case, but since there is no awareness (like there is 
in Gluster) when you e.g. fence bunch of oVirt hosts you may easily do some 
damage to each.

> We are not ready for Openshift/Kubevirt yet and we would like to investigate 
> whether oVirt on Ceph in HCI is doable.

OKD Virtualization (okd+kubevirt/hco+rook) would be doable in future...most 
people are not ready just yet, and the project is not so polished yet either, 
but it will get there...

Thanks,
michal

> 
> Thank for any feedback
> 
> Guillaume Pavese
> Ingénieur Système et Réseau
> Interactiv-Group
> 
> 
> On Mon, Feb 7, 2022 at 10:47 PM Nir Soffer  > wrote:
> On Mon, Feb 7, 2022 at 3:04 PM Sandro Bonazzola  > wrote:
> 
> 
> Il giorno lun 7 feb 2022 alle ore 09:28 Thomas Hoberg  > ha scritto:
> Sandro, I am ever so glad you're fighting on, buon coraggio!
> 
> Thanks :-)
>  
> 
> Yes, please write a blog post on how oVirt could develop without a commercial 
> downstream product that pays your salaries.
> 
> I have no magic recipe but I know oVirt is used in several universities with 
> computer science departments. If just 1 student for each of them would 
> contribute 1 patch per semester that would help keeping oVirt alive even 
> without any downstream company backing it.
> And there are also people in this list like @Jean-Louis Dupond 
>  who are contributing fixes, latest is here 
> https://github.com/oVirt/ovirt-engine/pull/59 
>   .
> I don't want to write a book on how an opensource project can be healthy, I 
> believe there are already out there :-) .
> It would indeed help if some company or foundation would show up and get 
> engaged with the project but this is not strictly needed for an open source 
> project to be alive.
> 
> 
> Ideally you'd add a perspective for current HCI users, many of which chose 
> this approach, because a fault-tolerant SAN or NAS wasn't available.
> 
> I'll let the storage team to answer here
> 
> The oVirt storage team never worked on HCI and we don't plan to work on
> it in the future. HCI was designed and maintained by Gluster folks. Our
> contribution for HCI was adding 4k support, enabling usage of VDO.
> 
> Improving on the HCI side is unlikely to come from Red Hat, but nothing
> blocks other companies or contributors from working on this.
> 
> Our focus for 4.5 is Managed Block Storage and incremental backup.
> 
> Nir
> ___
> 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/5JBTH3JKW23ZRKDTPLBNTIIF3PMFKZ3L/
>  
> 
> 
> Ce message et toutes les pièces jointes (ci-après le “message”) sont établis 
> à l’intention exclusive de ses destinataires et sont confidentiels. Si vous 
> recevez ce message par erreur, merci de le détruire et d’en avertir 
> immédiatement l’expéditeur. Toute utilisation de ce message non conforme a sa 
> destination, toute diffusion ou toute publication, totale ou partielle, est 
> interdite, sauf autorisation expresse. L’internet ne permettant pas d’assurer 
> l’intégrité de ce message . Interactiv-group (et ses filiales) décline(nt) 
> toute responsabilité au titre de ce message, dans l’hypothèse ou il aurait 
> été modifié. IT, ES, UK.  
> ___
> 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/VMNBYFNOMBRBGKMBOSM4AFXCFIHD2FAI/

___
Users 

[ovirt-users] Re: [ovirt-devel] gerrit.ovirt.org upgrade

[Michal Skrivanek]

> On 21. 1. 2022, at 17:05, Denis Volkov  wrote:
> 
> Hello
> 
> I'm starting upgrade, gerrit will be unavailable

ETA? any complications?

> 
> -- 
> Denis Volkov
> 
> ___
> Devel mailing list -- de...@ovirt.org
> To unsubscribe send an email to devel-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/de...@ovirt.org/message/IOO66W7HHFP6KAXOM2GM24P3GFWV4VYV/

___
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/FVATZHNON5L4YN5TAO7P5YJE22LS5CGH/

[ovirt-users] Re: CentOS Stream Guest OS 9 support

[Michal Skrivanek]

> On 18. 1. 2022, at 17:15, Nathanaël Blanchet  wrote:
> 
> Why not? I'm running several instances without specific issues.

There's nothing special about el9stream at this point, and unlikely that 
anything will break in near future either.
other than not being quite ready for prime time just yet. But that should 
improve quickly in next few months

> 
> Le 18/01/2022 à 16:49, Gangi Reddy a écrit :
>> Can we create CentOS Stream 9 guest OS VM in Ovirt? Do you have any link 
>> that i refer?
>> 
>> Ovirt:
>> Software Version:4.4.7.6-1.el8
>> 
>> Host:
>> OS Version: RHEL - 8.4.2105.0 - 3.el8
>> OS Description: oVirt Node 4.4.8
>> ___
>> 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/XZHHWKAOQ6ZIIKMEU3RB353ZBIHSHOPN/
> 
> -- 
> Nathanaël Blanchet
> 
> Supervision réseau
> SIRE
> 227 avenue Professeur-Jean-Louis-Viala
> 34193 MONTPELLIER CEDEX 5 
> Tél. 33 (0)4 67 54 84 55
> Fax  33 (0)4 67 54 84 14
> blanc...@abes.fr
> ___
> 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/F4PRUMBTNP7EUU43IOIXCILL34LZR5MN/
___
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/WLNVWXVTNWRBADLT2PBGFGC5PZFGDL3O/

[ovirt-users] Re: oVirt and log4j vulnerability

[Michal Skrivanek]

> On 13. 12. 2021, at 14:04, Gianluca Cecchi  wrote:
> 
> On Mon, Dec 13, 2021 at 1:38 PM Sandro Bonazzola  > wrote:
> So far we can't confirm whether oVirt engine systems are affected or not: the 
> oVirt infra team is digging into this.
> I can confirm that ovirt-engine-wildfly is shipping a log4j version which is 
> affected by the vulnerability and we are monitoring Wildfly project so we'll 
> be able to ship an update as soon as a fix will be available (we are just 
> repackaging the binary build they provide).
> But I got no report so far confirming if the way we run Wildfly exposes the 
> vulnerable system to potential attackers yet.

We concluded the investigation and we believe we are not affected, while a 
vulnerable log4j is being shipped (and will be fixed by wildfly/jboss) we are 
not using this functionality in any of or components.
Wildfly reimplements log4j and we use that instead, all other usage is in 
compile time, unit tests. We also use log4j 1.x but without the JMSAppender in 
runtime.
Thanks to MartinP for confirmation

Thanks,
michal

> 
> 
> 
> If I understood correctly reading here:
> https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-log4j2-zero-day-exploited-in-the-wild-log4shell
>  
> 
> 
> you are protected by the RCE if java is 1.8 and greater than 1.8.121 
> (released on 2017) 
> 
> "
> If the server has Java runtimes later than 8u121, then it is protected 
> against remote code execution by defaulting 
> “com.sun.jndi.rmi.object.trustURLCodebase” and 
> “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”(see 
> https://www.oracle.com/java/technologies/javase/8u121-relnotes.html 
> ).
> "
> 
> It is not clear to me if it means that Java 11 (and 17) also maintained that 
> setting.
> In one of my oVirt with 4.4.8 it seems that engine is using 
> java-11-openjdk-headless-11.0.12.0.7-0.el8_4.x86_64 package
> 
> 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/WH3WZLRM6NYC7MJVWSTA4LY5YWDF57VW/

___
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/GHGNV72UMH2IK5USAK7NJDK2KL7NZHFY/

[ovirt-users] Re: Issue upgrading VDSM in 4.4.9

[Michal Skrivanek]

Hi Thomas,

> On 4. 11. 2021, at 0:40, Thomas Simmons  wrote:
> 
> Hello Michal,
> Yes was running official RHEL 8.4 on my hosts and have also tried with Rocky. 
> Unfortunately I've already started running into broken dependencies when 
> using the CentOS Stream Advanced Virtualization repos with RHEL. Since oVirt 
> is now targeting Stream and packages are being pushed there, are RHEL and 
> other EL8 clones not going to be supported by oVirt? Thank you.

They are, and will be, supported, but it's lagging a bit behind Stream. The 
exact lag depends on how far are we from the next minor version. 4.4.9 will 
work on 8.5, there will be RHEL 8.5 and RHEL clones 8.5 soon, but there's not 
going to be CentOS 8.5, considering there's <2 months until CentOS EOL.
So..for oVirt 4.4.9 you can say it's supported only on Stream. And It will be 
supported very soon on RHEL/clone.

That said it will be probably a bit shaky once Stream 9 gets more traction. We 
will try to move to it whenever it starts working. And for that time until RHEL 
9 releases there might be again some issues with RHELs. 

Thanks,
michal

> 
> On Mon, Nov 1, 2021 at 2:52 AM Michal Skrivanek  <mailto:michal.skriva...@redhat.com>> wrote:
> 
> 
> > On 31. 10. 2021, at 2:02, Thomas Simmons  > <mailto:twsn...@gmail.com>> wrote:
> > 
> > Hello,
> > 
> > I am running into the same issue while attempting a new install of oVirt 
> > 4.4 to replace my hyperconverged 4.3 cluster. I am running into the issue 
> > on one of the inital steps (yum/dnf install cockpit-ovirt-dashboard 
> > vdsm-gluster ovirt-host). After some digging, I found that the version of 
> > libvirt that it's looking for (libvirt >= 7.6.0-2) is not in the CentOS 8 
> > Advanced Virt repo, but is only in the CentOS Stream Advanced Virt repo. 
> > 
> > You can see here that libvirt 7.0.0-14.1 is the latest available in the 
> > CentOS 8 Advanced Virt repo:
> > 
> > http://mirror.centos.org/centos/8/virt/x86_64/advanced-virtualization/Packages/l/
> >  
> > <http://mirror.centos.org/centos/8/virt/x86_64/advanced-virtualization/Packages/l/>
> > 
> > However, the newer libvirt 7.6.0-2 is available in the 8-stream repo:
> > 
> > http://mirror.centos.org/centos/8-stream/virt/x86_64/advancedvirt-common/Packages/l/
> >  
> > <http://mirror.centos.org/centos/8-stream/virt/x86_64/advancedvirt-common/Packages/l/>
> > 
> > I don't know if there will be any ramifications down the road (I'm hoping 
> > there will not be since Stream tracks just behind the next EL point 
> > release), however I was able to get past the error by adding the 8-stream 
> > Advanced Virt repo to my systems by creating the repo file below. It would 
> > be nice if a developer could respond and advise if this is a "safe" 
> > solution, or if this is a known problem that they expect to address?
> 
> Hi,
> qemu/libvirt packages are now being pushed to Stream, CentOS is supposedly 
> EOL in 2 months. Currently there's not much of a difference and if packages 
> are installed happily then it likely works just fine, but with the upcoming 
> RHEL 8.5 release it is unlikely CentOS would be updated to 8.5, so I'm afraid 
> CentOS based systems won't last for too long. It would be best to move to 
> Stream entirely, or use ovirt-node (as a snapshot of packages that work), or 
> move to RHEL or RHEL clones.
> 
> Thanks,
> michal
> 
> > 
> > # /etc/yum/repos.d/ovirt-4.4-stream-advanced-virt.repo
> > [ovirt-centos-stream-advanced-virtualization]
> > name=Advanced Virtualization CentOS Stream testing packages for $basearch
> > baseurl=https://buildlogs.centos.org/centos/8-stream/virt/$basearch/advancedvirt-common/
> >  
> > <https://buildlogs.centos.org/centos/8-stream/virt/$basearch/advancedvirt-common/>
> > enabled=1
> > gpgcheck=0
> > module_hotfixes=1
> > ___
> > Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
> > To unsubscribe send an email to users-le...@ovirt.org 
> > <mailto:users-le...@ovirt.org>
> > Privacy Statement: https://www.ovirt.org/privacy-policy.html 
> > <https://www.ovirt.org/privacy-policy.html>
> > oVirt Code of Conduct: 
> > https://www.ovirt.org/community/about/community-guidelines/ 
> > <https://www.ovirt.org/community/about/community-guidelines/>
> > List Archives: 
> > https://lists.ovirt.org/archives/list/users@ovirt.org/message/FNK5TJW7RWGUIYP5BFKGEDQT3CDX4DXN/
> >  
> > <https://lists.ovirt.org/archives/list/users@ovirt.org/message/FNK5TJW7RWGUIYP5BFKGEDQT3CDX4DXN/>
> 

___
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/A2XMUYPXGY7Z65WEM3RB7FXWBKMNA4BL/

[ovirt-users] Re: Host moved to Non-Operational state as host CPU type is not supported in this cluster compatibility version or is not supported at all

[Michal Skrivanek]

Hi,
what's the ovirt version? 
what's the cluster level you're trying to add/use?
EC2 bare metal instances?...even that might not really work, I don't know about 
ec2 specifically, but often these are not full bare metals and may not really 
work with kvm.

Thanks,
michal

> On 4. 11. 2021, at 13:22, sekevgeni...@gmail.com wrote:
> 
> Here is cat /proc/cpuinfo | head -n 26 output
> processor: 0 
> vendor_id: GenuineIntel   
>
> cpu family: 6 
>
> model: 85 
>
> model name: Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz 
> stepping: 4   
>  
> microcode: 0x2006906  
> 
> cpu MHz : 2499.998
>   
> cache size: 33792 KB  
>
> physical id: 0
> 
> siblings: 8   
>   
> core id: 0
> 
> cpu cores: 4  
>
> apicid: 0 
>
> initial apicid:0  
>   
> fpu: yes  
>  
> fpu_exception: yes
>   
> cpuid level: 13   
> 
> 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 ss ht syscall nx pdpe1gb rdtscp lm 
> constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni 
> pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt 
> tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 
> 3dnowprefetch invpcid_single pti fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 
> erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt clwb 
> avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves ida arat pku ospke  
>   bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass 
> l1tf mds swapgs taa itlb_multihitbogomips: 4999.99
>   
> 
> clflush size: 64  
>   
> cache_alignment : 64  
>   
> address sizes   : 46 bits physical, 48 bits virtual   
>   
> power management:   
> 
> And engine.log file 
> 2021-11-04 12:16:50,553Z INFO  
> [org.ovirt.engine.core.bll.provider.network.SyncNetworkProviderCommand] 
> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-61) 
> [2cf2c819] Lock freed to object 
> 'EngineLock:{exclusiveLocks='[e8c52ac7-1da1-4626-b1d3-99e7ff73894f=PROVIDER]',
>  sharedLocks=''}' 
>   2021-11-04 12:20:00,011Z INFO  
> [org.ovirt.engine.core.bll.AutoRecoveryManager] 
> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-2) [] 
> Autorecovering 1 hosts   2021-11-04 12:20:00,011Z INFO  
> [org.ovirt.engine.core.bll.AutoRecoveryManager] 
> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-2) [] 
> Autorecovering hosts id: 356bd3e0-8bb6-4cd6-94b5-a155091b9a3b , name : 
> ovirt.host_1  
>   
>  202
> 1-11-04 12:20:00,012Z INFO  [org.ovirt.engine.core.bll.ActivateVdsCommand] 
> 

[ovirt-users] Re: Issue upgrading VDSM in 4.4.9

[Michal Skrivanek]

> On 31. 10. 2021, at 2:02, Thomas Simmons  wrote:
> 
> Hello,
> 
> I am running into the same issue while attempting a new install of oVirt 4.4 
> to replace my hyperconverged 4.3 cluster. I am running into the issue on one 
> of the inital steps (yum/dnf install cockpit-ovirt-dashboard vdsm-gluster 
> ovirt-host). After some digging, I found that the version of libvirt that 
> it's looking for (libvirt >= 7.6.0-2) is not in the CentOS 8 Advanced Virt 
> repo, but is only in the CentOS Stream Advanced Virt repo. 
> 
> You can see here that libvirt 7.0.0-14.1 is the latest available in the 
> CentOS 8 Advanced Virt repo:
> 
> http://mirror.centos.org/centos/8/virt/x86_64/advanced-virtualization/Packages/l/
> 
> However, the newer libvirt 7.6.0-2 is available in the 8-stream repo:
> 
> http://mirror.centos.org/centos/8-stream/virt/x86_64/advancedvirt-common/Packages/l/
> 
> I don't know if there will be any ramifications down the road (I'm hoping 
> there will not be since Stream tracks just behind the next EL point release), 
> however I was able to get past the error by adding the 8-stream Advanced Virt 
> repo to my systems by creating the repo file below. It would be nice if a 
> developer could respond and advise if this is a "safe" solution, or if this 
> is a known problem that they expect to address?

Hi,
qemu/libvirt packages are now being pushed to Stream, CentOS is supposedly EOL 
in 2 months. Currently there's not much of a difference and if packages are 
installed happily then it likely works just fine, but with the upcoming RHEL 
8.5 release it is unlikely CentOS would be updated to 8.5, so I'm afraid CentOS 
based systems won't last for too long. It would be best to move to Stream 
entirely, or use ovirt-node (as a snapshot of packages that work), or move to 
RHEL or RHEL clones.

Thanks,
michal

> 
> # /etc/yum/repos.d/ovirt-4.4-stream-advanced-virt.repo
> [ovirt-centos-stream-advanced-virtualization]
> name=Advanced Virtualization CentOS Stream testing packages for $basearch
> baseurl=https://buildlogs.centos.org/centos/8-stream/virt/$basearch/advancedvirt-common/
> enabled=1
> gpgcheck=0
> module_hotfixes=1
> ___
> 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/FNK5TJW7RWGUIYP5BFKGEDQT3CDX4DXN/
___
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/4GZBPJWR4SMPY3FLIR4NWB5IPTL4CSGU/

[ovirt-users] Re: COarse-grained LOck-stepping for oVirt

[Michal Skrivanek]

> On 24. 9. 2021, at 11:09, Harry O  wrote:
> 
> Hi,
> Will COLO be implemented in oVirt?

Hi,
very unlikely. It's been in development for the past ~10 years and while it 
kept progressing I'm not sure it's yet in usable state. It would require some 
big changes in oVirt as well

Thanks,
michal

> Is it possible to do it myself? I see qemu-kvm and lots of other qemu 
> installed on my oVirt nodes.
> It's in Qemu upstream (v4.0)
> https://wiki.qemu.org/Features/COLO
> ___
> 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/6HTRAOVE3NKPTCB4MUVDK6I5MW3A5W2T/
___
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/5VD2PVQPU7PGUN4IUKPGOOB3GIN6FB77/

[ovirt-users] Re: Hosted Engine cluster version compatib.

[Michal Skrivanek]

> On 24. 9. 2021, at 11:28, Gianluca Cecchi  wrote:
> 
> On Fri, Sep 24, 2021 at 11:05 AM Michal Skrivanek 
> mailto:michal.skriva...@redhat.com>> wrote:
> 
> 
>> On 24. 9. 2021, at 9:43, Gianluca Cecchi > <mailto:gianluca.cec...@gmail.com>> wrote:
>> 
>> BTW: there are two things that are not so clear to me:
>> 1. Is this only impacting SHE environments or is it a general problem also 
>> with external standalone engine ones?
> 
> it’s affecting all VMs, in standalone envs engine is not a VM
> 
> Of course... I meant if I have standalone external engine that manages VM1 
> and VM2 and I update from 4.4.7 to 4.4.8-5, will VM1 and VM2 impacted?
> I presume yes from your answer

yes

> 
> 
>> 2. Is it correct to say that if I already upgraded in the past to 4.4.7 and 
>> at that time I updated my cluster level from 4.5 to 4.6 (both in case of SHE 
>> and external engine), then I shouldn't have this kind of problems if then I 
>> updated to the impacted 4.4.8-5 version? And then I can go and continue 
>> updating to 4.4.8-6 without any risk/problems?
> 
> the cluster level update problem is just a side effect of the time zone 
> missing. You will see problems in other flows, or next time you upgrade to 
> 4.7 if we ever have one.
> 
> 
> So I don't understand if I need to rollback or if I can anyway update to 
> 4.4.8-6 and eventually modify from database.
> By the way in my env all my VMs in 4.4.7 had timezone set to the default 
> value "Etc/GMT". Does this imply no impact at all?

you should set it to something. 
It sets it to default on its own whenever that VMs get "touched" in some way, 
and since Etc/GMT is the default you won't really notice much, but there might 
be places where it may cause issues (dunno, OVF export maybe)

> Eg on another environment I see that after updating from 4.4.7 to 4.4.8-5 and 
> then 4.4.8-6, in Web Admin GUI if I select a VM, in general subtab I have for 
> 2 of them
> 
> Hardware Clock Time Offset: Etc/GMT
> 
> for all the other ones there isn't the "Hardware Clock Time Offset" item...
> Fot these VMs under edit virtual machine -> system -> Hardware Clock Time 
> Offset I see they have the value
> default:(GMTZ) Greenwich Standard Time
> 
> and from database point of view:
> 
> engine=# select time_zone,count(*) from vm_static group by time_zone;
>  time_zone | count 
> ---+---
>|18
>  Etc/GMT   | 2
> (2 rows)
> 
> engine=#
> 
> engine=# select vm_name from vm_static where time_zone='Etc/GMT';
>   vm_name  
> ---
>  testcl1
>  c76client
> (2 rows)

yeah, so those are vms which you have probably edited and saved in the meantime.

> 
> engine=# 
> 
> So I should use the db statement too, correct?

Hard to say, to minimize changes HE might be enough as long as you do not see 
any other issues anywhere else and you would use the default anyway.

> Any need to restart engine service after or before that?

Not really needed.

Thanks,
michal
> 
> 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/JYQ5DVT5TA7XPUSPD3BYUTLTJE2VINBI/

[ovirt-users] Re: Hosted Engine cluster version compatib.

[Michal Skrivanek]

> On 24. 9. 2021, at 9:43, Gianluca Cecchi  wrote:
> 
> BTW: there are two things that are not so clear to me:
> 1. Is this only impacting SHE environments or is it a general problem also 
> with external standalone engine ones?

it’s affecting all VMs, in standalone envs engine is not a VM

> 2. Is it correct to say that if I already upgraded in the past to 4.4.7 and 
> at that time I updated my cluster level from 4.5 to 4.6 (both in case of SHE 
> and external engine), then I shouldn't have this kind of problems if then I 
> updated to the impacted 4.4.8-5 version? And then I can go and continue 
> updating to 4.4.8-6 without any risk/problems?

the cluster level update problem is just a side effect of the time zone 
missing. You will see problems in other flows, or next time you upgrade to 4.7 
if we ever have one.

> 
> Thanks,
> Gianluca
> 
> On Thu, Sep 23, 2021 at 9:45 PM Diggy Mc  > wrote:
> The only VM that my cluster compatibility upgrade complains about is 
> "HostedEngine".  I'm not about to test my SQL knowledge by writing my own SQL 
> command and I see no reason to touch VMs that don't upset the cluster 
> upgrade.  Can you please provide a SQL command that corrects ONLY the 
> HostedEngine VM ???  Much appreciated.  NOTE: All my servers' OS (physical 
> and VM) are set to "Etc/UCT" wherever possible.

update vm_static SET time_zone='Etc/GMT' where vm_name='HostedEngine';

> ___
> 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/TNM4W25ECQKXRXCDVMXEWAD3OA3B5IDE/
>  
> 
> ___
> 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/72BIXUGUE44Y2XGSNXD652VXYSQHTIEC/

___
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/EPPFHVBOVOQZAUN5Y2NUFQ3NPQSERNOI/

[ovirt-users] Re: Hosted Engine cluster version compatib.

[Michal Skrivanek]

> On 23. 9. 2021, at 19:35, Gianluca Cecchi  wrote:
> 
> On Thu, Sep 23, 2021 at 7:29 PM Diggy Mc  > wrote:
> I just upgraded the HE to 4.4.8.6 and rebooted it.  I still cannot upgrade 
> the cluster compatibility level.  Cannot edit properties of the HE either.
> 
> 
> If I understood correctly, the fix is in the sense that if not already 
> updated to 4.4.8, the flow should be ok now.

correct

> But probably to solve the problems for the guys that already updated to the 
> "broken" 4.4.8, more work still has to be done by the developers...

yeah, it can’t be fixed that easily once it happens. Probably time for direct 
database update….

Assuming that you don’t have VMs with different TZs then change all Windwos VMs 
to your local TZ(here EST) with
# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "update vm_static SET 
time_zone='Eastern Standard Time' where os in 
('1','3','4','10','11','12','16','17','20','21','23','25','26','27','29','31')";

And also for all non-Windows VMs to 'Etc/GMT’  with
# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "update vm_static SET 
time_zone='Etc/GMT' where os not in 
('1','3','4','10','11','12','16','17','20','21','23','25','26','27','29','31')”;

That will cover HostedEngine as well, and it should fix the CL update problem.

Caveat - I havent’ tried that and it’s not tested.
Doublecheck it has been set.
Zones should be from 
https://github.com/oVirt/ovirt-engine/blob/master/packaging/conf/timezones-defaults.properties

Hope it helps,
michal

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

___
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/FEPU7A6CB6LQUB46PPNJEHLMDSM2SLZB/

[ovirt-users] Re: [ANN] oVirt 4.4.8 Async update #1

[Michal Skrivanek]

Hi all,
please be aware of bug https://bugzilla.redhat.com/show_bug.cgi?id=2005221 that 
unfortunately removes the timezone info (Hardware Clock Time Offset) in VM 
properties. It matters mostly to Windows VMs since they use “localtime” so 
after reboot the guest time will probably be wrong. It also breaks the Cluster 
Level update with HE as described in the bug.
Unfortunately there’s no simple way how to restore that since the information 
is lost on 4.4.8 upgrade, if the time matters to you you have to set it again 
for each VM

Please refrain from upgrading engine to 4.4.8.5 and wait for 4.4.8.6
Nodes/hosts are not affected in any way.

Thanks,
michal


> On 27. 8. 2021, at 8:25, Sandro Bonazzola  wrote:
> 
> oVirt 4.4.8 Async update #1
> On August 26th 2021 the oVirt project released an async update to the 
> following packages:
> ovirt-ansible-collection 1.6.2
> ovirt-engine 4.4.8.5
> ovirt-release44 4.4.8.1
> oVirt Node 4.4.8.1
> oVirt Appliance 4.4-20210826
> 
> Fixing the following bugs:
> Bug 1947709  - [IPv6] 
> HostedEngineLocal is an isolated libvirt network, breaking upgrades from 4.3
> Bug 1966873  - [RFE] 
> Create Ansible role for remove stale LUNs example remove_mpath_device.yml
> Bug 1997663  - Keep 
> cinbderlib dependencies optional for 4.4.8
> Bug 1996816  - Cluster 
> upgrade fails with: 'OAuthException invalid_grant: The provided authorization 
> grant for the auth code has expired.
> 
> oVirt Node Changes:
> - Consume above oVirt updates
> - GlusterFS 8.6: https://docs.gluster.org/en/latest/release-notes/8.6/ 
>  
> - Fixes for:
> CVE-2021-22923  curl: 
> Metalink download sends credentials
> CVE-2021-22922  curl: 
> Content not matching hash in Metalink is not being discarded
> 
> 
> Full diff list:
> --- ovirt-node-ng-image-4.4.8.manifest-rpm2021-08-19 07:57:44.081590739 
> +0200
> +++ ovirt-node-ng-image-4.4.8.1.manifest-rpm  2021-08-27 08:11:54.863736688 
> +0200
> @@ -2,7 +2,7 @@
> -ModemManager-glib-1.10.8-3.el8.x86_64
> -NetworkManager-1.32.6-1.el8.x86_64
> -NetworkManager-config-server-1.32.6-1.el8.noarch
> -NetworkManager-libnm-1.32.6-1.el8.x86_64
> -NetworkManager-ovs-1.32.6-1.el8.x86_64
> -NetworkManager-team-1.32.6-1.el8.x86_64
> -NetworkManager-tui-1.32.6-1.el8.x86_64
> +ModemManager-glib-1.10.8-4.el8.x86_64
> +NetworkManager-1.32.8-1.el8.x86_64
> +NetworkManager-config-server-1.32.8-1.el8.noarch
> +NetworkManager-libnm-1.32.8-1.el8.x86_64
> +NetworkManager-ovs-1.32.8-1.el8.x86_64
> +NetworkManager-team-1.32.8-1.el8.x86_64
> +NetworkManager-tui-1.32.8-1.el8.x86_64
> @@ -94 +94 @@
> -curl-7.61.1-18.el8.x86_64
> +curl-7.61.1-18.el8_4.1.x86_64
> @@ -106,4 +106,4 @@
> -device-mapper-1.02.177-5.el8.x86_64
> -device-mapper-event-1.02.177-5.el8.x86_64
> -device-mapper-event-libs-1.02.177-5.el8.x86_64
> -device-mapper-libs-1.02.177-5.el8.x86_64
> +device-mapper-1.02.177-6.el8.x86_64
> +device-mapper-event-1.02.177-6.el8.x86_64
> +device-mapper-event-libs-1.02.177-6.el8.x86_64
> +device-mapper-libs-1.02.177-6.el8.x86_64
> @@ -140,36 +140,36 @@
> -fence-agents-all-4.2.1-74.el8.x86_64
> -fence-agents-amt-ws-4.2.1-74.el8.noarch
> -fence-agents-apc-4.2.1-74.el8.noarch
> -fence-agents-apc-snmp-4.2.1-74.el8.noarch
> -fence-agents-bladecenter-4.2.1-74.el8.noarch
> -fence-agents-brocade-4.2.1-74.el8.noarch
> -fence-agents-cisco-mds-4.2.1-74.el8.noarch
> -fence-agents-cisco-ucs-4.2.1-74.el8.noarch
> -fence-agents-common-4.2.1-74.el8.noarch
> -fence-agents-compute-4.2.1-74.el8.noarch
> -fence-agents-drac5-4.2.1-74.el8.noarch
> -fence-agents-eaton-snmp-4.2.1-74.el8.noarch
> -fence-agents-emerson-4.2.1-74.el8.noarch
> -fence-agents-eps-4.2.1-74.el8.noarch
> -fence-agents-heuristics-ping-4.2.1-74.el8.noarch
> -fence-agents-hpblade-4.2.1-74.el8.noarch
> -fence-agents-ibmblade-4.2.1-74.el8.noarch
> -fence-agents-ifmib-4.2.1-74.el8.noarch
> -fence-agents-ilo-moonshot-4.2.1-74.el8.noarch
> -fence-agents-ilo-mp-4.2.1-74.el8.noarch
> -fence-agents-ilo-ssh-4.2.1-74.el8.noarch
> -fence-agents-ilo2-4.2.1-74.el8.noarch
> -fence-agents-intelmodular-4.2.1-74.el8.noarch
> -fence-agents-ipdu-4.2.1-74.el8.noarch
> -fence-agents-ipmilan-4.2.1-74.el8.noarch
> -fence-agents-kdump-4.2.1-74.el8.x86_64
> -fence-agents-mpath-4.2.1-74.el8.noarch
> -fence-agents-redfish-4.2.1-74.el8.x86_64
> -fence-agents-rhevm-4.2.1-74.el8.noarch
> -fence-agents-rsa-4.2.1-74.el8.noarch
> -fence-agents-rsb-4.2.1-74.el8.noarch
> -fence-agents-sbd-4.2.1-74.el8.noarch
> -fence-agents-scsi-4.2.1-74.el8.noarch
> -fence-agents-vmware-rest-4.2.1-74.el8.noarch
> -fence-agents-vmware-soap-4.2.1-74.el8.noarch
> -fence-agents-wti-4.2.1-74.el8.noarch
> 

[ovirt-users] Re: Hosted Engine cluster version compatib.

[Michal Skrivanek]

please check bug https://bugzilla.redhat.com/show_bug.cgi?id=2005221

seems we ended up with a nasty bug in 4.4.8, We will be releasing 4.4.8.6 
shortly, but it won’t fix the problem for those who already upgraded.

If you have a Windows VM, can you please check "Hardware Clock Time Offset” in 
Edit VM/System, whther it has default GMT or a different value that you have 
set before - assuming that you did. For Windows people usually set it to their 
local time zone.

For the HE problem, can you try to actually edit that VM and change something 
(something that’s changeable, e.g. description) and save it? 
Regardless if that works, can you try to restart HE (by moving to global 
maintenance, or if you don’t care too much, just shut it down from within that 
HE VM and let it be restarted automatically)

If you have any additional logs/observation please add that to the bug

Thanks,
michal

> On 17. 9. 2021, at 15:33, Andrea Chierici  
> wrote:
> 
> Really no suggestions at all?
> 
> Andrea
> 
> On 15/09/2021 12:33, Andrea Chierici wrote:
>> Dear all,
>> I have just updated my ovirt installation, with self hosted engine, from 
>> 4.4.5 to 4.4.8.5-1.
>> Everything went smoothly and in a few minutes the system was back up and 
>> running.
>> A little issue is still puzzling me.
>> I am asked to update from 4.5 to 4.6 the cluster and data center 
>> compatibility level. When I try to issue the command from the cluster config 
>> I get this 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. If the save does not pass, fix the dialog 
>>> validation. After successful cluster update, you can revert your Custom 
>>> Compatibility Version change (or other changes). If the problem still 
>>> persists, you may refer to the engine.log file for further details.
>> 
>> It's very strange because the config of the hostedengine is "plain" and 
>> there are no constrains on compatibility version, as you can see in this 
>> picture:
>> 
>> 
>> 
>> In any case, if I try to force compatibility with 4.6 I get this error:
>> 
>>> Error while executing action:
>>> 
>>> HostedEngine:
>>> 
>>> There was an attempt to change Hosted Engine VM values that are locked.
>> 
>> So I am stuck. Not a big deal at the moment, but sooner or later I will have 
>> to do this upgrade and I don't know where I am wrong.
>> 
>> Can anybody give a clue?
>> Thanks in advance,
>> 
>> 
>> Andrea
>> 
>> -- 
>> Andrea Chierici - INFN-CNAF  
>> Viale Berti Pichat 6/2, 40127 BOLOGNA
>> Office Tel: +39 051 2095463  
>> SkypeID ataruz
>> --
>> 
>> 
>> ___
>> 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/BQMHMKNLPANYOIWDSLSPBB3UUY4FXRNR/
>>  
>> 
> 
> 
> -- 
> Andrea Chierici - INFN-CNAF   
> Viale Berti Pichat 6/2, 40127 BOLOGNA
> Office Tel: +39 051 2095463   
> SkypeID ataruz
> --
> ___
> 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/2WDJEQYIDZNNIKIVBFAFDX5DZHTLOWST/

___
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/2XV7REDJ2ACAGLZHFCER4DAUBNYBYWGG/

[ovirt-users] Re: virtio-win driver licensing

[Michal Skrivanek]

> On 2 Sep 2021, at 14:29, si...@justconnect.ie wrote:
>
> Hi,
>
> Can someone clarify the licensing around virtio-win drivers on oVirt 4.4.8 as 
> the following seems to imply a RedHat paid subscrition is required when 
> installing "virtio-win-guest-tools.exe"

Hi Simon,
can you please clarify which exe that is exactly, from where did you
download it?

Thanks,
michal
>
> "2.  Program License Grant.Red Hat grants User a non-exclusive,
> non-transferable license to use the Program during the term of and on systems
> with fully-paid applicable Red Hat subscription(s) provided User may not:
> (a) modify, copy, or create any derivative works of the Program;
> (b) decompile, disassemble or reverse engineer the Program (except to the
> extent permitted by applicable law);
> (c) redistribute, encumber, sell, rent, lease, sublicense, or otherwise
> transfer rights to the Program (except to the extent permitted herein); or
> (d) remove or alter any trademark, logo, copyright or other proprietary
> notices, legends, symbols or labels in the Program.  Upon expiration of the
> term set forth above, User will promptly remove, delete or destroy all copies
> of the Program in its possession."
>
> Kind Regards
>
> Simon...
> ___
> 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/BRJIXVQKYZ4LQWOFTIMCIHH7OLLFBPOH/
___
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/MED4EGAR2N3WUKJLWUCAPZ4DHA6HQGMZ/

[ovirt-users] Re: Faster local disk for VM

[Michal Skrivanek]

> On 20. 8. 2021, at 13:15, Shantur Rathore  wrote:
> 
> Hi Users,
> 
> Does oVirt support node local disk cache or scratch / transient disk for 
> faster disk access?

we have scratch disk hook, see 
https://github.com/oVirt/vdsm/tree/master/vdsm_hooks/scratchpad. That’s not 
supported but it should still work.
or you can use a regular feature of PCI or SCSI host passthrough to map the 
device into the guest.

Thanks,
michal

> The idea is similar to options we get on cloud where one can attach fast node 
> local scratch disk/ssd to the VM which gets deleted when VM dies.
> 
> Thanks in advance.
> 
> Kind Regards,
> Shantur
> ___
> 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/I7HBUUJES5P46O6CLHPM3ORAPTDGU5FF/
___
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/SSRQ6MGW4GSBTGTT7ZWTI2A3KNIBJYRX/

[ovirt-users] Re: Set fixed VNC/Spice Password for VMs.

[Michal Skrivanek]

> On 31. 7. 2021, at 9:19, Strahil Nikolov  wrote:
> 
> You need to (all Hypervisors that will be running this script):
> - download the engine's CA from 
> https:///ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA
> - put it at :
> /etc/pki/ca-trust/source/anchors/
> - make it trousted by running:
>  update-ca-trust extract
> 
> Best Regards,
> Strahil Nikolov
> 
> On Fri, Jul 30, 2021 at 18:05, Merlin Timm
>  wrote:
> Ah okay, i figured it out.
> 
> root@mypc <mailto:root@mypc>:/home/merlin/Documents/Ovirt-0.06# perl 
> set_ovirt_vnc_pw.pl
> LWP Status line : 500 Can't connect to my.ovirt.manager.com:443 
> (certificate verify failed) at /usr/local/share/perl/5.26.1/Ovirt/VM.pm 
> line 195.
> 
> it seems to work but it cant connect to the ovirt manager :/
> 
> Am 30.07.2021 14:54 schrieb Milan Zamazal:
> > Merlin Timm mailto:merlin.t...@posteo.de>> writes:
> > 
> >> actually I rather wanted to know how to generate a config with
> >> Ovirt::Display. I didn't really understand what I have to do to
> >> generate a config.
> > 
> > I've never tried it but I think you should fetch the perl library and
> > then run a perl script according to the example in Synopis section of
> > https://metacpan.org/pod/Ovirt::Display 
> > <https://metacpan.org/pod/Ovirt::Display>
> > 
> >> Am 30.07.2021 14:04 schrieb Milan Zamazal:
> >>> Merlin Timm mailto:merlin.t...@posteo.de>> writes:
> >>> 
> >>>> Hey,
> >>>> Thanks for the answers!
> >>>> I want to try the perl solution. One, maybe stupid, question: how
> >>>> do i run this perl module?
> >>>> Do i run it on the Host or from my local machne? I am a litte bit
> >>>> confused.
> >>> As I understand it, you can run it from anywhere where Engine REST
> >>> API
> >>> is reachable from.
> >>> Regards,
> >>> Milan
> >>> 
> >>>> Could someone explain it to me?
> >>>> Best regarda
> >>>> Am 8. Juli 2021 16:05:42 MESZ schrieb Milan Zamazal
> >>>> mailto:mzama...@redhat.com>>:
> >>>>> Sandro Bonazzola mailto:sbona...@redhat.com>> 
> >>>>> writes:
> >>>>> 
> >>>>>> Il giorno gio 8 lug 2021 alle ore 13:38 Sandro Bonazzola <
> >>>>>> sbona...@redhat.com <mailto:sbona...@redhat.com>> ha scritto:
> >>>>>> 
> >>>>>>> +Milan Zamazal mailto:mzama...@redhat.com>> , 
> >>>>>>> +Arik Hadas
> >>>>>>> mailto:aha...@redhat.com>> , +Michal
> >>>>>>> Skrivanek mailto:mskri...@redhat.com>> any hint?
> >>>>>>> 
> >>>>>> I found https://metacpan.org/pod/Ovirt::Display  
> >>>>>> <https://metacpan.org/pod/Ovirt::Display>but I think there
> >>>>>> should be
> >>>>>> an easier way within the engine to configure this.
> >>>>>> 
> >>>>>> 
> >>>>>>> Il giorno mar 6 lug 2021 alle ore 14:01 Merlin Timm
> >>>>>>> mailto:merlin.t...@posteo.de>>
> >>>>>>> ha scritto:
> >>>>>>> 
> >>>>>>>> Good day to all,
> >>>>>>>> I have a question about the console configuration of the VMs:
> >>>>>>>> By default, for each console connection to a VM, a password is
> >>>>>>>> set for
> >>>>>>>> 120 seconds, after that you can't use it again. We currently
> >>>>>>>> have the
> >>>>>>>> following concern:
> >>>>>>>> We want to access and control the VMs via the VNC/Spice of the
> >>>>>>>> Ovirt
> >>>>>>>> host. We have already tried to use the password from the
> >>>>>>>> console.vv for
> >>>>>>>> the connection and that works so far. Unfortunately we have to
> >>>>>>>> do this
> >>>>>>>> every 2 minutes when we want to connect again.
if you connect again you get a new concole.vv…why is that a problem?
> We are currently
> >>>>>>>> building
> >>>>>>>> an automatic test pipeline and for this we need to access the 
> >>>>>>>&

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

[Michal Skrivanek]

> On 1. 8. 2021, at 20:01, jimod4--- via Users  wrote:
> 
> i get the below error when i try to add a new kvm host to the cluster.  I 
> know that the cpu is a haswell, Intel E5-2640 v3.  if i run "virsh 
> capabilities" it returns Haswell-noTSX-IBRS.  My KVM server is 
> redhat 8.4 fully patched today on an DL-360 Gen9.  oVirt is at 4.4.7.7-1.el8. 
>  i have tried many diffent CPU settings for the cluster and none of them 
> work.  this is new oVirt install.
> 
> 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, 
> model_Haswell-noTSX, nx. Please update the host CPU microcode or change the 
> Cluster CPU Type."

if you do not see vmx and/or nx flags, you probably have virtualization 
disabled in BIOS

Thanks,
michal

> 
> MIRCOCODE:
> root@kvm09 ~]# dmesg | grep 'microcode'
> [0.00] microcode: microcode updated early to revision 0x46, date = 
> 2021-01-27
> [1.625108] microcode: sig=0x306f2, pf=0x1, revision=0x46
> [1.625753] microcode: Microcode Update Driver: v2.2.
> ___
> 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/4B2TMR6MGSJF7PG57WBU3IG5CMZP7G2L/
___
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/VGGXT7Q2XEOLKQYQ3SR4HVO3Q6VGUBQR/

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

[Michal Skrivanek]

> 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: Does anyone know How to install macOS on ovirt4.4？

[Michal Skrivanek]

> On 21. 7. 2021, at 12:58, Nir Soffer  wrote:
> 
> On Wed, Jul 21, 2021 at 9:33 AM zhou...@vip.friendtimes.net
>  wrote:
>> 
>> 
>> Does anyone know How to install macOS on ovirt4.4?
>> I used the image--"macOS.Big.Sur.11.2.3.20D91.iso"，It can run successfully 
>> on VMware.But on ovirt，I tested the boot type by both UEFI and BIOS ,they 
>> are all cant boot
> 
> Looking in https://github.com/kholia/OSX-KVM running previous
> versions of macOS is possible with qemu 4.2.0, so it can work
> with oVirt.
> 
> I guess some changes are needed in the libvirt xml oVirt generates,
> (maybe via a vdsm hook?) or custom vm properties (or both).
> 
> I don't think this can work out of the box unless Apple contributes
> to oVirt, but this can be a community effort. It is a shame that you
> can do this in VMware but not in oVirt.

You certainly can’t do that with default virtio divers as mac os doesn’t have 
them
with emulated it might work, with a sata disk
 
> 
> Nir
> ___
> 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/FROXKQGUBJKTWFOF4FOFOCJXDDZ2I4WB/
___
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/JZU4WAMBSTN4PX6JAELDDB5LLM53E77F/

[ovirt-users] Re: Import to VMware

[Michal Skrivanek]

> On 20. 5. 2021, at 22:58, Darin Schmidt  wrote:
> 
> Hello,
> 
> Ive exported an OVA of a server we had made on OVIRT and Im trying to import 
> it to VMware. Its complaining that the ovf:format is incorrect.

OVF/OVA is not really a fixed standard, every project is using it differently 
and it’s not compatible between each other that well. oVirt’s OVF are just for 
oVirt, same as VMware’s OVFs are just for VMware. Some can be converted with 
more or less issues…

> 
> ovf:format="http://www.gnome.org/~markmc/qcow-image-format.html;
> 
> That link doesnt resolve to anywhere because it appears its now 
> http://people.gnome.org/~markmc/qcow-image-format.html
> 
> But I dont know whats supposed to go there nor have I been able to locate 
> anything to help solve this issue. All I really need is access to the files 
> in the, what I assume is, vdmk file that comes along with the ovf file, which 
> mine is called: 154b3d77-d340-4d24-a448-66265c5fb613
> 
> So if anything, is there a way to open this vm disk so I can gain access to 
> the files?

vmware cannot read qcow2 dissk, you need to convert them to vmdk
Even then it’s not necessarily going to work as oVirt and VMware are using 
different virtual hardware, so if you want to boot from there it likely won’t 
work.
take a look at some conversion tools rather than direct import. E.g. for the 
other direction from vmware to ovirt you can use virt-v2v

Thanks,
michal

> 
> 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/3YAA7Z3SLLDX4GBW6EXPGNOII3OGRYJF/
___
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/ZHOSGFURPOTJGGCUDU42F6EVY4RBO5Y2/

[ovirt-users] vmfex in 4.4.7

[Michal Skrivanek]

Hi there,
just a heads up that in 4.4.7 we’ll be removing vdsm’s hard dependency on 
VM-FEX hook. The functionality has been more or less obsoleted by SR-IOV and 
its usage is minimal these days. With the upgrade the vdsm-hook-vmfex-dev rpm 
will get automatically uninstalled. 
If you happen to use it and it works well for you then please "dnf install" it 
after the upgrade. There is no change in functionality and the hook is not 
going away, it’s just that in order to not make it mandatory from now on, it 
gets removed during "dnf upgrade”.

Thanks,
michal
___
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/73O5WXHAVIUPQONM4CBMPMXJODNLWSCX/

[ovirt-users] oVirt 4.4.7 development

[Michal Skrivanek]

Hi all,
we are starting to work on oVirt 4.4.7 and as you probably noticed we are 
slowly transitioning away from CentOS. We added CentOS Stream option for 
regular hosts, and the current 4.4.6 Node and Appliance are already built from 
Stream. We also have some initial patches for alternative RHEL clones other 
than CentOS, however we can’t really support them until they provide the 
required dependencies.
We are not ditching CentOS just yet, but we can no longer accommodate the long 
delay it takes CentOS team to produce a next minor version, hence for oVirt 
4.4.7 we will require the operating system to be at the RHEL 8.4 level - that’s 
a CentOS 8.4 if that gets released in time
or the actual RHEL 8.4 or any 8.4 clone like Alma, Rocky, OL with the right 
dependencies (probably the ones from Stream) 
or CentOS Stream.

In the meantime we're going to be moving the existing CI resources to test with 
CentOS Stream to unblock development of new features. 
If you would want to help with testing other OSes patches are welcome to add 
support for them

Thanks,
michal
___
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/RE4AO7EGGXBL5AKVFNVSW4JPIK3YNLKL/

[ovirt-users] Re: Cluster level 4.5

[Michal Skrivanek]

> On 29. 4. 2021, at 6:54, Don Dupuis  wrote:
> 
> What version of libvirt is required for a host to be put in this cluster 
> level? I am using CentOS 8.3 and cpu is Cascade Lake Server. It says that my 
> host is only compatible with cluster version 4.2,4.3 and 4.4. I am doing a 
> new install of Ovirt 4.4.5. I have tried to update libvirt version but have 
> run into issues. Currently installed libvirt is 
> libvirt-6.0.0-28.module_el8.3.0+555+a55c8938.x86_64.

8.3 is fine, but you have some weird version there, where’s your 
libvirt-6.0.0-28.module_el8.3.0+555+a55c8938.x86_64 coming from? that’s not 
coming from any repo that we’re distributing in ovirt-release rpm, is it?

> 
> Don
> ___
> 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/CWAUC4NC45Z54QF3MN3ESGGYFIG6WZL7/
___
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/EOGG5PSSUSWBBFETQGKD5HRYAZE47DQL/

[ovirt-users] Re: oVirt longevity after CentOS 8, RHV changes

[Michal Skrivanek]

> On 7. 4. 2021, at 17:22, Nathanaël Blanchet  wrote:
> 
> Hi,
> 
> Le 06/04/2021 à 18:15, Sandro Bonazzola a écrit :
>> 
>> 
>> Il giorno sab 3 apr 2021 alle ore 18:22 Andrei Verovski 
>> mailto:andre...@starlett.lv>> ha scritto:
>> Hi,
>> 
>> Does all this mean oVirt will be sometime and somehow merged with OpenShift 
>> (or OKD)?
>> 
>> oVirt supports integration with OKD with KubeVirt. I've no video to show it 
>> for oVIrt (yet) but you can see it here for RHV / OCP: 
>> https://www.youtube.com/watch?v=MMEaZAxj9_8 
>> Tried to do the same as shown 
>> on the video on ovirt 4.4.4, but no kubevirt provider is available. Is it an 
>> option when installing or an upcoming feature?

it is there, but only enabled by default in 4.4.5
there’s KubevirtProviderSupportEnabled vdc_option for that in older versions

>> There is no plan to get oVirt merged into OKD.
>>  
>> 
>> Its not that easy since OKD designed primarily for Kubernetes/Docker 
>> containers.
>> 
>> Or oVirt may be considered just another abandonware within 2+ years?
>> 
>> oVirt is not going to be abandonware as long as the community will not 
>> abandon it.
>> 
>> 
>> 
>> -- 
>> Sandro Bonazzola
>> MANAGER, SOFTWARE ENGINEERING, EMEA R 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/Z7MPCRZKWD6JRYPDEKCUJWCYGUHMF6FM/
>>  
>> 
> -- 
> Nathanaël Blanchet
> 
> Supervision réseau
> SIRE
> 227 avenue Professeur-Jean-Louis-Viala
> 34193 MONTPELLIER CEDEX 5 
> Tél. 33 (0)4 67 54 84 55
> Fax  33 (0)4 67 54 84 14
> blanc...@abes.fr 
> ___
> 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/4C7UIUX37CUD5EPSLKSF6OB3Q3OS3F6B/

___
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/TD363JHJWO2TWZG7Y247RVNNY27SYXOD/

[ovirt-users] Re: Introduction & general question about oVirt

[Michal Skrivanek]

> On 6. 4. 2021, at 18:06, Sandro Bonazzola  wrote:
> 
> 
> 
> Il giorno dom 4 apr 2021 alle ore 16:13 Nicolas Kovacs  > ha scritto:
> Hi,
> 
> I'm a 53-year old Austrian living in Montpezat, a small village in South
> France. I'm an IT professional with a focus on Linux and free software, and
> I've been a Linux user since Slackware 7.1.
> 
> Welcome to oVirt community!

Hi!

> 
>  
> 
> I'm doing web & mail hosting for myself and several small structures like our
> local school and a handful of local companies. Up until recently these 
> hostings
> have happened on "bare metal" root servers using CentOS 7. One main server is
> hosting most of the stuff: WordPress sites, one OwnCloud instance, Dolibarr
> management software, GEPI learning platform, Postfix/Dovecot mail server,
> Roundcube webmail, etc.
> 
> This setup has become increasingly problematic to manage, since applications
> have more and more specific requirements, like different versions of PHP and
> corresponding modules.
> 
> So I decided to split everything up nicely into a series of virtual machines,
> each one with a nicely tailored setup.
> 
> I have a couple of sandbox servers, one public and one local, running Oracle
> Linux 7 (a RHEL clone like CentOS). I played around with it, and KVM-based
> virtualization already works quite nicely.
> 
> While looking for documentation, I stumbled over oVirt, which I didn't even
> know existed until last week. Before I dive head first into it, I'd be curious
> to know a few general things.
> 
> 1. Would it be overkill for a small structure like mine?
> 
> If you have only a couple of bare metal and a few VMs you may consider more 
> lightweight virtualization managers like cockpit project machine plugin 
> (https://cockpit-project.org/guide/latest/feature-virtualmachines 
>  ) or 
> kimchi project (https://github.com/kimchi-project/kimchi 
>  ) or virt-manager 
> (https://virt-manager.org/  )

We’ve seen people with 70+ machines being managed by shell scripts and libvirt, 
and also oVirt users with just a single host. Those would be extremes. I would 
personally start using oVirt once I have more than 4-5 hosts or so, and/or more 
than 20 VMs.

> 
>  
> 
> 2. Will I be able to do HA on a series of modest KVM-capable root servers even
> if they are located in different datacenters across different countries?
> 
> I think it mostly depends on the network latency and speed. Having HA with 
> servers in different countries may be problematic.

yeah, in a stretched cluster setup it would work, but the expectations are that 
the link is almost as local. It does work ok with several hundred ms latency. 
but it needs to be reliable.
 
 
> 
> 
> 3. One problem I couldn't resolve using a bone-headed keep-it-simple KVM setup
> is backup. For my bare-metal servers I've been using incremental backups using
> Rsnapshot for years. Here's a blog article I wrote on the subject:
> 
> https://blog.microlinux.fr/rsnapshot-centos-7/ 
> 
> 
> Unfortunately I can't use this approach with huge QCOW images, at least not
> without jumping through burning loops.
> 
> Is there an easy way to perform remote incremental backups with oVirt?
> 
> There are a few backup vendors that provide solutions for backing up oVirt 
> VMs, you can just query google for them.

I think none of the vendors are ready with their products to use incremental 
backup just yet. it’s close though.
you can also just adapt and use examples[1] of the incremental backup 
feature[2]. if you’d want to just hack up some DIY backup solution.
incremental backup us a fairly recent addition to oVirt (and to qemu/libvirt in 
general)

Thanks,
michal

[1] 
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/backup_vm.py
[2] 
https://www.ovirt.org/documentation/incremental-backup-guide/incremental-backup-guide.html

> 
>  
> 
> BTW, I took a peek at Proxmox and Ceph, but I admit I'm a die-hard RHEL-clone
> user.
> 
> Cheers from the sunny South of France,
> 
> Niki
> 
> -- 
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr 
> Blog : https://blog.microlinux.fr 
> Mail : i...@microlinux.fr 
> Tél. : 04 66 63 10 32
> Mob. : 06 51 80 12 12
> ___
> 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/ 
> 

[ovirt-users] Re: 4.4 -> 4.3

[Michal Skrivanek]

Hi Thomas,

> On 1. 4. 2021, at 23:44, Thomas Hoberg  wrote:
> 
> I personally consider the fact that you gave up on 4.3/CentOS7 before CentOS 
> 8 could have even been remotely reliable to run "a free open-source 
> virtualization solution for your entire enterprise", a rather violent break 
> of trust.

it wasn’t really any different from past big releases. It’s been in development 
for roughly a year. Sure, there were hiccups during el7->el8 transition, but it 
didn’t seem to me any worse than when we moved from el6 to el7.

> 
> I understand Redhat's motivation with Python 2/3 etc., but users just don't. 
> Please just try for a minute to view this from a user's perspective.

it’s not RedHat’s motivation, it’s python 2 end of life that was on January 
2020 already. Every larger project written in python suffered, we already 
exceeded py2 EOL by several months but it couldn’t have been avoided. 
Users may not care, but there’s no way for developers to work around a language 
deprecation/redesign. I do not see how we could do anything about it.

> With CentOS 7 supported until 2024, we naturally expect the added value on 
> top via oVirt to persist just as long.

oVirt has nothing to do with CentOS, it’s just been our choice to build on as a 
stable and ubiquitous OS to build on, but it doesn’t define our own lifecycle.

> 
> And with CentOS 8 support lasting until the end of this year, oVirt 4.4 can't 
> be considered "Petrus" or a rock to build on.

right, the end of good old CentOS model is a big issue we have to sort out 
before the end of the year. There’s been previous threads on this topic, we do 
have CentOS Stream support for development, for stable user environment we will 
probably need something else. Things are in motion, there’s “free” RHEL 
offering, there are multiple other clones like Rocky or Alma, patches on the 
way to support them.

> 
> Most of us run oVirt simply because we are most interested in the VMs it runs 
> (tenants paying rent).
> 
> We're not interested in keeping oVirt itself stable and from failing after 
> any update to the house of cards.
> 
> And yes, by now I am sorry to have chosen oVirt at all, finding that 4.3 was 
> abandonend before 4.4 or the CentOS 8 below was even stable and long before 
> the base OS ran out of support.

I’m sorry for your experience. 
It’s understandable end users do not see the developer’s issues. But this is an 
open source project, some involvement is kind of expected. if you’re looking 
for a guaranteed support without dealing with “details” you can always consider 
commercial offering, be it RHV or VMware or whatever else.

Maintaining older versions is usually “the thing” that you get with commercial 
products. OSS projects usually offer backward compatibility only to a certain 
degree depending of available resources. We don’t really have them, we cannot 
maintain python2, we cannot maintain CentOS 7 or keep running CentOS 8 program. 
If there is anyone interested in help, provide automation for older versions, 
keep fixing it, add other operating system support and maintain it, then 
absolutely, please come forward and let’s do that by all means.

Thanks,
michal

> 
> To the users out there oVirt is a platform, a tool, not a means to itself.
> ___
> 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/JHSFTNGNOMYNCE4H2CF55DXIXGMCASMK/
___
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/3PG4LNW5Z4EEV3YW2YQ37UBOX7USW5G4/

[ovirt-users] Re: Locked disks

[Michal Skrivanek]

> On 31. 3. 2021, at 16:29, Giulio Casella  wrote:
> 
> FYI: after upgrading to ovirt 4.4.5 (both manager and ovirt nodes) the
> issue seems fixed (or at least it didn't happen in about a week, with
> 4.4.4 I had the problem every couple of day).

likely thanks to https://bugzilla.redhat.com/show_bug.cgi?id=1796124
There were bunch of other related changes in 4.4.5.
It’s probably not entirely solved yet, but it’s good to see it already helped.
There will be further improvements in 4.4.6 hopefully, and also from 
storware/vprotect side.

> 
> Regards,
> gc
> 
> 
> On 04/02/2021 09:08, Giulio Casella wrote:
>> I've not been able to reproduce, if happens again I'll submit a bugzilla.
>> 
>> Thank you.
>> 
>> Regards,
>> gc
>> 
>> 
>> On 03/02/2021 17:49, Shani Leviim wrote:
>>> In such a case, the disks shouldn't remain locked - sounds like a bug.
>>> This one requires a deeper look.
>>> If you're able to reproduce it again, please open a bug in Bugzilla
>>> (https://bugzilla.redhat.com ) with engine
>>> and vdsm logs,
>>> so we'll be able to investigate it.
>>> 
>>> *Regards,
>>> *
>>> *Shani Leviim
>>> *
>>> 
>>> 
>>> On Wed, Feb 3, 2021 at 5:39 PM Giulio Casella >> > wrote:
>>> 
>>>Hi,
>>>I tried unlock_entity.sh, and it solved the issue. So far so good.
>>> 
>>>But it's still unclear why disks were locked.
>>> 
>>>Let me make an hypothesis: in ovirt 4.3 a failure in snapshot removal
>>>would lead to a snapshot in illegal status. No problem, you can remove
>>>again and the situation is fixed.
>>>In ovirt 4.4 a failure in snapshot removal leave the whole disk in
>>>locked state (maybe a bug?), preventing any further action.
>>> 
>>>Does it make sense?
>>> 
>>> 
>>>On 03/02/2021 12:25, Giulio Casella wrote:
 Hi Shani,
 no tasks listed in UI, and now "taskcleaner.sh -o" reports no task
>>>(just
 before I gave "taskcleaner.sh -r").
 But disks are still locked, and "unlock_entity.sh -q -t all -c"
 (accordingly) reports only two disk's uuid (with their vm's uuid).
 
 Time to give a chance to unlock_entity.sh?
 
 Regards,
 gc
 
 On 03/02/2021 11:52, Shani Leviim wrote:
> Hi Giulio,
> Before running unlock_entity.sh, let's try to find if there's any
>>>task
> in progress.
> Is there any hint on the events in the UI?
> Or try to run [1]:
> ./taskcleaner.sh -o  
> 
> Also, you can verify what entities are locked [2]:
> ./unlock_entity.sh -q -t all -c
> 
> [1]
> 
>>>
>>> https://github.com/oVirt/ovirt-engine/blob/master/packaging/setup/dbutils/taskcleaner.sh
>>>
>>> 
> 
>>>
>>> >>
>>> >
> [2]
> 
>>>
>>> https://github.com/oVirt/ovirt-engine/blob/master/packaging/setup/dbutils/unlock_entity.sh
>>>
>>> 
> 
>>>
>>> >>
>>> >
> 
> *Regards,
> *
> *Shani Leviim
> *
> 
> 
> On Wed, Feb 3, 2021 at 10:43 AM Giulio Casella
>>>mailto:giu...@di.unimi.it>
> >> wrote:
> 
>  Since yesterday I found a couple VMs with locked disk. I
>>>don't know the
>  reason, I suspect some interaction made by our backup system
>>>(vprotect,
>  snapshot based), despite it's working for more than a year.
> 
>  I'd give a chance to unlock_entity.sh script, but it reports:
> 
>  CAUTION, this operation may lead to data corruption and
>>>should be used
>  with care. Please contact support prior to running this command
> 
>  Do you think I should trust? Is it safe? VMs are in production...
> 
>  My manager is 4.4.4.7-1.el8 (CentOS stream 8), hosts are
>>>oVirt Node
>  4.4.4
> 
> 
>  TIA,
>  Giulio
>  ___
>  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-users] Re: 4.4 -> 4.3

[Michal Skrivanek]

First and foremost that’s something we do not support if your VMs live in a 
4.4+ cluster level in your oVirt 4.4.
The upgrade path for VM configuration is one way only.

if it’s just a handful of VMs it might be way easier to just recreate those VMs 
and move disks

I also wonder what’s reason for running 4.3 these days, we really do not 
develop/patch it for 10 months by now.

Thanks,
michal

> On 31. 3. 2021, at 23:08, Thomas Hoberg  wrote:
> 
> Export domain should work, with the usual constraints that you have to 
> detach/attach the whole domain and you'd probably want to test with one or a 
> few pilot VMs first.
> 
> There could be issues with 'base' templates etc. for VMs that where created 
> as new on 4.4: be sure to try every machine type first. Ideally you have 4.4 
> and 4.3 farms side by side, instead of rebasing your hosts on 4.3 and *then* 
> finding issues. Things to watch out for are hardware base lines (those 
> mitigation-enhanced CPU types can be nasty), BIOS types (Q35 vs. all others) 
> etc.
> 
> Personally I see OVA files as something that should be least risky and 
> minimal functionality that just ought to always work. The oVirt team doesn't 
> seem to share my opinion and views OVA as a VMware->oVirt migration tool, 
> mostly.
> 
> I still try to use OVA export/import for critical VMs, because sometimes it 
> means I can at least resurrect them on a stand-alone KVM host (even VMware 
> should work in theory: in practice I've seen both VMware and VirtualBox barf 
> at oVirt generated OVA exports).
> 
> Note that there is an issue with OVA exports from oVirt 4.3: They can result 
> in empty disks due to a race condition that wasn't fixed even with the last 
> 4.3 release. In your case, that shouldn't bite you, as you are moving in the 
> other direction. But should you decide to go forward again be sure to check 
> your 4.3 OVA exports via 'du -h ' showing more than a few KB of 
> actuall alloaction vs. the potentially multi-TB 'sparse' disk full of zeros 
> 'ls -l' might hint at.
> 
> With oVirt I consider blind faith as extremely ill advised. Everything you 
> haven't tested several times after every change of every component yourself, 
> is much more likely to fail than you ever thought befit a product that 
> carries "a free open-source virtualization solution for your entire 
> enterprise" on its home page.
> ___
> 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/GDJSP7UVVAORL3WBPKTRZUNZ7SRJ46E6/
___
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/JBUBR35AM6W5GOTC432DY4JDS6X4ARHM/

[ovirt-users] Re: Q: Set host CPU type to kvm64 for a single VM

[Michal Skrivanek]

> On 29. 3. 2021, at 14:43, Roman Bednar  wrote:
> 
> Hi Andrei,
> 
> kvm64 is a legacy type, not recommended for use by qemu project [1]. I 
> suppose that's the reason it's been left out from the list you're looking at.

we only include ~10 years old CPUs, anything older is usually not useful these 
days

> 
> Not sure how this is implemented exactly, anyway it seems like you can type 
> in any custom value into the field for cpu type, instead of just picking one 
> from the list provided. It seems to have worked for me:

yes, you can use any CPU type supported by qemu. They may not work of course, 
depending on your hw and other features we configure by default for a VM.

> 
> # virsh -r dumpxml vm1 | xpath -q -e "//domain/cpu/model"
> kvm64
> # virsh -r list
>  Id   Name   State
> --
>  1vm1running
> 
> 
> [1] 
> https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html#other-non-recommended-x86-cpus
>  
> 
> 
> 
> -Roman
> 
> On Mon, Mar 29, 2021 at 10:23 AM Andrei Verovski  > wrote:
> Hi,
> 
> OK, thanks, found this option.
> 
> But host CPU type “KVM64” is not available here, only Conroe, Penryn, 
> Nehalem, Westmere.
> 
> Where I can add CPU type “KVM64” in this list?
> 
> 
>> On 29 Mar 2021, at 11:00, Ritesh Chikatwar > > wrote:
>> 
>> Hello,
>> 
>> Yes , There is an option but I have not tried. 
>> Log in to the portal and edit the vm properties.
>> Steps:
>> 
>> Select VM -> Edit -> Click System Tab -> then click Advanced Parameter -> 
>> Custom CPU Type
>> 
>> 
>> 
>> On Mon, Mar 29, 2021 at 12:37 PM Andrei Verovski > > wrote:
>> Hi !
>> 
>> 
>> Is it possible to set host CPU type to kvm64 for a single VM ?
>> 
>> 
>> Thanks.
>> Andrei
>> 
>> ___
>> 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/MFTVL6WIALN6QL6D6MZMUIGLF3D2R2L6/
>>  
>> 
> 
> ___
> 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/WNPVLRRAH7ZDJPF56EEKPBASSNJ76CVE/
>  
> 
> ___
> 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/X2NTGFKFHETVYW3V2XSAMYSBIV5XWP46/

___
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/NJ7JUQQPXJDX7EHWV4O7JSVBWZJJUCBP/

[ovirt-users] Re: websockify + ovirt

[Michal Skrivanek]

> On 19. 3. 2021, at 20:26, Pascal DeMilly  wrote:
> 
> I will. I wish there was more documentation on how all of this works. My 
> current test sniffing the network show that actually the traffic is not on 
> the port as defined in the console file but on the tls-port of that file.  so 
> I am a little confused how all of this works. And since everything is  SSLed 
> it is quite difficult to know what is happening

Hi,
I don’t entirely follow your steps, but let me try to describe the ovirt 
specific implementation. spice-html5 used to work, but we removed it couple 
releases back since it’s not performing well and it’s not maintained much. It 
worked the same way as novnc.

We need to secure the communication between the client and the proxy(which is 
done by wss) and also make sure that only authorized targets are being proxied, 
and not any random request.
In oVirt we add one more layer to the stock novnc-websockify communication.  It 
could be that websockify added these options later on but when we integrated 
these consoles it had nothing.
We modified the client to sign the request for proxy that is verified by the 
(also modified) proxy. There are small changes but they would need to be done 
for any other client you’re trying to use (and for the proxy if you’d want to 
use a non-ovirt websockify)

HTH.
michal

> 
> On Fri, Mar 19, 2021 at 11:28 AM Vincent Royer  > wrote:
> Obviously I am assuming spice-html5 works with ovirt. Maybe it doesn't. I was 
> never able to make it work except with direct libvirt over spice.
> 
> I could never get the html5 implementation working.  If you get this new 
> spice-web-client working, please post your config to the list!
> 
>  
> ___
> 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/W3TBF4XPURKRVI2J3AWUDCTRCTYYHXGZ/
>  
> 
> ___
> 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/PJIOIEM5XXYZRAXQQJCS6MWPP3POBPMY/
>  
> 
> ___
> 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/6XTZH5LS63MEL6LO4PY3UGQAWKT24SCW/

___
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/XFUOLQ3HMXR4RHHDTQWEBMFJULXSQAU5/

[ovirt-users] Re: user portal

[Michal Skrivanek]

> On 23. 3. 2021, at 7:55, Enrico Becchetti  wrote:
> 
> Hi,
> 
> I've added a new ip public address and SSO_ALTERNATE_ENGINE_FQDNS,
> after that I run engine-setup. and now ovirt can also be access with a new 
> name
> but the last item is about X509 certificate.
> How can I add a second certificate for this new url ?

I think you’d have to use your own CA, the internal one doesn’t generate 
certificates with other names.
or as Didi suggested modify your DNS to use same FQDN for both ways


> Best regards.
> Enrico
> 
> Il 07/03/21 08:51, Yedidyah Bar David ha scritto:
>> On Fri, Mar 5, 2021 at 10:18 AM Enrico Becchetti
>> mailto:enrico.becche...@pg.infn.it>> wrote:
>>>   Dear all,
>>> I'm using ovirt 4.3.2 with its engine on a virtual machine. The nodes
>>> are all Centos 7.7.
>> Is this a hosted-engine?
> no
>>> Both engine and hypervisor systems work on a 10.0.0.0 private network.
>>> Now I would like to let users access the ovirt web page (user portal)
>>> and for this
>>> I must necessarily add a second network interface to the engine by
>>> inserting a public ip. I can't use NAT.
>>> Can you give me any advice for this operation ?
>>> Can I add the network interface and then run engine-setup ?
>>> Will oVirt be accessible from both ip addresses at the end of this
>>> operation ?
>> Generally speaking:
>> 
>> 1. You should be able to add an IP address to the existing NIC. If this
>> is a hosted-engine, this might be simpler than adding a NIC. Of course,
>> this might not be relevant in your case, depending on network topology,
>> conf, etc.
>> 
>> 2. The engine itself does not care at all about which IP addresses are
>> used to connect to it. Neither is httpd that is running there as a frontend
>> to it - it listens on all addresses. So just add the address somehow, perhaps
>> restart httpd if needed (but I do not think so), and everything should work.
>> 
>> 3. The engine _does_ care about the _name_. So make sure you use the
>> existing name. For this, you'll have to change your DNS, or /etc/hosts,
>> as applicable.
>> 
>> 4. If it's complex for you to keep the existing name (e.g. because you want
>> to make it work from both old and new addresses, etc.), you can also add
>> another name that the engine will agree to be connected to, using
>> SSO_ALTERNATE_ENGINE_FQDNS, see e.g. [1].
>> 
>> Best regards,
>> 
>> [1] https://www.ovirt.org/develop/networking/changing-engine-hostname.html
>> 
>>> Lots of thanks.
>>> Enrico
>>> 
>>> --
>>> ___
>>> 
>>> Enrico BecchettiServizio di Calcolo e Reti
>>> 
>>> Istituto Nazionale di Fisica Nucleare - Sezione di Perugia
>>> Via Pascoli,c/o Dipartimento di Fisica  06123 Perugia (ITALY)
>>> Phone:+39 075 5852777   Skype:enrico_becchetti
>>>   Mail: Enrico.Becchettipg.infn.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/ZW2SGNYGA4MEGUCA2ONQ3RVBRWIYMUJZ/
>> 
>> 
> 
> 
> -- 
> ___
> 
> Enrico BecchettiServizio di Calcolo e Reti
> 
> Istituto Nazionale di Fisica Nucleare - Sezione di Perugia
> Via Pascoli,c/o Dipartimento di Fisica  06123 Perugia (ITALY)
> Phone:+39 075 5852777 Skype:enrico_becchetti 
> 
> Mail: Enrico.Becchettipg.infn.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/MTSY7BKGWKFGBQXREFO4IBZESB62ESWG/
>  
> 
___
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/EIFTHZ7D673LAPPQ7WZGUVDDQE3USLIY/

[ovirt-users] Re: websockify + ovirt

[Michal Skrivanek]

Hi,

> On 19. 3. 2021, at 3:56, Pascal D  wrote:
> 
> Hi,
> 
> I am trying to get the spice-web-client working with ovirt.

what is spice-web-client?

> One area where I am having difficulties is authentication.Looking at 
> remote-viewer on linux I am able to see that the minimum fields to have a 
> successful spice connection are the following:
> 
> [virt-viewer]
> type=spice
> host=70.xxx.176.xxx
> port=5914
> password=WQJQWCo+s8tK
> tls-port=5915
> tls-ciphers=DEFAULT
> host-subject=O=.com,CN=d1c1v5.xxx.net
> ca=-BEGIN 
> CERTIFICATE-\nMIIDzDCCArSgAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCVVMxGDAWBgNVBAoM\nD2J1dHRlcmZseWl0LmNvbTEiMCAGA1UEAwwZb3YxLmJ1dHRlcmZseWl0LmNvbS40NTQ2NTAeFw0x\nOTA2MDQwMDMyMDVaFw0yOTA2MDIwMDMyMdXR0\nZXJmbHlpdC5jb20xIjAgBgNVBAMMGW92MS5idXR0ZXJmbHlpdC5jb20uNDU0NjUwggEiMA0GCSqG\nSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD218EJkIJewgmeDFcUM7vEQ3RQ4nL9ZNEg+zORlruLKON\neZRDfgXei3XTt+VFUNTrxBjepf+yN3WjhVP+lDeDveZU/3OYKj9dSewlz7Mj1XTKE8DXDMIGYc79\nXUrcSoiEjCRG1eB+w+uyP4WK0AlJwGKav3AZuU5awjvYAftkW0RhOgdjp80ofuoC3K9TUPPjemtw\n3EWb4bjRcWiDUj8owfhhAHnb4RfacUSMQmYpVJ5YfRunYrCOixlOeGx7PkvXLqWmu2Rnrnk7TNn6\nv74fHh3ruHmZHLk2i6/yNoOAiJC/M8piCGZ3tiOcnPcYF2ZoX+Ud6BV69Hp6SxnF/eCXAgMBAAGj\ngbkwgbYwHQYDVR0OBBYEFAlrTpLGY5Dq6gtA7d7CXc1QAFmOMHQGA1UdIwRtMGuAFAlrTpLGY5Dq\n6gtA7d7CXc1QAFmOoU+kTTBLMQswCQYDVQQGEwJVUzEYMBYGA1UECgwPYnV0dGVyZmx5aXQuY29t\nMSIwIAYDVQQDDBlvdjEuYnV0dGVyZmx5aXQuY29tLjQ1NDY1ggIQADAPBgNVHRMBAf8EBTADAQH/\nMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCA
> QEAoC8Nx/s4Uafgc3iyzxbLPb/chQ8U\n7+lULXTq+ZLOuMDdu6UKt7qKZpJZK8ZhjFh/1yVOnpzm7Np+oP7TQlOUkup8X4HsfAwrCgNK1IT1\nETdbdMYD8HYFjxz/0xbnMkJAHfPEh1vtqplw3YhVgiAZfZfT8HzVY/xGkjurvxSyVjBSbn+4uao1\n6W9URt2rWTHn+XxoT+j+cx8vv1WKsynlMBtUjCFy8eR7ZDngRcM/9iRkRCGHJvWJmi1CRrQeE5RZ\nvBH0zE64J3cOJj4BSlN3wOYWiRq28XLB9epDDyZaRpnsqLCOq/+/LscM7iPW1acdCoCu68nJUwTQ\nh1Jh7vQjCQ==\n-END
>  CERTIFICATE-\n
> 
> 
> with this I can successfully connect to a vm. Now I would like to do the same 
> from spice-web-client but websockify doesn't give me a tls-port.  

a tls-port for what? the one in .vv file is the qemu/spice-server tls port

> How to could I implement this? Is there a wrapper that exists that I can pass 
> to websockify to do the authentication on the port + 1 (it seems it is always 
> the next port)

the authentication in .vv file is for the SPICE protocol. it’s for the 
“spice-web-client” to implement that.

Thanks,
michal

> 
> Thanks in advance for your help
> ___
> 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/B7MIZRV5PHVVVMAX3GQSZCAYDUZI4HH7/
___
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/YPZ5CFLOXUFBKOAVBTLBRBMI5MOX3V75/

[ovirt-users] Re: Migrate windows 2003 server 64bits from libvirt to ovirt

[Michal Skrivanek]

> On 24. 2. 2021, at 16:13, Fernando Hallberg  wrote:
> 
> Hi Vinícius,
> 
> Thanks in advance.
> 
> I'm update all ovirt drivers in the drivers in windows 2003, and change de 
> IDE disk to VIRTIO-DISK.
> 
> I'm started the VM on the old libvirt ( centos7 - kvm ), and the machine boot 
> ok.
> 
> I'm copy the disk file to ovirt, and i have the same error again.
> 
> See VM dumpxml:
> 
> 
>   x
>   c09c46c2-ead5-2cee-d5d7-bd8c701312cd
>   8388608
>   8388608
>   4
>   
> /machine
>   
>   
> hvm

this doesn’t look like from ovirt, is this the original libvirt’s xml?

how does it look on ovirt? what OS Type do you use? You may try older cluster 
level, with older machine type, but in 4.4 it’s still going to be at least 
rhel7.5.0. Check if it works with that machine type in your  libvirt  env first.

Also, you can keep using IDE in ovirt…if it works then it’s alright, no?

Thanks,
michal

>   
>   
> 
> 
> 
>   
>   
> 
>   
>   destroy
>   restart
>   restart
>   
> /usr/libexec/qemu-kvm
> 
>   
>   
>   
>   
>function='0x0'/>
> 
> 
>function='0x2'/>
> 
> 
>function='0x1'/>
> 
> 
> 
>function='0x0'/>
> 
> 
>   
>   
>   
>function='0x0'/>
> 
> 
>   
> 
>   
> 
> 
>   
> 
> 
>   
> 
> 
>   
> 
> 
> 
> 
>   
> 
> 
>primary='yes'/>
>function='0x0'/>
> 
> 
>   
> 
> 
>function='0x0'/>
> 
>   
>   
> 
> 
> 
> Any idea?
> 
> Em seg., 22 de fev. de 2021 às 12:25, Vinícius Ferrão 
> mailto:fer...@versatushpc.com.br>> escreveu:
> Hi Fernando.
> 
> The blue screen message is in Portuguese, the majority of the list speaks 
> English. So it will be hard to get some help on this.
> 
> Regarding the message for non Portuguese speakers, is says that the BIOS 
> and/or the firmware isn’t compatible with ACPI.
> 
> Since the OS is legacy, this may be something related to missing drivers or 
> something similar to this, like wrong drivers from other hypervisors. You 
> said that you’ve imported the VM for other hypervisor, so it was 
> preinstalled. Did you installed the oVirt Guest Tools before uploading the VM 
> on oVirt? The guest tools should add the required drivers so the VM can boot. 
> It’s a good ideia to remove the tools from the other hypervisor too.
> 
> On 22 Feb 2021, at 12:15, Fernando Hallberg  > wrote:
>> 
>> Hi,
>> 
>> I have a VM with 2003 server x64, and I upload the vm image to oVirt.
>> 
>> The VM boot on the oVirt, but, the blue screen appear with a error message:
>> 
>> 
>> 
>> Anybody has some information about this?
>> 
>> I try to convert de img file from raw to qcow2, but the error persists.
>> 
>> Regards,
>> Fernando Hallberg
>> ___
>> 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/UPP7EBZZ776WE4JEEIOJCLOTMCKJIQWM/
>>  
>> 
> 
> ___
> 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/KTVYEYHATLKTEJ6SEOJNMLCVQRFGOI4B/

___
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/SL7AK7554LHO4D2YFSTQG3LOO36N2RB4/

[ovirt-users] Re: vGPU on ovirt 4.3

[Michal Skrivanek]

> On 27. 1. 2021, at 19:20, Thomas Hoberg  wrote:
> 
>> On Wed, Jan 27, 2021 at 9:14 AM > 
>> 
>> Ok, I think I found at least for Nvidia. You can follow what described for
>> RHV:
>> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/...
>> 
>> In the same manual there are also instructions for vGPU.
>> 
>> There is also the guide for 4.3:
>> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/...
>> 
>> Gianluca
> 
> Again, that's the easy part that works just fine.
> It's afterwards when you try to install the Nvidia driver when there might be 
> trouble because the driver refused to load on GPUs that aren't permitted to 
> operate inside a VM, quite independent of the hypervisor (same issue with 
> VMware, VirtualBox, KVM).
> 
> For that there are tricks you'll find on the Internet on how to cheat the 
> Nvidia driver into believing it's running on a physical machine but on KVM 
> that implies editing the XML config... which in the case of oVirt seems to be 
> generated at startup.

yes. you can use that.

> 
> So I guess the hooking mechanism can be used to take care of that, but I've 
> not progressed to that stage myself, mostly because the GPUs I use in the 
> corporate lab are whitelisted by Nvidia.

shouldn’t be too hard, you can use any of the existing hooks (even old ones) as 
a starting point. I think (I haven’t looked at that for a long time) that 
smbios modification may be enough, so there’s [1] right away. If not, it should 
be straightforward to adapt

> 
> And just to give a little credit: Pass-through works very well with oVirt 
> 4.3, only moving (inactive) VMs from host-to-host is a little more involved,
> while GPU live-migration unfortunately is out of the question. That makes 
> perfect sense for NICs and storage adapters, for GPUs one might argue that 
> their state could be migrated, too. But Linux doesn't really understand 
> heterogenous accelerators yet, so oVirt can't do better.

it’s a generic PCI VFIO passthrough, there’s nothing specific about GPU. 
Migrateable GPUs are not generic and will require some work, mostly in 
kernel/drivers. nvidia is working on it, but it’s hard to say when that’s going 
to be ready, and as always i doubt they’ll make it available for older/lowend 
cards. But then again maybe with some tricks…:)

Thanks,
michal

[1] https://github.com/oVirt/vdsm/tree/master/vdsm_hooks/smbios

> ___
> 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/S3DBQHTQDOZ6ASIK64OLZBGSEZRO623Y/
___
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/OEZOY7LWJWEJ5WSOECGWT6G6N5CXZ2N4/

[ovirt-users] Re: vGPU on ovirt 4.3

[Michal Skrivanek]

> On 26. 1. 2021, at 12:50, Gianluca Cecchi  wrote:
> 
> On Tue, Jan 26, 2021 at 10:26 AM  > wrote:
> Thanks all for the feedback. 
> 
> When we bought the servers, they put some Nvidia Quadro P4000's in, but I 
> can't seem to find anything that says they support vGPU. 
> 
> I wasn't aware of the license server requirement for Nvidia, but the pricing 
> isn't too bad, so I can probably get that pushed through. Anyone aware of 
> which AMD cards are supported by oVirt? I have only found a list of Nvidia 
> cards. 
> 
> Thanks,
> 
> Kim
> 
> 
> 
> Hello,
> updated list of supported GPUs for vGPU functionality should be this one:
> https://docs.nvidia.com/grid/gpus-supported-by-vgpu.html 
> 
> 
> and P4000 seems not to be present
> 
> So you could use the other supported method, with passthrough Gpu, following 
> what described here for qemu command line:
> https://docs.nvidia.com/grid/latest/grid-vgpu-user-guide/index.html#using-gpu-pass-through-red-hat-el-qemu-cli
>  
> 
> 
> and driving oVirt to do so with vdsm hook qemucmdline
> 


why a hook? we have a “native” ovirt support for both GPU and vGPU since cca 
4.1.
There was a hook initially, but that’s no longer needed…since 4.2 iirc
I think we also tested some Intel’s GTV-g card...



> [root@ov200 ~]# dnf info vdsm-hook-qemucmdline.noarch
> Last metadata expiration check: 2:48:59 ago on Tue 26 Jan 2021 09:58:06 AM 
> CET.
> Available Packages
> Name : vdsm-hook-qemucmdline
> Version  : 4.40.40
> Release  : 1.el8
> Architecture : noarch
> Size : 15 k
> Source   : vdsm-4.40.40-1.el8.src.rpm
> Repository   : ovirt-4.4
> Summary  : QEMU cmdline hook for VDSM
> URL  : http://www.ovirt.org/develop/developer-guide/vdsm/vdsm/ 
> 
> License  : GPLv2+
> Description  : Provides support for injecting QEMU cmdline via VDSM hook.
>  : It exploits libvirt's qemu:commandline facility available in 
> the
>  : qemu xml namespace.
> 
> [root@ov200 ~]# 
> 
> I donna if the doc here is up to date, not tested lately:
> https://www.ovirt.org/develop/developer-guide/vdsm/hook/qemucmdline.html 
> 
> 
> I think the persist command in case of node is not necessary with NG any more
> Developers could confirm and eventually point to the correct page for the 
> hook guide?
> 
> 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/BKXIHMPQZQRNVBW2JS3YC3T4QMRT4JPF/

___
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/3OB4CI2VEYTQDUJO4YI6POTASN3QI3MF/

[ovirt-users] Re: Is there a plan for ovirt 4.5 and furture versions?

[Michal Skrivanek]

> On 26. 1. 2021, at 9:04, Sandro Bonazzola  wrote:
> 
> 
> 
> Il giorno lun 25 gen 2021 alle ore 20:00 Thomas Hoberg  > ha scritto:
> To your question "Is it worth building a new virtualization platform based on 
> ovirt?" Sandro answered "currently there's no change in the Red Hat's support 
> of the oVirt project".
> 
> That may technically be true, but it doesn't really answer your question, I'd 
> believe.
> 
> oVirt is a management layer which has carried the motto "oVirt is a free 
> open-source virtualization solution for your entire enterprise" on its head 
> page for years.
> 
> In my experience oVirt hasn't been nearly ready and stable enough to run an 
> enterprise workload, unless you are ready to maintain a fully redundant team 
> of engineers to do QA on all your use cases.
> 
> The CentOS base, however, has been enterprise quality, just as good as RHEL 
> without the extra hassle of registration servers: I don't think we ever 
> rolled back an update in over 10 years because it broke any of our workloads. 
> And that was including OpenVZ on dozens of machines and thousands of 
> containers.
> 
> With oVirt 4.3 and CentOS 7 you knew which part you could trust and where to 
> look for errors (I found more than I believed possible).
> 
> With the de-facto elimination of CentOS as a functional RHEL clone, oVirt 4.4 
> becomes upstream-on-upstream and you know how fault probabilities don't add 
> but *multiply* when you combine them.
> 
> With that you now need three QA teams, one for CentOS-Stream, one for oVirt 
> and another for the integration.
> 
> Not even oVirt 4.4 on RHEL 8 will be a proper choice, because that 
> combination is also no longer a part of what little test automation oVirt 
> receives.

Specifically to this point - we never had any automation on RHEL, oVirt was 
never tested on it, and it didn’t work at all due to openvswitch dependencies 
for better half of past year.
That is something we may add if there are any changes in RHEL licensing which 
would allow us to run it for free on our CI infrastructure. 
For now Centos 8 and Stream are the only things that are feasible for our CI, 
if a good RHEL clone emerges we would very likely add it. But oVirt heavily 
depends on other projects so we can’t do it on our own.

> 
> We expect CentOS Stream to be the preferred upstream platform on which oVirt 
> should be run but I don't see why it shouldn't run on RHEL or on any RHEL 
> rebuild.
>  
> 
> Only RHV on RHEL will be properly tested and CentOS/oVirt as a 
> dev/QA/home/hobby ramp to RHV/RHEL is lost.
> 
> And CentOS 8 seems to decay before they even switch to upstream. I've just 
> done an update on my single-node HCI oVirt 4.4 infrastructure the other day, 
> which installed a new kernel on the host (4.18.0-240.10.1.el8_3 vs. 
> 4.18.0-193.19.1.el8_2). It turns out that kernel broke VDO because of 
> kernel/library mismatch caused by repository issues you'd need to manually 
> resolve, while VDO is a key ingredient to the HCI stack (error #1). VDO is 
> still treated as an "external" contribution I don't know how many years after 
> the aquisition. So on top of the mismatching userland and kernel versions, 
> the VDO module isn't signed (error #2), which can throw a wrench in your 
> system if e.g. after a BIOS update your system is reset to secure boot. 
> 
> Error #1 should show on RHEL, too, unless CentOS is no longer downstream of 
> RHEL already, while error #2 indicates that the CentOS process is broken 
> because VDO is only signed for RHEL.
> 
> In other words, the "enterprise quality" of CentOS is already going up in 
> smoke, while CentOS8 isn't yet officially dead.
> 
> I might count myself lucky, that I haven't done the oVirt 4.4 migration of my 
> HCI clusters yet, mostly beacuse it's far from seamless, extremely risky and 
> very disruptive.

While oVirt and Gluster have a great integration for many years now, for better 
or worse Gluster is a completely separate project and with that it is really 
another level of integration fo these two things together.

> Now I just won't do that because oVirt 4.4/CentOS 8 is EOL this year, while 
> CentOS 7 still has a couple of years left. By then, I'll hopefully have found 
> a new home for the non-production workloads I manage.
> 
> My hope of replacing the VMware production environment with a combination of 
> oVirt and RHV has been erased: My confidence that IBM will let oVirt will 
> survive another ten years is practically zero.
> 
> oVirt is a community project which already has several forks and downstreams. 
> Whatever may or may not happen in ten years, nothing will prevent the 
> community to keep oVirt project going on as for any other community 
> opensource project.
> 
>  
> 
> Redhat should know that nothing is as important as the size of the user base 
> for software to survive. oVirt/RHV's biggest chance would lie in everybody 
> building their home clusters using 3-node HCI 

[ovirt-users] Re: Is there a plan for ovirt 4.5 and furture versions?

[Michal Skrivanek]

> On 26. 1. 2021, at 8:48, Sandro Bonazzola  wrote:
> 
> 
> 
> Il giorno mar 26 gen 2021 alle ore 02:30 Flashbang  > ha scritto:
>  
> 
> In fact, our core production environment has been using redhat virtualization 
> since 2015, and upgrading from rhev 3.3 to rhv4.3 all the way, the platform 
> is getting better and better. 
> 
> But the guys at Red Hat have been reluctant to tell us whether redhat 
> virtualization will continue. I have tried kubevirt on openshift, and it is 
> obviously far from an enterprise product. 
> 
> So it is disappointed to hear that ovirt will stay at version 4.4, which 
> means it will gradually die.
> 
> As said in previous reply, right now we're missing substantial features to be 
> planned to justify a new 4.5 version. 

As I’ve shared some months ago, we shifted towards a continuous “zstream” 
improvements in 4.4.z rather than a big bang version we used to do. 
Main reason was the planning for next release was always a challenging task. It 
took a year for a feature to get into a GA version and since those plans rarely 
survived, we always ended up with different content than we planned anyway, and 
much later than we wanted.
For introduction of bigger features or breaking changes we always had the 
concept of cluster compatibility levels (and we introduced a 4.5 in 4.4.3, and 
probably a 4.6 in future), and with better CI…. we just believe that there’s no 
need for 9+ months release cycle.

Thanks,
michal

> You're welcome to join and contribute to help shaping the project's roadmap.
> 
> 
>  
> ___
> 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/WM5H2CA2ACXP65HMVW5DY3VTKCZBZFMX/
>  
> 
> 
> 
> -- 
> Sandro Bonazzola
> MANAGER, SOFTWARE ENGINEERING, EMEA R 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/QCBFKVDRHOGPWCRVO67QYPJDHU66M5HG/

___
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/LNG5OVUURUFSKGI7TCFVJNOBKA5PSC4J/

[ovirt-users] Re: CentOS Stream support

[Michal Skrivanek]

> On 5. 1. 2021, at 22:14, Alex K  wrote:
> 
> 
> 
> On Fri, Jun 5, 2020, 11:36 Michal Skrivanek  <mailto:michal.skriva...@redhat.com>> wrote:
> Hi all,
> we would like to ask about interest in community about oVirt moving to CentOS 
> Stream.
> There were some requests before but it’s hard to see how many people would 
> really like to see that.
> 
> With CentOS releases lagging behind RHEL for months it’s interesting to 
> consider moving to CentOS Stream as it is much more up to date and allows us 
> to fix bugs faster, with less workarounds and overhead for maintaining old 
> code. E.g. our current integration tests do not really pass on CentOS 8.1 and 
> we can’t really do much about that other than wait for more up to date 
> packages. It would also bring us closer to make oVirt run smoothly on RHEL as 
> that is also much closer to Stream than it is to outdated CentOS.
> 
> So..would you like us to support CentOS Stream?
> The answer is yes, though I do not see any other option, if I'm not mistaken. 

...this was sent under very different circumstances:) Now it seems to be an 
easier call...

We will be probably moving to Stream a bit more. We did it already, but since 
there was very little interest it’s not entirely working across automation, CI, 
release processes.
It does depend on all the dependencies we consume so don’t expect it to happen 
in a month, it’s probably going to take a while 

To that note, there is also a possibility of oVirt on RHEL which some tried(or 
even use). It was not very helpful yet because again the dependencies are not 
really part of the OS and they are not being published in a way that we can 
consume them. But if this ever changes, it would be a good option for stable 
underlying OS and up-to-date oVirt….

> 
> We don’t really have capacity to run 3 different platforms, would you still 
> want oVirt to support CentOS Stream if it means “less support” for regular 
> CentOS? 
> There are some concerns about Stream being a bit less stable, do you share 
> those concerns?
> 
> Thank you for your comments,
> michal
> ___
> Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
> To unsubscribe send an email to users-le...@ovirt.org 
> <mailto:users-le...@ovirt.org>
> Privacy Statement: https://www.ovirt.org/privacy-policy.html 
> <https://www.ovirt.org/privacy-policy.html>
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/ 
> <https://www.ovirt.org/community/about/community-guidelines/>
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/3B5MJKO7BS2DMQL3XOXPNO4BU3YDL52T/
>  
> <https://lists.ovirt.org/archives/list/users@ovirt.org/message/3B5MJKO7BS2DMQL3XOXPNO4BU3YDL52T/>

___
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/2Z33AH4XOFNIPL33PIAY6QLDMAZA7G5Z/

[ovirt-users] Re: difference between CPU server and client family

[Michal Skrivanek]

> On 9 Dec 2020, at 15:16, jb  wrote:
> 
> 
> 
> Am 09.12.20 um 14:42 schrieb Michal Skrivanek:
>> 
>> 
>>> On 9 Dec 2020, at 09:09, jb >> <mailto:jonba...@gmail.com>> wrote:
>>> 
>>> Thanks Michal for the explanation. I will dive in this article and see if I 
>>> understand it :-).
>>> 
>>> I use here the latest 4.4.3.12 Version. So I can hope, that newer version 
>>> will support my CPUs better :).
>>> 
>>> 
>> 
>> not sure.
>> 4.5 cluster level adds IceLake which is Gen10, that should work with CentOS 
>> 8.3 newly.
>> It could be that your particular model is something in between…
>> 
>> Either way, if you really do need every feature from the CPU and you’re 
>> willing to sacrifice migration compatibility you can always use CPU host 
>> passthrough. Then it ignores any compatibility and just uses everything it 
>> can(everything that KVM supports) from the underlying CPU
> No I don't need every feature. My concern was mostly, if I will have any 
> performance downsides in normal scenarios.
> 
A  compromise makes sense then. Because on one hand you do not need 
compatibility with CPUs that you don’t have because they’re 10 years old, vs 
you’re not recompiling every application with the highest optimizations to use 
the latest greatest instructions…so…using whatever it detects is usually the 
best choice:)
> 
>>> Am 08.12.20 um 19:12 schrieb Michal Skrivanek:
>>>> qemu CPUs are mostly mapping to microarchitectures, for this one there’s 
>>>> excessive number of details at [1] :)
>>>> 
>>>> but yours seems to be CofeeLake (8th gen) which is not really supported 
>>>> yet in that version. Well, you didn’t say anything about what your version 
>>>> is, so I don’t know for sure…
>>>> 
>>>> It’s usually a compromise between what the hardware has and what has been 
>>>> implemented just yet
>>>> 
>>>> Thanks,
>>>> michal
>>>> 
>>>> 
>>>> 
>>>> [1] https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server) 
>>>> <https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server)>
>>>> 
>>>>> On 8 Dec 2020, at 17:09, jb >>>> <mailto:jonba...@gmail.com>> wrote:
>>>>> 
>>>>> I get this output:
>>>>> 
>>>>> "cpuFlags": 
>>>>> "sse4_2,hle,mpx,pti,pge,pbe,rtm,popcnt,cpuid,md-clear,lm,invtsc,invpcid_single,ibrs,tsc_deadline_timer,movbe,avx2,ibpb,pse36,umip,hypervisor,erms,fpu,bts,monitor,cmov,arch-capabilities,nx,mca,abm,pschange-mc-no,aes,ht,xsaves,ds_cpl,nonstop_tsc,adx,epb,bmi2,hwp,hwp_act_window,dtherm,aperfmperf,vme,invpcid,art,nopl,fsgsbase,pts,sep,cx8,msr,acpi,x2apic,xgetbv1,fma,flush_l1d,vmx,sse2,pat,constant_tsc,ssbd,sdbg,rdrand,clflushopt,cx16,ept,tsc_adjust,intel_pt,pse,de,stibp,sse,vpid,hwp_epp,ida,xsavec,arat,pae,clflush,tm,rdtscp,lahf_lm,cpuid_fault,pclmulqdq,fxsr,flexpriority,mtrr,syscall,ssse3,pdcm,3dnowprefetch,sse4_1,smep,rep_good,est,tpr_shadow,smap,dts,skip-l1dfl-vmentry,tm2,vnmi,hwp_notify,tsc_known_freq,mmx,dtes64,xsave,arch_perfmon,avx,rdseed,smx,ss,xtpr,f16c,bmi1,pni,pdpe1gb,apic,mce,xtopology,xsaveopt,pebs,pcid,tsc,md_clear,amd-ssbd,pln,spec_ctrl,model_Conroe,model_kvm32,model_Penryn,model_Skylake-Client-noTSX-IBRS,model_IvyBridge-IBRS,model_Broadwell-noTSX-IBRS,model_Opteron_G2,model_n270,model_SandyBridge-IBRS,model_pentium,model_kvm64,model_Westmere,model_Haswell-noTSX-IBRS,model_Haswell,model_pentium2,model_pentium3,model_Westmere-IBRS,model_Opteron_G1,model_Skylake-Client-IBRS,model_Nehalem,model_coreduo,model_Skylake-Client,model_qemu64,model_Haswell-IBRS,model_Haswell-noTSX,model_Broadwell-IBRS,model_IvyBridge,model_core2duo,model_486,model_Nehalem-IBRS,model_Broadwell-noTSX,model_SandyBridge,model_Broadwell,model_qemu32",
>>>>> "cpuModel": "Intel(R) Xeon(R) E-2246G CPU @ 3.60GHz",
>>>>> "cpuSockets": "1",
>>>>> "cpuSpeed": "4499.377",
>>>>> "cpuThreads": "12",
>>>>> "deferred_preallocation": true,
>>>>> 
>>>>> 
>>>>> 
>>>>> Does this says something to you?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Am 08.12.20 um 17:02 schrieb Vinícius Ferrão:
>>>>>> AFAIK Client is for the i3/i5/i7/i9 families and the other one is for 
>>>>>> Xeon platforms.
&g

[ovirt-users] Re: difference between CPU server and client family

[Michal Skrivanek]

> On 9 Dec 2020, at 09:09, jb  wrote:
> 
> Thanks Michal for the explanation. I will dive in this article and see if I 
> understand it :-).
> 
> I use here the latest 4.4.3.12 Version. So I can hope, that newer version 
> will support my CPUs better :).
> 
> 

not sure.
4.5 cluster level adds IceLake which is Gen10, that should work with CentOS 8.3 
newly.
It could be that your particular model is something in between…

Either way, if you really do need every feature from the CPU and you’re willing 
to sacrifice migration compatibility you can always use CPU host passthrough. 
Then it ignores any compatibility and just uses everything it can(everything 
that KVM supports) from the underlying CPU

> Best regards
> 
> Jonathan
> 
> 
> 
> Am 08.12.20 um 19:12 schrieb Michal Skrivanek:
>> qemu CPUs are mostly mapping to microarchitectures, for this one there’s 
>> excessive number of details at [1] :)
>> 
>> but yours seems to be CofeeLake (8th gen) which is not really supported yet 
>> in that version. Well, you didn’t say anything about what your version is, 
>> so I don’t know for sure…
>> 
>> It’s usually a compromise between what the hardware has and what has been 
>> implemented just yet
>> 
>> Thanks,
>> michal
>> 
>> 
>> 
>> [1] https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server) 
>> <https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server)>
>> 
>>> On 8 Dec 2020, at 17:09, jb >> <mailto:jonba...@gmail.com>> wrote:
>>> 
>>> I get this output:
>>> 
>>> "cpuFlags": 
>>> "sse4_2,hle,mpx,pti,pge,pbe,rtm,popcnt,cpuid,md-clear,lm,invtsc,invpcid_single,ibrs,tsc_deadline_timer,movbe,avx2,ibpb,pse36,umip,hypervisor,erms,fpu,bts,monitor,cmov,arch-capabilities,nx,mca,abm,pschange-mc-no,aes,ht,xsaves,ds_cpl,nonstop_tsc,adx,epb,bmi2,hwp,hwp_act_window,dtherm,aperfmperf,vme,invpcid,art,nopl,fsgsbase,pts,sep,cx8,msr,acpi,x2apic,xgetbv1,fma,flush_l1d,vmx,sse2,pat,constant_tsc,ssbd,sdbg,rdrand,clflushopt,cx16,ept,tsc_adjust,intel_pt,pse,de,stibp,sse,vpid,hwp_epp,ida,xsavec,arat,pae,clflush,tm,rdtscp,lahf_lm,cpuid_fault,pclmulqdq,fxsr,flexpriority,mtrr,syscall,ssse3,pdcm,3dnowprefetch,sse4_1,smep,rep_good,est,tpr_shadow,smap,dts,skip-l1dfl-vmentry,tm2,vnmi,hwp_notify,tsc_known_freq,mmx,dtes64,xsave,arch_perfmon,avx,rdseed,smx,ss,xtpr,f16c,bmi1,pni,pdpe1gb,apic,mce,xtopology,xsaveopt,pebs,pcid,tsc,md_clear,amd-ssbd,pln,spec_ctrl,model_Conroe,model_kvm32,model_Penryn,model_Skylake-Client-noTSX-IBRS,model_IvyBridge-IBRS,model_Broadwell-noTSX-IBRS,model_Opteron_G2,model_n270,model_SandyBridge-IBRS,model_pentium,model_kvm64,model_Westmere,model_Haswell-noTSX-IBRS,model_Haswell,model_pentium2,model_pentium3,model_Westmere-IBRS,model_Opteron_G1,model_Skylake-Client-IBRS,model_Nehalem,model_coreduo,model_Skylake-Client,model_qemu64,model_Haswell-IBRS,model_Haswell-noTSX,model_Broadwell-IBRS,model_IvyBridge,model_core2duo,model_486,model_Nehalem-IBRS,model_Broadwell-noTSX,model_SandyBridge,model_Broadwell,model_qemu32",
>>> "cpuModel": "Intel(R) Xeon(R) E-2246G CPU @ 3.60GHz",
>>> "cpuSockets": "1",
>>> "cpuSpeed": "4499.377",
>>> "cpuThreads": "12",
>>> "deferred_preallocation": true,
>>> 
>>> 
>>> 
>>> Does this says something to you?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Am 08.12.20 um 17:02 schrieb Vinícius Ferrão:
>>>> AFAIK Client is for the i3/i5/i7/i9 families and the other one is for Xeon 
>>>> platforms.
>>>> 
>>>> But you have pretty unusually Xeon, so it may be missing some flags that 
>>>> will properly classify the CPU.
>>>> 
>>>> You can run this on the host to check what’s detected:
>>>> 
>>>> [root]# vdsm-client Host getCapabilities
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On 8 Dec 2020, at 10:52, jb  
>>>>> <mailto:jonba...@gmail.com> wrote:
>>>>> 
>>> ___
>>> Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
>>> To unsubscribe send an email to users-le...@ovirt.org 
>>> <mailto:users-le...@ovirt.org>
>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html 
>>> <https://www.ovirt.org/privacy-policy.html>
>>> oVirt Code of Conduct: 
>>> https://www.ovirt.org/community/about/community-guidelines/ 
>>> <https://www.ovirt.org/community/about/community-guidelines/>
>>> List Archives: 
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/XXI2TXLN6BW4PISDQXQGNZL5WB32CGKV/
>>>  
>>> <https://lists.ovirt.org/archives/list/users@ovirt.org/message/XXI2TXLN6BW4PISDQXQGNZL5WB32CGKV/>
>> 

___
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/GEB3KW6SLXES56MJFNDA4USS3D3YBBSE/

[ovirt-users] Re: CentOS 8 is dead

[Michal Skrivanek]

> On 9 Dec 2020, at 01:21, thilb...@generalpacific.com wrote:
> 
> I to would like to see if Ubuntu could become a bit more main stream with 
> oVirt now that CentOS is gone. I'm sure we won't hear anything until 2021 the 
> oVirt staff need to figure out what to do now.

Right now we’re happy that CentOS 8.3 is finally here. That aligns 4.4.3 and 
4.4.4 again, makes the 4.5 cluster level usable, tons of bug fixes. 
Afterwards…well, I think Stream is not a bad option, we already have it in some 
form. I suppose it’s going to be the most feasible option.
For anything else *someone* would need to do all the work. And I don’t mean it 
in a way that we - all the people with @redhat.com address - are forbidden to 
do that or something, it’s really about the sheer amount of work and dedication 
required, doubling the integration efforts. oVirt is (maybe surprisingly) 
complex and testing it on any new platform means a lot of extra manpower. 


> ___
> 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/7HHQH2XIHK2VPV4TTERO2NH7DGEYUWV4/
___
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/JCX24N4UYHZ6HAIE32D2FV4ZT3BAIZYH/

[ovirt-users] Re: CentOS 8 is dead

[Michal Skrivanek]

> On 8 Dec 2020, at 20:55, Wesley Stewart  wrote:
> 
> This is a little concerning.  
> 
> But it seems pretty easy to convert:
> https://www.centos.org/centos-stream/ 
> 
> However I would be curious to see if someone tests this with having an active 
> ovirt node!

We have CentOS Stream release rpm for a while now[1]. It’s not actively used 
AFAIK but we wanted to explore that since CentOS was long term lagging behind 
released versions.

It’s not really that important what OS we run on, the biggest problem is the 
other dependencies we have, jboss, ansible, openvswitch, virt stack - that 
doesn’t come from CentOS. If we get regular development and reliable releases 
of our dependencies on Stream then we can make oVirt as stable there as it is 
now on CentOS.


> 
> On Tue, Dec 8, 2020 at 2:39 PM Strahil Nikolov via Users  > wrote:
> Hello All,
> 
> I'm really worried about the following news: 
> https://blog.centos.org/2020/12/future-is-centos-stream/ 
> 
> 
> Did anyone tried to port oVirt to SLES/openSUSE or any Debian-based
> distro ?

We did invest in Debian support long long time ago (we eventually gave up due 
to lack of capacity and reliable/up-to-date dependencies)
We did support PowerKVM distro for ppc64 during the time when IBM was switching 
from PowerVM to qemu (it stopped being relevant). 
And Fedora (same reason as debian, but it still works)

Again, it’s not such a big deal to run on other distro, there’s work in oVirt 
that needs to happen but as long as it is not exotic and versions are not too 
off it’s not really that big of a change, IMHO. What is a big deal is a long 
term commitment to maintain that and help/provide CI resources.

Thanks,
michal

[1] 
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/3B5MJKO7BS2DMQL3XOXPNO4BU3YDL52T/

> 
> 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/
>  
> 
> ___
> 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/W2AUQ3UFT6SHPDTRXPVHQUL2VKKCAUSR/

___
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/KXLY4WOYLHLSCHRNYZHUTLUEA3PC3JDR/

[ovirt-users] Re: difference between CPU server and client family

[Michal Skrivanek]

qemu CPUs are mostly mapping to microarchitectures, for this one there’s 
excessive number of details at [1] :)

but yours seems to be CofeeLake (8th gen) which is not really supported yet in 
that version. Well, you didn’t say anything about what your version is, so I 
don’t know for sure…

It’s usually a compromise between what the hardware has and what has been 
implemented just yet

Thanks,
michal



[1] https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server)

> On 8 Dec 2020, at 17:09, jb  wrote:
> 
> I get this output:
> 
> "cpuFlags": 
> "sse4_2,hle,mpx,pti,pge,pbe,rtm,popcnt,cpuid,md-clear,lm,invtsc,invpcid_single,ibrs,tsc_deadline_timer,movbe,avx2,ibpb,pse36,umip,hypervisor,erms,fpu,bts,monitor,cmov,arch-capabilities,nx,mca,abm,pschange-mc-no,aes,ht,xsaves,ds_cpl,nonstop_tsc,adx,epb,bmi2,hwp,hwp_act_window,dtherm,aperfmperf,vme,invpcid,art,nopl,fsgsbase,pts,sep,cx8,msr,acpi,x2apic,xgetbv1,fma,flush_l1d,vmx,sse2,pat,constant_tsc,ssbd,sdbg,rdrand,clflushopt,cx16,ept,tsc_adjust,intel_pt,pse,de,stibp,sse,vpid,hwp_epp,ida,xsavec,arat,pae,clflush,tm,rdtscp,lahf_lm,cpuid_fault,pclmulqdq,fxsr,flexpriority,mtrr,syscall,ssse3,pdcm,3dnowprefetch,sse4_1,smep,rep_good,est,tpr_shadow,smap,dts,skip-l1dfl-vmentry,tm2,vnmi,hwp_notify,tsc_known_freq,mmx,dtes64,xsave,arch_perfmon,avx,rdseed,smx,ss,xtpr,f16c,bmi1,pni,pdpe1gb,apic,mce,xtopology,xsaveopt,pebs,pcid,tsc,md_clear,amd-ssbd,pln,spec_ctrl,model_Conroe,model_kvm32,model_Penryn,model_Skylake-Client-noTSX-IBRS,model_IvyBridge-IBRS,model_Broadwell-noTSX-IBRS,model_Opteron_G2,model_n270,model_SandyBridge-IBRS,model_pentium,model_kvm64,model_Westmere,model_Haswell-noTSX-IBRS,model_Haswell,model_pentium2,model_pentium3,model_Westmere-IBRS,model_Opteron_G1,model_Skylake-Client-IBRS,model_Nehalem,model_coreduo,model_Skylake-Client,model_qemu64,model_Haswell-IBRS,model_Haswell-noTSX,model_Broadwell-IBRS,model_IvyBridge,model_core2duo,model_486,model_Nehalem-IBRS,model_Broadwell-noTSX,model_SandyBridge,model_Broadwell,model_qemu32",
> "cpuModel": "Intel(R) Xeon(R) E-2246G CPU @ 3.60GHz",
> "cpuSockets": "1",
> "cpuSpeed": "4499.377",
> "cpuThreads": "12",
> "deferred_preallocation": true,
> 
> 
> 
> Does this says something to you?
> 
> 
> 
> 
> 
> Am 08.12.20 um 17:02 schrieb Vinícius Ferrão:
>> AFAIK Client is for the i3/i5/i7/i9 families and the other one is for Xeon 
>> platforms.
>> 
>> But you have pretty unusually Xeon, so it may be missing some flags that 
>> will properly classify the CPU.
>> 
>> You can run this on the host to check what’s detected:
>> 
>> [root]# vdsm-client Host getCapabilities
>> 
>> Sent from my iPhone
>> 
>>> On 8 Dec 2020, at 10:52, jb  
>>>  wrote:
>>> 
> ___
> 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/XXI2TXLN6BW4PISDQXQGNZL5WB32CGKV/

___
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/PGVY4QZUDW2XUKEYM6CVNLVNVUDSABTR/

[ovirt-users] Re: How to re-enroll (or renew) host certificates for a single-host hosted-engine deployment?

[Michal Skrivanek]

> On 7 Dec 2020, at 15:35, Gianluca Cecchi  wrote:
> 
> On Mon, Dec 7, 2020 at 2:22 PM Derek Atkins  > wrote:
> [snip] 
> 
> The main advantages of ovirt over virt-manager is the access-control and
> remote-access capabilities.  Specifically, I have several users which have
> different access to different VMs and their consoles.  Without providing
> ssh access to the host, I wasn't sure how to provide that access in a
> clean way via virt-manager.
> 
> I *used* to use vmware-server, and kept that running as long as I could
> (on a single server).  But that hardware was running long in the tooth, so
> I migrated to ovirt because it gave me a similar web-based UI interface to
> my users so it was relatively easy to migrate them.  When I migrated 4-5
> years ago, virt-manager was still in relative infancy and, IIRC, didn't
> have much remote capability.
> 
> 
> +1 here.
> And I think developers should put more attention in single host environments 
> than lastly done.

well, the truth is it is a corner case. I’m not saying it shouldn’t work but as 
Didi said a single host management was never the main goal. We’ve built oVirt 
around shared storage and DC scalability, that it sort of happens to work with 
single host is….nice, but it’s really not that typical. There are better 
options for desktop-like virtualization in OSS world, there’s virt-manager, 
there’s VM management in cockpit UI, gnome-boxes.

> Derek explained very well what could be many common situations to have a 
> single host environment and the reason not to use virt-manager and such.
> At time there was the all-in-one and then it was deprecated/abandoned in 
> favour of single host deployment.

yes. but it was never meant to be a real thing in a first place, it was created 
just for demo purposes so it can run on a single laptop. 

> Now due to perhaps ansible playbook or new logic in host upgrades it seems to 
> see more and more messages about single host not supported.

it’s not intentional, just not tested enough so it keeps breaking. we really 
can’t test every use case in automation.

> In my opinion to do a reinstall every minor update is not feasible.
> The free version of ESXi could become a more appealing alternative in the 
> near future for these kind of usages, with the risk of potentially eating 
> away also the bigger shape scenario then.
> Perhaps to support again the all-in-one effort could be a good approach.

all-in-one was awful, i’d rather fix those few little things around single host 
deployment:)

> 
> If you think it can get more attention I can open an RFE for revamping 
> all-in-one or an RFE to provide a mechanism to have an host update itself 
> through a locally executed playbook and then "acquired" by the SHE in a 
> second time when exiting global maintenance.
> I don't know the internals enough and I have not the coding skills, but I can 
> support testing the functionality

I don’t think it would take too much attention, TBH. We’re still dealing with 
4.4 and el8 complications (it’s still fairly early since GA of a major release)
What would make sense, I think, is to identify the actual issues/complications 
and do them differently, like indeed a special local playbooks or whatnot, or 
“special” hacks. And then document on oVirt wiki. But otherwise I do not really 
see them supportable - the amount of work to e.g. re-enroll certs on a running 
host is just too much to do properly, and everyone has a different level of 
“risk” they accept.

HTH,
michal

> 
> Thanks for listening
> 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/IXXAXY7IMAWSL7MSHHZN5JPHFWEI6GPF/

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

[ovirt-users] Re: Ballooning disabled when creating a VmPool

[Michal Skrivanek]

Hi Nicolas,
it does sound like a bug, ballooning shouldn’t be disabled in this case.
does it behave the same in GUI?

Thanks,
michal

> On 12 Nov 2020, at 11:49, Nicolás  wrote:
> 
> Sorry, I forgot to add the screenshot!
> 
> El 11/11/20 a las 12:32, Nicolás escribió:
>> Hi,
>> 
>> We're using oVirt 4.3.8 along with ovirt-engine-sdk-python (4.4.1) to handle 
>> our pools.
>> 
>> Pools are based on a template which has ballooning enabled. However, when 
>> deploying a VmPool based on that template, has the "Ballooning enabled" 
>> field disabled, uneditable and an icon which states: "The field is not 
>> attached to any instance type" (screenshot attached).
>> 
>> We're handling a big number of VMs based on pools (> 1500), and we think 
>> this should be enabled.
>> 
>> However, I don't see a field in the types.VmPool definition that allows that.
>> 
>> Is that even doable? Our Python code is similar to this:
>> newpool = types.VmPool(name='test',
>>  cluster=cl,
>>  template=t,
>>  max_user_vms=1,
>>  size=1,
>>  type=types.VmPoolType.MANUAL)
>> vmpool_serv.add(newpool)
>> 
>> cl is a types.Cluster instance with ballooning_enabled=True
>> t is a types.Template instance with Ballooning enabled.
>> Thanks.
>> 
>> Nico
>> 
>> 
>> 
>> ___
>> 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/FRWPZSNGX5UCZJW7NIT6XY72BFYTTHOL/
>>  
>> 
> 
>  12-17-02.png>___
> 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/PFO66W2AVDEPMZ74BG76IWJ4DRSY7TSF/

___
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/32N6GGDHWGRMMLINAA5DHWUDFUPLUREO/

[ovirt-users] Re: oVirt 4.4.2 MS Windows 10 sysprep floppy

[Michal Skrivanek]

> On 10 Nov 2020, at 12:30, ozme...@hotmail.com wrote:
> 
> thanks for reply,
> I've made a template W10 and sealed with sysprep generize.
> After now, we want to use this template for new user vms.
> For example, a user wants a vm for personnel usage.
> I create a new vm from template which sealed.
> after creation, we want to customize this vm for the person by using sysprep.
> Change Windows pc name, join domain and assign to specific OU

you can see the resulting unattend.xml, that’s all that we do, if windows is 
not happy with it you’d need to dig into logs
if you modified the template(and even if you didn’t, but it still doesn’t 
really work) you would have to check windows what’s failing. They keep changing 
the options and behavior between versions way too often and we don’t have 
automated tests for each and every sysprep option, so it could be that the 
particular setting in a particular windows version doesn’t work correctly.

Thanks,
michal

> ___
> 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/N5BF5NNEW7CQWA7A5JKQPB2L4ATBOZV3/
___
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/4A72Y57JPUCBLSRBG5ONJOKLLVF6MREQ/

[ovirt-users] Re: How can you avoid breaking 4.3.11 legacy VMs imported in 4.4.1 during a migration?

[Michal Skrivanek]

> On 31 Aug 2020, at 21:20, Arik Hadas  wrote:
> 
> 
> 
> On Mon, Aug 31, 2020 at 8:41 PM  > wrote:
> Testing the 4.3 to 4.4 migration... what I describe here is facts is mostly 
> observations and conjecture, could be wrong, just makes writing easier...
> 
> While 4.3 seems to maintain a default emulated machine type 
> (pc-i440fx-rhel7.6.0 by default), it doesn't actually allow setting it in the 
> cluster settings: Could be built-in, could be inherited from the default 
> template... Most of my VMs were created with the default on 4.3.
> 
> oVirt 4.4 presets that to pc-q35-rhel8.1.0 and that has implications:
> 1. Any VM imported from an export on a 4.3 farm, will get upgraded to Q35, 
> which unfortunately breaks things, e.g. network adapters getting renamed as 
> the first issue I stumbled on some Debian machines 
> 2. If you try to compensate by lowering the cluster default from Q35 to 
> pc-i44fx the hosted-engine will fail, because it was either built or came as 
> Q35 and can no longer find critical devices: It evidently doesn't take/use 
> the VM configuration data it had at the last shutdown, but seems to 
> re-generate it according to some obscure logic, which fails here.

that is currently the case, yes. We have 
https://bugzilla.redhat.com/show_bug.cgi?id=1871694 - should be fixed by that, 
right?

> 
> I've tried creating a bit of backward compatibility by creating another 
> template based on pc-i440fx, but at the time of the import, I cannot switch 
> the template.
> If I try to downgrade the cluster, the hosted-engine will fail to start and I 
> can't change the template of the hosted-engine to something Q35.
> 
> Currently this leaves me in a position where I can't separate the move of VMs 
> from 4.3 to 4.4 and the upgrade of the virtual hardware, which is a different 
> mess for every OS in the mix of VMs.
> 
> Recommendations, tips anyone?
> 
> If you have to preserve the i440fx chipset, you can create another cluster 
> that is set with legacy bios and import the VMs to that cluster.
> The drawback in the alternative you tested (importing it to a q35 cluster and 
> override the chipset/emulated machine before launching the VM) is that on 
> import we 
> convert the VM to q35 (changing devices, clearing PCI addresses) and later 
> the VM is converted back to i440fx - so it's less recommended.

once the HE problem goes away it should be perfectly fine to just use that one 
cluster in i440fx mode if you prefer to. It’s q35 only because it’s a new one 
and we assume a new one is for new stuff. For upgraded setups the cluster is 
left as it was.

>  
> 
> P.S. A hypervisor reconstructing the virtual hardware from anywhere but 
> storage at every launch, is difficult to trust IMHO.
> ___
> 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/36WNCP6YMRM3MG44WIVHLVOUD2MACDQ5/
>  
> 
> ___
> 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/PAJJNL44JIIY3RAQTWB456EMQALV4SHM/

___
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/QDWSRU6XSBZ6BSPQNE3ZKJCDKKTHK6G7/

[ovirt-users] Re: POWER9 (ppc64le) Support on oVirt 4.4.1

[Michal Skrivanek]

> On 26 Aug 2020, at 20:50, Vinícius Ferrão via Users  wrote:
> 
> Okay here we go Arik.
> 
> With your insight I’ve done the following:
> 
> # rpm -Va 
> 
> This showed what’s zeroed on the machine, since it was a lot of things, I’ve 
> just gone crazy and done:

you should still have host deploy logs on the engine machine. it’s weird it 
succeeded, unless it somehow happened afterwards?

> yum list installed | cut -f 1 -d " " > file
> yum -y reinstall `cat file | xargs`
> 
> Reinstalled everything.
> 
> Everything worked as expected and I finally added the machine back to the 
> cluster. It’s operational.

eh, I wouldn’t trust it much. did you run redeploy at least?

> 
> Now I’ve another issue, I have 3 VM’s that are ppc64le, when trying to import 
> them, the Hosted Engine identifies them as x86_64:
> 
> 
> 
> So…
> 
> This appears to be a bug. Any ideia on how to force it back to ppc64? I can’t 
> manually force the import on the Hosted Engine since there’s no buttons to do 
> this…

how exactly did you import them? could be a bug indeed.
we don’t support changing it as it doesn’t make sense, the guest can’t be 
converted

Thanks,
michal

> 
> Ideias?
> 
>> On 26 Aug 2020, at 15:04, Vinícius Ferrão > > wrote:
>> 
>> What a strange thing is happening here:
>> 
>> [root@power ~]# file /usr/bin/vdsm-client
>> /usr/bin/vdsm-client: empty
>> [root@power ~]# ls -l /usr/bin/vdsm-client
>> -rwxr-xr-x. 1 root root 0 Jul  3 06:23 /usr/bin/vdsm-client
>> 
>> A lot of files are just empty, I’ve tried reinstalling vdsm-client, it 
>> worked, but there’s other zeroed files:
>> 
>> Transaction test succeeded.
>> Running transaction
>>   Preparing: 
>> 
>> 1/1 
>>   Reinstalling : vdsm-client-4.40.22-1.el8ev.noarch  
>> 
>> 1/2 
>>   Cleanup  : vdsm-client-4.40.22-1.el8ev.noarch  
>> 
>> 2/2 
>>   Running scriptlet: vdsm-client-4.40.22-1.el8ev.noarch  
>> 
>> 2/2 
>> /sbin/ldconfig: File /lib64/libkadm5clnt.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libsensors.so.4 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libsensors.so.4.4.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-admin.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-admin.so.0.6000.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-lxc.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-lxc.so.0.6000.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-qemu.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-qemu.so.0.6000.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt.so.0.6000.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libisns.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libiscsi.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libopeniscsiusr.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libopeniscsiusr.so.0.2.0 is empty, not checked.
>> 
>> /sbin/ldconfig: File /lib64/libkadm5clnt.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5clnt_mit.so.11.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libkadm5srv_mit.so.11.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libsensors.so.4 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libsensors.so.4.4.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-admin.so.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-admin.so.0.6000.0 is empty, not checked.
>> /sbin/ldconfig: File /lib64/libvirt-lxc.so.0 is empty, not checked.
>> /sbin/ldconfig: File 

[ovirt-users] Re: Support for Shared SAS storage

[Michal Skrivanek]

> On 12 Aug 2020, at 21:16, tho...@hoberg.net wrote:
> 
> 
>> 
>> Since 4.4 is the last feature release, this will never change even if it is 
>> not
>> documented.
>> 
>> Nir
> Hi Nir,
> could you please clarfiy: What does "last feature release" mean here: Is 
> oVirt being feature frozen in preparation to something more drastic?

no, features are not frozen. We’re moving to a mode where we deliver features 
in shorter cycles, in 4.4.z instead of one large 10+ month major release. (e.g. 
in 4.4.3 there’s 25 RFEs targeted currently)

That said, about the original discussion point - it’s very unlikely we’ll 
change behavior and we’ll keep treating any non-iscsi multipath devices as FC 
since it works good enough and actually enables special use cases 

Thanks,
michal

> ___
> 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/FKGE2VELIU3XBTWDC65CRETNCOTGEDWJ/
___
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/A6VTGF3TXEURFG25KPVJMHICACFGXRPU/

[ovirt-users] Re: [ovirt-devel] Error during deployment of self hosted engine oVirt 4.4

[Michal Skrivanek]

> On 6 Aug 2020, at 00:41, i iordanov  wrote:
> 
> Hi Michal,
> 
> I dug down enough to see that I could alter the option that specifies the 
> supported CPUs in the database. What would have helped me is a diff of what 
> was removed. Ultimately, I didn't have enough time to dig for the diff, but 
> if you know where it can be found it may be of use for other people that need 
> to use a Penryn based server.

Hi,
the diff is right there, the option value for 4.2 cluster still has it. so you 
just need that piece (penryn definition) to copy into the 4.4 entry(i 
think the numbers are then duplicated, but it shouldn’t really matter, cpu name 
is the "key”)

Thanks,
michal

> 
> I was able to swap two systems at my place and get a Nehalem one to use with 
> oVirt, but if I get a chance I may try to revert to the older one since it's 
> a bit more convenient for me to use. I would certainly try updating the DB if 
> I could get the diff where you guys removed the line from the DB seed files.
> 
> Cheers and thanks!
> iordan
> 
> On Tue, Aug 4, 2020 at 4:46 AM Michal Skrivanek  <mailto:michal.skriva...@redhat.com>> wrote:
> 
> 
>> On 4 Aug 2020, at 06:10, i iordanov > <mailto:iiorda...@gmail.com>> wrote:
>> 
>> It seems the issue stems from cpu type being empty.
>> 
>> 'cpu': {'architecture': 'undefined', 'type': ''}
>> 
>> 2020-08-03 23:31:39,888-0400 DEBUG 
>> otopi.ovirt_hosted_engine_setup.ansible_utils 
>> ansible_utils._process_output:103 cluster_facts: {'changed': False, 
>> 'ansible_facts': {'ovirt_clusters': [{'href': 
>> '/ovirt-engine/api/clusters/0eb77d38-d5fe-11ea-8808-00163e42a94a', 
>> 'comment': '', 'description': 'The default server cluster', 'id': 
>> '0eb77d38-d5fe-11ea-8808-00163e42a94a', 'name': 'Default', 
>> 'affinity_groups': [], 'ballooning_enabled': True, 'bios_type': 
>> 'cluster_default', 'cpu': {'architecture': 'undefined', 'type': ''}, 
>> 'cpu_profiles': [], 'data_center': {'href': 
>> '/ovirt-engine/api/datacenters/0ea3b60e-d5fe-11ea-a87c-00163e42a94a', 'id': 
>> '0ea3b60e-d5fe-11ea-a87c-00163e42a94a'}, 'enabled_features': [], 
>> 'error_handling': {'on_error': 'migrate'}, 'external_network_providers': [], 
>> 'fencing_policy': {'enabled': True, 'skip_if_connectivity_broken': 
>> {'enabled': False, 'threshold': 50}, 'skip_if_gluster_bricks_up': False, 
>> 'skip_if_gluster_quorum_not_met': False, 'skip_if_sd_active': {'enabled': 
>> False}}, 'firewall_type': 'firewalld', 'gluster_hooks': [], 
>> 'gluster_service': False, 'gluster_volumes': [], 'ha_reservation': False, 
>> 'ksm': {'enabled': True, 'merge_across_nodes': True}, 
>> 'log_max_memory_used_threshold': 95, 'log_max_memory_used_threshold_type': 
>> 'percentage', 'mac_pool': {'href': 
>> '/ovirt-engine/api/macpools/58ca604b-017d-0374-0220-014e', 'id': 
>> '58ca604b-017d-0374-0220-014e'}, 'memory_policy': {'over_commit': 
>> {'percent': 100}, 'transparent_huge_pages': {'enabled': True}}, 'migration': 
>> {'auto_converge': 'inherit', 'bandwidth': {'assignment_method': 'auto'}, 
>> 'compressed': 'inherit', 'encrypted': 'inherit', 'policy': {'id': 
>> '80554327-0569-496b-bdeb-fcbbf52b827b'}}, 'network_filters': [], 'networks': 
>> [], 'permissions': [], 'required_rng_sources': ['urandom'], 
>> 'scheduling_policy': {'href': 
>> '/ovirt-engine/api/schedulingpolicies/b4ed2332-a7ac-4d5f-9596-99a439cb2812', 
>> 'id': 'b4ed2332-a7ac-4d5f-9596-99a439cb2812'}, 'switch_type': 'legacy', 
>> 'threads_as_cores': False, 'trusted_service': False, 'tunnel_migration': 
>> False, 'version': {'major': 4, 'minor': 4}, 'virt_service': True, 
>> 'vnc_encryption': False}]}, 'deprecations': [{'msg': "The 
>> 'ovirt_cluster_facts' module has been renamed to 'ovirt_cluster_info', and 
>> the renamed one no longer returns ansible_facts", 'version': '2.13'}], 
>> 'failed': False}
>> 
>> Perhaps this Penryn series CPU is too old for this oVirt installation...
> 
> Yes, we dropped Penryn from supported CPU list i 4.3. You could probably stil 
> make it run but it would need messing with engine’s db, adding back Nehalem 
> entry to ServerCPUList(e.g. from 4.2 cluster version line) and resume the 
> deployment somehow.
> 
>> 
>> iordan
>> 
>> On Mon, Aug 3, 2020 at 11:54 PM i iordanov > <mailto:iiorda...@gmail.com>> wrote:
>> Hi guys,
>> 
>> I am trying to install oVirt 4.4 for testing of the aSPICE and Opaque 
>> Android clients and tried to follow this slightly outdated doc:
>> 
>> https://www.ovirt.org/documentation/installing_ovirt_as_a_self-hosted_engine_using_the_command_line/#Insta

[ovirt-users] Re: VM Portal on a stand alone server

[Michal Skrivanek]

> On 15 Jul 2020, at 17:12, Gal Villaret  wrote:
> 
> I have the engine running on a dedicated server.
> 
> I would like to separate the VM Portal to another server or maybe have 
> another instance of VM portal on another server.
> 
> The idea is to be able to put the VM Portal on a different subnet and to put 
> a firewall between it and the engine.

it’s possible in devel mode, see docker container at 
https://github.com/oVirt/ovirt-web-ui
but we’re not really updating it very often, I wouldn’t recommend it for 
production

What’s the concern if you limit access to :443 and use a proxy? There’s not 
much more a random joe can do without a permission to log into webadmin, 
there’s just a static landing page with few links.

> 
> Thanks. 
> 
> On Wed, Jul 15, 2020, 17:18 Sandro Bonazzola  > wrote:
> 
> 
> Il giorno mer 15 lug 2020 alle ore 12:26  > ha scritto:
> Hi Folks, 
> 
> I'm rather new to oVirt and loving it. 
> running 4.4.1. 
> I would like to be able to run the VM Portal on a stand-alone server for 
> security concerns. 
> 
> Can anyone point in the right direction for achieving this? 
> 
> Can you please elaborate?
> Are you asking for having the admin portal and the VM user portal running on 
> 2 different servers?
> Or running the engine on a dedicated server instead of on self hosted engine 
> VM?
> 
> 
>  
> 
> Thanks, 
> 
> Gal Villaret
> ___
> 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/3BE6CNDNLDKZQW5ANOC3UFT3BQZZFGHC/
>  
> 
> 
> 
> -- 
> Sandro Bonazzola
> MANAGER, SOFTWARE ENGINEERING, EMEA R 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/EDCHL6QLGDWU2GASCOXHC4B3DFHJNPBC/

___
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/LRELPGG4GFRDX4NAYARVT4IFBT6QXBL2/

[ovirt-users] Re: video virtio (instead of qxl)

[Michal Skrivanek]

> On 15 Jul 2020, at 19:05, Michael Lipp  wrote:
> 
> Am 15.07.20 um 17:36 schrieb Michal Skrivanek:
>> 
>>> On 14 Jul 2020, at 16:44, Michael Lipp  wrote:
>>> 
>>> Am 14.07.20 um 15:27 schrieb Michal Skrivanek:
>>>>> This works perfectly with my Fedora 32 and Arch guests and the change is 
>>>>> really worth it.
>>>> Hi,
>>>> what kind of performance benefits you’ve seen? 
>>>> 
>>>> It’s not currently in near term roadmap, but if anyone wants to contribute 
>>>> patches I don’t see a problem including it as an option for newer guests 
>>>> indeed.
>>> The display (spice) updates much faster and more "smoothly". Most
>>> notibly when using Arch VMs. With QXL, I have an extreme delay when
>>> typing. This vanishes completey with virtio-vga.
>> using which client? remote-viewer? on which platform?
>> qxl needs drivers, not sure if Arch has that…it should have, but for Windows 
>> you definitely need to install them. If they’re not all right it falls back 
>> to vga emulation which is then slow indeed
> 
> Using ... interesting question. I always assumed that virt-manager
> starts a viewer, but I cannot find one in my process list. So: using
> virt-manager.

for vnc and spice it embeds the same component as remote-viewer. There’s 
“graphics” which is the console protocol(spice,vnc) and “video” which is the 
emulated guest video card. You could use both for graphics(that’s what we 
default to since ~4.3) and then you can choose. I’m not sure what virt-manager 
does in this case. Either way, I would suspect it uses VNC


> 
> My Arch system has "xf86-video-qxl" installed and loads the "qxl" kernel
> module automatically when the guest configuration is set to using QXL.
> It does not automatically load "bochs_drm" as mentioned here
> (https://wiki.archlinux.org/index.php/QEMU#qxl 
> <https://wiki.archlinux.org/index.php/QEMU#qxl>). However, adding it
> "manually" doesn't make any difference.

it could be just a misconfiguration, I’m really not familiar with how this is 
supposed to be configured on Arch, sorry, but it generally works ok elsewhere.

> 
> I know about Windows. I'm using these guests with QXL and the windows
> drivers installed (AFAIK there are no virtio-vga drivers for Windows).
> Contrary to Arch, Windows+QXL works satisfactory.

ok. that’s another indication it’s rather on the guest side.

The only reason we’re not adding it just yet is that it lacks wider support 
(e.g. those Windows drivers) and there’s not much difference. It may be that on 
Arch it’s already useful, but it’s still not widespread enough so not on the 
list yet.
If anyone wants to contribute a patch it would be welcome (it’s not exactly 
trivial, but not too complex either)

Thanks,
michal

> 
>  - Michael
> 
>> 
>>> - Michael
>>> 
>>>> Thanks,
>>>> michal
>>>> 
>>>>> ___
>>>>> 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/IZQHW3NZB4BFGMP4LMJE2VTJ6H2OSWSB/

___
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/MKA22EZKWUEUA4ZPGQF6PODQMRDSHL7X/

[ovirt-users] Re: video virtio (instead of qxl)

[Michal Skrivanek]

> On 14 Jul 2020, at 16:44, Michael Lipp  wrote:
> 
> Am 14.07.20 um 15:27 schrieb Michal Skrivanek:
>> 
>>> This works perfectly with my Fedora 32 and Arch guests and the change is 
>>> really worth it.
>> Hi,
>> what kind of performance benefits you’ve seen? 
>> 
>> It’s not currently in near term roadmap, but if anyone wants to contribute 
>> patches I don’t see a problem including it as an option for newer guests 
>> indeed.
> 
> The display (spice) updates much faster and more "smoothly". Most
> notibly when using Arch VMs. With QXL, I have an extreme delay when
> typing. This vanishes completey with virtio-vga.

using which client? remote-viewer? on which platform?
qxl needs drivers, not sure if Arch has that…it should have, but for Windows 
you definitely need to install them. If they’re not all right it falls back to 
vga emulation which is then slow indeed

> 
>  - Michael
> 
>> Thanks,
>> michal
>> 
>>> ___
>>> 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/IZQHW3NZB4BFGMP4LMJE2VTJ6H2OSWSB/
> 
> 
___
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/MMSHCWHO74MXAGYPRZHHNXZTJJKFCB6R/

[ovirt-users] Re: video virtio (instead of qxl)

[Michal Skrivanek]

> On 14 Jul 2020, at 13:48, Michael Lipp  wrote:
> 
>> Do you mean virtio-vga / virtio-gpu?
> 
> virtio-vga. To be specific (libvirt):
> 
>
>  
>
>  
>   function='0x0'/>
>
> 
> which results in:
> 
> -device virtio-vga,id=video0,virgl=off,max_outputs=1,bus=pci.0,addr=0x2
> 
> This works perfectly with my Fedora 32 and Arch guests and the change is 
> really worth it.

Hi,
what kind of performance benefits you’ve seen? 

It’s not currently in near term roadmap, but if anyone wants to contribute 
patches I don’t see a problem including it as an option for newer guests indeed.

Thanks,
michal

> ___
> 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/IZQHW3NZB4BFGMP4LMJE2VTJ6H2OSWSB/
___
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/JFXH4LHDHE2CFEXXWVZPMFCYA2QJU4NA/

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

[Michal Skrivanek]

On 19 Jun 2020, at 16:40, Ritesh Chikatwar  wrote:




On Fri, Jun 19, 2020, 7:26 PM Michal Skrivanek 
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/3RBWL4PEJIEKNQ2GMONNJJDK2ZCWS4PO/

[ovirt-users] Re: status of oVirt 4.4.x and CentOS 8.2

[Michal Skrivanek]

> On 19 Jun 2020, at 13:16, Gianluca Cecchi  wrote:
> 
> Hello,
> what is the current status both if using plain CentOS based nodes and 
> ovirt-node-ng?
> Do the release of CentOS 8.2 impact new installation for 4.4.0 and/or 4.4.1rc?

Hi,
newer builds (the 4.4.1 build sandro sent just now) use 8.2 and require 8.2.
If you’d upgrade your existing 4.4.0/4.4.1 host to 8.2 it may not necessarily 
work, openvswitch issues might break. We were not testing it, CentOS releases 
are always without any heads up.
I would suggest to do it together with upgrading to 4.4.1 rc5, but certainly 
not on a production setupu just yet

Thanks,
michal

> 
> 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/5QZZNPOBXC5T5XXJ52ZWWR4PRKMJZIXK/
___
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/EPFMUOGKKP4Z3L6GDKD5ZRIQ6ZC77S4W/

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

[Michal Skrivanek]

> On 19 Jun 2020, at 13:41, Ritesh Chikatwar  wrote:
> 
> 
> 
> On Thu, Jun 18, 2020 at 11:59 PM Michal Skrivanek 
> mailto:michal.skriva...@redhat.com>> wrote:
> 
> 
>> On 18 Jun 2020, at 08:59, Ritesh Chikatwar > <mailto:rchik...@redhat.com>> 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?:)

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 <mailto:users@ovirt.org>
>> To unsubscribe send an email to users-le...@ovirt.org 
>> <mailto:users-le...@ovirt.org>
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html 
>> <https://www.ovirt.org/privacy-policy.html>
>> oVirt Code of Conduct: 
>> https://www.ovirt.org/community/about/community-guidelines/ 
>> <https://www.ovirt.org/community/about/community-guidelines/>
>> List Archives: 
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/3EBGCBFDUBHNI6G5E3NG4DCD7RQJLUNC/
>>  
>> <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/TZZZWD76X2PAFCIMR4GXEZARNWDJBCZ7/

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

[Michal Skrivanek]

> 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?

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

[ovirt-users] Re: CentOS Stream support

[Michal Skrivanek]

Hi all,
there were not that many responses, thank you Strahil for sharing your 
thoughts, but it’s still quite useful for our CI so we are adding a Stream 
variant anyway:)
Feel free to try it out, it has been added[1] to the ovirt-release-master rpm, 
you can now install that on top of a CentOS Stream host.
Do not use in production

Thanks,
michal

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1844389

> On 5 Jun 2020, at 12:55, Strahil Nikolov  wrote:
> 
> Hi Michael,
> 
> Thanks for raising that topic.
> I personally believe that the CentOS Stream will be something between Fedora 
> and RHEL and thus it won't be as stable as I wish.
> Yet on the other side , if this speeds up bug fixing - I am OK for that.
> 
> P.S.: I'm still on 4.3, but I was planing to switch to regular CentOS instead 
> of Stream.
> 
> 
> Best Regards,
> Strahil Nikolov
> 
> 
> 
> 
> 
> 
> В петък, 5 юни 2020 г., 11:37:16 Гринуич+3, Michal Skrivanek 
>  написа: 
> 
> 
> 
> 
> 
> Hi all,
> we would like to ask about interest in community about oVirt moving to CentOS 
> Stream.
> There were some requests before but it’s hard to see how many people would 
> really like to see that.
> 
> With CentOS releases lagging behind RHEL for months it’s interesting to 
> consider moving to CentOS Stream as it is much more up to date and allows us 
> to fix bugs faster, with less workarounds and overhead for maintaining old 
> code. E.g. our current integration tests do not really pass on CentOS 8.1 and 
> we can’t really do much about that other than wait for more up to date 
> packages. It would also bring us closer to make oVirt run smoothly on RHEL as 
> that is also much closer to Stream than it is to outdated CentOS.
> 
> So..would you like us to support CentOS Stream?
> We don’t really have capacity to run 3 different platforms, would you still 
> want oVirt to support CentOS Stream if it means “less support” for regular 
> CentOS? 
> There are some concerns about Stream being a bit less stable, do you share 
> those concerns?
> 
> Thank you for your comments,
> michal
> ___
> 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/3B5MJKO7BS2DMQL3XOXPNO4BU3YDL52T/
> 
___
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/7IURDXYD3EV6VL2DXDKYMXPTAUYL3VDK/

[ovirt-users] Re: Cannot start ppc64le VM's

[Michal Skrivanek]

> On 10 Jun 2020, at 07:00, Vinícius Ferrão  wrote:
> 
> 
> 
>> On 8 Jun 2020, at 07:43, Michal Skrivanek > <mailto:michal.skriva...@redhat.com>> wrote:
>> 
>> 
>> 
>>> On 5 Jun 2020, at 20:23, Vinícius Ferrão >> <mailto:fer...@versatushpc.com.br>> wrote:
>>> 
>>> Hi Michal
>>> 
>>>> On 5 Jun 2020, at 04:39, Michal Skrivanek >>> <mailto:michal.skriva...@redhat.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 5 Jun 2020, at 08:19, Vinícius Ferrão via Users >>>> <mailto:users@ovirt.org>> wrote:
>>>>> 
>>>>> Hello, I’m trying to run ppc64le VM’s on POWER9 but qemu-kvm fails 
>>>>> complaining about NUMA issues:
>>>> 
>>>> that is not a line you should be looking at, it’s just a harmless warning.
>>>> I suppose it’s the other one, about spectre fixes
>>>>> 
>>>>> VM ppc64le.local.versatushpc.com.br 
>>>>> <http://ppc64le.local.versatushpc.com.br/> is down with error. Exit 
>>>>> message: internal error: qemu unexpectedly closed the monitor: 
>>>>> 2020-06-05T06:16:10.716052Z qemu-kvm: warning: CPU(s) not present in any 
>>>>> NUMA nodes: CPU 4 [core-id: 4], CPU 5 [core-id: 5], CPU 6 [core-id: 6], 
>>>>> CPU 7 [core-id: 7], CPU 8 [core-id: 8], CPU 9 [core-id: 9], CPU 10 
>>>>> [core-id: 10], CPU 11 [core-id: 11], CPU 12 [core-id: 12], CPU 13 
>>>>> [core-id: 13], CPU 14 [core-id: 14], CPU 15 [core-id: 15] 
>>>>> 2020-06-05T06:16:10.716067Z qemu-kvm: warning: All CPU(s) up to maxcpus 
>>>>> should be described in NUMA config, ability to start up with partial NUMA 
>>>>> mappings is obsoleted and will be removed in future 
>>>>> 2020-06-05T06:16:11.155924Z qemu-kvm: Requested safe indirect branch 
>>>>> capability level not supported by kvm, try cap-ibs=fixed-ibs.
>>>>> 
>>>>> Any idea of what’s happening?
>>>>> 
>>>>> I found some links, but I’m not sure if they are related or not:
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1732726 
>>>>> <https://bugzilla.redhat.com/show_bug.cgi?id=1732726>
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1592648 
>>>>> <https://bugzilla.redhat.com/show_bug.cgi?id=1592648>
>>>> yes, they look relevant if that’s the hw you have. We do use 
>>>> pseries-rhel7.6.0-sxxm machine type in 4.3 (not in 4.4. that would be the 
>>>> preferred solution, to upgrade).
>>>> If you don’t care about security you can also modify the machine type per 
>>>> VM (or in engine db for all VMs) to "pseries-rhel7.6.0"
>>> 
>>> I’m using an AC922 machine.
>> 
>> and is it oVirt  4.3 or 4.4?
>> Bug 1732726 is on RHEL 8, so relevant only for oVirt 4.4, i.e. you’d have to 
>> have a 4.3 cluster level?
>> if you really want to keep using -sxxm you need to modify it to add the 
>> extra flag the bug talks about
>> 
>> this shouldn’t be needed in 4.4 cluster level though
> 
> Hi Michal, I’m running 4.3.10. Not in 4.4 yet.
> 
> So the workaround would be add cap-ibs=fixed-ibs to VM parameters so sxxm 
> would work? Where do I add this? Do you know?

you could try custom emulated machine in VM configuration. If it doesn’t work 
you’d need to write a vdsm hook to alter the libvirt xml accordingly


> 
> Thanks.
> 
>> 
>>> 
>>> In fact I can boot the VMs with pseries-rhel7.6.0 but not with 
>>> pseries-rhel7.6.0-sxxm; how do you made pseries-rhel7.6.0-sxxm works on 4.3 
>>> release?
>>> 
>>> # lscpu
>>> Architecture:  ppc64le
>>> Byte Order:Little Endian
>>> CPU(s):128
>>> On-line CPU(s) list:   0-127
>>> Thread(s) per core:4
>>> Core(s) per socket:16
>>> Socket(s): 2
>>> NUMA node(s):  6
>>> Model: 2.2 (pvr 004e 1202)
>>> Model name:POWER9, altivec supported
>>> CPU max MHz:   3800.
>>> CPU min MHz:   2300.
>>> L1d cache: 32K
>>> L1i cache: 32K
>>> L2 cache:  512K
>>> L3 cache:  10240K
>>> NUMA node0 CPU(s): 0-63
>>> NUMA node8 CPU(s): 64-127
>>> NUMA node252 CPU(s):   
>>> NUMA node253 CPU(s):   
>>> NUMA node254 CPU

[ovirt-users] Re: Cannot start ppc64le VM's

[Michal Skrivanek]

> On 5 Jun 2020, at 20:23, Vinícius Ferrão  wrote:
> 
> Hi Michal
> 
>> On 5 Jun 2020, at 04:39, Michal Skrivanek > <mailto:michal.skriva...@redhat.com>> wrote:
>> 
>> 
>> 
>>> On 5 Jun 2020, at 08:19, Vinícius Ferrão via Users >> <mailto:users@ovirt.org>> wrote:
>>> 
>>> Hello, I’m trying to run ppc64le VM’s on POWER9 but qemu-kvm fails 
>>> complaining about NUMA issues:
>> 
>> that is not a line you should be looking at, it’s just a harmless warning.
>> I suppose it’s the other one, about spectre fixes
>>> 
>>> VM ppc64le.local.versatushpc.com.br 
>>> <http://ppc64le.local.versatushpc.com.br/> is down with error. Exit 
>>> message: internal error: qemu unexpectedly closed the monitor: 
>>> 2020-06-05T06:16:10.716052Z qemu-kvm: warning: CPU(s) not present in any 
>>> NUMA nodes: CPU 4 [core-id: 4], CPU 5 [core-id: 5], CPU 6 [core-id: 6], CPU 
>>> 7 [core-id: 7], CPU 8 [core-id: 8], CPU 9 [core-id: 9], CPU 10 [core-id: 
>>> 10], CPU 11 [core-id: 11], CPU 12 [core-id: 12], CPU 13 [core-id: 13], CPU 
>>> 14 [core-id: 14], CPU 15 [core-id: 15] 2020-06-05T06:16:10.716067Z 
>>> qemu-kvm: warning: All CPU(s) up to maxcpus should be described in NUMA 
>>> config, ability to start up with partial NUMA mappings is obsoleted and 
>>> will be removed in future 2020-06-05T06:16:11.155924Z qemu-kvm: Requested 
>>> safe indirect branch capability level not supported by kvm, try 
>>> cap-ibs=fixed-ibs.
>>> 
>>> Any idea of what’s happening?
>>> 
>>> I found some links, but I’m not sure if they are related or not:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1732726 
>>> <https://bugzilla.redhat.com/show_bug.cgi?id=1732726>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1592648 
>>> <https://bugzilla.redhat.com/show_bug.cgi?id=1592648>
>> yes, they look relevant if that’s the hw you have. We do use 
>> pseries-rhel7.6.0-sxxm machine type in 4.3 (not in 4.4. that would be the 
>> preferred solution, to upgrade).
>> If you don’t care about security you can also modify the machine type per VM 
>> (or in engine db for all VMs) to "pseries-rhel7.6.0"
> 
> I’m using an AC922 machine.

and is it oVirt  4.3 or 4.4?
Bug 1732726 is on RHEL 8, so relevant only for oVirt 4.4, i.e. you’d have to 
have a 4.3 cluster level?
if you really want to keep using -sxxm you need to modify it to add the extra 
flag the bug talks about

this shouldn’t be needed in 4.4 cluster level though

> 
> In fact I can boot the VMs with pseries-rhel7.6.0 but not with 
> pseries-rhel7.6.0-sxxm; how do you made pseries-rhel7.6.0-sxxm works on 4.3 
> release?
> 
> # lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
> CPU(s):128
> On-line CPU(s) list:   0-127
> Thread(s) per core:4
> Core(s) per socket:16
> Socket(s): 2
> NUMA node(s):  6
> Model: 2.2 (pvr 004e 1202)
> Model name:POWER9, altivec supported
> CPU max MHz:   3800.
> CPU min MHz:   2300.
> L1d cache: 32K
> L1i cache: 32K
> L2 cache:  512K
> L3 cache:  10240K
> NUMA node0 CPU(s): 0-63
> NUMA node8 CPU(s): 64-127
> NUMA node252 CPU(s):   
> NUMA node253 CPU(s):   
> NUMA node254 CPU(s):   
> NUMA node255 CPU(s): 
> 
> Thank you for helping out.
> 
>> 
>> Thanks,
>> michal
>>> 
>>> Thanks,
>>> 
>>> ___
>>> Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
>>> To unsubscribe send an email to users-le...@ovirt.org 
>>> <mailto:users-le...@ovirt.org>
>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html 
>>> <https://www.ovirt.org/privacy-policy.html>
>>> oVirt Code of Conduct: 
>>> https://www.ovirt.org/community/about/community-guidelines/ 
>>> <https://www.ovirt.org/community/about/community-guidelines/>
>>> List Archives: 
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/PVVQDBO2XJYBQN7EUDMM74QZJ2UTLRJ2/
>>>  
>>> <https://lists.ovirt.org/archives/list/users@ovirt.org/message/PVVQDBO2XJYBQN7EUDMM74QZJ2UTLRJ2/>

___
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/3GZBCJR4WRPJTQVH6LKIHQEYUMYYYNXI/

[ovirt-users] CentOS Stream support

[Michal Skrivanek]

Hi all,
we would like to ask about interest in community about oVirt moving to CentOS 
Stream.
There were some requests before but it’s hard to see how many people would 
really like to see that.

With CentOS releases lagging behind RHEL for months it’s interesting to 
consider moving to CentOS Stream as it is much more up to date and allows us to 
fix bugs faster, with less workarounds and overhead for maintaining old code. 
E.g. our current integration tests do not really pass on CentOS 8.1 and we 
can’t really do much about that other than wait for more up to date packages. 
It would also bring us closer to make oVirt run smoothly on RHEL as that is 
also much closer to Stream than it is to outdated CentOS.

So..would you like us to support CentOS Stream?
We don’t really have capacity to run 3 different platforms, would you still 
want oVirt to support CentOS Stream if it means “less support” for regular 
CentOS? 
There are some concerns about Stream being a bit less stable, do you share 
those concerns?

Thank you for your comments,
michal
___
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/3B5MJKO7BS2DMQL3XOXPNO4BU3YDL52T/

[ovirt-users] Re: Cannot start ppc64le VM's

[Michal Skrivanek]

> On 5 Jun 2020, at 08:19, Vinícius Ferrão via Users  wrote:
> 
> Hello, I’m trying to run ppc64le VM’s on POWER9 but qemu-kvm fails 
> complaining about NUMA issues:

that is not a line you should be looking at, it’s just a harmless warning.
I suppose it’s the other one, about spectre fixes
> 
> VM ppc64le.local.versatushpc.com.br 
>  is down with error. Exit message: 
> internal error: qemu unexpectedly closed the monitor: 
> 2020-06-05T06:16:10.716052Z qemu-kvm: warning: CPU(s) not present in any NUMA 
> nodes: CPU 4 [core-id: 4], CPU 5 [core-id: 5], CPU 6 [core-id: 6], CPU 7 
> [core-id: 7], CPU 8 [core-id: 8], CPU 9 [core-id: 9], CPU 10 [core-id: 10], 
> CPU 11 [core-id: 11], CPU 12 [core-id: 12], CPU 13 [core-id: 13], CPU 14 
> [core-id: 14], CPU 15 [core-id: 15] 2020-06-05T06:16:10.716067Z qemu-kvm: 
> warning: All CPU(s) up to maxcpus should be described in NUMA config, ability 
> to start up with partial NUMA mappings is obsoleted and will be removed in 
> future 2020-06-05T06:16:11.155924Z qemu-kvm: Requested safe indirect branch 
> capability level not supported by kvm, try cap-ibs=fixed-ibs.
> 
> Any idea of what’s happening?
> 
> I found some links, but I’m not sure if they are related or not:
> https://bugzilla.redhat.com/show_bug.cgi?id=1732726 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1592648 
> 
yes, they look relevant if that’s the hw you have. We do use 
pseries-rhel7.6.0-sxxm machine type in 4.3 (not in 4.4. that would be the 
preferred solution, to upgrade).
If you don’t care about security you can also modify the machine type per VM 
(or in engine db for all VMs) to "pseries-rhel7.6.0"

Thanks,
michal
> 
> 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/PVVQDBO2XJYBQN7EUDMM74QZJ2UTLRJ2/

___
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/UHZGIBF6QPKO7GWYELULQGRZKYLUMLCK/