- Users - oVirt List Archives

Has meltdown impacted glusterFS performance?
by Jayme 27 Jan '18

27 Jan '18

I've been considering hyperconverged oVirt setup VS san/nas but I wonder how the meltdown patches have affected glusterFS performance since it is CPU intensive. Has anyone who has applied recent kernel updates noticed a performance drop with glusterFS?

4 3

oVirt 4.1.9 and Spectre-Meltdown checks
by Gianluca Cecchi 26 Jan '18

26 Jan '18

Hello, nice to see integration of Spectre-Meltdown info in 4.1.9, both for guests and hosts, as detailed in release notes: I have upgraded my CentOS 7.4 engine VM (outside of oVirt cluster) and one oVirt host to 4.1.9. Now in General -> Software subtab of the host I see: OS Version: RHEL - 7 - 4.1708.el7.centos OS Description: CentOS Linux 7 (Core) Kernel Version: 3.10.0 - 693.17.1.el7.x86_64 Kernel Features: IBRS: 0, PTI: 1, IBPB: 0 Am I supposed to manually set any particular value? If I run version 0.32 (updated yesterday) of spectre-meltdown-checker.sh I got this on my Dell M610 blade with Version: 6.4.0 Release Date: 07/18/2013 [root@ov200 ~]# /home/g.cecchi/spectre-meltdown-checker.sh Spectre and Meltdown mitigation detection tool v0.32 Checking for vulnerabilities on current system Kernel is Linux 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 CPU is Intel(R) Xeon(R) CPU X5690 @ 3.47GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: NO * CPU indicates IBRS capability: NO * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: NO * CPU indicates IBPB capability: NO * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: NO * CPU indicates STIBP capability: NO * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO * CPU vulnerability to the three speculative execution attacks variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Checking count of LFENCE opcodes in kernel: YES > STATUS: NOT VULNERABLE (107 opcodes found, which is >= 70, heuristic to be improved when official patches become available) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: YES * Currently enabled features * IBRS enabled for Kernel space: NO (echo 1 > /sys/kernel/debug/x86/ibrs_enabled) * IBRS enabled for User space: NO (echo 2 > /sys/kernel/debug/x86/ibrs_enabled) * IBPB enabled: NO (echo 1 > /sys/kernel/debug/x86/ibpb_enabled) * Mitigation 2 * Kernel compiled with retpoline option: NO * Kernel compiled with a retpoline-aware compiler: NO * Retpoline enabled: NO > STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (PTI mitigates the vulnerability) A false sense of security is worse than no security at all, see --disclaimer [root@ov200 ~]# So it seems I'm still vulnerable only to Variant 2, but kernel seems ok: * Kernel is compiled with IBRS/IBPB support: YES while bios not, correct? Is RH EL / CentOS expected to follow the retpoline option too, to mitigate Variant 2, as done by Fedora for example? Eg on my just updated Fedora 27 laptop I get now: [g.cecchi@ope46 spectre_meltdown]$ sudo ./spectre-meltdown-checker.sh [sudo] password for g.cecchi: Spectre and Meltdown mitigation detection tool v0.32 Checking for vulnerabilities on current system Kernel is Linux 4.14.14-300.fc27.x86_64 #1 SMP Fri Jan 19 13:19:54 UTC 2018 x86_64 CPU is Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: NO * CPU indicates IBRS capability: NO * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: NO * CPU indicates IBPB capability: NO * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: NO * CPU indicates STIBP capability: NO * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO * CPU vulnerability to the three speculative execution attacks variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable) > STATUS: VULNERABLE (Vulnerable) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active) * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: NO * Currently enabled features * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * IBPB enabled: NO * Mitigation 2 * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) * Retpoline enabled: YES > STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active) * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (Mitigation: PTI) A false sense of security is worse than no security at all, see --disclaimer [g.cecchi@ope46 spectre_meltdown]$ BTW: I updated some days ago this laptop from F26 to F27 and I remember Variant 1 was fixed in F26, while now I see it as vulnerable..... I'm going to check with Fedora mailing list about this... Another question: what should I see for a VM instead related to meltdown/spectre? Currently in "Guest CPU Type" in General subtab of the VM I only see "Westmere".. Should I also see anythin aout IBRS, etc...? Thanks, Gianluca

3 3

Ovirt 4.2 - Help adding VM to numa node via python SDK
by Don Dupuis 26 Jan '18

26 Jan '18

I am able to create a vm using the sdk with nic and disks using the python sdk, but having trouble understanding how to assign it to virtual numanode onto the physical numanode via python sdk. Any help in this area would be greatly appreciated Thanks Don

2 2

Windows 2012R2 virtio-scsi abysmal disk write performance
by Jean-Francois Courteau 26 Jan '18

26 Jan '18

Hello there, I just installed oVirt on brend new machines. The engine on a Virtualbox VM in my current infrastructure, and a single dedicated CentOS host attached to the engine. Here are my host specs (srvhc02): CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (4C 8T) Mem: 32GB DDR3 Disks: - 2 x WD Black 2TB (RAID1) where the CentOS is installed - 4 x WD Gold 4TB (RAID10) dedicated for a storage domain (/dev/md0, ext4, mounted in /storage and exported with NFS with default settings) NIC: Intel 4 ports Gigabit. One port for VMs, one port for everything else. 2 unused ports. OS: Freshly installed CentOS 7 minimal latest (yum updated) oVirt deployed from the Engine using root account with a password Here are my Engine specs (srvvmmgmt): Virtualbox guest VM in another physical computer just for test purposes. CPU: 2vCPU Mem: 8GB Disk: 50GB VDI on a RAID10 array NIC: Virtual Intel Pro 1000 (Bridged over a physical Intel 4 ports Gigabit) OS: Freshly installed CentOS 7 minimal latest (yum updated) oVirt Engine 4.2 deployed from the repo, yum updated yesterday Storage domain: NFS - srvhc02:/storage ISO domain: NFS - srvhc02:/iso Physical network is Gigabit on Cisco switches, no VLAN tagging. My (barely usable) Windows 2012R2 guest (srvweb03) CPU: 2vCPU Mem: 8GB Disk1: 100GB on the storage domain Disk 2: 200GB on the storage domain (this is the one I was changing the controller for testing purposes) NIC: virtio bridged over the VM port I have tried every possible combination of drive controller (virtio-scsi, virtio, IDE), virtio drivers (stable and latest from the Fedora website, others found in sometimes obsucre places), and the disk write performances are simply unacceptable. Of course I had a reboot between each NIC driver update and driver change. I have compared with a Virtualbox installed on the same host after I cleaned up oVirt, and the host is absolutely not problematic. Here is the compare: oVirt Virtualbox ----------------------------------------------- SEQUENTIAL READ 3000MB/s 406MB/s (this is ridiculously high, oVirt probably reading from RAM) SEQUENTIAL WRITE 31MB/s 164MB/s 4k RANDOM READ 400MB/s 7.18MB/s (this is ridiculously high, oVirt probably reading from RAM) 4k RANDOM WRITE 0.3MB/s(80IOPS) 3MB/s (747IOPS) These performances are using the virtio-scsi in oVirt (any version, none gave me better performance), and the SATA driver in Virtualbox. Needless to say that this is frustrating. I have tried with oVirt virtio-blk (virtio in the interface) driver, it gave me a 10-15% improvement, but never up to the level I could expect from an enterprise grade solution. I also tried IDE. I could not even write at 10kbps on it. I had approx 10IOPM (yes, IO per minute!) with it. Is there something I am missing? -- https://nexcess.ca JEAN-FRANÇOIS COURTEAU _Président, Directeur Général_ C: jean-francois.courteau(a)nexcess.ca T: +1 (418) 558-5169 -------------------------

1 1

Storage Hardware for Hyperconverged oVirt: Gluster best practice
by ovirt＠fateknollogee.com 26 Jan '18

26 Jan '18

oVirt + Gluster (hyperconverged) RAID question: I have 3 nodes of SuperMicro hardware, each node has 1x SATADOM (boot drive for o/s install) and 6x 1TB SSD (to be used for Gluster). For the SSDs, is hardware or software RAID preferred or do I use an HBA? The RedHat docs seem to suggest hardware RAID, others on the forum say HBA or software RAID. What are other folks using?

4 6

live migrating vm from 4.1.7 to 4.1.9 failed because of vmx flag
by Gianluca Cecchi 26 Jan '18

26 Jan '18

Hello, I'm trying to update an environment from 4.1.7 to 4.1.9. Already migrated the engine (separate) and one host. This host is now running a pair of VMs, that was powered off and then powered on it via "run once" feature. Now I'm trying to evacuate VMs from other hosts and get all to 4.1.9. But I have tried with couple of VMs and I'm always getting error events of type: Jan 26, 2018 12:40:00 PM Migration failed (VM: dbatest3, Source: ov301, Destination: ov200). In engine.log 2018-01-26 12:39:48,267+01 INFO [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (default task-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] Lock Acquired to object 'EngineLock:{exclusiveLocks='[4f6ecae2-7d71-47c9-af23-2b3e49bc08fc=VM]', sharedLocks=''}' 2018-01-26 12:39:48,350+01 INFO [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] Running command: MigrateVmToServerCommand internal: false. Entities affected : ID: 4f6ecae2-7d71-47c9-af23-2b3e49bc08fc Type: VMAction group MIGRATE_VM with role type USER 2018-01-26 12:39:48,424+01 INFO [org.ovirt.engine.core.vdsbroker.MigrateVDSCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] START, MigrateVDSCommand( MigrateVDSCommandParameters:{runAsync='true', hostId='8ef1ce6f-4e38-486c-b3a4-58235f1f1d06', vmId='4f6ecae2-7d71-47c9-af23-2b3e49bc08fc', srcHost='ov301.mydomain', dstVdsId='d16e723c-b44c-4c1c-be76-c67911e47ccd', dstHost='ov200.mydomain:54321', migrationMethod='ONLINE', tunnelMigration='false', migrationDowntime='0', autoConverge='true', migrateCompressed='false', consoleAddress='null', maxBandwidth='500', enableGuestEvents='true', maxIncomingMigrations='2', maxOutgoingMigrations='2', convergenceSchedule='[init=[{name=setDowntime, params=[100]}], stalling=[{limit=1, action={name=setDowntime, params=[150]}}, {limit=2, action={name=setDowntime, params=[200]}}, {limit=3, action={name=setDowntime, params=[300]}}, {limit=4, action={name=setDowntime, params=[400]}}, {limit=6, action={name=setDowntime, params=[500]}}, {limit=-1, action={name=abort, params=[]}}]]'}), log id: 7013a234 2018-01-26 12:39:48,425+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateBrokerVDSCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] START, MigrateBrokerVDSCommand(HostName = ov301, MigrateVDSCommandParameters:{runAsync='true', hostId='8ef1ce6f-4e38-486c-b3a4-58235f1f1d06', vmId='4f6ecae2-7d71-47c9-af23-2b3e49bc08fc', srcHost='ov301.mydomain', dstVdsId='d16e723c-b44c-4c1c-be76-c67911e47ccd', dstHost='ov200.mydomain:54321', migrationMethod='ONLINE', tunnelMigration='false', migrationDowntime='0', autoConverge='true', migrateCompressed='false', consoleAddress='null', maxBandwidth='500', enableGuestEvents='true', maxIncomingMigrations='2', maxOutgoingMigrations='2', convergenceSchedule='[init=[{name=setDowntime, params=[100]}], stalling=[{limit=1, action={name=setDowntime, params=[150]}}, {limit=2, action={name=setDowntime, params=[200]}}, {limit=3, action={name=setDowntime, params=[300]}}, {limit=4, action={name=setDowntime, params=[400]}}, {limit=6, action={name=setDowntime, params=[500]}}, {limit=-1, action={name=abort, params=[]}}]]'}), log id: 25d9c017 2018-01-26 12:39:49,620+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateBrokerVDSCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] FINISH, MigrateBrokerVDSCommand, log id: 25d9c017 2018-01-26 12:39:49,622+01 INFO [org.ovirt.engine.core.vdsbroker.MigrateVDSCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] FINISH, MigrateVDSCommand, return: MigratingFrom, log id: 7013a234 2018-01-26 12:39:49,627+01 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] EVENT_ID: VM_MIGRATION_START(62), Correlation ID: 72ccfbb1-735a-4411-a990-cdb2c081e391, Job ID: b2f39d2c-87f1-480c-b4c7-b8ab09d09318, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Migration started (VM: dbatest3, Source: ov301, Destination: ov200, User: admin@internal-authz). 2018-01-26 12:39:50,782+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmsStatisticsFetcher] (DefaultQuartzScheduler1) [f2fc61e] Fetched 3 VMs from VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd' 2018-01-26 12:39:50,783+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (DefaultQuartzScheduler1) [f2fc61e] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'(dbatest3) was unexpectedly detected as 'MigratingTo' on VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd'(ov200) (expected on '8ef1ce6f-4e38-486c-b3a4-58235f1f1d06') 2018-01-26 12:39:50,784+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (DefaultQuartzScheduler1) [f2fc61e] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc' is migrating to VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd'(ov200) ignoring it in the refresh until migration is done 2018-01-26 12:39:51,968+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-15) [] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc' was reported as Down on VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd'(ov200) 2018-01-26 12:39:51,969+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-15) [] START, DestroyVDSCommand(HostName = ov200, DestroyVmVDSCommandParameters:{runAsync='true', hostId='d16e723c-b44c-4c1c-be76-c67911e47ccd', vmId='4f6ecae2-7d71-47c9-af23-2b3e49bc08fc', force='false', secondsToWait='0', gracefully='false', reason='', ignoreNoVm='true'}), log id: 3b49afe3 2018-01-26 12:39:52,236+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-15) [] Failed to destroy VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc' because VM does not exist, ignoring 2018-01-26 12:39:52,237+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-15) [] FINISH, DestroyVDSCommand, log id: 3b49afe3 2018-01-26 12:39:52,237+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-15) [] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'(dbatest3) was unexpectedly detected as 'Down' on VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd'(ov200) (expected on '8ef1ce6f-4e38-486c-b3a4-58235f1f1d06') 2018-01-26 12:40:00,237+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (DefaultQuartzScheduler3) [5c4b079b] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'(dbatest3) moved from 'MigratingFrom' --> 'Up' 2018-01-26 12:40:00,237+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (DefaultQuartzScheduler3) [5c4b079b] Adding VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'(dbatest3) to re-run list 2018-01-26 12:40:00,245+01 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring] (DefaultQuartzScheduler3) [5c4b079b] Rerun VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'. Called from VDS 'ov301' 2018-01-26 12:40:00,287+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateStatusVDSCommand] (org.ovirt.thread.pool-6-thread-15) [5c4b079b] START, MigrateStatusVDSCommand(HostName = ov301, MigrateStatusVDSCommandParameters:{runAsync='true', hostId='8ef1ce6f-4e38-486c-b3a4-58235f1f1d06', vmId='4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'}), log id: 65677081 2018-01-26 12:40:00,818+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateStatusVDSCommand] (org.ovirt.thread.pool-6-thread-15) [5c4b079b] FINISH, MigrateStatusVDSCommand, log id: 65677081 2018-01-26 12:40:00,823+01 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-15) [5c4b079b] EVENT_ID: VM_MIGRATION_TO_SERVER_FAILED(120), Correlation ID: 72ccfbb1-735a-4411-a990-cdb2c081e391, Job ID: b2f39d2c-87f1-480c-b4c7-b8ab09d09318, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Migration failed (VM: dbatest3, Source: ov301, Destination: ov200). 2018-01-26 12:40:00,825+01 INFO [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (org.ovirt.thread.pool-6-thread-15) [5c4b079b] Lock freed to object 'EngineLock:{exclusiveLocks='[4f6ecae2-7d71-47c9-af23-2b3e49bc08fc=VM]', sharedLocks=''}' 2018-01-26 12:40:05,796+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmsStatisticsFetcher] (DefaultQuartzScheduler1) [27a52eca] Fetched 2 VMs from VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd' I don't see errors in vdsm logs of target host, but I do see this in /var/log/messages of target host Jan 26 12:39:51 ov200 libvirtd: 2018-01-26 11:39:51.179+0000: 2588: error : virCPUx86UpdateLive:2726 : operation failed: guest CPU doesn't match specification: missing features: vmx Indeed dbatest3 VM has this "vmx=on" flag in qemu-kvm command line on source host, even if I never configured it explicitly...: [root@ov301 ~]# ps -ef|grep dbatest3 qemu 1455 1 1 2017 ? 08:41:29 /usr/libexec/qemu-kvm -name guest=dbatest3,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-27-dbatest3/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -cpu Westmere,vmx=on -m 32768 ... A quite similar VM named dbatest4 running on the already upgraded host doesn't have indeed the flag: [root@ov200 vdsm]# ps -ef|grep dbatest4 qemu 15827 1 3 10:47 ? 00:04:37 /usr/libexec/qemu-kvm -name guest=dbatest4,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-dbatest4/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -cpu Westmere -m 32768 The 2 VMs has been created from the same template and with the same options if I remember correctly and across the previous versions I could live migrate without problems.... What can have changed? This would be a possible great show stopper, because one has to power off all the VMs if he/she wants to upgrade..... Thanks in advance for any help, Gianluca

1 2

bonding mode-alb
by Demeter Tibor 26 Jan '18

26 Jan '18

--=_a87e03e3-4ae4-4dcb-8739-e4423d90cef2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dear members, I would like to use two switches for make high-availability network connection for my nfs storge. Unfortunately, these switches does not support 802.3.ad lacp, (really I can't stack them) but I've read about mode-alb and mode-tlb bonding modes. I know,these modes are available in ovirt, but how is work that? Also how is safe? Are there for HA or for load balance? I've read some forums, where does not recommended these modes to use in ovirt. What is the truths? I would like to use only for storage-traffic, it will be separated from other network traffic. I have two 10Gbe switches and two 10Gbe ports in my nodes. Thanks in advance, R Tibor --=_a87e03e3-4ae4-4dcb-8739-e4423d90cef2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: arial, helvetica, sans-serif; font-s= ize: 12pt; color: #000000"><div>Dear members,</div><div><br data-mce-bogus= =3D"1"></div><div>I would like to use two switches for make high-availabili= ty network connection for my nfs storge.</div><div>Unfortunately, these swi= tches does not support 802.3.ad lacp, (really I can't stack them)  but= I've read about mode-alb and mode-tlb bonding modes.  <br>I know= ,these modes are available in ovirt, but how is work that? Also how is safe= ? Are there for HA or for load balance? </div><div><br data-mce-bogus= =3D"1"></div><div>I've read some forums, where does not recommended these m= odes to use in ovirt. What is the truths? </div><div>I would like to u= se only for storage-traffic, it will be separated from other network traffi= c. I have two 10Gbe switches and two 10Gbe ports in my nodes. </div><d= iv><br data-mce-bogus=3D"1"></div><div>Thanks in advance, </div><div><= br data-mce-bogus=3D"1"></div><div>R</div><div><br data-mce-bogus=3D"1"></d= iv><div>Tibor</div><div> </div><div><br></div><div data-marker=3D"__SI= G_PRE__"><p style=3D"font-family: 'Times New Roman'; font-size: medium; mar= gin: 0px;"><strong><span style=3D"font-size: medium;"><span style=3D"color:= rgb(45, 103, 176);"></span></span></strong></p><p></p></div></div></body><= /html> --=_a87e03e3-4ae4-4dcb-8739-e4423d90cef2--

5 9

Re: [ovirt-users] oVirt 4.1.9 and Spectre-Meltdown checks
by Arman Khalatyan 26 Jan '18

26 Jan '18

you should download microcode from the intel web page and overwrite the /lib/firmware/intel-ucode or so...please check the readme. Am 26.01.2018 10:50 vorm. schrieb "Gianluca Cecchi" < gianluca.cecchi(a)gmail.com>: Hello, nice to see integration of Spectre-Meltdown info in 4.1.9, both for guests and hosts, as detailed in release notes: I have upgraded my CentOS 7.4 engine VM (outside of oVirt cluster) and one oVirt host to 4.1.9. Now in General -> Software subtab of the host I see: OS Version: RHEL - 7 - 4.1708.el7.centos OS Description: CentOS Linux 7 (Core) Kernel Version: 3.10.0 - 693.17.1.el7.x86_64 Kernel Features: IBRS: 0, PTI: 1, IBPB: 0 Am I supposed to manually set any particular value? If I run version 0.32 (updated yesterday) of spectre-meltdown-checker.sh I got this on my Dell M610 blade with Version: 6.4.0 Release Date: 07/18/2013 [root@ov200 ~]# /home/g.cecchi/spectre-meltdown-checker.sh Spectre and Meltdown mitigation detection tool v0.32 Checking for vulnerabilities on current system Kernel is Linux 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 CPU is Intel(R) Xeon(R) CPU X5690 @ 3.47GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: NO * CPU indicates IBRS capability: NO * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: NO * CPU indicates IBPB capability: NO * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: NO * CPU indicates STIBP capability: NO * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO * CPU vulnerability to the three speculative execution attacks variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Checking count of LFENCE opcodes in kernel: YES > STATUS: NOT VULNERABLE (107 opcodes found, which is >= 70, heuristic to be improved when official patches become available) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: YES * Currently enabled features * IBRS enabled for Kernel space: NO (echo 1 > /sys/kernel/debug/x86/ibrs_enabled) * IBRS enabled for User space: NO (echo 2 > /sys/kernel/debug/x86/ibrs_enabled) * IBPB enabled: NO (echo 1 > /sys/kernel/debug/x86/ibpb_enabled) * Mitigation 2 * Kernel compiled with retpoline option: NO * Kernel compiled with a retpoline-aware compiler: NO * Retpoline enabled: NO > STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (PTI mitigates the vulnerability) A false sense of security is worse than no security at all, see --disclaimer [root@ov200 ~]# So it seems I'm still vulnerable only to Variant 2, but kernel seems ok: * Kernel is compiled with IBRS/IBPB support: YES while bios not, correct? Is RH EL / CentOS expected to follow the retpoline option too, to mitigate Variant 2, as done by Fedora for example? Eg on my just updated Fedora 27 laptop I get now: [g.cecchi@ope46 spectre_meltdown]$ sudo ./spectre-meltdown-checker.sh [sudo] password for g.cecchi: Spectre and Meltdown mitigation detection tool v0.32 Checking for vulnerabilities on current system Kernel is Linux 4.14.14-300.fc27.x86_64 #1 SMP Fri Jan 19 13:19:54 UTC 2018 x86_64 CPU is Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: NO * CPU indicates IBRS capability: NO * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: NO * CPU indicates IBPB capability: NO * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: NO * CPU indicates STIBP capability: NO * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO * CPU vulnerability to the three speculative execution attacks variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable) > STATUS: VULNERABLE (Vulnerable) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active) * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: NO * Currently enabled features * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * IBPB enabled: NO * Mitigation 2 * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) * Retpoline enabled: YES > STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active) * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (Mitigation: PTI) A false sense of security is worse than no security at all, see --disclaimer [g.cecchi@ope46 spectre_meltdown]$ BTW: I updated some days ago this laptop from F26 to F27 and I remember Variant 1 was fixed in F26, while now I see it as vulnerable..... I'm going to check with Fedora mailing list about this... Another question: what should I see for a VM instead related to meltdown/spectre? Currently in "Guest CPU Type" in General subtab of the VM I only see "Westmere".. Should I also see anythin aout IBRS, etc...? Thanks, Gianluca _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

1 0

Ovirt 4.2, failing to connect to VDSM.
by CRiMSON 25 Jan '18

25 Jan '18

I did a quick upgrade this afternoon on a dev machine. Jan 25 11:57:07 Updated: glusterfs-libs-3.12.5-2.el7.x86_64 Jan 25 11:57:08 Updated: glusterfs-client-xlators-3.12.5-2.el7.x86_64 Jan 25 11:57:08 Updated: glusterfs-3.12.5-2.el7.x86_64 Jan 25 11:57:09 Updated: kernel-ml-tools-libs-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:09 Updated: kernel-ml-tools-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:10 Updated: glusterfs-api-3.12.5-2.el7.x86_64 Jan 25 11:57:10 Updated: glusterfs-fuse-3.12.5-2.el7.x86_64 Jan 25 11:57:10 Updated: glusterfs-cli-3.12.5-2.el7.x86_64 Jan 25 11:57:11 Updated: python-perf-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:37 Installed: kernel-ml-devel-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:39 Updated: kernel-ml-headers-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:52 Installed: kernel-ml-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:52 Updated: rubygem-fluent-plugin-viaq_data_model-0.0.13-1.el7.noarch This is all that was upgraded. But now my storage domains are failing to come up and the host keeps saying it's getting a connection refused. It's all on 1 host. In mom.log I see. 2018-01-25 17:10:49,929 - mom - INFO - MOM starting 2018-01-25 17:10:49,955 - mom.HostMonitor - INFO - Host Monitor starting 2018-01-25 17:10:49,955 - mom - INFO - hypervisor interface vdsmjsonrpcbulk 2018-01-25 17:10:50,013 - mom.vdsmInterface - ERROR - Cannot connect to VDSM! [Errno 111] Connection refused 2018-01-25 17:10:50,013 - mom - ERROR - Failed to initialize MOM threads Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29, in run hypervisor_iface = self.get_hypervisor_interface() File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 217, in get_hypervisor_interface return module.instance(self.config) File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcbulkInterface.py", line 47, in instance return JsonRpcVdsmBulkInterface() File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcbulkInterface.py", line 29, in __init__ super(JsonRpcVdsmBulkInterface, self).__init__() File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcInterface.py", line 43, in __init__ .orRaise(RuntimeError, 'No connection to VDSM.') File "/usr/lib/python2.7/site-packages/mom/optional.py", line 28, in orRaise raise exception(*args, **kwargs) RuntimeError: No connection to VDSM. [root@lv426 vdsm]# My vdsm.log is 0 byes (nothing being logged?) In my engine.log I'm seeing: 2018-01-25 17:12:11,027-05 INFO [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] Connecting to lv426.dasgeekhaus.org/127.0.0.1 2018-01-25 17:12:11,028-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-99) [] Command 'GetCapabilitiesVDSCommand(HostName = lv426, VdsIdAndVdsVDSCommandParametersBase:{hostId='a645af84-3da1-45ed-bab5-2af66b5924dd', vds='Host[lv426,a645af84-3da1-45ed-bab5-2af66b5924dd]'})' execution failed: java.net.ConnectException: Connection refused 2018-01-25 17:12:11,028-05 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (EE-ManagedThreadFactory-engineScheduled-Thread-99) [] Failure to refresh host 'lv426' runtime info: java.net.ConnectException: Connection refused 2018-01-25 17:12:13,517-05 INFO [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] Connecting to lv426.dasgeekhaus.org/127.0.0.1 2018-01-25 17:12:13,517-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetAllVmStatsVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-25) [] Command 'GetAllVmStatsVDSCommand(HostName = lv426, VdsIdVDSCommandParametersBase:{hostId='a645af84-3da1-45ed-bab5-2af66b5924dd'})' execution failed: java.net.ConnectException: Connection refused 2018-01-25 17:12:13,518-05 INFO [org.ovirt.engine.core.vdsbroker.monitoring.PollVmStatsRefresher] (EE-ManagedThreadFactory-engineScheduled-Thread-25) [] Failed to fetch vms info for host 'lv426' - skipping VMs monitoring. All of my network interfaces do come up ok, iptables is turned off so it's not getting in the way. I'm at a complete loss right now as to what to look at.

1 1

Imageio-Proxy: Failed to verify proxy ticket: Ticket life time expired
by Gabriel Stein 25 Jan '18

25 Jan '18

Hi, oVirt Version: 4.2 Imageio-Proxy: ovirt-imageio-proxy-1.0.0-0 vdsm: vdsm-4.20.9.3-1 I can't upload disks with more than 200GB to oVirt(using UI). Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1538814 I would appreciate any help. Thank you Best Regards Gabriel

1 0