- Users - oVirt List Archives

Can not connect to gluster storage
by Stefan Wolf 27 Nov '20

27 Nov '20

Hello, I ve a host that can not connet to gluster storage. It has worked since I ve set up the environment, and today it stoped working this are the error messages in the webui The error message for connection kvm380.durchhalten.intern:/data returned by VDSM was: Failed to fetch Gluster Volume List Failed to connect Host kvm380.durchhalten.intern to the Storage Domains data. Failed to connect Host kvm380.durchhalten.intern to the Storage Domains hosted_storage. and here the vdsm.log StorageDomainDoesNotExist: Storage domain does not exist: (u'36663740-576a-4498-b28e-0a402628c6a7',) 2020-11-27 12:59:07,665+0000 INFO (jsonrpc/2) [storage.TaskManager.Task] (Task='8bed48b8-0696-4d3f-966a-119219f3b013') aborting: Task is aborted: "Storage domain does not exist: (u'36663740-576a-4498-b28e-0a402628c6a7',)" - code 358 (task:1181) 2020-11-27 12:59:07,665+0000 ERROR (jsonrpc/2) [storage.Dispatcher] FINISH getStorageDomainInfo error=Storage domain does not exist: (u'36663740-576a-4498-b28e-0a402628c6a7',) (dispatcher:83) 2020-11-27 12:59:07,666+0000 INFO (jsonrpc/2) [jsonrpc.JsonRpcServer] RPC call StorageDomain.getInfo failed (error 358) in 0.38 seconds (__init__:312) 2020-11-27 12:59:07,698+0000 INFO (jsonrpc/7) [vdsm.api] START connectStorageServer(domType=7, spUUID=u'00000000-0000-0000-0000-000000000000', conList=[{u'id': u'e29cf818-5ee5-46e1-85c1-8aeefa33e95d', u'vfs_type': u'glusterfs', u'connection': u'kvm380.durchhalten.intern:/engine', u'user': u'kvm'}], options=None) from=::1,40964, task_id=3a3eeb80-50ef-4710-a4f4-9d35da2ff281 (api:48) 2020-11-27 12:59:07,871+0000 ERROR (jsonrpc/7) [storage.HSM] Could not connect to storageServer (hsm:2420) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 2417, in connectStorageServer conObj.connect() File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py", line 167, in connect self.validate() File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py", line 297, in validate if not self.volinfo: File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py", line 284, in volinfo self._volinfo = self._get_gluster_volinfo() File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py", line 329, in _get_gluster_volinfo self._volfileserver) File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 56, in __call__ return callMethod() File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 54, in <lambda> **kwargs) File "<string>", line 2, in glusterVolumeInfo File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod raise convert_to_error(kind, result) GlusterVolumesListFailedException: Volume list failed: rc=30806 out=() err=['Volume does not exist'] 2020-11-27 12:59:07,871+0000 INFO (jsonrpc/7) [vdsm.api] FINISH connectStorageServer return={'statuslist': [{'status': 4149, 'id': u'e29cf818-5ee5-46e1-85c1-8aeefa33e95d'}]} from=::1,40964, task_id=3a3eeb80-50ef-4710-a4f4-9d35da2ff281 (api:54) 2020-11-27 12:59:07,871+0000 INFO (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC call StoragePool.connectStorageServer succeeded in 0.18 seconds (__init__:312) 2020-11-27 12:59:08,474+0000 INFO (Reactor thread) [ProtocolDetector.AcceptorImpl] Accepted connection from ::1:40966 (protocoldetector:61) 2020-11-27 12:59:08,484+0000 INFO (Reactor thread) [ProtocolDetector.Detector] Detected protocol stomp from ::1:40966 (protocoldetector:125) 2020-11-27 12:59:08,484+0000 INFO (Reactor thread) [Broker.StompAdapter] Processing CONNECT request (stompserver:95) 2020-11-27 12:59:08,485+0000 INFO (JsonRpc (StompReactor)) [Broker.StompAdapter] Subscribe command received (stompserver:124) 2020-11-27 12:59:08,525+0000 INFO (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC call Host.ping2 succeeded in 0.00 seconds (__init__:312) 2020-11-27 12:59:08,529+0000 INFO (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.ping2 succeeded in 0.00 seconds (__init__:312) 2020-11-27 12:59:08,533+0000 INFO (jsonrpc/6) [vdsm.api] START getStorageDomainInfo(sdUUID=u'36663740-576a-4498-b28e-0a402628c6a7', options=None) from=::1,40966, task_id=ee3ac98e-6a93-4cb2-a626-5533c8fb78ad (api:48) 2020-11-27 12:59:08,909+0000 INFO (jsonrpc/6) [vdsm.api] FINISH getStorageDomainInfo error=Storage domain does not exist: (u'36663740-576a-4498-b28e-0a402628c6a7',) from=::1,40966, task_id=ee3ac98e-6a93-4cb2-a626-5533c8fb78ad (api:52) 2020-11-27 12:59:08,910+0000 ERROR (jsonrpc/6) [storage.TaskManager.Task] (Task='ee3ac98e-6a93-4cb2-a626-5533c8fb78ad') Unexpected error (task:875) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in _run return fn(*args, **kargs) File "<string>", line 2, in getStorageDomainInfo File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 2753, in getStorageDomainInfo dom = self.validateSdUUID(sdUUID) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 305, in validateSdUUID sdDom = sdCache.produce(sdUUID=sdUUID) File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 110, in produce domain.getRealDomain() File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 51, in getRealDomain return self._cache._realProduce(self._sdUUID) File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 134, in _realProduce domain = self._findDomain(sdUUID) File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 151, in _findDomain return findMethod(sdUUID) File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 176, in _findUnfetchedDomain raise se.StorageDomainDoesNotExist(sdUUID) StorageDomainDoesNotExist: Storage domain does not exist: (u'36663740-576a-4498-b28e-0a402628c6a7',) can somebody tell me where the problem is and how can it solved

2 1

[ANN] oVirt 4.4.4 Third Release Candidate is now available for testing
by Sandro Bonazzola 27 Nov '20

27 Nov '20

oVirt 4.4.4 Third Release Candidate is now available for testing The oVirt Project is pleased to announce the availability of oVirt 4.4.4 Third Release Candidate for testing, as of November 26th, 2020. This update is the fourth in a series of stabilization updates to the 4.4 series. How to prevent hosts entering emergency mode after upgrade from oVirt 4.4.1 Note: Upgrading from 4.4.2 GA or later should not require re-doing these steps, if already performed while upgrading from 4.4.1 to 4.4.2 GA. These are only required to be done once. Due to Bug 1837864 <https://bugzilla.redhat.com/show_bug.cgi?id=1837864> - Host enter emergency mode after upgrading to latest build If you have your root file system on a multipath device on your hosts you should be aware that after upgrading from 4.4.1 to 4.4.4 you may get your host entering emergency mode. In order to prevent this be sure to upgrade oVirt Engine first, then on your hosts: 1. Remove the current lvm filter while still on 4.4.1, or in emergency mode (if rebooted). 2. Reboot. 3. Upgrade to 4.4.4 (redeploy in case of already being on 4.4.4). 4. Run vdsm-tool config-lvm-filter to confirm there is a new filter in place. 5. Only if not using oVirt Node: - run "dracut --force --add multipath” to rebuild initramfs with the correct filter configuration 6. Reboot. Documentation - If you want to try oVirt as quickly as possible, follow the instructions on the Download <https://ovirt.org/download/> page. - For complete installation, administration, and usage instructions, see the oVirt Documentation <https://ovirt.org/documentation/>. - For upgrading from a previous version, see the oVirt Upgrade Guide <https://ovirt.org/documentation/upgrade_guide/>. - For a general overview of oVirt, see About oVirt <https://ovirt.org/community/about.html>. Important notes before you try it Please note this is a pre-release build. The oVirt Project makes no guarantees as to its suitability or usefulness. This pre-release must not be used in production. Installation instructions For installation instructions and additional information please refer to: https://ovirt.org/documentation/ This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 8.2 or newer * CentOS Linux (or similar) 8.2 or newer This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 8.2 or newer * CentOS Linux (or similar) 8.2 or newer * oVirt Node 4.4 based on CentOS Linux 8.2 (available for x86_64 only) See the release notes [1] for installation instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available for CentOS Linux 8 - oVirt Node NG is already available for CentOS Linux 8 Additional Resources: * Read more about the oVirt 4.4.4 release highlights: http://www.ovirt.org/release/4.4.4/ * Get more oVirt project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4.4.4/ [2] http://resources.ovirt.org/pub/ovirt-4.4-pre/iso/ -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

1 0

"gluster-ansible-roles is not installed on Host" error on Cockpit
by Hesham Ahmed 26 Nov '20

26 Nov '20

On a new 4.3.1 oVirt Node installation, when trying to deploy HCI (also when trying adding a new gluster volume to existing clusters) using Cockpit, an error is displayed "gluster-ansible-roles is not installed on Host. To continue deployment, please install gluster-ansible-roles on Host and try again". There is no package named gluster-ansible-roles in the repositories: [root@localhost ~]# yum install gluster-ansible-roles Loaded plugins: enabled_repos_upload, fastestmirror, imgbased-persist, package_upload, product-id, search-disabled-repos, subscription-manager, vdsmupgrade This system is not registered with an entitlement server. You can use subscription-manager to register. Loading mirror speeds from cached hostfile * ovirt-4.3-epel: mirror.horizon.vn No package gluster-ansible-roles available. Error: Nothing to do Uploading Enabled Repositories Report Cannot upload enabled repos report, is this client registered? This is due to check introduced here: https://gerrit.ovirt.org/#/c/98023/1/dashboard/src/helpers/AnsibleUtil.js Changing the line from: [ "rpm", "-qa", "gluster-ansible-roles" ], { "superuser":"require" } to [ "rpm", "-qa", "gluster-ansible" ], { "superuser":"require" } resolves the issue. The above code snippet is installed at /usr/share/cockpit/ovirt-dashboard/app.js on oVirt node and can be patched by running "sed -i 's/gluster-ansible-roles/gluster-ansible/g' /usr/share/cockpit/ovirt-dashboard/app.js && systemctl restart cockpit"

2 1

VM memory decrease
by Erez Zarum 26 Nov '20

26 Nov '20

I have an 8 node cluster running oVirt 4.4.2, i have noticed lately that some VMs started to have their memory decrease. For example a VM that was configured to have 32GB memory without any notice were had their memory decrease to about 4GB, if i restart the VM the VM comes up with the correct memory but shortly after it decreases again. The VM configuration has: Memory Size: 32768 MB Maximum Memory: 131072 MB Physical Memory Guaranteed: 1024 MB It's worth mentioning that those are Linux VMs which are provisioned through Foreman, Windows VMs are not provisioned from Foreman and their "Memory Size" is identical to "Physical Memory Guaranteed", so far i have not observed a Windows VM with this behaviour, though there might be some that i haven't caught. Is there a possibility the cause for this issue is by having "Physical Memory Guaranteed" set to this low?

2 2

Check multipath status using API
by Paulo Silva 26 Nov '20

26 Nov '20

Hi, Is it possible to check the multipath status using the current REST API on ovirt? There is an old page that hints at this but I'm not sure if this has been implemented: https://www.ovirt.org/develop/release-management/features/storage/multipath… Thanks -- Paulo Silva <paulojjs(a)gmail.com>

2 1

Re: EPYC CPU not being detected correctly on cluster
by Lucia Jelinkova 26 Nov '20

26 Nov '20

Hi Vinícius, I am glad you've managed to solve it and thanks for sharing your findings. Lucia On Wed, Nov 25, 2020 at 9:07 PM Vinícius Ferrão <ferrao(a)versatushpc.com.br> wrote: > Lucia, I ended figuring out. > > > > The culprit is that I was pinned with the wrong virt module; after running > this commands I was able to have the CPU properly detected: > > > > # dnf module reset virt > > # dnf module enable virt:8.3 > > # dnf upgrade –nobest > > > > I think virt was in 8.2. > > > > Thank you! > > > > *From:* Lucia Jelinkova <ljelinko(a)redhat.com> > *Sent:* Monday, November 23, 2020 6:25 AM > *To:* Vinícius Ferrão <ferrao(a)versatushpc.com.br> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] EPYC CPU not being detected correctly on > cluster > > > > Hi Vinícius, > > > > Thank you for the libvirt output - libvirt marked the EPYC CPU as not > usable. Let's query qemu why that is. You do not need an oVirt VM to do > that, just any VM running on qemu, e.g. created by Virtual Machines Manager > or you can follow the command from the answer here: > > > > > https://unix.stackexchange.com/questions/309788/how-to-create-a-vm-from-scr… > > > > Then you can use the following commands: > > sudo virsh list --all > > sudo virsh qemu-monitor-command [your-vm's-name] --pretty > '{"execute":"query-cpu-definitions"}' > > > > I do not know if this could be related to UEFI Firmware, lets check the > qemu output first. > > > > Regards, > > > > Lucia > > > > > > On Fri, Nov 20, 2020 at 4:07 PM Vinícius Ferrão <ferrao(a)versatushpc.com.br> > wrote: > > Hi Lucia, > > > > I had to create an user for virsh: > > # saslpasswd2 -a libvirt test > > Password: > > Again (for verification): > > > > With that in mind, here’s the outputs: > > > > <domainCapabilities> > > <path>/usr/libexec/qemu-kvm</path> > > <domain>kvm</domain> > > <machine>pc-i440fx-rhel7.6.0</machine> > > <arch>x86_64</arch> > > <vcpu max='240'/> > > <iothreads supported='yes'/> > > <os supported='yes'> > > <enum name='firmware'/> > > <loader supported='yes'> > > <value>/usr/share/OVMF/OVMF_CODE.secboot.fd</value> > > <enum name='type'> > > <value>rom</value> > > <value>pflash</value> > > </enum> > > <enum name='readonly'> > > <value>yes</value> > > <value>no</value> > > </enum> > > <enum name='secure'> > > <value>no</value> > > </enum> > > </loader> > > </os> > > <cpu> > > <mode name='host-passthrough' supported='yes'/> > > <mode name='host-model' supported='yes'> > > <model fallback='forbid'>EPYC-IBPB</model> > > <vendor>AMD</vendor> > > <feature policy='require' name='x2apic'/> > > <feature policy='require' name='tsc-deadline'/> > > <feature policy='require' name='hypervisor'/> > > <feature policy='require' name='tsc_adjust'/> > > <feature policy='require' name='clwb'/> > > <feature policy='require' name='umip'/> > > <feature policy='require' name='spec-ctrl'/> > > <feature policy='require' name='stibp'/> > > <feature policy='require' name='arch-capabilities'/> > > <feature policy='require' name='ssbd'/> > > <feature policy='require' name='xsaves'/> > > <feature policy='require' name='cmp_legacy'/> > > <feature policy='require' name='perfctr_core'/> > > <feature policy='require' name='invtsc'/> > > <feature policy='require' name='clzero'/> > > <feature policy='require' name='wbnoinvd'/> > > <feature policy='require' name='amd-ssbd'/> > > <feature policy='require' name='virt-ssbd'/> > > <feature policy='require' name='rdctl-no'/> > > <feature policy='require' name='skip-l1dfl-vmentry'/> > > <feature policy='require' name='mds-no'/> > > <feature policy='require' name='pschange-mc-no'/> > > <feature policy='disable' name='monitor'/> > > <feature policy='disable' name='svm'/> > > </mode> > > <mode name='custom' supported='yes'> > > <model usable='yes'>qemu64</model> > > <model usable='yes'>qemu32</model> > > <model usable='no'>phenom</model> > > <model usable='yes'>pentium3</model> > > <model usable='yes'>pentium2</model> > > <model usable='yes'>pentium</model> > > <model usable='no'>n270</model> > > <model usable='yes'>kvm64</model> > > <model usable='yes'>kvm32</model> > > <model usable='no'>coreduo</model> > > <model usable='no'>core2duo</model> > > <model usable='no'>athlon</model> > > <model usable='yes'>Westmere-IBRS</model> > > <model usable='yes'>Westmere</model> > > <model usable='no'>Skylake-Server-noTSX-IBRS</model> > > <model usable='no'>Skylake-Server-IBRS</model> > > <model usable='no'>Skylake-Server</model> > > <model usable='no'>Skylake-Client-noTSX-IBRS</model> > > <model usable='no'>Skylake-Client-IBRS</model> > > <model usable='no'>Skylake-Client</model> > > <model usable='yes'>SandyBridge-IBRS</model> > > <model usable='yes'>SandyBridge</model> > > <model usable='yes'>Penryn</model> > > <model usable='no'>Opteron_G5</model> > > <model usable='no'>Opteron_G4</model> > > <model usable='yes'>Opteron_G3</model> > > <model usable='yes'>Opteron_G2</model> > > <model usable='yes'>Opteron_G1</model> > > <model usable='yes'>Nehalem-IBRS</model> > > <model usable='yes'>Nehalem</model> > > <model usable='no'>IvyBridge-IBRS</model> > > <model usable='no'>IvyBridge</model> > > <model usable='no'>Icelake-Server-noTSX</model> > > <model usable='no'>Icelake-Server</model> > > <model usable='no'>Icelake-Client-noTSX</model> > > <model usable='no'>Icelake-Client</model> > > <model usable='no'>Haswell-noTSX-IBRS</model> > > <model usable='no'>Haswell-noTSX</model> > > <model usable='no'>Haswell-IBRS</model> > > <model usable='no'>Haswell</model> > > <model usable='no'>EPYC-IBPB</model> > > <model usable='no'>EPYC</model> > > <model usable='no'>Dhyana</model> > > <model usable='no'>Cooperlake</model> > > <model usable='yes'>Conroe</model> > > <model usable='no'>Cascadelake-Server-noTSX</model> > > <model usable='no'>Cascadelake-Server</model> > > <model usable='no'>Broadwell-noTSX-IBRS</model> > > <model usable='no'>Broadwell-noTSX</model> > > <model usable='no'>Broadwell-IBRS</model> > > <model usable='no'>Broadwell</model> > > <model usable='yes'>486</model> > > </mode> > > </cpu> > > <devices> > > <disk supported='yes'> > > <enum name='diskDevice'> > > <value>disk</value> > > <value>cdrom</value> > > <value>floppy</value> > > <value>lun</value> > > </enum> > > <enum name='bus'> > > <value>ide</value> > > <value>fdc</value> > > <value>scsi</value> > > <value>virtio</value> > > <value>usb</value> > > <value>sata</value> > > </enum> > > <enum name='model'> > > <value>virtio</value> > > <value>virtio-transitional</value> > > <value>virtio-non-transitional</value> > > </enum> > > </disk> > > <graphics supported='yes'> > > <enum name='type'> > > <value>sdl</value> > > <value>vnc</value> > > <value>spice</value> > > </enum> > > </graphics> > > <video supported='yes'> > > <enum name='modelType'> > > <value>vga</value> > > <value>cirrus</value> > > <value>qxl</value> > > <value>virtio</value> > > <value>none</value> > > <value>bochs</value> > > <value>ramfb</value> > > </enum> > > </video> > > <hostdev supported='yes'> > > <enum name='mode'> > > <value>subsystem</value> > > </enum> > > <enum name='startupPolicy'> > > <value>default</value> > > <value>mandatory</value> > > <value>requisite</value> > > <value>optional</value> > > </enum> > > <enum name='subsysType'> > > <value>usb</value> > > <value>pci</value> > > <value>scsi</value> > > </enum> > > <enum name='capsType'/> > > <enum name='pciBackend'> > > <value>default</value> > > <value>vfio</value> > > </enum> > > </hostdev> > > <rng supported='yes'> > > <enum name='model'> > > <value>virtio</value> > > <value>virtio-transitional</value> > > <value>virtio-non-transitional</value> > > </enum> > > <enum name='backendModel'> > > <value>random</value> > > <value>egd</value> > > </enum> > > </rng> > > </devices> > > <features> > > <gic supported='no'/> > > <vmcoreinfo supported='yes'/> > > <genid supported='yes'/> > > <backingStoreInput supported='yes'/> > > <backup supported='no'/> > > <sev supported='yes'> > > <cbitpos>47</cbitpos> > > <reducedPhysBits>1</reducedPhysBits> > > </sev> > > </features> > > </domainCapabilities> > > > > Regarding the last two commands, I don’t have any VM running, since I > cannot start anything on the engine. > > > > I’m starting to suspect that this may be something in the UEFI Firmware. > > > > Any thoughts? > > > > Thanks, > > > > *From:* Lucia Jelinkova <ljelinko(a)redhat.com> > *Sent:* Friday, November 20, 2020 5:30 AM > *To:* Vinícius Ferrão <ferrao(a)versatushpc.com.br> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] EPYC CPU not being detected correctly on > cluster > > > > Hi, > > > > oVirt CPU detection depends on libvirt (and that depends on qemu) CPU > models. Could you please run the following command to see what libvirt > reports? > > > > virsh domcapabilities > > > > That should give you the list of CPUs known to libvirt with a usability > flag for each CPU. > > > > If you find out that the CPU is not usable by libvirt, you might want to > dig deeper by querying quemu directly. > > > > Locate any VM running on the system by > > sudo virsh list --all > > > > Use the name of a VM in the following command: > > sudo virsh qemu-monitor-command [your-vm's-name] --pretty > '{"execute":"query-cpu-definitions"}' > > > > That would give you the list of all CPUs supported by qemu and it will > list all cpu's features that are not available on your system. > > > > Regards, > > > > Lucia > > > > On Thu, Nov 19, 2020 at 9:38 PM Vinícius Ferrão via Users <users(a)ovirt.org> > wrote: > > Hi > > > > I’ve an strange issue with two hosts (not using the hypervisor image) with > EPYC CPUs, on the engine I got this 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_EPYC. Please > update the host CPU microcode or change the Cluster CPU Type. > > > > But it is an EPYC CPU, the firmware is updated to the latest versions, but > for some reason oVirt does not like it. > > > > Here’s the relevant output from VDSM: > > "cpuCores": "128", > > "cpuFlags": > "ibs,vme,abm,sep,ssse3,perfctr_core,sse4_2,skip-l1dfl-vmentry,cx16,pae,misalignsse,avx2,smap,movbe,vgif,rdctl-no,extapic,clflushopt,de,sse4_1,xsaveerptr,perfctr_llc,fma,mca,sse,rdtscp,monitor,umip,mwaitx,cr8_legacy,mtrr,stibp,bmi2,pclmulqdq,amd-ssbd,lbrv,pdpe1gb,constant_tsc,vmmcall,f16c,ibrs,fsgsbase,invtsc,nopl,lm,3dnowprefetch,smca,ht,tsc_adjust,popcnt,cpb,bmi1,mmx,arat,aperfmperf,bpext,cqm_occup_llc,virt-ssbd,tce,pse,xsave,xgetbv1,topoext,sha_ni,amd_ppin,rdrand,cpuid,tsc_scale,extd_apicid,cqm,rep_good,tsc,sse4a,flushbyasid,pschange-mc-no,mds-no,ibpb,smep,clflush,tsc-deadline,fxsr,pat,avx,pfthreshold,v_vmsave_vmload,osvw,xsavec,cdp_l3,clzero,svm_lock,nonstop_tsc,adx,hw_pstate,spec-ctrl,arch-capabilities,xsaveopt,skinit,rdt_a,svm,rdpid,lahf_lm,fpu,rdseed,fxsr_opt,sse2,nrip_save,vmcb_clean,sme,cat_l3,cqm_mbm_local,irperf,overflow_recov,avic,mce,mmxext,msr,cx8,hypervisor,wdt,mba,nx,decodeassists,cmp_legacy,x2apic,perfctr_nb,succor,pni,xsaves,clwb,cqm_llc,syscall,apic,pge,npt,pse36,cmov,ssbd,pausefilter,sev,aes,wbnoinvd,cqm_mbm_total,spec_ctrl,model_qemu32,model_Opteron_G3,model_Nehalem-IBRS,model_qemu64,model_Conroe,model_kvm64,model_Penryn,model_SandyBridge,model_pentium,model_pentium2,model_kvm32,model_Nehalem,model_Opteron_G2,model_pentium3,model_Opteron_G1,model_SandyBridge-IBRS,model_486,model_Westmere-IBRS,model_Westmere", > > "cpuModel": "AMD EPYC 7H12 64-Core Processor", > > "cpuSockets": "2", > > "cpuSpeed": "3293.405", > > "cpuThreads": "256", > > > > Any ideia on why ou what to do to fix it? > > > > Thanks, > > > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/WP6XL6ODTLJVB… > >

1 0

Connecting OVN network to physical network
by Alex K 26 Nov '20

26 Nov '20

Hi all, I have created some logical switches at the OVN network provider (the default provider that is configured during engine-setup). This is working fine. I would like though to be able to connect a logical OVN switch to a physical network at which the hosts have access, so as to give access to guest VMs to this network. When connecting such switch to a physical network the guest VMs do not have access to the physical network: [image: image.png] It seems that this should be supported from ovirt. Am I missing something? P.S. I know I can provide such connectivity through standard networking, though was wondering if this can be done with OVN. Many thanx, Alex

2 2

Re: EPYC CPU not being detected correctly on cluster
by Lucia Jelinkova 25 Nov '20

25 Nov '20

Hi Vinícius, Thank you for the libvirt output - libvirt marked the EPYC CPU as not usable. Let's query qemu why that is. You do not need an oVirt VM to do that, just any VM running on qemu, e.g. created by Virtual Machines Manager or you can follow the command from the answer here: https://unix.stackexchange.com/questions/309788/how-to-create-a-vm-from-scr… Then you can use the following commands: sudo virsh list --all sudo virsh qemu-monitor-command [your-vm's-name] --pretty '{"execute":"query-cpu-definitions"}' I do not know if this could be related to UEFI Firmware, lets check the qemu output first. Regards, Lucia On Fri, Nov 20, 2020 at 4:07 PM Vinícius Ferrão <ferrao(a)versatushpc.com.br> wrote: > Hi Lucia, > > > > I had to create an user for virsh: > > # saslpasswd2 -a libvirt test > > Password: > > Again (for verification): > > > > With that in mind, here’s the outputs: > > > > <domainCapabilities> > > <path>/usr/libexec/qemu-kvm</path> > > <domain>kvm</domain> > > <machine>pc-i440fx-rhel7.6.0</machine> > > <arch>x86_64</arch> > > <vcpu max='240'/> > > <iothreads supported='yes'/> > > <os supported='yes'> > > <enum name='firmware'/> > > <loader supported='yes'> > > <value>/usr/share/OVMF/OVMF_CODE.secboot.fd</value> > > <enum name='type'> > > <value>rom</value> > > <value>pflash</value> > > </enum> > > <enum name='readonly'> > > <value>yes</value> > > <value>no</value> > > </enum> > > <enum name='secure'> > > <value>no</value> > > </enum> > > </loader> > > </os> > > <cpu> > > <mode name='host-passthrough' supported='yes'/> > > <mode name='host-model' supported='yes'> > > <model fallback='forbid'>EPYC-IBPB</model> > > <vendor>AMD</vendor> > > <feature policy='require' name='x2apic'/> > > <feature policy='require' name='tsc-deadline'/> > > <feature policy='require' name='hypervisor'/> > > <feature policy='require' name='tsc_adjust'/> > > <feature policy='require' name='clwb'/> > > <feature policy='require' name='umip'/> > > <feature policy='require' name='spec-ctrl'/> > > <feature policy='require' name='stibp'/> > > <feature policy='require' name='arch-capabilities'/> > > <feature policy='require' name='ssbd'/> > > <feature policy='require' name='xsaves'/> > > <feature policy='require' name='cmp_legacy'/> > > <feature policy='require' name='perfctr_core'/> > > <feature policy='require' name='invtsc'/> > > <feature policy='require' name='clzero'/> > > <feature policy='require' name='wbnoinvd'/> > > <feature policy='require' name='amd-ssbd'/> > > <feature policy='require' name='virt-ssbd'/> > > <feature policy='require' name='rdctl-no'/> > > <feature policy='require' name='skip-l1dfl-vmentry'/> > > <feature policy='require' name='mds-no'/> > > <feature policy='require' name='pschange-mc-no'/> > > <feature policy='disable' name='monitor'/> > > <feature policy='disable' name='svm'/> > > </mode> > > <mode name='custom' supported='yes'> > > <model usable='yes'>qemu64</model> > > <model usable='yes'>qemu32</model> > > <model usable='no'>phenom</model> > > <model usable='yes'>pentium3</model> > > <model usable='yes'>pentium2</model> > > <model usable='yes'>pentium</model> > > <model usable='no'>n270</model> > > <model usable='yes'>kvm64</model> > > <model usable='yes'>kvm32</model> > > <model usable='no'>coreduo</model> > > <model usable='no'>core2duo</model> > > <model usable='no'>athlon</model> > > <model usable='yes'>Westmere-IBRS</model> > > <model usable='yes'>Westmere</model> > > <model usable='no'>Skylake-Server-noTSX-IBRS</model> > > <model usable='no'>Skylake-Server-IBRS</model> > > <model usable='no'>Skylake-Server</model> > > <model usable='no'>Skylake-Client-noTSX-IBRS</model> > > <model usable='no'>Skylake-Client-IBRS</model> > > <model usable='no'>Skylake-Client</model> > > <model usable='yes'>SandyBridge-IBRS</model> > > <model usable='yes'>SandyBridge</model> > > <model usable='yes'>Penryn</model> > > <model usable='no'>Opteron_G5</model> > > <model usable='no'>Opteron_G4</model> > > <model usable='yes'>Opteron_G3</model> > > <model usable='yes'>Opteron_G2</model> > > <model usable='yes'>Opteron_G1</model> > > <model usable='yes'>Nehalem-IBRS</model> > > <model usable='yes'>Nehalem</model> > > <model usable='no'>IvyBridge-IBRS</model> > > <model usable='no'>IvyBridge</model> > > <model usable='no'>Icelake-Server-noTSX</model> > > <model usable='no'>Icelake-Server</model> > > <model usable='no'>Icelake-Client-noTSX</model> > > <model usable='no'>Icelake-Client</model> > > <model usable='no'>Haswell-noTSX-IBRS</model> > > <model usable='no'>Haswell-noTSX</model> > > <model usable='no'>Haswell-IBRS</model> > > <model usable='no'>Haswell</model> > > <model usable='no'>EPYC-IBPB</model> > > <model usable='no'>EPYC</model> > > <model usable='no'>Dhyana</model> > > <model usable='no'>Cooperlake</model> > > <model usable='yes'>Conroe</model> > > <model usable='no'>Cascadelake-Server-noTSX</model> > > <model usable='no'>Cascadelake-Server</model> > > <model usable='no'>Broadwell-noTSX-IBRS</model> > > <model usable='no'>Broadwell-noTSX</model> > > <model usable='no'>Broadwell-IBRS</model> > > <model usable='no'>Broadwell</model> > > <model usable='yes'>486</model> > > </mode> > > </cpu> > > <devices> > > <disk supported='yes'> > > <enum name='diskDevice'> > > <value>disk</value> > > <value>cdrom</value> > > <value>floppy</value> > > <value>lun</value> > > </enum> > > <enum name='bus'> > > <value>ide</value> > > <value>fdc</value> > > <value>scsi</value> > > <value>virtio</value> > > <value>usb</value> > > <value>sata</value> > > </enum> > > <enum name='model'> > > <value>virtio</value> > > <value>virtio-transitional</value> > > <value>virtio-non-transitional</value> > > </enum> > > </disk> > > <graphics supported='yes'> > > <enum name='type'> > > <value>sdl</value> > > <value>vnc</value> > > <value>spice</value> > > </enum> > > </graphics> > > <video supported='yes'> > > <enum name='modelType'> > > <value>vga</value> > > <value>cirrus</value> > > <value>qxl</value> > > <value>virtio</value> > > <value>none</value> > > <value>bochs</value> > > <value>ramfb</value> > > </enum> > > </video> > > <hostdev supported='yes'> > > <enum name='mode'> > > <value>subsystem</value> > > </enum> > > <enum name='startupPolicy'> > > <value>default</value> > > <value>mandatory</value> > > <value>requisite</value> > > <value>optional</value> > > </enum> > > <enum name='subsysType'> > > <value>usb</value> > > <value>pci</value> > > <value>scsi</value> > > </enum> > > <enum name='capsType'/> > > <enum name='pciBackend'> > > <value>default</value> > > <value>vfio</value> > > </enum> > > </hostdev> > > <rng supported='yes'> > > <enum name='model'> > > <value>virtio</value> > > <value>virtio-transitional</value> > > <value>virtio-non-transitional</value> > > </enum> > > <enum name='backendModel'> > > <value>random</value> > > <value>egd</value> > > </enum> > > </rng> > > </devices> > > <features> > > <gic supported='no'/> > > <vmcoreinfo supported='yes'/> > > <genid supported='yes'/> > > <backingStoreInput supported='yes'/> > > <backup supported='no'/> > > <sev supported='yes'> > > <cbitpos>47</cbitpos> > > <reducedPhysBits>1</reducedPhysBits> > > </sev> > > </features> > > </domainCapabilities> > > > > Regarding the last two commands, I don’t have any VM running, since I > cannot start anything on the engine. > > > > I’m starting to suspect that this may be something in the UEFI Firmware. > > > > Any thoughts? > > > > Thanks, > > > > *From:* Lucia Jelinkova <ljelinko(a)redhat.com> > *Sent:* Friday, November 20, 2020 5:30 AM > *To:* Vinícius Ferrão <ferrao(a)versatushpc.com.br> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] EPYC CPU not being detected correctly on > cluster > > > > Hi, > > > > oVirt CPU detection depends on libvirt (and that depends on qemu) CPU > models. Could you please run the following command to see what libvirt > reports? > > > > virsh domcapabilities > > > > That should give you the list of CPUs known to libvirt with a usability > flag for each CPU. > > > > If you find out that the CPU is not usable by libvirt, you might want to > dig deeper by querying quemu directly. > > > > Locate any VM running on the system by > > sudo virsh list --all > > > > Use the name of a VM in the following command: > > sudo virsh qemu-monitor-command [your-vm's-name] --pretty > '{"execute":"query-cpu-definitions"}' > > > > That would give you the list of all CPUs supported by qemu and it will > list all cpu's features that are not available on your system. > > > > Regards, > > > > Lucia > > > > On Thu, Nov 19, 2020 at 9:38 PM Vinícius Ferrão via Users <users(a)ovirt.org> > wrote: > > Hi > > > > I’ve an strange issue with two hosts (not using the hypervisor image) with > EPYC CPUs, on the engine I got this 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_EPYC. Please > update the host CPU microcode or change the Cluster CPU Type. > > > > But it is an EPYC CPU, the firmware is updated to the latest versions, but > for some reason oVirt does not like it. > > > > Here’s the relevant output from VDSM: > > "cpuCores": "128", > > "cpuFlags": > "ibs,vme,abm,sep,ssse3,perfctr_core,sse4_2,skip-l1dfl-vmentry,cx16,pae,misalignsse,avx2,smap,movbe,vgif,rdctl-no,extapic,clflushopt,de,sse4_1,xsaveerptr,perfctr_llc,fma,mca,sse,rdtscp,monitor,umip,mwaitx,cr8_legacy,mtrr,stibp,bmi2,pclmulqdq,amd-ssbd,lbrv,pdpe1gb,constant_tsc,vmmcall,f16c,ibrs,fsgsbase,invtsc,nopl,lm,3dnowprefetch,smca,ht,tsc_adjust,popcnt,cpb,bmi1,mmx,arat,aperfmperf,bpext,cqm_occup_llc,virt-ssbd,tce,pse,xsave,xgetbv1,topoext,sha_ni,amd_ppin,rdrand,cpuid,tsc_scale,extd_apicid,cqm,rep_good,tsc,sse4a,flushbyasid,pschange-mc-no,mds-no,ibpb,smep,clflush,tsc-deadline,fxsr,pat,avx,pfthreshold,v_vmsave_vmload,osvw,xsavec,cdp_l3,clzero,svm_lock,nonstop_tsc,adx,hw_pstate,spec-ctrl,arch-capabilities,xsaveopt,skinit,rdt_a,svm,rdpid,lahf_lm,fpu,rdseed,fxsr_opt,sse2,nrip_save,vmcb_clean,sme,cat_l3,cqm_mbm_local,irperf,overflow_recov,avic,mce,mmxext,msr,cx8,hypervisor,wdt,mba,nx,decodeassists,cmp_legacy,x2apic,perfctr_nb,succor,pni,xsaves,clwb,cqm_llc,syscall,apic,pge,npt,pse36,cmov,ssbd,pausefilter,sev,aes,wbnoinvd,cqm_mbm_total,spec_ctrl,model_qemu32,model_Opteron_G3,model_Nehalem-IBRS,model_qemu64,model_Conroe,model_kvm64,model_Penryn,model_SandyBridge,model_pentium,model_pentium2,model_kvm32,model_Nehalem,model_Opteron_G2,model_pentium3,model_Opteron_G1,model_SandyBridge-IBRS,model_486,model_Westmere-IBRS,model_Westmere", > > "cpuModel": "AMD EPYC 7H12 64-Core Processor", > > "cpuSockets": "2", > > "cpuSpeed": "3293.405", > > "cpuThreads": "256", > > > > Any ideia on why ou what to do to fix it? > > > > Thanks, > > > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/WP6XL6ODTLJVB… > >

2 1

OVS - interface in a weir (broken) state after each system reboot.
by lejeczek 25 Nov '20

25 Nov '20

2 2

Re: Ovirt 4 2 NIC's
by Dominik Holler 24 Nov '20

24 Nov '20

https://www.ovirt.org/documentation/administration_guide/#Designate_a_Speci… documents how to use a display network. A possible flow could be like this: 1. Create a new logical network, use a VLAN if you do not have a free NIC on every host 2. Attach the new logical network and attach it in Compute > Hosts > hostname > Network Interfaces > Setup Host Networks to a free NIC (or an already used one if the network has a VLAN) for every host. This new network attachment should have an IP address. 3. Ensure that your network infrastructure allows the communication of your users into the display network. 4. Assign the role "Display Network" in Compute > Clusters > ClusterName > Logical Networks > Manage Networks to the new network. > El vie, 20 de nov. de 2020 a la(s) 06:01, Dominik Holler ( > dholler(a)redhat.com) escribió: > >> >> >> On Wed, Nov 18, 2020 at 7:30 PM Facundo Badaracco <varekoarfa(a)gmail.com> >> wrote: >> >>> Hi everyone! >>> >>> Hope someone can help me with this.. >>> >>> I have 3 servers with centos 8 and ovirt 4 installed. Each server has 2 >>> nic. >>> Server A = HE (HA) >>> Nic1= 192.169.2.24 Nic2=no ip >>> Server B = HE (HA) >>> Nic1= 192.169.2.25 Nic2=no ip >>> Server C = simply host. >>> Nic1= 192.169.2.26 Nic2=no ip >>> >>> How can i configure the second NIC in each server in order to use it for >>> clients connect to the vms?. I want one nic for management, the other for >>> connections. >>> >> >> >> If the clients want to access network services provided by the VMs, >> you could create an additional logical network in oVirt, and attach it in >> Compute > Hosts > hostname > Network Interfaces > Setup Host Networks >> to Nic2 for every host. This new network attachment should have no IP >> address. >> After that, you could reference this new logical network in your VMs >> virtual NICs. >> If possible, I would recommend using a VLAN to provide isolation to the >> management network. >> >> If the clients connect via SPICE or VNC, you would require a >> dedicated display network. >> >> >> >>> _______________________________________________ >>> Users mailing list -- users(a)ovirt.org >>> To unsubscribe send an email to users-leave(a)ovirt.org >>> Privacy Statement: https://www.ovirt.org/privacy-policy.html >>> oVirt Code of Conduct: >>> https://www.ovirt.org/community/about/community-guidelines/ >>> List Archives: >>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/PL7WFXC4UZBUZ… >>> >>

1 0