[ovirt-users] Re: Can't import some VMs after storage domain detach and reattach to new datacenter.

2020-12-09 Thread adrianquintero 
Hi Nir,
Trying to revive this old thread, I ran in to a similar issue. I imported a few 
VMs from an old VMWARE version into ovirt 4.3.3 using OVAs generated on the 
VMWARE side. After adjusting a bit the OVAs I was able to do the import.

A year later I have tried to export those VMs from 4.3.3 to a new 
Hyperconverged cluster that uses oVirt 4.3.10.
If I try to import a VM with only 1 disk I need to modify  the DISKTYPE from 1 
to DATA, and Need to add the alias on the DESCRIPTION field as it does not 
appear on  the v5 (ovirt 4.3.10).

Original settings:

Disk1.-
[root@ovirt1 images]# strings  
a88461c4-61cb-4dbc-806e-484ce6fd5b4d/247d61c6-46a1-4c48-bb2d-55f6b8743692.meta 
DOMAIN=523debef-f166-407d-a8d8-9cfd6d20ebb7
VOLTYPE=LEAF
CTIME=1574205481
MTIME=1574205481
IMAGE=a88461c4-61cb-4dbc-806e-484ce6fd5b4d
DISKTYPE=1
PUUID=----
LEGALITY=LEGAL
POOL_UUID=
SIZE=209715200
FORMAT=RAW
TYPE=SPARSE
DESCRIPTION=generated by virt-v2v 1.38.2rhel_7,release_12.el7_6.2,libvirt

Disk2.-
[root@ovirt1 images]# strings 
75044386-90db-4c16-94ad-0f376fa7ceea/d17a4bf4-e633-4e08-aa7c-42b22a2c8769.meta 
CAP=268435456000
CTIME=1575689283
DESCRIPTION=generated by virt-v2v 1.38.2rhel_7,release_12.el7_6.2,libvirt
DISKTYPE=1
DOMAIN=523debef-f166-407d-a8d8-9cfd6d20ebb7
FORMAT=RAW
GEN=0
IMAGE=75044386-90db-4c16-94ad-0f376fa7ceea
LEGALITY=LEGAL
PUUID=----
TYPE=PREALLOCATED
VOLTYPE=LEAF


I changed  DISKTYPE=1 to DISKTYPE=DATA and DESCRIPTION=DESCRIPTION=generated by 
virt-v2v 1.38.2rhel_7,release_12.el7_6.2,libvirt TO 
DESCRIPTION={"DiskAlias":"MYVM-DISK1","DiskDescription":""} and for Disk2 
DESCRIPTION={"DiskAlias":"MYVM-DISK2","DiskDescription":""}

VMs with only 1 disk on their configuration only migrates the disk and only 
able to import the disk, not the VM from an NFS sharead data domain. So I had 
to create the VM and attach the imported disk and worked fine. Then I tranfered 
the disk from the NFS domain to the VMSTORE Gluster domain... up to here all 
good.

Problem when I tried to do the same with a VM with 2 disks, up to starting the 
VM all was good, however migrating the storage to the VMSTORE Gluster domain 
the second disk stays in migration forever, issue related to deleting auto 
generated snapshot of the second disk. 

In order to half way solve the issue I had to follow up on:
 https://access.redhat.com/solutions/396753
 https://access.redhat.com/solutions/1347513
https://access.redhat.com/solutions/3991591
/usr/share/ovirt-engine/setup/dbutils/   
https://lists.ovirt.org/pipermail/users/2016-May/039898.html


but this caused a lot of downtime, so right now 1 disk of the VM is on VMSTORE 
DOMAIN (Gluster), and one disk on the migration data domain (NFS). Seems I 
can't transfer the second disk to VMSTORE Domain.

Any ideas?

Thanks,

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

[ovirt-users] Re: ovirt 4.3 - locked image vm - unable to remove a failed deploy of a guest dom

2020-12-09 Thread 3c . monitor 
Hi,
change that state was unuseful...

Cannot remove Template. The following Disk(s) are based on it:
(0ae7f8f0-9dff-4649-8009-34191349dcc9) .

Of course, in disk list there isn't...

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

[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 >> > 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) 
 
 
> 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: 
>

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

2020-12-09 Thread jb 


Am 09.12.20 um 14:42 schrieb 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


No I don't need every feature. My concern was mostly, if I will have any 
performance downsides in normal scenarios.




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) 



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

[ovirt-users] Re: Turkey Standart Time

2020-12-09 Thread Sandro Bonazzola 
Il giorno mer 9 dic 2020 alle ore 12:45  ha scritto:

> Hi,
> We've figured out there is no Turkish time zone on "Hardware Clock Time
> Offset" when we were trying sysprep
> it causes some problems on GPO applyment, Outlook, Skype etc. connections
> in AD environment
> Is there any cli options we can add this?
> If you take this as an future request we'll appreciate
>

Can you please open a BZ about it on bugzilla.redhat.com?
As an alternative, you can try pushing a fix yourself following
https://www.ovirt.org/develop/developer-guide/engine/engine-supported-time-zones.html

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


-- 

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

[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) 
>> 
>> 
>>> 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/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-using existing SD for SHE 4.3 when upgrading to 4.4

2020-12-09 Thread branimir 
Hi,
How easy would it be to re-use the existing Storage Domain used for 4.3 Self 
Hosted Engine VM when upgrading to oVirt 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/W6JQC7YBNUAZ5NCSBMRPPZNGD2QO23FZ/

[ovirt-users] Re: Another illegal disk snapshot problem!

2020-12-09 Thread Joseph Goldman 

Attached XML dump.

Looks like its let me run a 'reboot' but im afraid to do a shutdown at 
this point.


I have taken just a raw copy of the whole image group folder in the hope 
if worse came to worse I'd be able to recreate the disk with the actual 
files.


All existing files seem to be referenced in the xmldump.

On 9/12/2020 11:54 pm, Benny Zlotnik wrote:

The VM is running, right?
Can you run:
$ virsh -r dumpxml 

On Wed, Dec 9, 2020 at 2:01 PM Joseph Goldman  wrote:

Looks like the physical files dont exist:

2020-12-09 22:01:00,122+1000 INFO (jsonrpc/4) [api.virt] START
merge(drive={u'imageID': u'23710238-07c2-46f3-96c0-9061fe1c3e0d',
u'volumeID': u'4b6f7ca1-b70d-4893-b473-d8d30138bb6b', u'domainID':
u'74c06ce1-94e6-4064-9d7d-69e1d956645b', u'poolID':
u'e2540c6a-33c7-4ac7-b2a2-175cf51994c2'},
baseVolUUID=u'c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1',
topVolUUID=u'a6d4533b-b0b0-475d-a436-26ce99a38d94', bandwidth=u'0',
jobUUID=u'ff193892-356b-4db8-b525-e543e8e69d6a')
from=:::192.168.5.10,56030,
flow_id=c149117a-1080-424c-85d8-3de2103ac4ae,
vmId=2a0df965-8434-4074-85cf-df12a69648e7 (api:48)

2020-12-09 22:01:00,122+1000 INFO  (jsonrpc/4) [api.virt] FINISH merge
return={'status': {'message': 'Drive image file could not be found',
'code': 13}} from=:::192.168.5.10,56030,
flow_id=c149117a-1080-424c-85d8-3de2103ac4ae,
vmId=2a0df965-8434-4074-85cf-df12a69648e7 (api:54)

Although looking on the physical file system they seem to exist:

[root@ov-node1 23710238-07c2-46f3-96c0-9061fe1c3e0d]# ll
total 56637572
-rw-rw. 1 vdsm kvm  15936061440 Dec  9 21:51
4b6f7ca1-b70d-4893-b473-d8d30138bb6b
-rw-rw. 1 vdsm kvm  1048576 Dec  8 01:11
4b6f7ca1-b70d-4893-b473-d8d30138bb6b.lease
-rw-r--r--. 1 vdsm kvm  252 Dec  9 21:37
4b6f7ca1-b70d-4893-b473-d8d30138bb6b.meta
-rw-rw. 1 vdsm kvm  21521825792 Dec  8 01:47
a6d4533b-b0b0-475d-a436-26ce99a38d94
-rw-rw. 1 vdsm kvm  1048576 May 17  2020
a6d4533b-b0b0-475d-a436-26ce99a38d94.lease
-rw-r--r--. 1 vdsm kvm  256 Dec  8 01:49
a6d4533b-b0b0-475d-a436-26ce99a38d94.meta
-rw-rw. 1 vdsm kvm 107374182400 Dec  9 01:13
c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1
-rw-rw. 1 vdsm kvm  1048576 Feb 24  2020
c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1.lease
-rw-r--r--. 1 vdsm kvm  320 May 17  2020
c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1.meta

The UUID's match the UUID's in the snapshot list.

So much stuff happens in vdsm.log its hard to pinpoint whats going on
but grepping 'c149117a-1080-424c-85d8-3de2103ac4ae' (flow-id) shows
pretty much those 2 calls and then XML dump.

Still a bit lost on the most comfortable way forward unfortunately.

On 8/12/2020 11:15 pm, Benny Zlotnik wrote:

[root@ov-engine ~]# tail -f /var/log/ovirt-engine/engine.log | grep ERROR

grepping error is ok, but it does not show the reason for the failure,
which will probably be on the vdsm host (you can use flow_id
9b2283fe-37cc-436c-89df-37c81abcb2e1 to find the correct file
Need to see the underlying error causing: VDSGenericException:
VDSErrorException: Failed to SnapshotVDS, error =
Snapshot failed, code = 48


Using unlock_entity.sh -t all sets the status back to 1 (confirmed in
DB) and then trying to create does not change it back to illegal, but
trying to delete that snapshot fails and sets it back to 4.

I see, can you share the removal failure log (similar information as
requested above)

regarding backup, I don't have a good answer, hopefully someone else
has suggestions
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MJHKYBPBTINAWY4VDSLLZZPWYI2O3SHB/



  prod-DC1
  2a0df965-8434-4074-85cf-df12a69648e7
  http://ovirt.org/vm/tune/1.0; 
xmlns:ovirt-vm="http://ovirt.org/vm/1.0;>

http://ovirt.org/vm/1.0;>
{}
4.3
False
0
false
8192
8192
kill
1606783465.63

CorpNetwork

4




74c06ce1-94e6-4064-9d7d-69e1d956645b
\\.\PhysicalDrive1

6863ab60-0d80-4cbf-95d5-2b209c776dc3
e2540c6a-33c7-4ac7-b2a2-175cf51994c2

83b02923-646f-419b-933e-7f90f30da7a6



74c06ce1-94e6-4064-9d7d-69e1d956645b

6863ab60-0d80-4cbf-95d5-2b209c776dc3
0

/rhev/data-center/mnt/192.168.5.11:_ovirt/74c06ce1-94e6-4064-9d7d-69e1d956645b/images/6863ab60-0d80-4cbf-95d5-2b209c776dc3/d848dbf8-6ee0-4d82-9ab8-7c7c1e461900.lease

/rhev/data-center/mnt/192.168.5.11:_ovirt/74c06ce1-94e6-4064-9d7d-69e1d956645b/images/6863ab60-0d80-4cbf-95d5-2b209c776dc3/d848dbf8-6ee0-4d82-9ab8-7c7c1e461900

d848dbf8-6ee0-4d82-9ab8-7c7c1e461900

[ovirt-users] Re: Another illegal disk snapshot problem!

2020-12-09 Thread Benny Zlotnik 
The VM is running, right?
Can you run:
$ virsh -r dumpxml 

On Wed, Dec 9, 2020 at 2:01 PM Joseph Goldman  wrote:
>
> Looks like the physical files dont exist:
>
> 2020-12-09 22:01:00,122+1000 INFO (jsonrpc/4) [api.virt] START
> merge(drive={u'imageID': u'23710238-07c2-46f3-96c0-9061fe1c3e0d',
> u'volumeID': u'4b6f7ca1-b70d-4893-b473-d8d30138bb6b', u'domainID':
> u'74c06ce1-94e6-4064-9d7d-69e1d956645b', u'poolID':
> u'e2540c6a-33c7-4ac7-b2a2-175cf51994c2'},
> baseVolUUID=u'c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1',
> topVolUUID=u'a6d4533b-b0b0-475d-a436-26ce99a38d94', bandwidth=u'0',
> jobUUID=u'ff193892-356b-4db8-b525-e543e8e69d6a')
> from=:::192.168.5.10,56030,
> flow_id=c149117a-1080-424c-85d8-3de2103ac4ae,
> vmId=2a0df965-8434-4074-85cf-df12a69648e7 (api:48)
>
> 2020-12-09 22:01:00,122+1000 INFO  (jsonrpc/4) [api.virt] FINISH merge
> return={'status': {'message': 'Drive image file could not be found',
> 'code': 13}} from=:::192.168.5.10,56030,
> flow_id=c149117a-1080-424c-85d8-3de2103ac4ae,
> vmId=2a0df965-8434-4074-85cf-df12a69648e7 (api:54)
>
> Although looking on the physical file system they seem to exist:
>
> [root@ov-node1 23710238-07c2-46f3-96c0-9061fe1c3e0d]# ll
> total 56637572
> -rw-rw. 1 vdsm kvm  15936061440 Dec  9 21:51
> 4b6f7ca1-b70d-4893-b473-d8d30138bb6b
> -rw-rw. 1 vdsm kvm  1048576 Dec  8 01:11
> 4b6f7ca1-b70d-4893-b473-d8d30138bb6b.lease
> -rw-r--r--. 1 vdsm kvm  252 Dec  9 21:37
> 4b6f7ca1-b70d-4893-b473-d8d30138bb6b.meta
> -rw-rw. 1 vdsm kvm  21521825792 Dec  8 01:47
> a6d4533b-b0b0-475d-a436-26ce99a38d94
> -rw-rw. 1 vdsm kvm  1048576 May 17  2020
> a6d4533b-b0b0-475d-a436-26ce99a38d94.lease
> -rw-r--r--. 1 vdsm kvm  256 Dec  8 01:49
> a6d4533b-b0b0-475d-a436-26ce99a38d94.meta
> -rw-rw. 1 vdsm kvm 107374182400 Dec  9 01:13
> c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1
> -rw-rw. 1 vdsm kvm  1048576 Feb 24  2020
> c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1.lease
> -rw-r--r--. 1 vdsm kvm  320 May 17  2020
> c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1.meta
>
> The UUID's match the UUID's in the snapshot list.
>
> So much stuff happens in vdsm.log its hard to pinpoint whats going on
> but grepping 'c149117a-1080-424c-85d8-3de2103ac4ae' (flow-id) shows
> pretty much those 2 calls and then XML dump.
>
> Still a bit lost on the most comfortable way forward unfortunately.
>
> On 8/12/2020 11:15 pm, Benny Zlotnik wrote:
> >> [root@ov-engine ~]# tail -f /var/log/ovirt-engine/engine.log | grep ERROR
> > grepping error is ok, but it does not show the reason for the failure,
> > which will probably be on the vdsm host (you can use flow_id
> > 9b2283fe-37cc-436c-89df-37c81abcb2e1 to find the correct file
> > Need to see the underlying error causing: VDSGenericException:
> > VDSErrorException: Failed to SnapshotVDS, error =
> > Snapshot failed, code = 48
> >
> >> Using unlock_entity.sh -t all sets the status back to 1 (confirmed in
> >> DB) and then trying to create does not change it back to illegal, but
> >> trying to delete that snapshot fails and sets it back to 4.
> > I see, can you share the removal failure log (similar information as
> > requested above)
> >
> > regarding backup, I don't have a good answer, hopefully someone else
> > has suggestions
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/privacy-policy.html
> > oVirt Code of Conduct: 
> > https://www.ovirt.org/community/about/community-guidelines/
> > List Archives: 
> > https://lists.ovirt.org/archives/list/users@ovirt.org/message/MJHKYBPBTINAWY4VDSLLZZPWYI2O3SHB/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CAKIPJCTQHNNVLZWQLLZXCJPKDLVIKKL/

[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: Another illegal disk snapshot problem!

2020-12-09 Thread Joseph Goldman 
On top of this, looks like this redhat article may have the solution but 
I cant access it, any help someone?


https://access.redhat.com/solutions/2852341

Thanks.

On 9/12/2020 10:51 pm, Joseph Goldman wrote:

This looks to be the problem:

2020-12-09 22:01:00,122+1000 INFO (jsonrpc/4) [api.virt] START 
merge(drive={u'imageID': u'23710238-07c2-46f3-96c0-9061fe1c3e0d', 
u'volumeID': u'4b6f7ca1-b70d-4893-b473-d8d30138bb6b', u'domainID': 
u'74c06ce1-94e6-4064-9d7d-69e1d956645b', u'poolID': 
u'e2540c6a-33c7-4ac7-b2a2-175cf51994c2'}, 
baseVolUUID=u'c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1', 
topVolUUID=u'a6d4533b-b0b0-475d-a436-26ce99a38d94', bandwidth=u'0', 
jobUUID=u'ff193892-356b-4db8-b525-e543e8e69d6a') 
from=:::192.168.5.10,56030, 
flow_id=c149117a-1080-424c-85d8-3de2103ac4ae, 
vmId=2a0df965-8434-4074-85cf-df12a69648e7 (api:48)


2020-12-09 22:01:00,122+1000 INFO  (jsonrpc/4) [api.virt] FINISH merge 
return={'status': {'message': 'Drive image file could not be found', 
'code': 13}} from=:::192.168.5.10,56030, 
flow_id=c149117a-1080-424c-85d8-3de2103ac4ae, 
vmId=2a0df965-8434-4074-85cf-df12a69648e7 (api:54)



Physical disk file does not appear to be there. Why would it still be 
in the

On 8/12/2020 11:15 pm, Benny Zlotnik wrote:

[root@ov-engine ~]# tail -f /var/log/ovirt-engine/engine.log | grep ERROR

grepping error is ok, but it does not show the reason for the failure,
which will probably be on the vdsm host (you can use flow_id
9b2283fe-37cc-436c-89df-37c81abcb2e1 to find the correct file
Need to see the underlying error causing: VDSGenericException:
VDSErrorException: Failed to SnapshotVDS, error =
Snapshot failed, code = 48


Using unlock_entity.sh -t all sets the status back to 1 (confirmed in
DB) and then trying to create does not change it back to illegal, but
trying to delete that snapshot fails and sets it back to 4.

I see, can you share the removal failure log (similar information as
requested above)

regarding backup, I don't have a good answer, hopefully someone else
has suggestions
___
Users mailing list --users@ovirt.org
To unsubscribe send an email tousers-le...@ovirt.org
Privacy Statement:https://www.ovirt.org/privacy-policy.html
oVirt Code of 
Conduct:https://www.ovirt.org/community/about/community-guidelines/
List 
Archives:https://lists.ovirt.org/archives/list/users@ovirt.org/message/MJHKYBPBTINAWY4VDSLLZZPWYI2O3SHB/



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

[ovirt-users] Re: Another illegal disk snapshot problem!

2020-12-09 Thread Joseph Goldman 

Looks like the physical files dont exist:

2020-12-09 22:01:00,122+1000 INFO (jsonrpc/4) [api.virt] START 
merge(drive={u'imageID': u'23710238-07c2-46f3-96c0-9061fe1c3e0d', 
u'volumeID': u'4b6f7ca1-b70d-4893-b473-d8d30138bb6b', u'domainID': 
u'74c06ce1-94e6-4064-9d7d-69e1d956645b', u'poolID': 
u'e2540c6a-33c7-4ac7-b2a2-175cf51994c2'}, 
baseVolUUID=u'c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1', 
topVolUUID=u'a6d4533b-b0b0-475d-a436-26ce99a38d94', bandwidth=u'0', 
jobUUID=u'ff193892-356b-4db8-b525-e543e8e69d6a') 
from=:::192.168.5.10,56030, 
flow_id=c149117a-1080-424c-85d8-3de2103ac4ae, 
vmId=2a0df965-8434-4074-85cf-df12a69648e7 (api:48)


2020-12-09 22:01:00,122+1000 INFO  (jsonrpc/4) [api.virt] FINISH merge 
return={'status': {'message': 'Drive image file could not be found', 
'code': 13}} from=:::192.168.5.10,56030, 
flow_id=c149117a-1080-424c-85d8-3de2103ac4ae, 
vmId=2a0df965-8434-4074-85cf-df12a69648e7 (api:54)


Although looking on the physical file system they seem to exist:

[root@ov-node1 23710238-07c2-46f3-96c0-9061fe1c3e0d]# ll
total 56637572
-rw-rw. 1 vdsm kvm  15936061440 Dec  9 21:51 
4b6f7ca1-b70d-4893-b473-d8d30138bb6b
-rw-rw. 1 vdsm kvm  1048576 Dec  8 01:11 
4b6f7ca1-b70d-4893-b473-d8d30138bb6b.lease
-rw-r--r--. 1 vdsm kvm  252 Dec  9 21:37 
4b6f7ca1-b70d-4893-b473-d8d30138bb6b.meta
-rw-rw. 1 vdsm kvm  21521825792 Dec  8 01:47 
a6d4533b-b0b0-475d-a436-26ce99a38d94
-rw-rw. 1 vdsm kvm  1048576 May 17  2020 
a6d4533b-b0b0-475d-a436-26ce99a38d94.lease
-rw-r--r--. 1 vdsm kvm  256 Dec  8 01:49 
a6d4533b-b0b0-475d-a436-26ce99a38d94.meta
-rw-rw. 1 vdsm kvm 107374182400 Dec  9 01:13 
c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1
-rw-rw. 1 vdsm kvm  1048576 Feb 24  2020 
c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1.lease
-rw-r--r--. 1 vdsm kvm  320 May 17  2020 
c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1.meta


The UUID's match the UUID's in the snapshot list.

So much stuff happens in vdsm.log its hard to pinpoint whats going on 
but grepping 'c149117a-1080-424c-85d8-3de2103ac4ae' (flow-id) shows 
pretty much those 2 calls and then XML dump.


Still a bit lost on the most comfortable way forward unfortunately.

On 8/12/2020 11:15 pm, Benny Zlotnik wrote:

[root@ov-engine ~]# tail -f /var/log/ovirt-engine/engine.log | grep ERROR

grepping error is ok, but it does not show the reason for the failure,
which will probably be on the vdsm host (you can use flow_id
9b2283fe-37cc-436c-89df-37c81abcb2e1 to find the correct file
Need to see the underlying error causing: VDSGenericException:
VDSErrorException: Failed to SnapshotVDS, error =
Snapshot failed, code = 48


Using unlock_entity.sh -t all sets the status back to 1 (confirmed in
DB) and then trying to create does not change it back to illegal, but
trying to delete that snapshot fails and sets it back to 4.

I see, can you share the removal failure log (similar information as
requested above)

regarding backup, I don't have a good answer, hopefully someone else
has suggestions
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MJHKYBPBTINAWY4VDSLLZZPWYI2O3SHB/

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

[ovirt-users] Turkey Standart Time

2020-12-09 Thread ozmen62 
Hi,
We've figured out there is no Turkish time zone on "Hardware Clock Time Offset" 
when we were trying sysprep
it causes some problems on GPO applyment, Outlook, Skype etc. connections in AD 
environment
Is there any cli options we can add this?
If you take this as an future request we'll appreciate 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/DLGEM3Z66QEEBTMV4D2PKZVNQPEVLEKC/

[ovirt-users] Re: How to install win-virtio Drivers (aka guest tools) silently

2020-12-09 Thread Gal Zaidman 
Hi,

Sorry it took so long, I was on PTO.
Anyway, I looked into it today and that is a bug we need to open (should be
an easy fix).
There are a few issues here:
1. The newest version of the drivers uses an EXE to install everything, and
we didn't expose a parameter to install the ovirt guest agent from the cmd
- I'll handle it in the next couple of days and make sure there is an
upstream build available.
2. The docs still relate to the msi installation which includes the
agent... that is not the case anymore. @Steve Goodman 
 FYI

As a temp workaround the ovirt agent manually.

I'll update once the fix is done

On Mon, Nov 30, 2020 at 4:34 PM Sandro Bonazzola 
wrote:

>
>
> Il giorno lun 30 nov 2020 alle ore 15:25  ha
> scritto:
>
>> Hi,
>>
>> i am currently trying to automate an upgrade process from the "old" oVirt
>> 4.3 Guest Tools new one which should using starting with oVirt 4.4
>> To achieve this I have to install the win-virtio tools quietly. This
>> works even if I use the parameters /install /passive /norestart. But then
>> the oVirt Guest Agent is not installed. Is there a parameter or another way
>> to install it during a silent installation?
>>
>
> +Gal Zaidman  can you help here?
>
>
>
>>
>> Thanks in advance.
>>
>>  - Tim
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/43BP5RIM5RZYLHD6RXXDQAQWYAWT2GWA/
>>
>
>
> --
>
> 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.
> *
>
>
>

-- 

Gal Zaidman, RHCSA, RHCE

Software Engineer, EMEA R RHV

Red Hat 

gzaid...@redhat.com
M: +972509980092

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

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

2020-12-09 Thread jb 
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 :).


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) 



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