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

2021-09-24 Thread 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.

2021-09-24 Thread 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.

2021-09-24 Thread 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.

2021-09-23 Thread 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

2021-09-22 Thread 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.

2021-09-22 Thread 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

2021-09-02 Thread 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

2021-08-20 Thread 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.

2021-08-02 Thread 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"

2021-08-02 Thread 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

2021-07-28 Thread 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?

2021-07-21 Thread 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

2021-05-21 Thread 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

2021-05-20 Thread 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

2021-05-04 Thread 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

2021-05-03 Thread 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

2021-04-07 Thread 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

2021-04-07 Thread 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

2021-04-06 Thread 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

2021-04-01 Thread 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

2021-04-01 Thread 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

2021-03-30 Thread 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

2021-03-23 Thread 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

2021-03-23 Thread 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

2021-03-19 Thread 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

2021-02-24 Thread 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

2021-01-28 Thread 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

2021-01-26 Thread 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?

2021-01-26 Thread 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?

2021-01-26 Thread 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

2021-01-07 Thread 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

2020-12-09 Thread 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

2020-12-09 Thread 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

2020-12-09 Thread 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

2020-12-09 Thread 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

2020-12-08 Thread 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?

2020-12-07 Thread 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

2020-11-12 Thread 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

2020-11-10 Thread 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?

2020-09-01 Thread 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

2020-08-27 Thread 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

2020-08-13 Thread 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

2020-08-07 Thread 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

2020-07-15 Thread 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)

2020-07-15 Thread 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)

2020-07-15 Thread 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)

2020-07-14 Thread 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

2020-06-19 Thread 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

2020-06-19 Thread 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

2020-06-19 Thread 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

2020-06-18 Thread 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

2020-06-11 Thread 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

2020-06-10 Thread 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

2020-06-08 Thread 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

2020-06-05 Thread 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

2020-06-05 Thread 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/


[ovirt-users] Re: Weird problem starting VMs in oVirt-4.4

2020-06-04 Thread Michal Skrivanek


> On 4 Jun 2020, at 13:08, Joop  wrote:
> 
> On 3-6-2020 22:13, Strahil Nikolov wrote:
>> Is  it UEFI based  or the lagacy bios ?
> Legacy BIOS.
> 

> Hi,

it is indeed weird and I’m afraid there’s no clear indication where to start.
maybe try with different guests?
create a different VM and attach the same disk?
things like that to narrow it down…

> Joop
> 
>> 
>> Best Regards,
>> Strahil Nikolov
>> 
>> На 3 юни 2020 г. 19:00:48 GMT+03:00, Marco Fais  написа:
>>> Hi Joop
>>> 
>>> I am having the same problem -- thought initially was due to the VM
>>> import
>>> but it is now happening even on newly created VMs.
>>> Rebooting (e.g. ctrl-alt-del) the machine a couple of times solves the
>>> issue, but a power off / power on might cause it again...
>>> 
>>> Not sure how best to capture this behaviour in the logs yet...
>>> 
>>> Regards,
>>> Marco
>>> 
>>> On Wed, 3 Jun 2020 at 14:00, Joop  wrote:
>>> 
 Hi All,
 
 Just had a rather new experience in that starting a VM worked but the
 kernel entered grub2 rescue console due to the fact that something
>>> was
 wrong with its virtio-scsi disk.
 The message is Booting from Hard Disk 
 error: ../../grub-core/kern/dl.c:266:invalid arch-independent ELF
>>> maginc.
 entering rescue mode...
 
 Doing a CTRL-ALT-Del through the spice console let the VM boot
 correctly. Shutting it down and repeating the procedure I get a disk
 problem everytime. Weird thing is if I activate the BootMenu and then
 straight away start the VM all is OK.
 I don't see any ERROR messages in either vdsm.log, engine.log
 
 If I would have to guess it looks like the disk image isn't connected
 yet when the VM boots but thats weird isn't it?
 
 Regards,
 
 Joop
 
 ___
 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/TA6BJ2A4XUGKU7P47OGM42TT26GXZJXP/
> ___
> 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/EKU7MBUWBTXMUX3527ZCV4CKCKA6IWDC/
___
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/ZJTHASYXYQBXLXDVH4LKOBTMUHU5GOII/


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

2020-06-01 Thread Michal Skrivanek
I believe your problem is similar to Mark’s, you need qemu-kvm’s virtualized 
tsx-ctrl that was added to qemu 4.2 upstream and (I think) also the 
corresponding kernel-4.18.0-147.4.1.el8_1
can you confirm your versions?

all of these issues should be addressed in 8.2, we’re just still waiting for 
that:/


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

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

2020-06-01 Thread Michal Skrivanek


> On 28 May 2020, at 16:26, Mark R  wrote:
> 
> I should have also mentioned that I found an existing report for the issue 
> I'm having on RedHat's Bugzilla:  
> https://bugzilla.redhat.com/show_bug.cgi?id=1783180

And that is the one behind the problem
In  el8 this has been fixed by 
https://bugzilla.redhat.com/show_bug.cgi?id=1797092
kernel-4.18.0-147.8.el8. That is only in 8.2 (or probably CentOS Stream, but ew 
don’t have a CI or build system set up for it)
It’s probably easier to just update only the kernel from CentOS Stream and it 
may work good enough

We still use virt-ssbd in Secure type because it’s supposed to give you a 
mitigation in any case. You can always choose the insecure EPYC variant which 
doesn’t enable any of that. But you have to choose that explicitly

Thanks,
michal

> 
> Mark
> ___
> 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/IDIH7L3QLX6TPER6IY2KTUSMWGVIGP6W/
___
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/NOYPDQGQBKVWOIY6AVVXJVTN4FQ7HOKM/


[ovirt-users] Re: how to save stateless disk

2020-05-22 Thread Michal Skrivanek


> On 22 May 2020, at 12:52, Jiří Sléžka  wrote:
> 
> Hi,
> 
> I have one vm configured as stateless (useful for example for testing
> ansible deploying). But now I am in the middle of work and we have
> planned power outage. If I power down this wm now I will lost my work.

suspend/resume _may_ work. I would suggest to try that first:)
If it doesn’t work it’s worth a bug

> 
> It looks like I am unable to create snapshot if vm is in stateless
> state. Is there any trick how to not loose my stateless state?
> 
> Is it RFE worth problem? 
> 
> Cheers,
> 
> Jiri
> 
> ___
> 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/BZCJI4U3WQ22AHUU234TSNN5ZXJLXXCP/
___
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/QGW47AMZ5ZAFJL5KJLHYAE2AO3QLKZAR/


[ovirt-users] Re: [ovirt-devel] oVirt and Fedora

2020-05-20 Thread Michal Skrivanek


> On 19 May 2020, at 14:06, Neal Gompa  wrote:
> 
> On Mon, May 11, 2020 at 11:45 AM Michal Skrivanek
>  wrote:
>> 
>> 
>> 
>>> On 11 May 2020, at 14:49, Neal Gompa  wrote:
>>> 
>>> On Mon, May 11, 2020 at 8:32 AM Nir Soffer  wrote:
>>>> 
>>>> On Mon, May 11, 2020 at 2:24 PM Neal Gompa  wrote:
>>>>> 
>>>>> As far as the oVirt software keeping up with Fedora, the main problem 
>>>>> here has always been that people aren't integrating their software into 
>>>>> the distribution itself.
>> 
>> it was never a good fit for oVirt to be part of other distributions. We had 
>> individual packages part of Fedora in history, but there are things which 
>> are hard to accept (like automatically enabling of installed services, 
>> UIDs), and overall it’s just too complex, we’re rather a distribution than a 
>> simple app on top of base OS.
>> 
> 
> None of those things are hard to do in Fedora. They're incredibly easy
> to do. I know this because I've gone through this process already
> before.
> 
> But fine, let's assume I consider this argument valid. Then there's
> still no reason not to be continually providing support for Fedora as
> an add-on, as you have before.

the reason is mentioned in the original email, the lack of resources to keep 
actively supporting 3 different platforms.
If you want to provide a helping hand and maintain Fedora infrastructure I 
don’t think anyone would object 

> 
>>>>> That's how everything can get tested together. And this comes back to the 
>>>>> old bug about fixing vdsm so that it doesn't use /rhev, but instead 
>>>>> something FHS-compliant (RHBZ#1369102). Once that is resolved, pretty 
>>>>> much the entire stack can go into Fedora. And then you benefit from the 
>>>>> Fedora community being able to use, test, and contribute to the oVirt 
>>>>> project. As it stands, why would anyone do this for you when you don't 
>>>>> even run on the cutting edge platform that feeds into Red Hat Enterprise 
>>>>> Linux?
>>>> 
>>>> This was actually fixed a long time ago. With this commit:
>>>> https://github.com/oVirt/vdsm/commit/67ba9c4bc860840d6e103fe604b16f494f60a09d
>>>> 
>>>> You can configure a compatible vdsm that does not use /rhev.
>>>> 
>>>> Of course it is not backward compatible, for this we need much more
>>>> work to support live migration
>>>> between old and new vdsm using different data-center configurations.
>>>> 
>>> 
>>> It'd probably be simpler to just *change* it to an FHS-compatible path
>>> going forward with EL8 and Fedora and set up a migration path there,
>>> but it's a bit late for that... :(
>> 
>> It wouldn’t. We always support live migration across several versions (now 
>> it’s 4.2-4.4) and it needs to stay the same or youo have to go with arcane 
>> code to mangle it back and forth which gets a bit ugly when you consider 
>> suspend/resume, snapshots, etc
>> 
> 
> Erk. At some point you need to bite the bullet though...

it’s about capacity as well, it’s just a matter of someone writing a code which 
can handle the (long) transition period

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


[ovirt-users] Re: ovirt, SATA for VM Disks

2020-05-12 Thread Michal Skrivanek


> On 12 May 2020, at 17:09, kubunt...@gmail.com wrote:
> 
> is it possible to change the Interface to SATA?  (like KVM) 

yes. SATA is used with q35 VMs (default in 4.4)
___
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/DQXP7DUON6FALGGKZ5SMBFTXHWN7M3NX/


[ovirt-users] Re: [ovirt-devel] oVirt and Fedora

2020-05-11 Thread Michal Skrivanek


> On 11 May 2020, at 14:49, Neal Gompa  wrote:
> 
> On Mon, May 11, 2020 at 8:32 AM Nir Soffer  wrote:
>> 
>> On Mon, May 11, 2020 at 2:24 PM Neal Gompa  wrote:
>>> 
>>> As far as the oVirt software keeping up with Fedora, the main problem here 
>>> has always been that people aren't integrating their software into the 
>>> distribution itself.

it was never a good fit for oVirt to be part of other distributions. We had 
individual packages part of Fedora in history, but there are things which are 
hard to accept (like automatically enabling of installed services, UIDs), and 
overall it’s just too complex, we’re rather a distribution than a simple app on 
top of base OS.

>>> That's how everything can get tested together. And this comes back to the 
>>> old bug about fixing vdsm so that it doesn't use /rhev, but instead 
>>> something FHS-compliant (RHBZ#1369102). Once that is resolved, pretty much 
>>> the entire stack can go into Fedora. And then you benefit from the Fedora 
>>> community being able to use, test, and contribute to the oVirt project. As 
>>> it stands, why would anyone do this for you when you don't even run on the 
>>> cutting edge platform that feeds into Red Hat Enterprise Linux?
>> 
>> This was actually fixed a long time ago. With this commit:
>> https://github.com/oVirt/vdsm/commit/67ba9c4bc860840d6e103fe604b16f494f60a09d
>> 
>> You can configure a compatible vdsm that does not use /rhev.
>> 
>> Of course it is not backward compatible, for this we need much more
>> work to support live migration
>> between old and new vdsm using different data-center configurations.
>> 
> 
> It'd probably be simpler to just *change* it to an FHS-compatible path
> going forward with EL8 and Fedora and set up a migration path there,
> but it's a bit late for that... :(

It wouldn’t. We always support live migration across several versions (now it’s 
4.2-4.4) and it needs to stay the same or youo have to go with arcane code to 
mangle it back and forth which gets a bit ugly when you consider 
suspend/resume, snapshots, etc

> 
> 
> -- 
> 真実はいつも一つ!/ Always, there's only one truth!
> ___
> 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/SBAZ2F3FCOVGHRL7UNYTBLRX63BSBTCC/
___
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/SNM3D2ZBFXUQOA5PGU6FTLZOFYLJGM3V/


[ovirt-users] Re: export vm from 3.4 to 4.3

2020-04-13 Thread Michal Skrivanek
On 13 Apr 2020, at 12:56, Shani Leviim  wrote:


Hi Nagaraju,
You can detach the relevant storage domain and attach it back to the
relevant DC.
That functionality replaces the export domains.
You can find a detailed explanation here:
https://www.ovirt.org/develop/release-management/features/storage/importstoragedomain.html

You can also import a VM using an OVA file.
You can find the relevant information here:
https://www.ovirt.org/develop/release-management/features/virt/enhance-import-export-with-ova.html


It’s not going to work from 3.5 to 4.3 directly
If you have an old setup with those VMs then just incrementally upgrade.



*Regards,*

*Shani Leviim*


On Mon, Apr 13, 2020 at 11:25 AM Budur Nagaraju  wrote:

>  Hi
>
> Can someone help in exporting a vm from  3.5  to 4.3  version , any help
> or links for exporting a vm ?
>
> Thanks,
> Nagaraju
>
>
>
> ___
> 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/6S767MMLOBXFKT3LRYMVGUIX3P2LNYGY/
>
___
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/3VSKYBNUI2GW3HMGYOFR6OCRRIB65QW3/
___
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/5T3NXGIMQ5WMN5FEJFQCJB2CJJRBLPPG/


[ovirt-users] Re: Ovirt engine showing wrong host's memory usage

2020-03-16 Thread Michal Skrivanek


> On 13 Mar 2020, at 18:55, Alan G  wrote:
> 
> I've observed that oVirt considers cache/buffer memory as "used”.

Where do you see that?

> So a host can report, for example, 10% memory utilisation when hosting 0 VMs. 
> A reboot of the host will of course free all that memory and the host will 
> again report something close to 0%.
> 
> This caused me a shock a few weeks ago when I thought my cluster was running 
> out of memory.
> 
> Given that the kernel will give back the buffer memory as required, is it not 
> perhaps a bit misleading to count it as "used"?

it is not counted as used, 
https://github.com/oVirt/vdsm/blob/95d734bace00b87a17d333ac1871a489b1812160/lib/vdsm/host/api.py#L131
 
> 
> 
>  On Fri, 13 Mar 2020 17:47:34 + Michal Skrivanek 
>  wrote 
> 
> > On 10 Mar 2020, at 15:46, Noua TOUKOUROU  > <mailto:noua.toukou...@uni.lu>> wrote: 
> > 
> >  
> > Hi, 
> > 
> > My ovirt engine is showing wrong host's memory usage. Even when this one 
> > has no VM. 
> > How to fix it ? 
> 
> What’s wrong with it? 
> 
> > 
> > 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/XBHQUIDKZDNIKPNWGWIL67EVJA2QYXKG/
> >  
> > <https://lists.ovirt.org/archives/list/users@ovirt.org/message/XBHQUIDKZDNIKPNWGWIL67EVJA2QYXKG/>
> >  
> ___
> 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/FNYIXMSBRHV2A3U55UG2P2WAQ5P5CFXO/
>  
> <https://lists.ovirt.org/archives/list/users@ovirt.org/message/FNYIXMSBRHV2A3U55UG2P2WAQ5P5CFXO/>
> 
> 

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


[ovirt-users] Re: Ovirt engine showing wrong host's memory usage

2020-03-13 Thread Michal Skrivanek
> On 10 Mar 2020, at 15:46, Noua TOUKOUROU  wrote:
>
> 
> Hi,
>
> My ovirt engine is showing wrong host's memory usage. Even when this one has 
> no VM.
> How to fix it ?

What’s wrong with it?

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


[ovirt-users] Re: [moVirt] Error: sos conflicts with vdsm-4.20.46-1.el7.x86_64

2020-03-10 Thread Michal Skrivanek
On 10 Mar 2020, at 14:02, Tomas Jelinek  wrote:


forwarding to the correct list

On Tue, Mar 10, 2020 at 1:58 PM  wrote:

> Hello,
> I'm sorry. I've the problem for install ovirt in my server with the system
> centos 7.7.
> I'm installing vdsm. But I've the message:
>
> Error: sos conflicts with vdsm-4.20.46-1.el7.x86_64
>

 4.2 version doesn’t support  el7.7.  Upgrade/use oVirt 4.3.

Thanks,
michal


> Could you help me?
>
> Thanks,
>
> Anne
> ___
> moVirt mailing list -- mov...@ovirt.org
> To unsubscribe send an email to movirt-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/mov...@ovirt.org/message/4Y4IUFTH5S3QB2H7UTRIFPMTYT4MMPYR/
>
___
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/LP34JJHTGOE6IOYO5EQU6D3JVWLXEG5O/
___
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/27EZZ5WJQPHVDHXTD6M3MXXBQTHD7WCO/


[ovirt-users] Re: Different cpu flags preventing live migration

2020-03-02 Thread Michal Skrivanek


> On 2 Mar 2020, at 12:10, Gianluca Cecchi  wrote:
> 
> Hello,
> I would like to share some problems that I'm finding on an environment based 
> on RHV, but could impact also oVirt based environments.
> For my problems I'm working on an opened case to understand root cause.
> I have Dell R730 hypervisors (with Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz 
> cpu) and some VMs configured for "customized" high performance.
> In the sense that I configure VM as high performance type and then:
> - I enable the graphical console (I remove the flag of headless Mode" in 
> Console section);
> - In Host section I set for "Start Running On" Any Host in Cluster and allow 
> manual and automating migration; 
> - I also set HA in high availability section, accepting default values for 
> leasing, resume behaviour, ecc..
> 
> These settings however have the effect to leave enable the flag related to 
> "Pass-Through Host CPU" in Host section.
> 
> I noticed that with same Bios, ecc with kernel in 4.3.8 (that seems equal 
> between oVirt and RHV):
> [g.cecchi@ov200 ~]$ uname -r
> 3.10.0-1062.12.1.el7.x86_64
> [g.cecchi@ov200 ~]$ 
> 
> I have this cpu flag set: invpcid_single
> 
> Instead on the same host in 4.3.5 (eg kernel 3.10.0-1062.el7.x86_64) the flag 
> is not set.

sometimes there are kernel changes like that, but more usually it’s just the 
microcode version on each host (not bios), did you check that too?

> This creates problem during upgrade from 4.3.5 to 4.3.8 because initially I 
> empty one host and update it, but then I cannot live migrate back the VMs to 
> update the other one, due to the pass-through flag set, that requires exact 
> set of flags.

yes, they need to completely match, and even when they do..it’s a good idea to 
really do this only across same hw, same microcode, same kernel versions…

> 
> So crosscheck on a test environment in case you have the  "Pass-Through Host 
> CPU" set in Host section for any critical VM you cannot shutdown.
> 
> BTW: the flag is somehow tricky to remove if you set the VM as High 
> Performance type; you have to:
> edit VM --> Host 
> Start Running On --> change to select a specific host among the available ones
> Now you can remove the "Pass-Through Host CPU" flag --> remove it

but then you’re losing probably the biggest differentiator for “high 
performance”, so then maybe not use that profile at all?

> Start Running On --> change again to "Any Host in Cluster"
> Save
> 
> Now you can live migrate this "customized" High Performance VM
> But the problem is that if the VM is running, you have to shutdown it to get 
> the change in effect.
> 
> HH,
> Gianluca
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/DB4FSA6MIDBJ35AYUCIPU7KFLXC6KTEG/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/74EZBAV2WPO7A37TMK6UG4WBWJKRLBCH/


[ovirt-users] Re: OVA import fails always

2020-03-02 Thread Michal Skrivanek


> On 28 Feb 2020, at 19:37, Juan Pablo Lorier  wrote:
> 
> So far nor virtualbox ova in any format nor EXi work :-(
> 
> 
yes, because none of those are supported. OVA doesn’t mean much, it’s just a 
generic “wrapper” for anything inside, you need to specifically support OVA 
which some other app exports. Currently oVirt supports importing VMware’s OVA 
and its own OVAs

Thanks,
michal

> Thanks
> 
> El 28/2/20 a las 12:25, Edward Berger escribió:
>> I haven't tried many but for one I just untarred the thing to get the disk 
>> image file and created a new VM with that.
>> Sometimes the ova file is compressed/assembled in some way that might not be 
>> compatible.
>> 
>> On Fri, Feb 28, 2020 at 1:12 AM Jayme > > wrote:
>> If the problem is with the upload process specifically it’s likely that you 
>> do not have the ovirt engine certificate installed in your browser. 
>> 
>> On Thu, Feb 27, 2020 at 11:34 PM Juan Pablo Lorier > > wrote:
>> Hi,
>> 
>> I'm running 4.3.8.2-1.el7 (just updated engine to see if it helps) and I 
>> haven't been able to import vms in OVA format, I've tried many appliances 
>> downloaded from the web but couldn't get them to work.
>> 
>> Any hints?
>> 
>> Regards
>> 
>> 
>> ___
>> Users mailing list -- users@ovirt.org 
>> To unsubscribe send an email to users-le...@ovirt.org 
>> 
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ 
>> 
>> oVirt Code of Conduct: 
>> https://www.ovirt.org/community/about/community-guidelines/ 
>> 
>> List Archives: 
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/KRCE36GYQIOCXYR6K3KWUJA6R4ODWU56/
>>  
>> 
>> ___
>> Users mailing list -- users@ovirt.org 
>> To unsubscribe send an email to users-le...@ovirt.org 
>> 
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ 
>> 
>> oVirt Code of Conduct: 
>> https://www.ovirt.org/community/about/community-guidelines/ 
>> 
>> List Archives: 
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/VWU7EM2ZFX6STEJU67WQTIRJZWBBVWZG/
>>  
>> 
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/XLTS63CJFGUA6T5XAKHWEKWEOWUCMBCV/

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CEG6LSAZ4FV7YUZ45HE6MTYV5OU5GTWF/


[ovirt-users] Re: Get CPU Family

2020-02-20 Thread Michal Skrivanek


> On 20 Feb 2020, at 11:50, Strahil Nikolov  wrote:
> 
> On February 20, 2020 11:17:00 AM GMT+02:00, Luca   
>  wrote:
>> Hello guys,
>> 
>> how can I get the correct CPU Family in a ovirt host?
>> 
>> When I execute virsh -r capabilities I get only "Broadwell-noTSX-IBRS"
>> and not the full "Broadwell-noTSX IBRS SSBD MDS"

libvirt stopped naming CPUs after IBRS, so anything newer is oVirt’s doing…ad 
you need to derive that from the flags you see (and ideally from domcapabilties 
instead of capabilities)
if you see md-clear and ssbd there then you can use the named type above

>> 
>> 
>> Regards,
>> Luca
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/FD27EY7M6F7QC2HFLLHKFPFEVD4MYJVZ/
> 
> Hey Luca,
> For MDS -> check the thread of Marko.

hopefully it’s applicable only to certain CPUs and doesn’t affect everyone

> 
> 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/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/6ANJVJTDHDSQH5H5HKYTJHCKCMF47VXZ/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MX4QACNDMOJ44QXGCZAXQLJUZDSEVRWK/


[ovirt-users] Re: populating the ISO domain

2020-02-19 Thread Michal Skrivanek
On 19 Feb 2020, at 17:10, Gianluca Cecchi  wrote:

On Wed, Feb 19, 2020 at 4:37 PM Robert Webb  wrote:

> No.
>
> I am using the Spice viewer and my Data domain is on NFS. When I open the
> "Change CD" option in the viewer, I only see ISO's from the ISO Domain.
>
> I haven't found any other way to actually mount an ISO to a VM other then
> the viewer which kinda sucks. I am used to other environments where I could
> just mount an ISO to a cdrom in the VM config and it shows up in the OS.
>
>
If you can shutdown the VM, you could try to shutdown it and then choose
the arrow near "run" and select "run once".
There you can attach an iso: do you see your data domain isos there?
In my case I have isos on block based data domains: I cannot dynamically
change cd due to the bug I reported,


Yeah, sadly it’s still not fixed yet and I can only recommend to stay away
from isos on data domains for now. At least for cases when you need to
change cd or attach same cd to multiple vms

but if I start a VM with "run once" I can see the ISOs on data domain
available and usable (eg to install OS)

See also the "Explanation of Settings in the Run Once Window" section here:
https://www.ovirt.org/documentation/vmm-guide/appe-Reference_Settings_in_Administration_Portal_and_User_Portal_Windows.html

Gianluca

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/SKHIW2RGH7ANSZ2KVFSQ6J5HQQ5UUOYV/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/HQW5IQH236GCJSOLXPA6CYVCACYJZW34/


[ovirt-users] Re: 0virt VMs status down after host reboot

2020-01-31 Thread Michal Skrivanek


> On 30 Jan 2020, at 00:07, Joseph Goldman  wrote:
> 
> There is an important distinction though, if your reboot process involves 
> shutting down the VM's cleanly - then rebooting the server - they will not 
> auto start - however if their operation was interrupted and they are listed 
> as Highly Available, then they will be automatically restarted.
> 
> I believe they are working on a proper clean shutdown/ auto start procedure 
> so you can order which VM's come up first and have wait times etc but its 
> been coming for a while.

Indeed. And finally coming in 4.4. The order is not entirely customisable, but 
you can use priorities and group VMs so you can have some started before others

But still if you shut them down cleanly they won’t come up. It would make 
shutting them down impossible if we always intervene and immediately start them 
up.

Thanks,
michal

> 
> On 2020-01-30 2:37 AM, Eugène Ngontang wrote:
>> OK Jayme,
>> 
>> I'll try using that option.
>> 
>> Thankx
>> 
>> Le mer. 29 janv. 2020 à 15:04, Jayme > > a écrit :
>> Hello,
>> 
>> It's my understanding that the engine will make every attempt at restarting 
>> highly available VMs. All of my VMs are highly available and none have never 
>> not started after rebooting hosts.
>> 
>> 
>> On Wed, Jan 29, 2020 at 9:28 AM Eugène Ngontang > > wrote:
>> I was looking if the "High Availability" option could be used for automatic 
>> startup, but Ovirt documentation is pretty clear about it as explained here 
>>  you the documentation in the 
>> screenshot.
>> 
>> I was wondering if there may be a flag that controls the VMs startup 
>> behavior...
>> 
>> Le mer. 29 janv. 2020 à 12:07, Jayme > > a écrit :
>> Check if highly available is selected in vm configuration
>> 
>> On Wed, Jan 29, 2020 at 2:55 AM Eugène Ngontang > > wrote:
>> Hi all,
>> 
>> I've set up an infrastructure with OVirt, using self-hosted engine.
>> 
>> I use some ansible scripts from my Virtualization Host (the physical 
>> machine), to bootstrap the hosted engine, and create a set of virtual 
>> machines on which I deploy a k8s cluster.
>> 
>> The deployment goes well, and everything is OK.  
>> 
>> Now I'm doing some reboot tests, and when I reboot the physical server, only 
>> the hosted-engine vm is up after the reboot, the rest of VMs and thus the 
>> k8s cluster are down.
>> 
>> Had someone here ever experienced this issue? What can cause it and how to 
>> automate the virtual machines startup in RHVE/Ovirt?
>> 
>> Thanks.
>> 
>> Regards,
>> Eugene
>> 
>> 
>> -- 
>> LesCDN 
>> engont...@lescdn.com 
>> 
>> Aux hommes il faut un chef, et au chef il faut des hommes!
>> L'habit ne fait pas le moine, mais lorsqu'on te voit on te juge!
>> ___
>> Users mailing list -- users@ovirt.org 
>> To unsubscribe send an email to users-le...@ovirt.org 
>> 
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ 
>> 
>> oVirt Code of Conduct: 
>> https://www.ovirt.org/community/about/community-guidelines/ 
>> 
>> List Archives: 
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/YWVB43KDNMXVIZCCIZJI5EOJGZ7ATLZK/
>>  
>> 
>> 
>> 
>> -- 
>> LesCDN 
>> engont...@lescdn.com 
>> 
>> Aux hommes il faut un chef, et au chef il faut des hommes!
>> L'habit ne fait pas le moine, mais lorsqu'on te voit on te juge!
>> 
>> 
>> -- 
>> LesCDN 
>> engont...@lescdn.com 
>> 
>> Aux hommes il faut un chef, et au chef il faut des hommes!
>> L'habit ne fait pas le moine, mais lorsqu'on te voit on te juge!
>> 
>> 
>> ___
>> Users mailing list -- users@ovirt.org 
>> To unsubscribe send an email to users-le...@ovirt.org 
>> 
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ 
>> 
>> oVirt Code of Conduct: 
>> https://www.ovirt.org/community/about/community-guidelines/ 
>> 
>> List Archives: 
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/BRMTZF7XAQXV5OVJH7HFEXZAW5CB73D7/
>>  
>> 
> 
> 

[ovirt-users] Re: Update 4.4

2020-01-31 Thread Michal Skrivanek


> On 27 Jan 2020, at 19:53, Dirk Streubel  wrote:
> 
> Hello,
> 
> i use for testing Version 4.4 and i wanted to make a update.
> 
> This is the result:
> 
> LANG=C engine-setup
> 
> ...
> 
> [ INFO  ] Checking for product updates...
> [ ERROR ] Yum
> [u'ovirt-engine-backend-4.4.0-0.0.master.20200122090542.git5f0a359.el7.noarch
> requires java-client-kubevirt >= 0.1.0']
> [ INFO  ] Yum Performing yum transaction rollback
> [ ERROR ] Failed to execute stage 'Environment customization':
> [u'ovirt-engine-backend-4.4.0-0.0.master.20200122090542.git5f0a359.el7.noarch
> requires java-client-kubevirt >= 0.1.0']
> [ INFO  ] Stage: Clean up
>   Log file is located at
> /var/log/ovirt-engine/setup/ovirt-engine-setup-20200127193352-x6p04t.log
> [ INFO  ] Generating answer file
> '/var/lib/ovirt-engine/setup/answers/20200127193405-setup.conf'
> [ ERROR ] Failed to execute stage 'Clean up': must be unicode, not str
> [ INFO  ] Stage: Pre-termination
> [ INFO  ] Stage: Termination
> [ ERROR ] Execution of setup failed
> 
> So, i found this:
> 
> https://repo1.maven.org/maven2/org/ovirt/java-client-kubevirt/java-client-kubevirt/0.2.0/
> 
> So, do i have to install a.jar to make the engine update or what is the
> best way to do the update?

no, it should come in rpm form, maybe you’re missing a repo or something.
In any case, keep in mind that 4.4 is still *not* really supporting upgrades, 
even from an earlier 4.4 build.
Especially the recent updates around picking up CentOS 8;1 and AdvancedVirt are 
kind of breaking changes…

Thanks,
michal

> 
> Dirk
> 
> 
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/ONLFPJSS35ACSZNIPBU7VZ5UO75M6Y6Z/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KIAUJLNNP5B25FLRYCM2CX4V7RU2UIO4/


[ovirt-users] Re: Details about bios and custom emulated machine values

2020-01-29 Thread Michal Skrivanek


> On 27 Jan 2020, at 22:01, Gianluca Cecchi  wrote:
> 
> Hello,
> in oVirt 4.3.7 in "Edit VM" -> System -> Advanced parameters
> I can choose 
> 
> Bios Type:
> Default
> Q35 Chipset with Legacy BIOS
> Q35 Chipset with UEFI BIOS
> Q35 Chipset with SecureBoot
> 
> and
> Custom Emulated Machine:
> Use cluster default (pc-i440fx-rhel7.6.0)
> ...
> q35
> pc-q35-rhel7.3.0
> pc-q35-rhel7.4.0
> pc-q35-rhel7.5.0
> pc-q35-rhel7.6.0
> 
> and I can apparently mix all possible values.

you can, but they won’t work:)
in 4.3 the whole q35 is tech preview, with bugs we’ve fixed in 4.4. 
custom emulated machine is really just for the cases where you can troubleshoot 
by trying a “similar enough” machine type. using a different chipset or type 
from different major version will likely just fail on vm start.

> Any deeper information about implications?
> What is the "Default" value for Bios Type?

i440fx with seabios(Legacy BIOS)

> 
> Did anything change in 4.3.8 (eg official support for q35)?

no, only in 4.4 where q35/seabios becomes the new default for new 4.4 clusters

> 
> I search also through official docs for RHV 4.3 (virtual mgmt guide, appendix 
> A), but for example I don't find any reference to the "Bios Type" parameter 
> and a vague reference to the "Custom Emulated Machine". Is there any more 
> detailed link?

there should be a bit more about bios, since it’s becoming a default, but don’t 
ahve it in front of me/at hand at the moment, sorry

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/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/RBXYGBA6MBUYURYYMDC75LU7LOJJBOPB/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/SDMZMZOTCNI234I3ORBAEKQQW5S5JTCJ/


[ovirt-users] Re: [moVirt] Expanding oVirt

2020-01-17 Thread Michal Skrivanek
[fwding to the right list]

> On 15 Jan 2020, at 22:57, mwe...@maetrix.tech wrote:
> 
> I am planning a basic 3-host hyperconverged oVirt cluster and am very happy 
> with tests I have conducted regarding the deployment. 
> 
> I have a question regarding expanding the cluster and cant seem to find a 
> direct answer. My hosts have a limited number of HDD slots and am curious 
> about expanding the gluster volumes. Is this a simple process of adding 
> another host or hosts as I go and adding the gluster bricks to the volume and 
> rebalancing? I also recall seeing a hard limit of nine hosts in a cluster. Is 
> this correct?
> Thank you,
> ___
> moVirt mailing list -- mov...@ovirt.org
> To unsubscribe send an email to movirt-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/mov...@ovirt.org/message/YSSYKBGN6HMUTPIHBXJHRGE7VU73ASER/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/73PBXE5XFFOWJ42VS2HRET3PCPXIFAP4/


[ovirt-users] Re: Import an exported VM using Ansible

2020-01-16 Thread Michal Skrivanek
On 15 Jan 2020, at 23:12, pa...@airaldi.it wrote:

Hello everybody!

I'm trying to automate a copy of a VM from one Datacenter to another using
an Ansible.playbook.

I'm able to:
- Create a snapshot of the source VM
- create a clone from the snapshot
- remove the snapshot
- attach an Export Domain
- export the clone to the Export Domain
- remove the clone
- detach the Export domain from the source Datacenter and attach to the
destination.

Unfortunately I cannot find a module to:
- import the VM from the Export Domain
- delete the VM image from the Export Domain.


Hi,
those are legacy flows, on their way out. Use OVA export and import, it’s
going to be much more straightforward.
See import and export examples at
https://github.com/oVirt/ovirt-engine-sdk/tree/master/sdk/examples
It is in ansible too

Thanks,
michal


Any hint on how to do that?

Thanks in advance. Cheers.

Paolo


PS: if someone is interested I can share the playbook.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QMFXXQFYYW6SJ43QO6W44IQZ2M3V2WU2/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/I6JSEWBLS5UWPYOFWZNPCBWQ7B7EAX6I/


[ovirt-users] Re: kernel parameter "spectre_v2=retpoline"

2019-12-12 Thread Michal Skrivanek
> On 12 Dec 2019, at 17:38, Matthias Leopold 
>  wrote:
>
> Hi,
>
> I'm planning to upgrade my installation from CentOS 7.6/oVirt 4.3.5 to CentOS 
> 7.7/oVirt 4.3.7.
> According to
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.7_release_notes/new_features#enhancement_kernel
> there's a new default setting for Spectre V2 mitigation in new RHEL 7 
> installs. Shall I switch my hypervisor hosts to this setting when upgrading? 
> Would newly installed CentOS 7 oVirt hosts have that kernel parameter?

Doesn’t the same paragraph describe new install vs upgrade behavior?;)
I wouldn’t think Centos is going to be any different .

>
> thx
> Matthias
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/45OHIHG3JGQQFF7HAC5OVUERDNEK6BVH/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/RIKODIA7DZ6BV73HFX7PFMMASOXAL2Q2/


[ovirt-users] Re: CPU Type compatibility matrix

2019-12-10 Thread Michal Skrivanek


> On 10 Dec 2019, at 11:57, Joseph Goldman  wrote:
> 
> The matrix is basically Intel ARK - oVirt, from my understanding, will set 
> the cluster to the minimum supported set of instructions. Meaning if they are 
> identical instruction sets across all CPU's - then nothing is lost, but if 
> even 1 CPU in the cluster has less available features then the rest, then all 
> will be brought down to that level so to speak. There may be some major 
> incompatibilities im not aware of, but with at least 2CPU's in the same 
> family, I don't think you would be losing much if any.

yep
plus if you really really need later cpu features for a specific VM which you 
would pin on this special host you can always use VM setting of Host CPU 
Passthrough which just uses all instructions the host has.

> 
> On 10/12/19 8:18 pm, Gianluca Cecchi wrote:
>> Hello,
>> In my case I currently have a cluster with hosts with cpu Intel E5-2680 v4 
>> (each socket with 14 cores) and their Cluster is set as "Intel Broadwell 
>> Family" and I would like to add in the same oVirt Cluster two more hosts 
>> with Intel E5-2640 v4 cpus (each socket 10 cores) that should be the same 
>> CPU Family Type. 
>> Is it true?
>> Is there a sort of matrix where one could compare and match?
>> 
>> Thanks in advance,
>> Gianluca
>> 
>> 
>> ___
>> Users mailing list -- users@ovirt.org 
>> To unsubscribe send an email to users-le...@ovirt.org 
>> 
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ 
>> 
>> oVirt Code of Conduct: 
>> https://www.ovirt.org/community/about/community-guidelines/ 
>> 
>> List Archives: 
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/QHR2KYXWGGSFS7GH3CWTXU22L2K3TWFG/
>>  
>> 
> 
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/3F4OW4DGN55T35OKWYAK77N6ASNOYW73/

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZB5LCVDVB7SZ6YYSZIJCSQRKVWZTMHHA/


[ovirt-users] Re: Windows Sluggish Performance

2019-12-05 Thread Michal Skrivanek
On 4 Dec 2019, at 04:16, Vijay Sachdeva  wrote:

Hey,



The problem what I have found is when I am using SPICE as default console
option, the  console performance is very sluggish. So what I understand
here is one needs to install additional spice guest tools to improve the
performance as it includes QLX video driver.


Yes. So did you do that?



https://www.spice-space.org/download.html



The moment I switched to VNC console options, performance improved but not
far better as it should be when taking a console of machine.



So still any suggestions to improve console access?



Thanks



Vijay Sachdeva





*From: *Strahil 
*Date: *Wednesday, 4 December 2019 at 5:12 AM
*To: *users , Vijay 
*Subject: *Re: [ovirt-users] Re: Windows Sluggish Performance



What is your virtual GPU ?
I'm using QLX, and despite being sluggish, when you tune windows for best
performance -it is workable.

Of course, if you passthrough a GPU, performance will be completely
different.

Best Regards,
Strahil Nikolov

On Dec 3, 2019 21:19, Vijay Sachdeva  wrote:

Anyone?



On Tue, 3 Dec 2019 at 11:21 PM, Vijay Sachdeva 
wrote:

Hello Everyone,



I managed to install Windows Server 2016 server on Ovirt node using ovirt
engine.All virtio-Win drivers also installed, but the performance of
Windows using console is very sluggish and mouse pointer is not at all
responsive.



Can anyone let me know, what could be the reason. Not able to to even add
IP to VM as mouse doesn’t work at all.



Thanks

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/SCW3GKSIVIHL6O32FQQW4CGYXJZMYB4T/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/AJ65IF3JJKAGI4Y5RRBPP4GAN5P2WGCE/


[ovirt-users] Re: Importing a Virtual Machine from a KVM Host

2019-12-05 Thread Michal Skrivanek
> On 5 Dec 2019, at 12:10, Dirk Streubel  wrote:
>
> Hello everbody,
>
> i am just a little bit confused about importing Qemu Images from my KVM Host.
>
> At home, and at work i am using a ovirt engine in a VM. The Version is 4.3.7 
> and on bare metal my host.
>
> Everything works fine but i have the same problem at home and on work. I want 
> to import my qcow2
> Images from a KVM Host but i
>
> will not work.
>
> The command  virsh -r -c 'qemu+tcp://r...@host1.example.org/system' list 
> --all shows me akk my VMs.
>
> But when i want to load the images in the GUI, nothing happens. I follow this 
> instruction:
>
> https://www.ovirt.org/develop/release-management/features/virt/KvmToOvirt.html
>
> After that, i take a look on the official 4.3 Rhev Documentation from Red 
> Hat. There stand this:
>
> Log in to the proxy host and generate SSH keys for the vdsm user.
>
> sudo -u vdsm ssh-keygen
>
> So, i have no proxy host.  So i want to do this on my ovirt-engine. Is this 
> right?

No, proxy host is the host you select to use for import. One of your
virtualization hosts

>
> Next thing: the user vdsm is locked on the ovirt-engine machine and the host.
>
> So, do i have to unlocked the account of the user vdsm or what is the best 
> way.
>
> My Problem is i found nothing that would help me to solve this problem.
>
> Maybe somebody here do me a favour and help me to solve this "challenge"
>
> Regards
>
> Dirk
>
>
>
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/WSDZ3E4VN5HMHMYV2CSDC5GCIZTMS2ED/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/E7ZRNPIBKAMVYHXUU674SM7V3WWGOXSR/


[ovirt-users] Re: Ovirt 4.3.6 USB passthrough not working with iommu_intel=on iommu=pt

2019-11-21 Thread Michal Skrivanek


> On 21 Nov 2019, at 16:31, Don Dupuis  wrote:
> 
> Anyone else have this problem? I haven't been able to find a solution.
> 
> Don
> 
> On Tue, Nov 19, 2019 at 10:03 AM Don Dupuis  > wrote:
> with that approach, still get same error.
> 
> Don
> 
> On Mon, Nov 18, 2019 at 10:49 PM Strahil Nikolov  > wrote:
> I would recommend you to "unpresent" that USB, then replug (if that's 
> possible) the USB and then to refresh the hosts's Capabilities (management 
> dropdown). Only then try to assign the USB.
> 
> Best Regards,
> Strahil Nikolov
> 
> В вторник, 19 ноември 2019 г., 05:30:00 ч. Гринуич+2, Don Dupuis 
> mailto:donds...@gmail.com>> написа:
> 
> 
> I am trying to pass through a USB Dongle to a Windows virtual machine in 
> ovirt 4.3.6. This will work if these options aren't used. Below is the output 
> of lsusb with no iommu enable:
> 
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 005: ID 1604:10c0 Tascam
> Bus 001 Device 004: ID 1604:10c0 Tascam
> Bus 001 Device 003: ID 1604:10c0 Tascam
> Bus 001 Device 002: ID 07f2:0001 Microcomputer Applications, Inc. KEYLOK II
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> The device I am passing through is Bus 001 Device 002.
> 
> This is the error I get in vdsmd.log:
> 
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 867, in 
> _startUnderlyingVm
> self._run()
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2890, in _run
> self._domDependentInit()
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2466, in 
> _domDependentInit
> self._vmDependentInit()
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2480, in 
> _vmDependentInit
> self._getUnderlyingVmDevicesInfo()
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2448, in 
> _getUnderlyingVmDevicesInfo
> vmdevices.common.update_device_info(self, self._devices)
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vmdevices/common.py", line 
> 94, in update_device_info
> hostdevice.HostDevice.update_device_info(vm, devices[hwclass.HOSTDEV])
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vmdevices/hostdevice.py", 
> line 426, in update_device_info
> vm, device_conf, device_xml)
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vmdevices/hostdevice.py", 
> line 223, in update_from_xml
> if host_address == dev.hostAddress:
> AttributeError: 'MdevDevice' object has no attribute 'hostAddress'
> 2019-11-18 18:20:06,173-0600 INFO  (vm/9944089c) [virt.vm] 
> (vmId='9944089c-2109-4352-a0c6-7d0d9e04bb3f') Changed state to Down: 
> 'MdevDevice' object has no attribute 'hostAddress' (code=1) (vm:1690)

Looks like a code bug. Would you please open it? On vdsm, oVirt team “virt”

Thanks,
michal


> 
> I am using kernel 3.10.0-957.12.1.el7.x86_64
> 
> vdsm is vdsm-4.30.33-1.el7.x86_64
> libvirt is libvirt-5.0.0-1.el7.x86_64
> qemu is qemu-img-ev-2.12.0-33.1.el7.x86_64
> 
> Any help with this issue would be appreciated.
> 
> Thanks
> Don
> ___
> Users mailing list -- users@ovirt.org 
> To unsubscribe send an email to users-le...@ovirt.org 
> 
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ 
> 
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/ 
> 
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/3JWP5GNYJWH7HDLBDRU3UGGHUENINW4I/
>  
> 
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/BFES4PVZJ5LTNWPNOWZTZOB2DGUPDKCN/

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BYVZLY5PIVRGZASAGNR2TE4Q5CY3JA7F/


[ovirt-users] Re: Wrong CPU?

2019-11-19 Thread Michal Skrivanek


> On 18 Nov 2019, at 09:29, Christian Reiss  wrote:
> 
> Ugh,
> 
> first off thanks for all your effort and information. Much obliged.
> But this also means that I am looking at a lng time before I can go to 
> production with this cluster. Now I am sad.
> 
> Would it be an option to run the engine on dedicated hardware and control the 
> cluster from there? Or is that thing in total not usable?

I’m curious why do you need virt-ssbd for hosted engine? What for? 

> 
> -Chris.
> 
> On 18/11/2019 07:25, Juhani Rautiainen wrote:
>> Hi!
>> Had to get back to work to check which CPU we had. We have AMD Epyc
>> 7281 and ovirt CPU Type is AMD EPYC IBPB SSBD. It seems that your CPU
>> is the next generation (Zen2) and I'm pretty sure that problem is with
>> Qemu version. As far as I can see from git there is not even Zen2

yes, AFAIK Zen2 is not yet supported in upstream. Once it is we’ll pick it up 
afterwards.
But it doesn’t mean you can’t use it for running stuff in EPYC or lower CPU 
family feature set.


>> support in latest Qemu (checking by target/i386/cpu.c)? I mean they
>> added Hygon Dhyana (never even heard about this chinese AMD EPYC
>> clone) and in that discussion there was reference to Zen2
>> architecture. So biggest problem for oVirt seems to come from
>> upstream. I mean that Zen2 is quite good for virtualization and it's
>> going to sell a lot. Maybe AMD should help with that push?
>> -Juhani
>> On Fri, Nov 15, 2019 at 9:03 PM Christian Reiss
>> mailto:em...@christian-reiss.de>> wrote:
>>> 
>>> Sorry,
>>> 
>>> I meant EPYC, not Ryzen.
>>> How did you solve your EPYC issue?
>>> 
>>> -Chris.
>>> 
>>> On 15/11/2019 18:55, Juhani Rautiainen wrote:
 Hi!
 
 It might be that the Qemu in oVirt doesn't recognize the Ryzen. That
 was case with Epyc when I started using oVirt. It was reconized as a
 Opteron G2 which caused lot's of problems when upgrading to 4.3.
 
 -Juhani
 
 On Fri, Nov 15, 2019 at 6:45 PM Christian Reiss
  wrote:
> 
> Hey folks,
> 
> running an AMD Ryzen CPU here:
> 
> processor   : 0
> vendor_id   : AuthenticAMD
> cpu family  : 23
> model   : 49
> model name  : AMD EPYC 7282 16-Core Processor
> 
> However, libvirt is detecting this as EPYC-IBPB without the ssbd flags?
> 
>   
> x86_64
> EPYC-IBPB
> AMD
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   

in 4.3 we still use flags instead of libvirt feature detection (which we’re 
fixing in 4.4, but so far it’s playing to your advantage:) 
So seeing “ssbd" below in cpuinfo should be enough to detect the oVirt type 
with SSBD. Where exatly you see that not working?
 
Thanks,
michal

> 
> 
> [root@node01 ~]# grep ssbd /var/cache/libvirt/qemu/capabilities/*.xml
>   
>   
>   
>   
> 
> But the flag is there:
> 
> [root@node01 ~]# grep ssbd /proc/cpuinfo | tail -n1
> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
> mca cmov
> pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
> pdpe1gb rdtscp lm constant_tsc art rep_good nopl xtopology nonstop_tsc
> extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16
> sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy
> svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
> skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 cpb
> cat_l3 cdp_l3 hw_pstate sme retpoline_amd ssbd ibrs ibpb stibp vmmcall
> fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb
> sha_ni xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total
> cqm_mbm_local clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save
> tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
> avic v_vmsave_vmload vgif umip overflow_recov succor smca
> 
> I tried adding "options kvm_amd avic=1" as well as "options kvm_amd
> avic=0" to /etc/modprobe.d/kvm.conf (always with reboots), adding
> mitigations=off to grub.. I can't think of any other solution.
> 
> I just can't get the oVirt engine running with the ssbd flag. Seems cpu
> can do this, oVirt can do this, libvirt does not detect the cpu
> correctly or at least ignores it. But the hosted engine demands it.
> 
> I am at a loss. Any help is oh-so-greatly appreciated.
> 
> -Chris.
> 
> --
>Christian Reiss - em...@christian-reiss.de /"\  ASCII Ribbon
>  

[ovirt-users] Re: How to change the CPU of the win10 virtual machine on ovirt-node from 2 cores to 8 cores?

2019-11-01 Thread Michal Skrivanek


> On 1 Nov 2019, at 04:05, Kaustav Majumder  wrote:
> 
> Hi,
> You can try username  : vdsm@ovirt
> password: shibboleth
> 

no
just don’t touch it
please

> On Fri, 1 Nov, 2019, 6:01 AM ,  > wrote:
> The version of The ovirt-engine is 4.3.5. I created a win10 virtual machine 
> on ovirt-node, which is allocated 8 cores, and when using the virtual machine 
> I found only 2 cores. I used the command "virsh edit win10" on ovirt-node to 
> prepare to modify the CPU core. I was prompted to enter my username and 
> password. I entered the username and password of the ovirt-engine web 
> interface and ssh log in to the ovirt-node username root and password, but 
> both prompt:
> 
> Error: failed to connect to the hypervisor
> Error: authentication failed: authentication failed
> 
> How can this problem be solved?

what problem?
if you configured the vm with 8 then there are 8. if the guest is only using 2 
then it’s likely a guest problem or you’re just looking at a wrong thing….

Thanks,
michal

> ___
> Users mailing list -- users@ovirt.org 
> To unsubscribe send an email to users-le...@ovirt.org 
> 
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ 
> 
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/ 
> 
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/2WLX56RLN4NYX3456W5IAEDFRGAWVHSY/
>  
> 
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/TLJGJMQ3DYFTKUVKPGI5IV63RICRJ3F2/

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/FGQBNPXGWLVQZ3TKMX4Y6Z2Y3VAXIQWX/


[ovirt-users] Re: How to pass parameters between VDSM Hooks domxml in single run

2019-10-03 Thread Michal Skrivanek


> On 3 Oct 2019, at 12:50, Vrgotic, Marko  wrote:
> 
> Hi Michal,
> 
> Thank you. Would you be so kind to provide me with additional clarification?
> 
>> you can’t just add a random tag into libvirt xml in a random place, it will 
>> be dropped by libvirt.
> I understand, thank you. About persistence of added tag, it was not 
> used/written during 1xMigration, but it was present in domxml in 2xMigration. 
> 
>> you can add it to metadata though. we use that for ovirt-specific information
> Can you please provide some more HowTo/HowNotTo information?
> Can we manipulate the tag in metadata section in each iteration?
> I assume VM metadata shared/communicated between Hosts or read and provided 
> to Hosts by oVirt-Engine?
> In short we are trying to achive:
>   - start migration
>  - ex: 10_create_tag inserts   tag into XML 
> metadata section  <= maybe we can use before_vm_migration_source hook 
>  - migration is finished and after_vm_destroy hooks comes to turn:
>  - ex:  20_nsupdate reads the metadata and:
> - if tag  exists,  do not run dns 
> update, but remove the tag
> - if tag  does not exists, run dns 
> update and remove the tag

so..hmm..if IIUC you basically just need not to execute dns update(remove the 
entry for vm) when VM migrates away. and do execute it when it shuts down.

maybe i can suggest two other approaches which could work? these would be 
preferable because manipulating with libvirt’s xml at the time of lifecycle 
changes are better to be avoided. libvirt is touching the xml at the same tie 
and it may run into ugly locking problems.
how about
- use after_vm_migrate_source and make a note of that vmid (touch a file in 
/tmp/ or whatever), and then check that in after_vm_destroy
or
- use before_vm_destroy and use vdsm-client VM getStats vmid=‘xyz’ to get the 
curent VM’s status from vdsm (before it goes away) and you should see if it’s 
“Migration Source” vs anything else(Powering Down for ordinary shutdowns or Up 
for crashes, I guess)

Thanks,
michal

> 
> Kindly awaiting your reply.
> 
> Marko Vrgotic
> 
> On 03/10/2019, 12:27, "Michal Skrivanek"  wrote:
> 
> 
> 
>> On 2 Oct 2019, at 13:29, Vrgotic, Marko  wrote:
>> 
>> Any ideas
>> 
>> From: "Vrgotic, Marko" 
>> Date: Friday, 27 September 2019 at 17:26
>> To: "users@ovirt.org" 
>> Subject: How to pass parameters between VDSM Hooks domxml in single run
>> 
>> Dear oVIrt,
>> 
>> A while ago we discussed on ways to change/update content of parameters of 
>> domxml in certain action.
>> 
>> As I mentioned before, we have added the VDSMHook 60_nsupdate which removes 
>> the DNS record entries when a VM is destroyed:
>> 
>> …
>> domxml = hooking.read_domxml()
>>name = domxml.getElementsByTagName('name')[0]
>>name = " ".join(name.nodeValue for name in name.childNodes if 
>> name.nodeType == name.TEXT_NODE)
>>nsupdate_commands = """server {server_ip}
>> update delete {vm_name}.example.com a
>> update delete {vm_name}. example.com 
>> update delete {vm_name}. example.com txt
>> send
>> """.format(server_ip="172.16.1.10", vm_name=name)
>> …
>> 
>> The goal:
>> However, we did not want to execute remove dns records when VM is only 
>> migrated. Since its considered a “destroy” action we took following approach.
>>  • In state “before_vm_migrate_source add hook which will write flag 
>> “is_migration” to domxml
>>  • Once VM is scheduled for migration, this hook should add the flag 
>> “is_migration” to domxml
>>  • Once 60_nsupdate is triggered, it will check for the flag and if 
>> there, skip executing dns record action, but only remove the flag 
>> “is_migration” from domxml of the VM
>> 
>> …
>> domxml = hooking.read_domxml()
>>migration = domxml.createElement("is_migration")
>>domxml.getElementsByTagName("domain")[0].appendChild(migration)
>>logging.info("domxml_updated {}".format(domxml.toprettyxml()))
>>hooking.write_domxml(domxml)
>> …
>> 
>> When executing first time, we observed that flag “
>> 
>>hookiesvm
>>fcfa66cb-b251-43a3-8e2b-f33b3024a749
>>http://ovirt.org/vm/tune/1.0; 
>> xmlns:ns1="http://ovirt.org/vm/1.0;>
>>
>>http://ovirt.org/vm/1.0;>
>>4.3
>>> type="bool"

[ovirt-users] Re: How to pass parameters between VDSM Hooks domxml in single run

2019-10-03 Thread Michal Skrivanek


> On 2 Oct 2019, at 13:29, Vrgotic, Marko  wrote:
> 
> Any ideas
>  
> From: "Vrgotic, Marko" 
> Date: Friday, 27 September 2019 at 17:26
> To: "users@ovirt.org" 
> Subject: How to pass parameters between VDSM Hooks domxml in single run
>  
> Dear oVIrt,
>  
> A while ago we discussed on ways to change/update content of parameters of 
> domxml in certain action.
>  
> As I mentioned before, we have added the VDSMHook 60_nsupdate which removes 
> the DNS record entries when a VM is destroyed:
>  
> …
> domxml = hooking.read_domxml()
> name = domxml.getElementsByTagName('name')[0]
> name = " ".join(name.nodeValue for name in name.childNodes if 
> name.nodeType == name.TEXT_NODE)
> nsupdate_commands = """server {server_ip}
> update delete {vm_name}.example.com a
> update delete {vm_name}. example.com 
> update delete {vm_name}. example.com txt
> send
> """.format(server_ip="172.16.1.10", vm_name=name)
> …
>  
> The goal:
> However, we did not want to execute remove dns records when VM is only 
> migrated. Since its considered a “destroy” action we took following approach.
>   • In state “before_vm_migrate_source add hook which will write flag 
> “is_migration” to domxml
>   • Once VM is scheduled for migration, this hook should add the flag 
> “is_migration” to domxml
>   • Once 60_nsupdate is triggered, it will check for the flag and if 
> there, skip executing dns record action, but only remove the flag 
> “is_migration” from domxml of the VM
>  
> …
> domxml = hooking.read_domxml()
> migration = domxml.createElement("is_migration")
> domxml.getElementsByTagName("domain")[0].appendChild(migration)
> logging.info("domxml_updated {}".format(domxml.toprettyxml()))
> hooking.write_domxml(domxml)
> …
>  
> When executing first time, we observed that flag “
>  
> hookiesvm
> fcfa66cb-b251-43a3-8e2b-f33b3024a749
> http://ovirt.org/vm/tune/1.0; 
> xmlns:ns1="http://ovirt.org/vm/1.0;>
> 
> http://ovirt.org/vm/1.0;>
> 4.3
>  type="bool">False
> false
>  type="int">1024
>  type="int">1024
> ...skipping...
>  slot="0x09" type="pci"/>
> 
> 
> 
> system_u:system_r:svirt_t:s0:c169,c575
> 
> system_u:object_r:svirt_image_t:s0:c169,c575
> 
> 
> +107:+107
> +107:+107
> 
> 

you can’t just add a random tag into libvirt xml in a random place, it will be 
dropped by libvirt.
you can add it to metadata though. we use that for ovirt-specific information

>   
> is added to domxml, but was present once 60_nsupdate hook was executed.
>  
> The question: How do we make sure that, when domxml is updated, that the 
> update is visible/usable by following hook, in single run? How to pass these 
> changes between hooks?
>  
> Kindly awaiting your reply.
>  
>  
> — — —
> Met vriendelijke groet / Kind regards,
> 
> Marko Vrgotic
>  
>  
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/IC4J6CAJUQOSLU3ZJPX3ZHTUM4HUCMGU/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MHQ4VQ4IXO6GM5MOGQSHAX74SCP2QUJD/


[ovirt-users] Re: failed import ova vm

2019-08-16 Thread Michal Skrivanek


> On 16 Aug 2019, at 09:28, David David  wrote:
> 
> hi
> 
> cant import vmware OVA
> 
> Engine: 4.3.5.5-1.el7
> OS Version: RHEL - 7 - 6.1810.2.el7.centos
> Kernel Version: 3.10.0 - 957.27.2.el7.x86_64
> KVM Version: 2.12.0 - 18.el7_6.7.1
> LIBVIRT Version: libvirt-4.5.0-10.el7_6.12
> VDSM Version: vdsm-4.30.24-1.el7
> 
> 
> WebUI -> Virtual Machines -> Import (select vmware OVA, select OVAs
> path, Load) - OK(details) - OK
> 
> vdsm.log, engine.log in attachment

it failed in the actual v2v job, you need to look there too.
In your case it’s in 
/var/log/vdsm/import/import-38f066c0-fb9b-4cae-8c65-086fee410381-20190816T030932.log

> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/POB34JI3EYDMQUPF6X66PPATBB7S5PER/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/C7MAIYPQKXB34G44EKC3FRGHRKX4JPHZ/


[ovirt-users] Re: Either allow 2 CD-ROM's or selectable *.vfd Floppy Images from Storage via Run Once other than from deprcated ISO-Storage

2019-08-13 Thread Michal Skrivanek


> On 12 Aug 2019, at 15:05, Vinícius Ferrão  wrote:
> 
> Ralf, you can change CD on the Load Drivers section.
> 
> Change for the oVirt Tools Disc, load the drivers and then change back to 
> Windows.

you can also use emulate drivers during installation, e.g. in Run Once dialog 
instead of virtio drivers

> 
> It’s a bad workflow, I know. But it’s how I’m doing here. I agree that the 
> Windows Tools is not really friendly with oVirt.

go ahead and complain to Microsoft that they don’t include virtio drivers in 
their installation images. Without that we can’t really do much…they’re just 
not there out of the box.

Thanks,
michal

> 
> Sent from my iPhone
> 
> On 12 Aug 2019, at 08:03, Ralf Schenk  > wrote:
> 
>> Hello,
>> 
>> when Installing Windows VM's on Ovirt we need either 2 CD-ROM's attached as 
>> ISO Files (Installer ISO and Virtio-Win-ISO) to be able to install to 
>> Virtio-(SCSI)-Disks.
>> 
>> In Ovirt 4.3.4 it is not possible to attach 2 CD-ROM's to a VM. So we have 
>> to use Floppy Images (virtio-win-*.vfd) attached to install drivers within 
>> Installer.
>> 
>> We need to use "Run Once" to attach flopppy disks. There are only *.vfd 
>> selectable which are located on ISO-Storage.Domain, which will be deprecated 
>> now or then. 
>> 
>> -> We won't be able to install Windows VM's from unmodified ISO 
>> Installer-CD's without ISO Storage Domain or making *.vfd Files selectable 
>> via "Run Once" 
>> 
>> When will that be available... ?
>> 
>> Bye
>> 
>> -- 
>> 
>> 
>> 
>> Ralf Schenk
>> fon +49 (0) 24 05 / 40 83 70
>> fax +49 (0) 24 05 / 40 83 759
>> mail r...@databay.de 
>>  
>> Databay AG
>> Jens-Otto-Krag-Straße 11
>> D-52146 Würselen
>> www.databay.de 
>> 
>> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202
>> Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. 
>> Philipp Hermanns
>> Aufsichtsratsvorsitzender: Wilhelm Dohmen
>> ___
>> Users mailing list -- users@ovirt.org 
>> To unsubscribe send an email to users-le...@ovirt.org 
>> 
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ 
>> 
>> oVirt Code of Conduct: 
>> https://www.ovirt.org/community/about/community-guidelines/ 
>> 
>> List Archives: 
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/3G5BEWATSBZCUKLPS5ZNOAFDHIVNAYQV/
>>  
>> 
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/HLWL43FJ2D5WYXUCVNCBCMI34U3TTXQA/

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/6T2O6XMNSRR4VGITHY4CZYTNHAS5DKRF/


[ovirt-users] Re: Manual Migration not working and Dashboard broken after 4.3.4 update

2019-08-02 Thread Michal Skrivanek
> have also tried clearing all data out of my browser and re-logged back in.
> 
> I see a new error though in my engine.log as below, however I still don't see 
> anything logged when I click the migrate button...
> 
> 2019-07-16 15:01:19,600+02 WARN  
> [org.ovirt.engine.core.utils.ObjectIdentityChecker] (default task-15) 
> [685e07c0-b76f-4093-afc9-7c3999ee4ae2] Field 'balloonEnabled' can not be 
> updated when status is 'Up'
> 2019-07-16 15:01:19,601+02 WARN  
> [org.ovirt.engine.core.utils.ObjectIdentityChecker] (default task-15) 
> [685e07c0-b76f-4093-afc9-7c3999ee4ae2] Field 'watchdog' can not be updated 
> when status is 'Up'
> 2019-07-16 15:01:19,602+02 WARN  
> [org.ovirt.engine.core.utils.ObjectIdentityChecker] (default task-15) 
> [685e07c0-b76f-4093-afc9-7c3999ee4ae2] Field 'rngDevice' can not be updated 
> when status is 'Up'
> 2019-07-16 15:01:19,602+02 WARN  
> [org.ovirt.engine.core.utils.ObjectIdentityChecker] (default task-15) 
> [685e07c0-b76f-4093-afc9-7c3999ee4ae2] Field 'soundDeviceEnabled' can not be 
> updated when status is 'Up'
> 2019-07-16 15:01:19,603+02 WARN  
> [org.ovirt.engine.core.utils.ObjectIdentityChecker] (default task-15) 
> [685e07c0-b76f-4093-afc9-7c3999ee4ae2] Field 'consoleEnabled' can not be 
> updated when status is 'Up'
> 
> Then in my vdsm.log I'm seeing the following error
> 
> 2019-07-16 15:05:59,038+0200 WARN  (qgapoller/3) [virt.periodic.VmDispatcher] 
> could not run  at 0x7f00a00476e0> on 
> ['ded20d05-f558-4e17-bf2d-e4907e1bbcde', 
> '8c93b301-b50d-4d3d-b6cb-54abb3d7f0bb', 
> '8d8571bf-a7ce-4e73-8d3e-fe1a2aab9b4b', 
> '2489c75f-2758-4d82-8338-12f02ff78afa', 
> '9a6561b8-5702-43dc-9e92-1dc5dfed4eef', 
> '523ad9ee-5738-42f2-9ee1-50727207e93b', 
> '84f4685b-39e1-4bc8-b8ab-755a2c325cb0', 
> '43c06f86-2e37-410b-84be-47e83052344a', 
> '6f44a02c-5de6-4002-992f-2c2c5feb2ee5', 
> '19844323-b3cc-441a-8d70-e45326848b10', 
> '77872f3d-c69f-48ab-992b-1d2765a38481'] (periodic:289)
> 
> 2019-07-16 15:06:09,036+0200 WARN  (qgapoller/2) [virt.periodic.VmDispatcher] 
> could not run  at 0x7f00a00476e0> on 
> ['ded20d05-f558-4e17-bf2d-e4907e1bbcde', 
> '8c93b301-b50d-4d3d-b6cb-54abb3d7f0bb', 
> '8d8571bf-a7ce-4e73-8d3e-fe1a2aab9b4b', 
> '2489c75f-2758-4d82-8338-12f02ff78afa', 
> '9a6561b8-5702-43dc-9e92-1dc5dfed4eef', 
> '523ad9ee-5738-42f2-9ee1-50727207e93b', 
> '84f4685b-39e1-4bc8-b8ab-755a2c325cb0', 
> '43c06f86-2e37-410b-84be-47e83052344a', 
> '6f44a02c-5de6-4002-992f-2c2c5feb2ee5', 
> '19844323-b3cc-441a-8d70-e45326848b10', 
> '77872f3d-c69f-48ab-992b-1d2765a38481'] (periodic:289)
> 
> I'm not sure if this is related to either of the above issues though, but I 
> can attach the full log if needed.
> 
> Please shout if there is anything else you think I can try doing.
> 
> Thank you.
> 
> Regards.
> 
> Neil Wilson
> 
> 
> 
> 
> On Mon, Jul 15, 2019 at 11:29 AM Sharon Gratch  <mailto:sgra...@redhat.com>> wrote:
> Hi Neil,
> 
> Regarding issue 1 (Dashboard):
> I recommend to upgrade to latest oVirt version 4.3.5, for this fix as well as 
> other enhancements and bug fixes. 
> For oVirt 4.3.5 installation / upgrade instructions: 
> http://www.ovirt.org/release/4.3.5/ <http://www.ovirt.org/release/4.3.5/>
> 
> Regarding issue 2 (Manual Migrate dialog):
> If it will be reproduced after upgrading then please try to clean your 
> browser caching before running the admin portal. It might help.
> 
> Regards,
> Sharon
> 
> On Thu, Jul 11, 2019 at 1:24 PM Neil  <mailto:nwilson...@gmail.com>> wrote:
> 
> Hi Sharon,
> 
> Thanks for the assistance.
> On Thu, Jul 11, 2019 at 11:58 AM Sharon Gratch  <mailto:sgra...@redhat.com>> wrote:
> Hi,
> 
> Regarding issue 1 (Dashboard):
> Did you upgrade the engine to 4.3.5? There was a bug fixed in version 4.3.4-5 
> https://bugzilla.redhat.com/show_bug.cgi?id=1713967 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1713967> and it may be the same 
> issue.
> 
> 
> No I  wasn't aware that there were updates, how do I obtain 4.3.4-5 is there 
> another repo available?
> 
> Regarding issue 2 (Manual Migrate dialog):
> Can you please attach your browser console log and engine.log snippet when 
> you have the problem?
> If you could take from the console log the actual REST API response, that 
> would be great.
> The request will be something like /api/hosts?migration_target_of=...
> 
> Please see attached text log for the browser console, I don't see any REST 
> API being logged, just a stack trace error.
> The engine.log literally doesn't get updated when I click the Migrate button 
> so there isn't anything to share unfortunately.
> 
> Please 

[ovirt-users] Re: 4.3.5 update error

2019-07-31 Thread Michal Skrivanek
Didi,
is this the same thing you’ve found out recently?

Thanks,
michal

> On 31 Jul 2019, at 10:01, Kapetanakis Giannis  
> wrote:
> 
> On 31/07/2019 10:47, Kapetanakis Giannis wrote:
>> Hi,
>> 
>> Trying today engine-setup to update from 4.3.3 -> 4.3.5 I got this error:
>> 
>> [ ERROR ] Failed to execute stage 'Setup validation': local variable 
>> 'snapshot_cl' referenced before assignment
>> 
>> In log file I see:
>> 
>> 2019-07-31 10:43:00,375+0300 DEBUG otopi.context context._executeMethod:145 
>> method exception
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in 
>> _executeMethod
>> method['method']()
>>   File 
>> "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py",
>>  line 437, in _validation
>> self._checkSnapshotCompatibilityVersion()
>>   File 
>> "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py",
>>  line 212, in _checkSnapshotCompatibilityVersion
>> 'v': snapshot_cl,
>> UnboundLocalError: local variable 'snapshot_cl' referenced before assignment
>> 2019-07-31 10:43:00,381+0300 ERROR otopi.context context._executeMethod:154 
>> Failed to execute stage 'Setup validation': local variable 'snapshot_cl' 
>> referenced before assignment
>> 
>> Any hints?
>> 
>> thanks
>> 
>> Giannis
> 
> 
> After removing all snapshots, I was able to continue the upgrade.
> 
> G
> ___
> Users mailing list -- users@ovirt.org 
> To unsubscribe send an email to users-le...@ovirt.org 
> 
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ 
> 
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/ 
> 
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/JDGJW2C4JWRZJK5AVDXCDMBCL374K246/
>  
> 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/FFCYHYB3WQOTVZ5MRARN6UH53B4TO6WD/


[ovirt-users] Re: template permissions not inherited (4.3.4)

2019-07-24 Thread Michal Skrivanek


> On 24 Jul 2019, at 12:07, Timmi  wrote:
> 
> Hi Lucie,
> 
> so I installed the latest 4.3.5 RC on my platform and I still have the same 
> issue.
> Only system or cluster permissions are inherited.

which other permission do you expect to see?
the actual ownership is set according to the creator, not the owner of the 
template

> 
> Best regards
> Christoph
> 
> Am 24.07.19 um 11:26 schrieb Timmi:
>> Hi Lucie,
>> 
>> thank you for the reply.
>> 
>> Am 24.07.19 um 08:21 schrieb Lucie Leistnerova:
>>> Hi Christoph,
>>> 
>>> On 7/22/19 2:28 PM, Timmi wrote:
 Hi oVirt List,
 
 I have just a quick question if I should open a ticket for this or if I'm 
 doing something wrong.
 
 I created a new VM template with specific permissions in addition to the 
 system wide permissions. If I create a new VM with the template I notices 
 that only system permissions are copied to the permission of the new VM.
 
 Is this the intended behavior? I was somehow under the impression that the 
 permission from the template should have been copied to the newly created 
 VM.
>>> 
>>> Did you check by creating the VM that permissions should be copied?
>> I have activated the copy of the permission while creating the template from 
>> an existing VM.
>> Also I have checked the permission on the template afterwards an I can see 
>> that the permissions are correct.
>> But these permissions are not copied to the new VM created from the template.
>>> 
>>> I've tested ovirt 4.3.5 and I added UserRole and custom role to the 
>>> template for test user. Newly created VM contained both of the roles for 
>>> the user. Is this the case you mean?
>>> 
>> OK I will update to the latest RC from 4.3.5 and check again.
>> Keep you posted.
 
 Tested with Version 4.3.4.3-1.el7
 
 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/site/privacy-policy/
 oVirt Code of Conduct: 
 https://www.ovirt.org/community/about/community-guidelines/
 List Archives: 
 https://lists.ovirt.org/archives/list/users@ovirt.org/message/ADS2EUY4K3RA2ZF6OEG2GHW6ZPUIZKLH/
>>> Best regards,
>>> 
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct: 
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives: 
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/VVHSHEVAHSFGKZHUG324LMGZYB3MIG56/
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/6ZVXEDJNCPZW4H5VFWO4UBIPXS2IHRCF/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3QLQH4L5K7UWJRZ74GPTYMXWUJSH4O6O/


[ovirt-users] Re: Hardware Used

2019-07-17 Thread Michal Skrivanek


> On 16 Jul 2019, at 15:10, Adrian Odendaal  wrote:
> 
> No well we saw that only CPU’s are supported.
> 
> So we want to find out what hardware we need in order to progress.
> 
> Servers with the needed CPU architecture. 

Not sure what you’re looking for. A developer kind of answer - you got that 
already. If you want anything better I suggest you talk to a vendor who sells 
oVirt for a living and help you with the right architecture fitting your needs. 
List of certified Intel CPUs for RHEL (and hence CentOS) is here [1] and 
here[2]. We also support IBM POWER8 and POWER9, and if you wanna start 
something really big, IBM zSystem mainframes as a tech preview;-)

Thanks,
michal

[1] https://access.redhat.com/support/policy/intel 
<https://access.redhat.com/support/policy/intel>
[2] https://access.redhat.com/support/policy/amd 
<https://access.redhat.com/support/policy/amd>

> 
> Kind Regards
> 
> 
> 
> 
> 
> 
> 
> 
> Legal Disclaimer:
> 
> This message contains privileged and confidential information intended only 
> for the use of the addressee named above. If you are not the intended 
> recipient of this message, you are hereby notified that you may not 
> disseminate, copy or take any action based on the contents thereof; kindly 
> inform the sender immediately. Any views expressed in this message are those 
> of the individual sender, except where the sender specifically states them to 
> be the view of Quodes Solutions CC. While every care has been taken in 
> preparing this document, no representation, warranty or undertaking 
> (expressed or implied) is given and no responsibility nor liability is 
> accepted by any member of Quodes Solutions CC as to the accuracy of the 
> information contained herein, or for any loss arising from reliance on it.
> 
>> On 16 Jul 2019, at 15:08, Michal Skrivanek > <mailto:michal.skriva...@redhat.com>> wrote:
>> 
>> 
>> 
>>> On 16 Jul 2019, at 15:02, Adrian Odendaal >> <mailto:adr...@quodes.co.za>> wrote:
>>> 
>>> Hi There
>>> 
>>> I need some help regarding what hardware we can use to get this up and 
>>> going as your website indicates only certain cpu’s can be used.
>> 
>> hey
>> where exactly? For running ovirt we support exact same hardware as 
>> RHEL/CentOS does
>> 
>>> 
>>> Kind Regards
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Legal Disclaimer:
>>> 
>>> This message contains privileged and confidential information intended only 
>>> for the use of the addressee named above. If you are not the intended 
>>> recipient of this message, you are hereby notified that you may not 
>>> disseminate, copy or take any action based on the contents thereof; kindly 
>>> inform the sender immediately. Any views expressed in this message are 
>>> those of the individual sender, except where the sender specifically states 
>>> them to be the view of Quodes Solutions CC. While every care has been taken 
>>> in preparing this document, no representation, warranty or undertaking 
>>> (expressed or implied) is given and no responsibility nor liability is 
>>> accepted by any member of Quodes Solutions CC as to the accuracy of the 
>>> information contained herein, or for any loss arising from reliance on it.
>>> 
>>>> On 15 Jul 2019, at 11:54, Adrian Odendaal >>> <mailto:adr...@quodes.co.za>> wrote:
>>>> 
>>>> Are those CPU’s dedicated for the Hypervisors? 
>> 
>> again not sure what you mean. but usually the entire host is dedicated for 
>> virtualization
>> 
>>>> 
>>>> What are the minimal requirements to setting up a cluster?
>> 
>> depends what you want it to do. the general a meaningful scale is from cca 
>> three hosts up to several hundreds.
>> 
>>>> 
>>>> We are looking into using Ovirt over the likes on Hyper-v and VMWare.
>>>> 
>>>> Can you give me a run down?
>>>> 
>>>> Kind Regards
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Legal Disclaimer:
>>>> 
>>>> This message contains privileged and confidential information intended 
>>>> only for the use of the addressee named above. If you are not the intended 
>>>> recipient of this message, you are hereby notified that you may not 
>>>> disseminate, copy or take any action based on the contents t

[ovirt-users] Re: Hardware Used

2019-07-16 Thread Michal Skrivanek


> On 16 Jul 2019, at 15:02, Adrian Odendaal  wrote:
> 
> Hi There
> 
> I need some help regarding what hardware we can use to get this up and going 
> as your website indicates only certain cpu’s can be used.

hey
where exactly? For running ovirt we support exact same hardware as RHEL/CentOS 
does

> 
> Kind Regards
> 
> 
> 
> 
> 
> 
> 
> 
> Legal Disclaimer:
> 
> This message contains privileged and confidential information intended only 
> for the use of the addressee named above. If you are not the intended 
> recipient of this message, you are hereby notified that you may not 
> disseminate, copy or take any action based on the contents thereof; kindly 
> inform the sender immediately. Any views expressed in this message are those 
> of the individual sender, except where the sender specifically states them to 
> be the view of Quodes Solutions CC. While every care has been taken in 
> preparing this document, no representation, warranty or undertaking 
> (expressed or implied) is given and no responsibility nor liability is 
> accepted by any member of Quodes Solutions CC as to the accuracy of the 
> information contained herein, or for any loss arising from reliance on it.
> 
>> On 15 Jul 2019, at 11:54, Adrian Odendaal > <mailto:adr...@quodes.co.za>> wrote:
>> 
>> Are those CPU’s dedicated for the Hypervisors? 

again not sure what you mean. but usually the entire host is dedicated for 
virtualization

>> 
>> What are the minimal requirements to setting up a cluster?

depends what you want it to do. the general a meaningful scale is from cca 
three hosts up to several hundreds.

>> 
>> We are looking into using Ovirt over the likes on Hyper-v and VMWare.
>> 
>> Can you give me a run down?
>> 
>> Kind Regards
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Legal Disclaimer:
>> 
>> This message contains privileged and confidential information intended only 
>> for the use of the addressee named above. If you are not the intended 
>> recipient of this message, you are hereby notified that you may not 
>> disseminate, copy or take any action based on the contents thereof; kindly 
>> inform the sender immediately. Any views expressed in this message are those 
>> of the individual sender, except where the sender specifically states them 
>> to be the view of Quodes Solutions CC. While every care has been taken in 
>> preparing this document, no representation, warranty or undertaking 
>> (expressed or implied) is given and no responsibility nor liability is 
>> accepted by any member of Quodes Solutions CC as to the accuracy of the 
>> information contained herein, or for any loss arising from reliance on it.
>> 
>>> On 15 Jul 2019, at 11:23, Michal Skrivanek >> <mailto:michal.skriva...@redhat.com>> wrote:
>>> 
>>> 
>>> 
>>>> On 15 Jul 2019, at 09:38, Emil Natan >>> <mailto:e...@redhat.com>> wrote:
>>>> 
>>>> I think the right place for this question is the ovirt users mailing list. 
>>>> Added.
>>>> 
>>>> On Mon, Jul 15, 2019 at 10:28 AM >>> <mailto:adr...@quodes.co.za>> wrote:
>>>> Hi All
>>>> 
>>>> We are looking into setting up a highly scalable and HA Ovirt 
>>>> infrastructure but I see only some CPU's are supported. Is this only for 
>>>> th Hypervisors or for the entire cluster?
>>> 
>>> Not sure what difference you have in mind. In general those are for guest 
>>> CPUs, in general KVM capabilities are a bit behind the real hardware and 
>>> gets added to oVirt as we add the relevant qemu-kvm having them, e.g. right 
>>> now the “best” x86_64 Intel CPU is Skylake-Server and you can run it on any 
>>> RHEL/CentOS 7.6 supported hw capable of at least that, e.g. any Cascade 
>>> Lake.
>>> 
>>>> ___
>>>> Infra mailing list -- in...@ovirt.org <mailto:in...@ovirt.org>
>>>> To unsubscribe send an email to infra-le...@ovirt.org 
>>>> <mailto:infra-le...@ovirt.org>
>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ 
>>>> <https://www.ovirt.org/site/privacy-policy/>
>>>> 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/in...@ovirt.org/message/X5MMJXN67

[ovirt-users] Re: VM status codes

2019-07-15 Thread Michal Skrivanek
On 15 Jul 2019, at 15:11, Mitja Mihelič  wrote:

Hi!

We are graphing certain parameters we collect from the engine database.
We use following query to get the count of running VMs:
select count(*),cluster.name as cluster from vms, cluster where
vms.cluster_id = cluster.cluster_id and vms.status = 1 group by cluster;

It would help extremely if we knew what the numeric VM status codes mean.


https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/businessentities/VMStatus.java#L9

For example, I know that "status = 1" means the VM is running. The ones we
can cause through the web interface are easy enough to figure out. But
there are error states, that cannot be produced by standard use.

For instance, when the event log says "VM foobar has been paused due to
storage I/O problem." the following states get set in the DB
(Query used: select * from vm_dynamic where vm_guid =(select vm_guid from
vm_static where vm_name = 'foobar';):
status | 4
exit_status| 0
pause_status   | 2
guest_agent_status | 0

What do they mean?

If you could point me to a table somewhere with the state descriptions it
would be extremely helpful.

Kind regards,
Mitja Mihelič
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZBNGPWHGYHV4M3MM2VXTMKVYKUNARWVG/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/N6BO7K76NJK2TFT2BR7FYIKYL3EQ336G/


[ovirt-users] Re: Hardware Used

2019-07-15 Thread Michal Skrivanek


> On 15 Jul 2019, at 09:38, Emil Natan  wrote:
> 
> I think the right place for this question is the ovirt users mailing list. 
> Added.
> 
> On Mon, Jul 15, 2019 at 10:28 AM  > wrote:
> Hi All
> 
> We are looking into setting up a highly scalable and HA Ovirt infrastructure 
> but I see only some CPU's are supported. Is this only for th Hypervisors or 
> for the entire cluster?

Not sure what difference you have in mind. In general those are for guest CPUs, 
in general KVM capabilities are a bit behind the real hardware and gets added 
to oVirt as we add the relevant qemu-kvm having them, e.g. right now the “best” 
x86_64 Intel CPU is Skylake-Server and you can run it on any RHEL/CentOS 7.6 
supported hw capable of at least that, e.g. any Cascade Lake.

> ___
> Infra mailing list -- in...@ovirt.org 
> To unsubscribe send an email to infra-le...@ovirt.org 
> 
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ 
> 
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/ 
> 
> List Archives: 
> https://lists.ovirt.org/archives/list/in...@ovirt.org/message/X5MMJXN67LMBCJQKDPK4MJECHMQWVKXZ/
>  
> 
> 
> 
> -- 
> Emil Natan
> RHV/CNV DevOps
> ___
> Infra mailing list -- in...@ovirt.org
> To unsubscribe send an email to infra-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/in...@ovirt.org/message/H62H2FA2DBEUF6CENHXTWVR6GEXVCYCX/

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/V7P2AN27TN6ZIZBBS2JBLWD2MW3OIEF6/


[ovirt-users] Re: Manual Migration not working and Dashboard broken after 4.3.4 update

2019-07-10 Thread Michal Skrivanek
On 11 Jul 2019, at 06:34, Alex K  wrote:



On Tue, Jul 9, 2019, 19:10 Michal Skrivanek 
wrote:

>
>
> On 9 Jul 2019, at 17:16, Strahil  wrote:
>
> I'm not sure, but I always thought that you need  an agent for live
> migrations.
>
>
> You don’t. For snapshots, and other less important stuff like reporting
> IPs you do. In 4.3 you should be fine with qemu-ga only
>
I've seen resolving live migration issues by installing newer versions of
ovirt ga.


Hm, it shouldn’t make any difference whatsoever. Do you have any concrete
data? that would help.

You can always try installing either qemu-guest-agent  or ovirt-guest-agent
> and check if live  migration between hosts is possible.
>
> Have you set the new cluster/dc version ?
>
> Best Regards
> Strahil Nikolov
> On Jul 9, 2019 17:42, Neil  wrote:
>
> I remember seeing the bug earlier but because it was closed thought it was
> unrelated, this appears to be it
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1670701
>
> Perhaps I'm not understanding your question about the VM guest agent, but
> I don't have any guest agent currently installed on the VM, not sure if the
> output of my qemu-kvm process maybe answers this question?
>
> /usr/libexec/qemu-kvm -name guest=Headoffice.cbl-ho.local,debug-threads=on
> -S -object
> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-Headoffice.cbl-ho.lo/master-key.aes
> -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -cpu
> Broadwell,vme=on,f16c=on,rdrand=on,hypervisor=on,arat=on,xsaveopt=on,abm=on,rtm=on,hle=on
> -m 8192 -realtime mlock=off -smp 8,maxcpus=64,sockets=16,cores=4,threads=1
> -numa node,nodeid=0,cpus=0-7,mem=8192 -uuid
> 9a6561b8-5702-43dc-9e92-1dc5dfed4eef -smbios
> type=1,manufacturer=oVirt,product=oVirt
> Node,version=7-3.1611.el7.centos,serial=4C4C4544-0034-5810-8033-
>
>
It’s 7.3, likely oVirt 4.1. Please upgrade...

C2C04F4E4B32,uuid=9a6561b8-5702-43dc-9e92-1dc5dfed4eef -no-user-config
> -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon
> chardev=charmonitor,id=monitor,mode=control -rtc
> base=2019-07-09T10:26:53,driftfix=slew -global
> kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on
> -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
> virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device
> virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 -drive
> if=none,id=drive-ide0-1-0,readonly=on -device
> ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
> file=/rhev/data-center/59831b91-00a5-01e4-0294-0018/8a607f8a-542a-473c-bb18-25c05fe2a3d4/images/56e8240c-a172-4f52-b0c1-2bddc4f34f93/9f245467-d31d-4f5a-8037-7c5012a4aa84,format=qcow2,if=none,id=drive-virtio-disk0,serial=56e8240c-a172-4f52-b0c1-2bddc4f34f93,werror=stop,rerror=stop,cache=none,aio=native
> -device
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on
> -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device
> virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:16:01:5b,bus=pci.0,addr=0x3
> -chardev socket,id=charchannel0,fd=35,server,nowait -device
> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm
> -chardev socket,id=charchannel1,fd=36,server,nowait -device
> virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
> -chardev spicevmc,id=charchannel2,name=vdagent -device
> virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0
> -spice 
> tls-port=5900,addr=10.0.1.11,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=default,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on
> -device
> qxl-vga,id=video0,ram_size=67108864,vram_size=8388608,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2
> -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
> -object rng-random,id=objrng0,filename=/dev/urandom -device
> virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x8 -sandbox
> on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
> -msg timestamp=on
>
> Please shout if you need further info.
>
> Thanks.
>
>
>
>
>
>
> On Tue, Jul 9, 2019 at 4:17 PM Strahil Nikolov 
> wrote:
>
> Shouldn't cause that problem.
>
> You have to find the bug in bugzilla and report a regression (if it's not
> closed) , or open a new one and report the regression.
> As far as I remember , only the dashboard was affected due to new features
> about vdo disk savings.
>
> 

[ovirt-users] Re: VM Migrations Failing

2019-07-10 Thread Michal Skrivanek
> On 10 Jul 2019, at 21:01, Strahil  wrote:
>
> Power down the VM and reduce the memory a little bit but keep the maximum 
> memory value the same or larger.
> Then power it up and extend the ram to the same value the VM had.
>
> It's a wild guess... So don't expect miracles.
>
> Best Regards,
> Strahil NikolovOn Jul 10, 2019 18:21, Michael Watters  
> wrote:
>>
>> I need to migrate running VMs from one host in our cluster to another
>> however the task keeps failing any time I start a migration.  The engine
>> logs show a few different errors as follows.
>>
>> 2019-07-10 09:53:19,440-04 ERROR
>> [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer]
>> (ForkJoinPool-1-worker-2) [] Migration of VM 'vm1' to host
>> 'ovirt-node-production3' failed: VM destroyed during the startup.
>>
>> 2019-07-10 09:53:06,542-04 ERROR
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-51) [c1daf639-ff39-4397-b1bf-09426cacf72d] EVENT_ID:
>> VM_MIGRATION_FAILED(65), Migration failed due to a failed validation:
>> [Cannot migrate VM. There is no host that satisfies current scheduling
>> constraints. See below for details:, The host ovirt-node-production3 did
>> not satisfy internal filter Memory.] (VM: vm2, Source:
>> ovirt-node-production2).

You do not have enough available memory on the target. It happens with
high overcommit, migrating to a new host require more space initially
than what it currently takes on source. Check avail mem for scheduling
on the other host

Host Maintenance just tries over and over, so there’s a better chance
it succeeds eventually.

>>
>>
>> I also checked the vdsm.log on the destination host which is showing an
>> error like this.
>>
>> ERROR (jsonrpc/2) [virt.vm]
>> (vmId='f5bb25a8-3176-40b6-b21b-f07ed1089b27') Alias not found for device
>> type balloon during migration at destination host (vm:5562)
>>
>> Does anybody know how to resolve this?  The destination host is able to
>> run VMs and I've been able to move a few VMs by shutting down and doing
>> a restart however I'd like to do a live migration if possible.
>>
>>
>>
>>
>>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct: 
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives: 
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/AWOTK2Q7OJGJXHKNSBBHJJNJP3O2ANVJ/
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/STQLZJJSQ3L36QFV253IZ3SRAWIJ6AM3/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UJG2IAPTTVB5RNLEP2HSJ7T4B6KKPAJJ/


[ovirt-users] Re: Regarding VDSM_Hooks

2019-07-10 Thread Michal Skrivanek


> On 9 Jul 2019, at 22:09, Vrgotic, Marko  wrote:
> 
> Dear Michal,
> 
> Thank you for the update.
> 
> 
> On 9 Jul 2019, at 19:07, Michal Skrivanek  <mailto:michal.skriva...@redhat.com>> wrote:
> 
>> 
>> 
>>> On 5 Jul 2019, at 16:09, Vrgotic, Marko >> <mailto:m.vrgo...@activevideo.com>> wrote:
>>> 
>>> Dear oVIrt,
>>>  
>>> Happy to report I have deployed my first python vdsm_hook which removes A, 
>>> , TXT records of VM each time after_vm_destroy event is triggered, and 
>>> it works fine.
>>> This was required to be able to quickly redploy/rebuild VMs using same 
>>> hostname.
>>>  
>>> Issue I am observing/just discovered now is:
>>> Since live_migration of VM guest is considered a destruction from Host 
>>> perspective, DNS records get deleted and VM lands on new host without being 
>>> resolvable  .
>>>  
>>> I would like to introduce another python script for hook regarding 
>>> migration events to get these entries back into DNS but for that I need 
>>> there IPs.
>>>  
>>> Question:
>>> Where can I find/locate/read VMs IPs and Hostnames (is it dom_xml) to be 
>>> able to incorporate them for DNS Update script?
>> 
>> IP is reported via guest agent.
>> You can get that from engine’s API. But this being a hook you can probably 
>> poll directly as part of the pre/post migration hook by directly interacting 
>> with vdsm, either from a python hook or using vdsm-client, get VM's stats 
>> and parse it from there
> This is definitely option I will look into. The downside of this is that I 
> need to delete the records, read the IPs and update the record into DNS. If 
> software tests are running and we have request relying on DNS after records 
> deleted and before updated, they would fail. But I assume that period is very 
> short and it could be mitigated using cache.

is that a record for the guest IP? It won’t change during migration.

>> 
>>> Or even better:
>>> What would be even better, is there a way to not trigger the dns update if 
>>> VM is being Migrated? Can I use dom_xml or other location to check wheter 
>>> VM is migrated  or not,  which would allow me to control if dnsupdate 
>>> should be triggered or not
>> 
>> Not sure how exactly you mean that to work, in general you can use 
>> before/after_vm_migrate_source and before/after_vm_migrate_destination hook 
>> points to intervene wherever you prefer.
>> 
> The reason why I mentioned this would be better, if it can be pulled off, is 
> that I would not need to trigger deletion of records if I could catch the 
> migration action. In case it would be shutdown/power off or delete, it would 
> be triggered, but not in case of migration.

there are hook points for all lifecycle actions, usually both before and after 
so you can put it in the right place as you see fit.

Thanks
michal

>>>  
>>>  
>>> If its relevant for the question: we are currently running oVIrt 4.3.3 
>>> version
>>>  
>>> Kindly awaiting your reply.
>>>  
>>> Marko Vrgotic
>>> ActiveVideo
>>> ___
>>> 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/site/privacy-policy/ 
>>> <https://www.ovirt.org/site/privacy-policy/>
>>> 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/TRQJAAGDZN67BLLWRLLRAGYUSB2EDAWA/
>>>  
>>> <https://lists.ovirt.org/archives/list/users@ovirt.org/message/TRQJAAGDZN67BLLWRLLRAGYUSB2EDAWA/>

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CZREIPHMMJTCBHYFBH6UHEO5CAZXOBOU/


[ovirt-users] Re: VM Portal please add search filter box and list view as in Administration portal

2019-07-09 Thread Michal Skrivanek
On 9 Jul 2019, at 18:07, Vrgotic, Marko  wrote:

Dear oVirt,

This email has bounced two times already, and I am not sure what is wrong.
Hopefully you get it this time.

 Request is below.

Sent from my iPhone

Dear oVirt,



Would it be possible to discuss/consider adding search/filter field for VM
Portal, resembling one in Administration Portal?



I have 60 users with over 500VMs and it would be really good to have this
option. At this moment is virtually impossible to use the VMPortal due to
poor view options.


https://github.com/oVirt/ovirt-web-ui/pull/997 is in progress



We are currently running oVirt 4.3.3.





— — —
Met vriendelijke groet / Kind regards,

*Marko Vrgotic*

Sr.  System Engineer @ System Administration
m.vrgo...@activevideo.com



___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/EEO3OJ2EVVN4HGRDI7ODHNKSUHCGXRM2/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MQKZYMLL5PTU3ZS6MC5K6CGIPWBSS3FM/


[ovirt-users] Re: "Actual timezone in guest doesn't match configuration" for Windows VMs since guest agent 4.3

2019-07-09 Thread Michal Skrivanek


> On 8 Jul 2019, at 16:58, Matthias Leopold  
> wrote:
> 
> Hi,
> 
> the oVirt guest agent seems to report DST configuration for the timezone 
> since version 4.3 (of the guest agent). this results in "Actual timezone in 
> guest doesn't match configuration" messages in the UI for windows VMs because 
> the timezone field can't be matched with oVirt configuration anymore (no DST 
> flag). to me this looks like a bug. shall I report it?

Yes please. With more details if possible:) We started using qemu-ga for these 
and it’s possible that the report differs in this aspect. Then it needs to be 
fixed

Thanks,
michal

> 
> I know there was a similar thread at the beginning of May, but there was no 
> solution mentioned.
> 
> Matthias
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/F7QBHRUKETL77KM6LMDNHIT3UDFLG3ND/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CS5ORKIIVLQGBUOUMFTJOU3DRHZ4VYD5/


[ovirt-users] Re: UI exception when changing Cluster in New VM window

2019-07-09 Thread Michal Skrivanek
can you please try that on 4.3.5 and if it persist open a bug with that ui.log 
attached?

thanks,
michal

> On 5 Jul 2019, at 16:06, Vrgotic, Marko  wrote:
> 
> Hi Strahil,
>  
> I tried what you said and I am still getting an exception.
>  
> Correct me if I am wrong, but my expectation is following, when creating new 
> VM:
> Select cluster
> Whether I want to use template or create brand new VM from scratch, list of 
> templates and everything else specific to cluster I selected should be loaded
>  
> Instead, I get the exception and have to refresh/reload the page.
>  
> In short, when creating new VM, I am currently locked to a default loaded 
> cluster, which in my case is avshared1.
>  
> To give you bit more insight into configuration, here are the cluster details:
>  
> 
>  
> Per cluster:
> 
>  
> Let me know if you need me to provide more valuable information.
>  
> Kindly awaiting your reply.
>  
>  
> Best regards,
> Marko Vrgotic
>  
> From: Strahil Nikolov mailto:hunter86...@yahoo.com>>
> Date: Friday, 5 July 2019 at 15:42
> To: "users@ovirt.org "  >, "Vrgotic, Marko"  >
> Subject: Re: [ovirt-users] UI exception when changing Cluster in New VM window
>  
> As per your e-mail you try to both set a new cluster and new template , right?
> Could you try to edit the cluster and save and then edit again and check the 
> template lit ?
>  
> Best Regards,
> Strahil Nikolov
>  
> В четвъртък, 4 юли 2019 г., 22:31:11 ч. Гринуич-4, Vrgotic, Marko 
> mailto:m.vrgo...@activevideo.com>> написа:
>  
>  
> Dear oVirt,
> 
>  
> 
> We are running oVIrt SHE 4.3.3 version.
> 
>  
> 
> We have three production DCCs/clusters:
> 
> avshared1
> avlocal1
> avlocal2
>  
> 
> When navigating to Vitrual Machines > Selecting New VM > and changing 
> cluster, we get an UI exception:
> 
>  
> 
> Engine.log:
> 
> 2019-07-04 12:45:27,538Z ERROR 
> [org.ovirt.engine.core.utils.servlet.ServletUtils] (default task-468) [] 
> Error sending file 
> '/etc/ovirt-engine/branding/00-ovirt.brand/bundled/patternfly/fonts/fontawesome-webfont.woff2'.:
>  java.io.IOException: Connection reset by peer
> 
> at sun.nio.ch.FileDispatcherImpl.writev0(Native Method) 
> [rt.jar:1.8.0_201]
> 
> at 
> sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51) 
> [rt.jar:1.8.0_201]
> 
> at sun.nio.ch.IOUtil.write(IOUtil.java:148) [rt.jar:1.8.0_201]
> 
> at 
> sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:504) 
> [rt.jar:1.8.0_201]
> 
> at 
> org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:162)
> 
> at 
> io.undertow.conduits.AbstractFramedStreamSinkConduit.doWrite(AbstractFramedStreamSinkConduit.java:137)
>  [undertow-core-2.0.15.Final.jar:2.0.15.Final]
> 
> at 
> io.undertow.conduits.AbstractFramedStreamSinkConduit.write(AbstractFramedStreamSinkConduit.java:108)
>  [undertow-core-2.0.15.Final.jar:2.0.15.Final]
> 
> at 
> io.undertow.server.protocol.ajp.AjpServerResponseConduit.write(AjpServerResponseConduit.java:298)
>  [undertow-core-2.0.15.Final.jar:2.0.15.Final]
> 
> at 
> org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> 
> at 
> io.undertow.channels.DetachableStreamSinkChannel.write(DetachableStreamSinkChannel.java:240)
>  [undertow-core-2.0.15.Final.jar:2.0.15.Final]
> 
> at 
> io.undertow.server.HttpServerExchange$WriteDispatchChannel.write(HttpServerExchange.java:2103)
>  [undertow-core-2.0.15.Final.jar:2.0.15.Final]
> 
> at 
> io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:574)
>  [undertow-servlet-2.0.15.Final.jar:2.0.15.Final]
> 
> at 
> io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:150)
>  [undertow-servlet-2.0.15.Final.jar:2.0.15.Final]
> 
> at 
> org.ovirt.engine.core.utils.servlet.ServletUtils.writeFileToStream(ServletUtils.java:145)
>  [utils.jar:]
> 
> at 
> org.ovirt.engine.core.utils.servlet.ServletUtils.sendFile(ServletUtils.java:121)
>  [utils.jar:]
> 
> at 
> org.ovirt.engine.core.utils.servlet.ServletUtils.sendFile(ServletUtils.java:74)
>  [utils.jar:]
> 
> at 
> org.ovirt.engine.core.utils.servlet.ServletUtils.sendFile(ServletUtils.java:70)
>  [utils.jar:]
> 
> at 
> org.ovirt.engine.core.branding.BrandingServlet.doGet(BrandingServlet.java:50) 
> [branding.jar:]
> 
> at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:686) 
> [jboss-servlet-api_4.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 
> at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:791) 
> [jboss-servlet-api_4.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 
> at 
> 

  1   2   3   4   5   6   7   8   9   >