September 2019 - Users - oVirt List Archives

There are too many tasks running on the server. Does it affect my system?
by zhouhao＠vip.friendtimes.net 18 Oct '19

18 Oct '19

There are too many tasks running on the server. Does it affect my system？

2 3

disk locked after export as OVA
by adam_xu＠adagene.com.cn 15 Oct '19

15 Oct '19

Hello, everyone. I tried to export a vm as OVA. I got a error in webui: VDSM ovirt1.ntbaobei.com command HSMGetAllTasksStatusesVDS failed: Volume Group not big enough: (u'Not enough free extents for extending LV d9f2378f-92f0-4bc1-96a8-20a0f2c575cb/c515a3f9-0590-4ebe-81c5-9d0993f1fec9 (free=848, needed=872)',) seems no enough space in the storage domain. I deleted the vm which i wanted to export as OVA before, but I saw a disk with id 8140d2e7-6908-438e-a646-23e58a33913e left in the storage and the status is locked. here's some log in the engine.log: 2018-09-17 14:27:03,467+08 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand] (EE-ManagedThreadFactory-engine-Thread-107849) [a407f6a9-445d-4ccc-b998-f9dfc6dc67ec] START, CopyImageVDSCommand( CopyImageVDSCommandParameters:{storagePoolId='79432500-ad45-11e8-98f3-00163e188641', ignoreFailoverLimit='false', storageDomainId='d9f2378f-92f0-4bc1-96a8-20a0f2c575cb', imageGroupId='ee55bbe7-8001-4c82-b1a6-0cac7710704b', imageId='701a7472-8c00-4b9f-aa87-4837eb128695', dstImageGroupId='8140d2e7-6908-438e-a646-23e58a33913e', vmId='b3aa623e-3072-430e-87d6-b81a3b07f466', dstImageId='c515a3f9-0590-4ebe-81c5-9d0993f1fec9', imageDescription='', dstStorageDomainId='d9f2378f-92f0-4bc1-96a8-20a0f2c575cb', copyVolumeType='LeafVol', volumeFormat='COW', preallocate='Sparse', postZero='false', discard='false', force='true'}), log id: 164e3046 2018-09-17 14:27:03,467+08 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand] (EE-ManagedThreadFactory-engine-Thread-107849) [a407f6a9-445d-4ccc-b998-f9dfc6dc67ec] ++ dstImageGUID=8140d2e7-6908-438e-a646-23e58a33913e I think maybe some command did not been excuted after I export the vm as OVA. I can find the similar case here: https://access.redhat.com/solutions/1298893 I have used the tool unlock_entity.sh but cannot find any disk that is locked. So what should I do to delete the disk that is been locked? yours Adam

2 1

Re: change connection string in db
by Strahil 14 Oct '19

14 Oct '19

I think that there is a special file on the shared storage (something like OVA) that stores the necessary data. Have you tried with: hosted-engine --set-shared-config storage <server1>:/engine hosted-engine --set-shared-config mnt_options backup-volfile-servers=<server2>:<server3> Best Regards, Strahil NikolovOn Sep 30, 2019 19:14, olaf.buitelaar(a)gmail.com wrote: > > Dear oVirt users, > > one thing i still cannot find out, is where the engine gathers the storage= value from in the /etc/ovirt-hosted-engine/hosted-engine.conf > I suppose it's somewhere in a answers file, but i cannot find it. > Any points are appreciated. hopfully this is the last place where the old connection string lives. > > Thanks Olaf > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/GPPKRN5YLUMEJ…

2 1

Re: VDI
by Alex McWhirter 09 Oct '19

09 Oct '19

To achieve that all you need to do is create a template of the desktop base vm, make sure the vm type is set to desktop. Afterwards just create new vms from that template. As long as the VM type is set to desktop each new VM will use a qcow overlay on top of the base image. Taking this a step further you can then create VM pools from said template, allowing users to dynamically be assigned a new VM on login. Granted pools are usually stateless, so you need to have network file storage. We use pools for windows 10 VDI instances, where we use sysprep to autojoin the new pool vm to the domain where redirected folders are already setup. For VDI only use spice protocol. By default we found spice to be semi lackluster, so we do apply custom settings and we have recompiled spice on both servers and clients with h264 support. This is not 100% necessary, but makes things like youtube much more usable. We have also backported some audio patches to KVM. CentOS 8 should resolve a lot of these customizations that we've had to do. As far as updating, pretty much. We create a VM from the template, update it, then push it back as a new version of the template. The pools are set to always use the latest template version. Users have to log out, then back in to the VDI system in order to get the new image as logging out will destroy the users current instance and create a new one on log in. On 2019-09-23 15:16, Fabio Marzocca wrote: > Hi Alex, thanks for answering. > > I am approaching and studying oVirt in order to propose the solution to a customer as a replacement for a commercial solution they have now. > They only need Desktop virtualization. > Sorry for the silly question, but I can't find a way to deploy a VM (template) to users as a "linked-clone", meaning that the users' image still refers to the original image but modification are written (and afterwards read) from a new location. This technique is called Copy-on-write. > Can this be achieved with oVirt? > > Then, what is the Best Practice to update WIndows OS for the all the users? Currently they simply "check-out" the Gold Image, update it and check-in, while all users are running... > > Fabio > > On Mon, Sep 23, 2019 at 8:04 PM Alex McWhirter <Alex(a)triadic.us> wrote: > > yes, we do. All spice, with some customizations done at source level for spice / kvm packages. > > On 2019-09-23 13:44, Fabio Marzocca wrote: > Is there anyone who uses oVirt as a full VDI environment? I would have a bunch of questions... > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/D44YB5VOKNBNC…

5 4

oVirt Software after upgrade
by Rick A 07 Oct '19

07 Oct '19

I'm wondering why after upgrading our hosts, when viewing the host details, it's still showing the OS Description as 4.3.3.1. We are using the oVirt Node. Shouldn't the OS Description show the version we just upgraded to? I do the upgrade using the web UI. Thanks OS Version: RHEL - 7 - 6.1810.2.el7.centos OS Description: oVirt Node 4.3.3.1 <-------------------------------------- Kernel Version: 3.10.0 - 957.10.1.el7.x86_64 KVM Version: 2.12.0 - 18.el7_6.3.1 LIBVIRT Version: libvirt-4.5.0-10.el7_6.6 VDSM Version: vdsm-4.30.13-1.el7 SPICE Version: 0.14.0 - 6.el7_6.1 GlusterFS Version: glusterfs-5.5-1.el7 CEPH Version: librbd1-10.2.5-4.el7 Open vSwitch Version: openvswitch-2.10.1-3.el7 Kernel Features: PTI: 1, IBRS: 1, RETP: 0, SSBD: 3 VNC Encryption: Disabled

2 1

Managed Block Storage/Ceph: Experiences from Catastrophic Hardware failure
by Dan Poltawski 06 Oct '19

06 Oct '19

Yesterday we had a catastrophic hardware failure with one of our nodes using ceph and the experimental cinderlib integration. Unfortunately the ovirt cluster recover the situation well and took some manual intervention to resolve. I thought I'd share what happened and how we resolved it in case there is any best practice to share/bugs which are worth creating to help others in similar situaiton. We are early in our use of ovirt, so its quite possible we have things incorreclty configured. Our setup: We have two nodes, hosted engine on iSCSI, about 40vms all using managed block storage mounting the rbd volumes directly. I hadn't configured power management (perhaps this is the fundamental problem). Yesterday a hardware fault caused one of the nodes to crash and stay down awaiting user input in POST screens, taking 20 vms with it. The hosted engine was fortunately on the 'good' node and detected that the node had become unresponsive, but noted 'Host cannot be fenced automatically because power management for the host is disabled.'. At this point, knowing that one node was dead, I wanted to bring up the failed vms on the good node. However, the vms were appearing in an unknown state and I couldn't do any operations on them. It wasn't clear to me what the best course of action to do there would be. I am not sure if there is a way to mark the node as failed? In my urgency to try and resolve the situation I managed to get the failed node startred back up, shortly after it came up the engine detected that all the vms were down, I put the failed host into maintaince mode and tried to start the failed vms. Unfortunately the failed vms did not start up cleanly - it turned out that they still had rbd locks preventing writing from the failed node. To finally gets the vms to start I then manually went through every vm's managed block, found the id and found the lock and removed it: rbd lock list rbd/volume-{id} rbd lock remove rbd/voleume-{id} 'auto {lockid}' {lockername} Some overall thoughts I had: * I'm not sure what the best course of action is to notify the engine about a catastrophic hardware failure? If power management was configured, I suppose it would've removed the power and marked them all down? * Would ovirt have been able to deal with clearing the rbd locks, or did I miss a trick somewhere to resolve this situation with manually going through each device and clering the lock? * Might it be possible for ovirt to detect when the rbd images are locked for writing and prevent launching? regards, Dan ________________________________ The Networking People (TNP) Limited. Registered office: Network House, Caton Rd, Lancaster, LA1 3PE. Registered in England & Wales with company number: 07667393 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

3 2

[ANN] oVirt 4.3.6 is now generally available
by Sandro Bonazzola 06 Oct '19

06 Oct '19

The oVirt Project is pleased to announce the general availability of oVirt 4.3.6 as of September 26th, 2019. This update is the sixth in a series of stabilization updates to the 4.3 series. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.7 or later (but < 8) * CentOS Linux (or similar) 7.7 or later (but < 8) This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.7 or later (but < 8) * CentOS Linux (or similar) 7.7 or later (but < 8) * oVirt Node 4.3 (available for x86_64 only) Due to Fedora 28 being now at end of life this release is missing experimental tech preview for x86_64 and s390x architectures for Fedora 28. We are working on Fedora 29 and 30 support and we may re-introduce experimental support for Fedora in next release. See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Node is already available[2] oVirt Node and Appliance have been updated including: - oVirt 4.3.6: http://www.ovirt.org/release/4.3.6/ - Wildfly 17.0.1: https://wildfly.org/news/2019/07/07/WildFly-1701-Released/ - Latest CentOS 7.7 updates including: - Release for CentOS Linux 7 (1908) on the x86_64 Architecture <https://lists.centos.org/pipermail/centos-announce/2019-September/023405.ht…> - CEBA-2019:2601 CentOS 7 NetworkManager BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023423.ht…> - CEBA-2019:2023 CentOS 7 efivar BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023445.ht…> - CEBA-2019:2614 CentOS 7 firewalld BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023412.ht…> - CEBA-2019:2227 CentOS 7 grubby BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023441.ht…> - CESA-2019:2258 Moderate CentOS 7 http-parser Security Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023439.ht…> - CESA-2019:2600 Important CentOS 7 kernel Security Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023444.ht…> - CEBA-2019:2599 CentOS 7 krb5 BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023420.ht…> - CEBA-2019:2358 CentOS 7 libguestfs BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023421.ht…> - CEBA-2019:2679 CentOS 7 libvirt BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023422.ht…> - CEBA-2019:2501 CentOS 7 rsyslog BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023431.ht…> - CEBA-2019:2355 CentOS 7 selinux-policy BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023432.ht…> - CEBA-2019:2612 CentOS 7 sg3_utils BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023433.ht…> - CEBA-2019:2602 CentOS 7 sos BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023434.ht…> - CEBA-2019:2564 CentOS 7 subscription-manager BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023435.ht…> - CEBA-2019:2356 CentOS 7 systemd BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023436.ht…> - CEBA-2019:2605 CentOS 7 tuned BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023437.ht…> - CEBA-2019:2871 CentOS 7 tzdata BugFix Update <https://lists.centos.org/pipermail/centos-announce/2019-September/023450.ht…> - latest CentOS Virt and Storage SIG updates: - Ansible 2.8.5: https://github.com/ansible/ansible/blob/stable-2.8/changelogs/CHANGELOG-v2.… - Glusterfs 6.5: https://docs.gluster.org/en/latest/release-notes/6.5/ - QEMU KVM EV 2.12.0-33.1 : https://cbs.centos.org/koji/buildinfo?buildID=26484 Given the amount of security fixes provided by this release, upgrade is recommended as soon as practical. Additional Resources: * Read more about the oVirt 4.3.6 release highlights: http://www.ovirt.org/release/4.3.6/ * 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.3.6/ [2] http://resources.ovirt.org/pub/ovirt-4.3/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. <https://mojo.redhat.com/docs/DOC-1199578>*

13 33

oVirt 4.3.5 glusterfs 6.3 performance tunning
by adrianquintero＠gmail.com 04 Oct '19

04 Oct '19

Hello, I have a hyperconverged setup using ovirt 4.3.5 and the "optimize for ovirt store" seems to fail on gluster volumes. I am seeing poor performance and trying to see how should I tune gluster to give better performance. Can you provide any suggestions on the following volume settings(parameters)? option Value ------ ----- cluster.lookup-unhashed on cluster.lookup-optimize on cluster.min-free-disk 10% cluster.min-free-inodes 5% cluster.rebalance-stats off cluster.subvols-per-directory (null) cluster.readdir-optimize off cluster.rsync-hash-regex (null) cluster.extra-hash-regex (null) cluster.dht-xattr-name trusted.glusterfs.dht cluster.randomize-hash-range-by-gfid off cluster.rebal-throttle normal cluster.lock-migration off cluster.force-migration off cluster.local-volume-name (null) cluster.weighted-rebalance on cluster.switch-pattern (null) cluster.entry-change-log on cluster.read-subvolume (null) cluster.read-subvolume-index -1 cluster.read-hash-mode 1 cluster.background-self-heal-count 8 cluster.metadata-self-heal off cluster.data-self-heal off cluster.entry-self-heal off cluster.self-heal-daemon on cluster.heal-timeout 600 cluster.self-heal-window-size 1 cluster.data-change-log on cluster.metadata-change-log on cluster.data-self-heal-algorithm full cluster.eager-lock enable disperse.eager-lock on disperse.other-eager-lock on disperse.eager-lock-timeout 1 disperse.other-eager-lock-timeout 1 cluster.quorum-type auto cluster.quorum-count (null) cluster.choose-local off cluster.self-heal-readdir-size 1KB cluster.post-op-delay-secs 1 cluster.ensure-durability on cluster.consistent-metadata no cluster.heal-wait-queue-length 128 cluster.favorite-child-policy none cluster.full-lock yes diagnostics.latency-measurement off diagnostics.dump-fd-stats off diagnostics.count-fop-hits off diagnostics.brick-log-level INFO diagnostics.client-log-level INFO diagnostics.brick-sys-log-level CRITICAL diagnostics.client-sys-log-level CRITICAL diagnostics.brick-logger (null) diagnostics.client-logger (null) diagnostics.brick-log-format (null) diagnostics.client-log-format (null) diagnostics.brick-log-buf-size 5 diagnostics.client-log-buf-size 5 diagnostics.brick-log-flush-timeout 120 diagnostics.client-log-flush-timeout 120 diagnostics.stats-dump-interval 0 diagnostics.fop-sample-interval 0 diagnostics.stats-dump-format json diagnostics.fop-sample-buf-size 65535 diagnostics.stats-dnscache-ttl-sec 86400 performance.cache-max-file-size 0 performance.cache-min-file-size 0 performance.cache-refresh-timeout 1 performance.cache-priority performance.cache-size 32MB performance.io-thread-count 16 performance.high-prio-threads 16 performance.normal-prio-threads 16 performance.low-prio-threads 32 performance.least-prio-threads 1 performance.enable-least-priority on performance.iot-watchdog-secs (null) performance.iot-cleanup-disconnected- reqsoff performance.iot-pass-through false performance.io-cache-pass-through false performance.cache-size 128MB performance.qr-cache-timeout 1 performance.cache-invalidation false performance.ctime-invalidation false performance.flush-behind on performance.nfs.flush-behind on performance.write-behind-window-size 1MB performance.resync-failed-syncs-after -fsyncoff performance.nfs.write-behind-window-s ize1MB performance.strict-o-direct on performance.nfs.strict-o-direct off performance.strict-write-ordering off performance.nfs.strict-write-ordering off performance.write-behind-trickling-wr iteson performance.aggregate-size 128KB performance.nfs.write-behind-tricklin g-writeson performance.lazy-open yes performance.read-after-open yes performance.open-behind-pass-through false performance.read-ahead-page-count 4 performance.read-ahead-pass-through false performance.readdir-ahead-pass-throug h false performance.md-cache-pass-through false performance.md-cache-timeout 1 performance.cache-swift-metadata true performance.cache-samba-metadata false performance.cache-capability-xattrs true performance.cache-ima-xattrs true performance.md-cache-statfs off performance.xattr-cache-list performance.nl-cache-pass-through false features.encryption off network.frame-timeout 1800 network.ping-timeout 30 network.tcp-window-size (null) client.ssl off network.remote-dio off client.event-threads 4 client.tcp-user-timeout 0 client.keepalive-time 20 client.keepalive-interval 2 client.keepalive-count 9 network.tcp-window-size (null) network.inode-lru-limit 16384 auth.allow * auth.reject (null) transport.keepalive 1 server.allow-insecure on server.root-squash off server.all-squash off server.anonuid 65534 server.anongid 65534 server.statedump-path /var/run/gluster server.outstanding-rpc-limit 64 server.ssl off auth.ssl-allow * server.manage-gids off server.dynamic-auth on client.send-gids on server.gid-timeout 300 server.own-thread (null) server.event-threads 4 server.tcp-user-timeout 42 server.keepalive-time 20 server.keepalive-interval 2 server.keepalive-count 9 transport.listen-backlog 1024 transport.address-family inet performance.write-behind on performance.read-ahead off performance.readdir-ahead on performance.io-cache off performance.open-behind on performance.quick-read off performance.nl-cache off performance.stat-prefetch on performance.client-io-threads on performance.nfs.write-behind on performance.nfs.read-ahead off performance.nfs.io-cache off performance.nfs.quick-read off performance.nfs.stat-prefetch off performance.nfs.io-threads off performance.force-readdirp true performance.cache-invalidation false performance.global-cache-invalidation true features.uss off features.snapshot-directory .snaps features.show-snapshot-directory off features.tag-namespaces off network.compression off network.compression.window-size -15 network.compression.mem-level 8 network.compression.min-size 0 network.compression.compression-level -1 network.compression.debug false features.default-soft-limit 80% features.soft-timeout 60 features.hard-timeout 5 features.alert-time 86400 features.quota-deem-statfs off geo-replication.indexing off geo-replication.indexing off geo-replication.ignore-pid-check off geo-replication.ignore-pid-check off features.quota off features.inode-quota off features.bitrot disable debug.trace off debug.log-history no debug.log-file no debug.exclude-ops (null) debug.include-ops (null) debug.error-gen off debug.error-failure (null) debug.error-number (null) debug.random-failure off debug.error-fops (null) nfs.disable on features.read-only off features.worm off features.worm-file-level off features.worm-files-deletable on features.default-retention-period 120 features.retention-mode relax features.auto-commit-period 180 storage.linux-aio off storage.batch-fsync-mode reverse-fsync storage.batch-fsync-delay-usec 0 storage.owner-uid 36 storage.owner-gid 36 storage.node-uuid-pathinfo off storage.health-check-interval 30 storage.build-pgfid off storage.gfid2path on storage.gfid2path-separator : storage.reserve 1 storage.health-check-timeout 10 storage.fips-mode-rchecksum off storage.force-create-mode 0 storage.force-directory-mode 0 storage.create-mask 777 storage.create-directory-mask 777 storage.max-hardlinks 100 features.ctime on config.gfproxyd off cluster.server-quorum-type server cluster.server-quorum-ratio 0 changelog.changelog off changelog.changelog-dir {{ brick.path }}/.glusterfs/changelogs changelog.encoding ascii changelog.rollover-time 15 changelog.fsync-interval 5 changelog.changelog-barrier-timeout 120 changelog.capture-del-path off features.barrier disable features.barrier-timeout 120 features.trash off features.trash-dir .trashcan features.trash-eliminate-path (null) features.trash-max-filesize 5MB features.trash-internal-op off cluster.enable-shared-storage disable locks.trace off locks.mandatory-locking off cluster.disperse-self-heal-daemon enable cluster.quorum-reads no client.bind-insecure (null) features.shard on features.shard-block-size 64MB features.shard-lru-limit 16384 features.shard-deletion-rate 100 features.scrub-throttle lazy features.scrub-freq biweekly features.scrub false features.expiry-time 120 features.cache-invalidation off features.cache-invalidation-timeout 60 features.leases off features.lease-lock-recall-timeout 60 disperse.background-heals 8 disperse.heal-wait-qlength 128 cluster.heal-timeout 600 dht.force-readdirp on disperse.read-policy gfid-hash cluster.shd-max-threads 8 cluster.shd-wait-qlength 10000 cluster.locking-scheme granular cluster.granular-entry-heal enable features.locks-revocation-secs 0 features.locks-revocation-clear-all false features.locks-revocation-max-blocked 0 features.locks-monkey-unlocking false features.locks-notify-contention no features.locks-notify-contention-dela y 5 disperse.shd-max-threads 1 disperse.shd-wait-qlength 1024 disperse.cpu-extensions auto disperse.self-heal-window-size 1 cluster.use-compound-fops off performance.parallel-readdir off performance.rda-request-size 131072 performance.rda-low-wmark 4096 performance.rda-high-wmark 128KB performance.rda-cache-limit 10MB performance.nl-cache-positive-entry false performance.nl-cache-limit 10MB performance.nl-cache-timeout 60 cluster.brick-multiplex off cluster.max-bricks-per-process 250 disperse.optimistic-change-log on disperse.stripe-cache 4 cluster.halo-enabled False cluster.halo-shd-max-latency 99999 cluster.halo-nfsd-max-latency 5 cluster.halo-max-latency 5 cluster.halo-max-replicas 99999 cluster.halo-min-replicas 2 features.selinux on cluster.daemon-log-level INFO debug.delay-gen off delay-gen.delay-percentage 10% delay-gen.delay-duration 100000 delay-gen.enable disperse.parallel-writes on features.sdfs off features.cloudsync off features.ctime on ctime.noatime on feature.cloudsync-storetype (null) features.enforce-mandatory-lock off thank you!

2 2

oVirt 4.3.5 WARN no gluster network found in cluster
by adrianquintero＠gmail.com 03 Oct '19

03 Oct '19

Hi, I have a 4.3.5 hyperconverged setup with 3 hosts, each host has 2x10G NIC ports Host1: NIC1: 192.168.1.11 NIC2: 192.168.0.67 (Gluster) Host2: NIC1: 10.10.1.12 NIC2: 192.168.0.68 (Gluster) Host3: NIC1: 10.10.1.13 NIC2: 192.168.0.69 (Gluster) I am able to ping all the gluster IPs from within the hosts. i.e from host1 i can ping 192.168.0.68 and 192.168.0.69 However from the HostedEngine VM I cant ping any of those IPs [root@ovirt-engine ~]# ping 192.168.0.9 PING 192.168.0.60 (192.168.0.60) 56(84) bytes of data. From 10.10.255.5 icmp_seq=1 Time to live exceeded and on the HostedEngine I see the following WARNINGS (only for host1) which make me think that I am not using a separate network exclusively for gluster. 2019-08-21 21:04:34,215-04 WARN [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler10) [397b6038] Could not associate brick 'host1.example.com:/gluster_bricks/engine/engine' of volume 'ac1f73ce-cdf0-4bb9-817d-xxxxxxcxxx' with correct network as no gluster network found in cluster 'xxxxxxxx11e9-b8d3-00163e5d860d' Any ideas? thank you!! 2019-08-21 21:04:34,220-04 WARN [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler10) [397b6038] Could not associate brick 'vmm01.virt.ord1d:/gluster_bricks/data/data' of volume 'bc26633a-9a0b-49de-b714-97e76f222a02' with correct network as no gluster network found in cluster 'e98e2c16-c31e-11e9-b8d3-00163e5d860d' 2019-08-21 21:04:34,224-04 WARN [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler10) [397b6038] Could not associate brick 'host1:/gluster_bricks/vmstore/vmstore' of volume 'xxxxxxxxx-ca96-45cc-9e0f-649055e0e07b' with correct network as no gluster network found in cluster 'e98e2c16-c31e-11e9-b8d3xxxxxxxxxxxxxxx'

3 4

web admin: snapshots UI
by Yedidyah Bar David 03 Oct '19

03 Oct '19

Hi all, I'd like to ask/suggest something: In the previous UI (4.2?), when you entered the VM snapshots page, you saw per each snapshot some details that you do not see in the current UI. Specifically, to see the creation date, you have to press General. So I got used to writing longer descriptions, with the creation date in them, but that also does not work well, because in the main view only the start of the description is shown. At least for me (combination of browser, OS, etc.), there is a lot of white unused space between the end of the presented-part of the description, and the "> General" after it. Can we somehow use this space to either add the creation date, or more/all of the description, or even make this customizable? And perhaps make this a sortable table (so that you can sort by description, or if you added Data, you can sort by that, or memory, or whatever)? I don't mind opening a bug/RFE for this, if more people agree that it's useful, and unless there are some (unknown to me) reasons against that (other than the time needed for implementing this, which I expect is quite minimal for the simplest option of just showing more of the description). Thanks and best regards, -- Didi

2 2