- Users - oVirt List Archives

Re: Managed Block Storage/Ceph: Experiences from Catastrophic Hardware failure
by Strahil 07 Oct '19

07 Oct '19

Hi Dan, As CEPH support is quite new, we need DEV clarification. Hi Sandro, Who can help to clarify if Ovirt supports direct RBD LUNs presented on the VMs? Are there any limitations in the current solution ? Best Regards, Strahil NikolovOn Oct 7, 2019 13:54, Dan Poltawski <dan.poltawski(a)tnp.net.uk> wrote: > > On Mon, 2019-10-07 at 01:56 +0300, Strahil Nikolov wrote: > > I'm not very sure that you are supposed to use the CEPH by giving > > each VM direct access. > > > > Have you considered using an iSCSI gateway as an entry point for your > > storage domain ? This way oVirt will have no issues dealing with the > > rbd locks. > > > > Of course, oVirt might be able to deal with RBD locks , but that can > > be confirmed/denied by the devs. > > Thanks for your response - regarding the locks point, I realised later > that this was my own incorrect permissions given to the client. The > ceph client was detecting the broken locks when mounting the rbd device > and unable to blacklist it. I addressed this by swithcign to the > permissions 'profile rbd'. > > Regarding iSCSI, we are using this for the hosted engine. However, I am > attracted to the idea of managing block devices with individual rbd > devices to facilate individual block device level snapshotting and I > assume performance will be better. > > thanks, > > 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.

2 1

Re: VDI
by Leo David 07 Oct '19

07 Oct '19

Thank you for sharing the informations Alex, they are very helpfull. I am now able to get sound from the vms, although performance is pretty poor even with "adjust for performance" setting in Win10. Cannot even talk about youtube video playing - freezing and crackling. Could you please be so kind to share the following infos: 1. Have you upgraded the "spice-server" installed on the hosts with a newer version than 1.4.0 ? If so, could you provide me how could I get these packages ? 2. What graphic card have you used for getting better graphic performance with the vms ? Im trying to understand what "accepted" card could I use with my 1U chassis servers... 3. Is it only needed to install the card and the platform will alocate physical video memory to "desktop" vms ? ( Will the card RAM be automatically shared across the desktop tyoe vms running on top of the host ? ) 4. Is it necesarilly to activate sr-iov in the hosts bios or any other platform configurations ? I am really sorry for asking too many things, but im just trying to get these vdi vms working at least decent... Thank you so much ! Leo ---------- Forwarded message --------- From: <alex(a)triadic.us> Date: Tue, Sep 24, 2019 at 7:50 PM Subject: Re: [ovirt-users] Re: VDI To: Leo David <leoalex(a)gmail.com> Audio should just work as long as the VM is of the desktop type. On Sep 24, 2019 6:50 AM, Leo David <leoalex(a)gmail.com> wrote: Thank you Alex, When you say "gpu backed" are you referring to sr-iov to share same gpu to multiple vms ? Any thoughts regarding passing audio form the vm to the client ? Did you do any update of the spice-server on the hosts ? Thanks, Leo On Tue, Sep 24, 2019 at 12:01 PM <alex(a)triadic.us> wrote: I believe a lot of the package updates in CentOS 8 will solve some of the issues. But for now we get around them by disabling all visual effects on our VMS. If you are gpu backing the VMS with something like Nvidia grid the issues are non existent, but for non gpu backed VMS currently disabling all the effects is a must. We deploy the changes via gpo directly to the registry, so they take effect on first VM boot. On Sep 24, 2019 2:03 AM, Leo David <leoalex(a)gmail.com> wrote: Thank you Alex from my side as well, very usefull information. I am the middle of vdi implementation as well, and i'm having issues with the spice console since 4.2, and it seems that latest 4.3 is still having the problem. What am i confrunting is: - spice console is very slaggy and slow for Win10 vms ( not even talking about running videos..) - i can't find a way to get audio from the vm At the moment i am running 4.3, latest virt-viewer installed on the client, and latest qxl-dod driver installed on the vm. Any thoughts on solving video performance and audio redirection ? Thank you again, Leo On Mon, Sep 23, 2019, 22:53 Alex McWhirter <Alex(a)triadic.us> wrote: 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… _______________________________________________ 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/DWY46KJGSYJGR… -- Best regards, Leo David -- Best regards, Leo David

2 3

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

07 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

Trying to add a LUN to a host and use that, instead of Gluster, as the datastore for my VM's.
by TomK 06 Oct '19

06 Oct '19

Hey All, I've added a 4TB LUN to my physical storage and now I want to use that, instead of GlusterFS as my datastore for VM's on that physical. How do I do this? I've tried a number of options, including adding LUN's but appears I can only add them to VM's directly but not use them as my datastores instead of GlusterFS. -- Thx, TK.

1 0

Problem with logical network
by Alex Irmel Oviedo Solis 04 Oct '19

04 Oct '19

Hello, I'm trying to run a vm with two ethernet interfaces, one of them attached to ovirmnt and the other attached to a logical network named internal_servers and got this error: "VM is down with error. Exit message: can not get MTU interface in 'br-int': No such device2 Then I created the bridge manually but I get the following error: "VM is down with error. Exit message: Hook Error: ('',)." Please help me. Best Regards

1 0

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

Re: Recover node from partial upgrade
by Strahil 04 Oct '19

04 Oct '19

You can boot from the older image (grub menu) and then a cleanup procedure should be performed. I'm not sure if the thin LVs will be removed when you rerun the upgrade process , or they will remain the same. Beat Regards, Strahil NikolovOn Oct 4, 2019 14:04, Stefano Danzi <s.danzi(a)hawai.it> wrote: > > Hello!!! > > I upgraded oVirtNode 4.3.5.2 to 4.3.6 using Engine UI. > In the middle of the upgrade Engine fenced it, I can't understand why. > > Now Engine UI, and yum, report that there are no updates but node still > to version 4.3.5.2. > If I run "yum reinstall ovirt-node-ng-image-update" The result is as > follow, but the system remain not upgraded. > > ovirt-node-ng-image-update-4.3.6-1.el7.noarch.rpm | 719 MB 00:06:31 > Running transaction check > Running transaction test > Transaction test succeeded > Running transaction > Installazione : ovirt-node-ng-image-update-4.3.6-1.el7.noarch 1/1 > warning: %post(ovirt-node-ng-image-update-4.3.6-1.el7.noarch) scriptlet > failed, exit status 1 > Non-fatal POSTIN scriptlet failure in rpm package > ovirt-node-ng-image-update-4.3.6-1.el7.noarch > Uploading Package Profile > Cannot upload package profile. Is this client registered? > Verifica in corso : ovirt-node-ng-image-update-4.3.6-1.el7.noarch 1/1 > > Installato: > ovirt-node-ng-image-update.noarch 0:4.3.6-1.el7 > > Completo! > _______________________________________________ > 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/Y52X663MAR347…

2 1

Recover node from partial upgrade
by Stefano Danzi 04 Oct '19

04 Oct '19

Hello!!! I upgraded oVirtNode 4.3.5.2 to 4.3.6 using Engine UI. In the middle of the upgrade Engine fenced it, I can't understand why. Now Engine UI, and yum, report that there are no updates but node still to version 4.3.5.2. If I run "yum reinstall ovirt-node-ng-image-update" The result is as follow, but the system remain not upgraded. ovirt-node-ng-image-update-4.3.6-1.el7.noarch.rpm | 719 MB 00:06:31 Running transaction check Running transaction test Transaction test succeeded Running transaction Installazione : ovirt-node-ng-image-update-4.3.6-1.el7.noarch 1/1 warning: %post(ovirt-node-ng-image-update-4.3.6-1.el7.noarch) scriptlet failed, exit status 1 Non-fatal POSTIN scriptlet failure in rpm package ovirt-node-ng-image-update-4.3.6-1.el7.noarch Uploading Package Profile Cannot upload package profile. Is this client registered? Verifica in corso : ovirt-node-ng-image-update-4.3.6-1.el7.noarch 1/1 Installato: ovirt-node-ng-image-update.noarch 0:4.3.6-1.el7 Completo!

1 0

Re: Ovirt 4.2.7 won't start and drops to emergency console
by Strahil 04 Oct '19

04 Oct '19

Trust Red Hat :) At least their approach should be safer. Of course, you can raise a docu bug but RHEL7 is in such phase that it might not be fixed unless this is found in v8. Best Regards, Strahil NikolovOn Oct 2, 2019 05:43, jeremy_tourville(a)hotmail.com wrote: > > http://man7.org/linux/man-pages/man7/lvmthin.7.html > Command to repair a thin pool: > lvconvert --repair VG/ThinPoolLV > > Repair performs the following steps: > > 1. Creates a new, repaired copy of the metadata. > lvconvert runs the thin_repair command to read damaged metadata from > the existing pool metadata LV, and writes a new repaired copy to the > VG's pmspare LV. > > 2. Replaces the thin pool metadata LV. > If step 1 is successful, the thin pool metadata LV is replaced with > the pmspare LV containing the corrected metadata. The previous thin > pool metadata LV, containing the damaged metadata, becomes visible > with the new name ThinPoolLV_tmetaN (where N is 0,1,...). > > If the repair works, the thin pool LV and its thin LVs can be > activated, and the LV containing the damaged thin pool metadata can > be removed. It may be useful to move the new metadata LV (previously > pmspare) to a better PV. > > If the repair does not work, the thin pool LV and its thin LVs are > lost. > > This info seems to conflict with Red Hat advice. Red Hat says if metadat volume is full don't run a lvconvert --repair operation. Now I am confused. I am familiar with LVM and comfortable with it but this is my first time trying to repair thin LVM. The concepts of a metadata volume are new to me. > _______________________________________________ > 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/FFN3HWUQVRPFS…

2 2