- Users - oVirt List Archives

Error while executing action Change CD: Drive image file could not be found
by racevedo＠lenovo.com 22 May '19

22 May '19

I see that this was apparently a bug in previous version, but I'm currently using oVirt Node 4.3.3.1. This was working fine before updating from oVirt Node 4.2. This occurs when trying to change the CD on a running VM. Log shows: 2019-05-03 12:09:24,731-04 ERROR [org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand] (default task-52) [309a3a99-c754-45d5-add7-c45e094d2e69] Command 'org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand' failed: EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to ChangeDiskVDS, error = Drive image file could not be found, code = 13 (Failed with error imageErr and code 13) Any advice on how to solve this Current configuration: 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

2 2

[ANN] oVirt 4.3.4 Second Release Candidate is now available
by Sandro Bonazzola 22 May '19

22 May '19

The oVirt Project is pleased to announce the availability of the oVirt 4.3.4 Second Release Candidate, as of May 22nd, 2019. This update is a release candidate of the fourth in a series of stabilization updates to the 4.3 series. This is pre-release software. This pre-release should not to be used inproduction. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later * oVirt Node 4.3 (available for x86_64 only) Experimental tech preview for x86_64 and s390x architectures for Fedora 28 is also included. 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] Additional Resources: * Read more about the oVirt 4.3.4 release highlights: http://www.ovirt.org/release/4.3.4/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4.3.4/ [2] http://resources.ovirt.org/pub/ovirt-4.3-pre/iso/ -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

1 0

vGPU becomes very inefficient when I use it in ovirt instead of qemu-kvm
by weizhengya16＠gmail.com 22 May '19

22 May '19

We distribute vGpu in order to use it in virtual machines. I find the same type vGpu get differently performance in Ovirt and Qemu-kvm . when I distribute a vGPU to Ovirt virtual machine,it's performance becomes very strange.Some games can run efficiently and attach 200+ fps.However,in some other games,it's can't even attach 10 FPS. But in Qemu-kvm,the vGpu's performance always efficiently,can run these games all in 200+fps. I've been stuck with this for weeks and I have to make it always runs efficiently. Can someone help me?Thank you very very very much....

2 2

Re: [ovirt-announce] Re: [ANN] oVirt 4.3.4 First Release Candidate is now available
by Strahil 22 May '19

22 May '19

Dear Krutika, Yes I did but I use 6 ports (1 gbit/s each) and this is the reason that reads get slower. Do you know a way to force gluster to open more connections (client to server & server to server)? Thanks for the detailed explanation. Best Regards, Strahil NikolovOn May 21, 2019 08:36, Krutika Dhananjay <kdhananj(a)redhat.com> wrote: > > So in our internal tests (with nvme ssd drives, 10g n/w), we found read performance to be better with choose-local > disabled in hyperconverged setup. See https://bugzilla.redhat.com/show_bug.cgi?id=1566386 for more information. > > With choose-local off, the read replica is chosen randomly (based on hash value of the gfid of that shard). > And when it is enabled, the reads always go to the local replica. > We attributed better performance with the option disabled to bottlenecks in gluster's rpc/socket layer. Imagine all read > requests lined up to be sent over the same mount-to-brick connection as opposed to (nearly) randomly getting distributed > over three (because replica count = 3) such connections. > > Did you run any tests that indicate "choose-local=on" is giving better read perf as opposed to when it's disabled? > > -Krutika > > On Sun, May 19, 2019 at 5:11 PM Strahil Nikolov <hunter86_bg(a)yahoo.com> wrote: >> >> Ok, >> >> so it seems that Darell's case and mine are different as I use vdo. >> >> Now I have destroyed Storage Domains, gluster volumes and vdo and recreated again (4 gluster volumes on a single vdo). >> This time vdo has '--emulate512=true' and no issues have been observed. >> >> Gluster volume options before 'Optimize for virt': >> >> Volume Name: data_fast >> Type: Replicate >> Volume ID: 378804bf-2975-44d8-84c2-b541aa87f9ef >> Status: Started >> Snapshot Count: 0 >> Number of Bricks: 1 x (2 + 1) = 3 >> Transport-type: tcp >> Bricks: >> Brick1: gluster1:/gluster_bricks/data_fast/data_fast >> Brick2: gluster2:/gluster_bricks/data_fast/data_fast >> Brick3: ovirt3:/gluster_bricks/data_fast/data_fast (arbiter) >> Options Reconfigured: >> transport.address-family: inet >> nfs.disable: on >> performance.client-io-threads: off >> cluster.enable-shared-storage: enable >> >> Gluster volume after 'Optimize for virt': >> >> Volume Name: data_fast >> Type: Replicate >> Volume ID: 378804bf-2975-44d8-84c2-b541aa87f9ef >> Status: Stopped >> Snapshot Count: 0 >> Number of Bricks: 1 x (2 + 1) = 3 >> Transport-type: tcp >> Bricks: >> Brick1: gluster1:/gluster_bricks/data_fast/data_fast >> Brick2: gluster2:/gluster_bricks/data_fast/data_fast >> Brick3: ovirt3:/gluster_bricks/data_fast/data_fast (arbiter) >> Options Reconfigured: >> network.ping-timeout: 30 >> performance.strict-o-direct: on >> storage.owner-gid: 36 >> storage.owner-uid: 36 >> server.event-threads: 4 >> client.event-threads: 4 >> cluster.choose-local: off >> user.cifs: off >> features.shard: on >> cluster.shd-wait-qlength: 10000 >> cluster.shd-max-threads: 8 >> cluster.locking-scheme: granular >> cluster.data-self-heal-algorithm: full >> cluster.server-quorum-type: server >> cluster.quorum-type: auto >> cluster.eager-lock: enable >> network.remote-dio: off >> performance.low-prio-threads: 32 >> performance.io-cache: off >> performance.read-ahead: off >> performance.quick-read: off >> transport.address-family: inet >> nfs.disable: on >> performance.client-io-threads: on >> cluster.enable-shared-storage: enable >> >> After that adding the volumes as storage domains (via UI) worked without any issues. >> >> Can someone clarify why we have now 'cluster.choose-local: off' when in oVirt 4.2.7 (gluster v3.12.15) we didn't have that ? >> I'm using storage that is faster than network and reading from local brick gives very high read speed. >> >> Best Regards, >> Strahil Nikolov >> >> >> >> В неделя, 19 май 2019 г., 9:47:27 ч. Г�

2 1

Supporting comments on ovirt-site Blog section
by Roy Golan 22 May '19

22 May '19

It would be very useful to have a comment section on our ovirt site. It is quite standard to have that on every blog out there, and for a reason - you get feedback and conversation around the topic, without going somewhere else (users list, irc, etc...) What do we need to do to help the middle man with that? Regards, Roy

4 3

Re: Scale out ovirt 4.3 (from 3 to 6 or 9 nodes) with hyperconverged setup and Gluster
by Strahil 21 May '19

21 May '19

I have edited my multipath.conf to exclude local disks , but you need to set '#VDSM private' as per the comments in the header of the file. Otherwise, use the /dev/mapper/multipath-device notation - as you would do with any linux. Best Regards, Strahil NikolovOn Apr 23, 2019 01:07, adrianquintero(a)gmail.com wrote: > > Thanks Alex, that makes more sense now while trying to follow the instructions provided I see that all my disks /dev/sdb, /dev/sdc, /dev/sdd are locked and inidicating " multpath_member" hence not letting me create new bricks. And on the logs I see > > Device /dev/sdb excluded by a filter.\n", "item": {"pvname": "/dev/sdb", "vgname": "gluster_vg_sdb"}, "msg": "Creating physical volume '/dev/sdb' failed", "rc": 5} > Same thing for sdc, sdd > > Should I manually edit the filters inside the OS, what will be the impact? > > thanks again. > _______________________________________________ > 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/FW3IR3NMQTYZL…

7 19

Gluster rebuild: request suggestions (poor IO performance)
by Jim Kusznir 21 May '19

21 May '19

Hi: I've been having one heck of a time for nearly the entire time I've been running ovirt with disk IO performance. I've tried a variety of things, I've posted to this list for help several times, and it sounds like in most cases the problems are due to design decisions and such. My cluster has been devolving into nearly unusable performance, and I believe its mostly disk IO related. I'm currently using FreeNAS as my primary VM storage (via NFS), but now it too is performing slowly (it started out reasonable, but slowly devolved for unknown reasons). I'm ready to switch back to gluster if I can get specific recommendations as to what I need to do to make it work. I feel like I've been trying random things, and sinking money into this to try and make it work, but nothing has really fixed the problem. I have 3 Dell R610 servers with 750GB SSDs as their primary drive. I had used some Seagate SSHDs, but the internal Dell DRAC raid controller (which had been configured to pass them through as a single disk volume, but still wasn't really JBOD), but it started silently failing them, and causing major issues for gluster. I think the DRAC just doesn't like those HDDs. I can put some real spinning disks in; perhaps a RAID-1 pair of 2TB? These servers only take 2.5" hdd's, so that greatly limits my options. I'm sure others out there are using Dell R610 servers...what do you use for storage? How does it perform? What do I need to do to get this cluster actually usable again? Are PERC-6i storage controllers usable? I'm not even sure where to go troubleshooting now...everything is so sloooowwwww. BTW: I had a small data volume on the SSDs, and the gluster performance on those was pretty poor. performance of the hosted engine is pretty poor still, and it is still on the SSDs.

1 0

Re: Scale out ovirt 4.3 (from 3 to 6 or 9 nodes) with hyperconverged setup and Gluster
by Strahil 21 May '19

21 May '19

> EUREKA: After doing the above I was able to get past the filter issues, however I am still concerned if during a reboot the disks might come up differently. For example /dev/sdb might come up as /dev/sdx... Even if they change , you don't have to worry about as each PV contains LVM metadata (including VG configuration) which is read by LVM on boot (actually everything that is not in the LVM filter is being scanned like that). Once all PVs are available the VG is activated and then the LVs are also activated. > I am trying to make sure this setup is always the same as we want to move this to production, however seems I still don't have the full hang of it and the RHV 4.1 course is way to old :) > > Thanks again for helping out with this. It's a plain KVM with some management layer. Just a hint: Get your HostedEngine's configuration xml from the vdsm log (for emergencies) and another copy with reverse boot order where DVD is booting first. Also get the xml for the ovirtmgmt network. It helped me a lot of times when I wanted to recover my HostedEngine. I'm too lazy to rebuild it. Hint2: Vdsm logs contain each VM's configuration xml when the VMs are powered on. Hint3: Get regular backups of the HostedEngine and patch it from time to time. I would go in prod as follows: Let's say you are on 4.2.8 Next step would be to go to 4.3.latest and then to 4.4.latest . A test cluster (even in VMs ) is also benefitial. Despite the hiccups I have stumbled upon, I think that the project is great. Best Regards, Strahil Nikolov

2 1

Migrating self-HostedEngine from NFS to iSCSI
by Miha Verlic 21 May '19

21 May '19

Hello, I have a few questions regarding migration of HostedEngine. Currently I have a cluster of 3 oVirt 4.3.3 nodes, all three of them are capable of running HE and I can freely migrate HostedEngine and regular VMs between them. However I deployed HostedEngine storage on rather edgy NFS server and I would like to migrate it to iSCSI based storage with multipathing. Quite a few VMs are already running on cluster and are using iSCSI data storage. Documentation is rather chaotic and fragmented, but from what I gathered the path of migration is someting like: - place one host (#1), the "failover" host, into maintenance mode prior to backup - export configuration with engine-backup - set global maintenance mode on all hosts - install ovirt engine on that host (#1) (already installed, since this is HE capable host) - restore engine configuration using engine-backup - run engine-setup with new parameters regarding storage - after engine-setup, log into admin portal and remove old host (#1) - redeploy hosts #2 and #3 Last two steps are a bit confusing as I'm not sure how removing old failover host on which new HE is running would work. Also not understanding the part where hosts 2 and 3 are described as unrecoverable (but with running VMs, which I'd have to live migrate to other hosts - how, if they're not operational?). Few other things: - Should I first remove & re-add host #1 without HE already deployed on host? - Should I set global maintenance mode on all hosts before migration? I'm guessing this is required if I want to prevent HE being started on random host during transition... - Which host should be selected as SPM during the transition phase? - How can I configure iSCSI multipathing? Self-hosted engine documentation mentions Multipath Helper tool, however I cannot find any info about it. Is this tool freely available or only a part od RHEL subscription? - Can I configure existing iSCSI Domain which already hosts some VMs as HE storage? Or do I have to assign extra LUN/target exclusively for HE? Cheers -- Miha

2 1

Re: Scale out ovirt 4.3 (from 3 to 6 or 9 nodes) with hyperconverged setup and Gluster
by Strahil 21 May '19

21 May '19

Thanks for the clarification. It seems that my nvme (used by vdo) is not locked. I will check again before opening a bug. Best Regards, Strahil NikolovOn May 21, 2019 09:52, Sahina Bose <sabose(a)redhat.com> wrote: > > > > On Tue, May 21, 2019 at 2:36 AM Strahil Nikolov <hunter86_bg(a)yahoo.com> wrote: >> >> Hey Sahina, >> >> it seems that almost all of my devices are locked - just like Fred's. >> What exactly does it mean - I don't have any issues with my bricks/storage domains. > > > > If the devices show up as locked - it means the disk cannot be used to create a brick. This is when the disk either already has a filesystem or is in use. > But if the device is a clean device and it still shows up as locked - this could be a bug with how python-blivet/ vdsm reads this > > The code to check is implemented as > _canCreateBrick(device): > if not device or device.kids > 0 or device.format.type or \ > hasattr(device.format, 'mountpoint') or \ > device.type in ['cdrom', 'lvmvg', 'lvmthinpool', 'lvmlv', 'lvmthinlv']: > return False > return True > >> >> Best Regards, >> Strahil Nikolov >> >> В понеделник, 20 май 2019 г., 14:56:11 ч. Гринуич+3, Sahina Bose <sabose(a)redhat.com> написа: >> >> >> To scale existing volumes - you need to add bricks and run rebalance on the gluster volume so that data is correctly redistributed as Alex mentioned. >> We do support expanding existing volumes as the bug https://bugzilla.redhat.com/show_bug.cgi?id=1471031 has been fixed >> >> As to procedure to expand volumes: >> 1. Create bricks from UI - select Host -> Storage Device -> Storage device. Click on "Create Brick" >> If the device is shown as locked, make sure there's no signature on device. If multipath entries have been created for local devices, you can blacklist those devices in multipath.conf and restart multipath. >> (If you see device as locked even after you do this -please report back). >> 2. Expand volume using Volume -> Bricks -> Add Bricks, and select the 3 bricks created in previous step >> 3. Run Rebalance on the volume. Volume -> Rebalance. >> >> >> On Thu, May 16, 2019 at 2:48 PM Fred Rolland <frolland(a)redhat.com> wrote: >>> >>> Sahina, >>> Can someone from your team review the steps done by Adrian? >>> Thanks, >>> Freddy >>>

1 0