- Users - oVirt List Archives

oVirt 4.3.2 Disk extended broken (UI)
by Strahil Nikolov 06 Apr '19

06 Apr '19

Hi, I have just extended the disk of one of my openSuSE VMs and I have noticed that despite the disk is only 140GiB (in UI), the VM sees it as 180GiB. I think that this should not happen at all. [root@ovirt1 ee8b1dce-c498-47ef-907f-8f1a6fe4e9be]# qemu-img info c525f67d-92ac-4f36-a0ef-f8db501102faimage: c525f67d-92ac-4f36-a0ef-f8db501102fafile format: rawvirtual size: 180G (193273528320 bytes)disk size: 71G Attaching some UI screen shots. Note: I have extended the disk via the UI by selecting 40GB (old value in UI -> 100GB). Best Regards,Strahil Nikolov

1 0

errors upgrading ovirt 4.3.1 to 4.3.2
by Jason Keltz 05 Apr '19

05 Apr '19

Hi. I have a few issues after a recent upgrade from 4.3.1 to 4.3.2: 1) Power management is no longer working. I'm using Dell drac7. This has always worked previously. When I click on the "Test" button, I get: "Testing in progress. It will take a few seconds. Please wait" but then it just sits there and never returns. 2) After rekickstarting one of my hosts, when I click on it, and choose "Host Console", I get "Authentication failed: invalid-hostkey". If I click "Try again", I'm taken to a page with "404 - Page not found Click here to continue". The page not found is likely a bug. Now, if I visit cockpit directly on the host via its own URL, it works just fine. Given that I deleted the host and re-added to engine, it's really not clear to me how to tell engine to refresh. I figured after rekickstarting the host, the problem would surely go away, but it did not. 3) From time to time, I am seeing the following error appear in engine: "Uncaught exception occurred. Please try reloading the page. Details: (TypeError): oab (...) is null Please have your administrator check the UI logs". Another bug ... Engine is standalone engine, not hosted. Jason.

1 0

I can't create disk with ovirt 4.3.2
by siovelrm＠gmail.com 05 Apr '19

05 Apr '19

Hello, I just installed ovirt 4.3.2, in Self-Hosted mode, all the same as in previous versions. It happens that when I want to create a disk with a user that is not the admin I get the following error. "Error while executing action Add Disk to VM: Internal Engine Error" This happens to me with all the other users except the admin even when those users are also Super User. Please I need your help. Engine logs say the following 2019-04-05 15: 34: 09,977-04 INFO [org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (default task-13) [37026e0a-92e6-4bfa-9f0f-f052d9eced2d] Running command: AddDiskCommand internal: false. Entities affected: ID: c76a5059-f891-496a-b45f-7ba7ea878ceb Type: StorageAction group CREATE_DISK with role type USER 2019-04-05 15: 34: 10,002-04 WARN [org.ovirt.engine.core.bll.storage.disk.image.AddImageFromScratchCommand] (default task-13) [37026e0a-92e6-4bfa-9f0f-f052d9eced2d] Validation of action 'AddImageFromScratch' failed for user jdoe @ internal-authz. Reasons: VAR__TYPE__STORAGE__DOMAIN, NON_ADMIN_USER_NOT_AUTHORIZED_TO_PERFORM_ACTION_ON_HE 2019-04-05 15: 34: 10,070-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-13) [37026e0a-92e6-4bfa-9f0f-f052d9eced2d] EVENT_ID: USER_FAILED_ADD_DISK (2,023), Add-Disk operation failed (User: jdoe @ internal-authz). 2019-04-05 15: 34: 10,432-04 INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-8) [37026e0a-92e6-4bfa-9f0f-f052d9eced2d] Command ' AddDisk 'id:' 8b10a2b8-3a38-45a4-9c08-7e742eca001b 'child commands' [bcfaa199-dee6-4ae4-9404-9b75cd8e9339]' executions were completed, status' FAILED ' 2019-04-05 15: 34: 11,461-04 ERROR [org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-59) [37026e0a-92e6-4bfa-9f0f- f052d9eced2d] Ending command 'org.ovirt.engine.core.bll.storage.disk.AddDiskCommand' with failure. 2019-04-05 15: 34: 11,471-04 ERROR [org.ovirt.engine.core.bll.storage.disk.image.AddImageFromScratchCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-59) [37026e0a-92e6-4bfa- 9f0f-f052d9eced2d] Ending command 'org.ovirt.engine.core.bll.storage.disk.image.AddImageFromScratchCommand' with failure. 2019-04-05 15: 34: 11,493-04 WARN [org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-59) [] VM is null - not unlocking 2019-04-05 15: 34: 11,523-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-59) [] EVENT_ID: USER_ADD_DISK_FINISHED_FAILURE (2,022), Add-Disk operation failed to complete.

1 0

All hosts non-operational after upgrading from 4.2 to 4.3
by John Florian 05 Apr '19

05 Apr '19

I am in a severe pinch here. A while back I upgraded from 4.2.8 to 4.3.3 and only had one step remaining and that was to set the cluster compat level to 4.3 (from 4.2). When I tried this it gave the usual warning that each VM would have to be rebooted to complete, but then I got my first unusual piece when it then told me next that this could not be completed until each host was in maintenance mode. Quirky I thought, but I stopped all VMs and put both hosts into maintenance mode. I then set the cluster to 4.3. Things didn't want to become active again and I eventually noticed that I was being told the DC needed to be 4.3 as well. Don't remember that from before, but oh well that was easy. However, the DC and SD remains down. The hosts are non-op. I've powered everything off and started fresh but still wind up in the same state. Hosts will look like their active for a bit (green triangle) but then go non-op after about a minute. It appears that my iSCSI sessions are active/logged in. The one glaring thing I see in the logs is this in vdsm.log: 2019-04-05 12:03:30,225-0400 ERROR (monitor/07bb1bf) [storage.Monitor] Setting up monitor for 07bb1bf8-3b3e-4dc0-bc43-375b09e06683 failed (monitor:329) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/monitor.py", line 326, in _setupLoop self._setupMonitor() File "/usr/lib/python2.7/site-packages/vdsm/storage/monitor.py", line 348, in _setupMonitor self._produceDomain() File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 158, in wrapper value = meth(self, *a, **kw) File "/usr/lib/python2.7/site-packages/vdsm/storage/monitor.py", line 366, in _produceDomain self.domain = sdCache.produce(self.sdUUID) File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 110, in produce domain.getRealDomain() File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 51, in getRealDomain return self._cache._realProduce(self._sdUUID) File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 134, in _realProduce domain = self._findDomain(sdUUID) File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 151, in _findDomain return findMethod(sdUUID) File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 176, in _findUnfetchedDomain raise se.StorageDomainDoesNotExist(sdUUID) StorageDomainDoesNotExist: Storage domain does not exist: (u'07bb1bf8-3b3e-4dc0-bc43-375b09e06683',) How do I proceed to get back operational?

3 4

Re: All hosts non-operational after upgrading from 4.2 to 4.3
by John Florian 05 Apr '19

05 Apr '19

This is sn iscsi storage domain. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

1 0

Re: Hosted-Engine constantly dies
by Strahil 05 Apr '19

05 Apr '19

Hi Simone, > According to gluster administration guide: > https://docs.gluster.org/en/latest/Administrator%20Guide/Network%20Configur… > > in the "when to bond" section we can read: > network throughput limit of client/server \<\< storage throughput limit > > 1 GbE (almost always) > 10-Gbps links or faster -- for writes, replication doubles the load on the network and replicas are usually on different peers to which the client can transmit in parallel. > > So if you are using oVirt hyper-converged in replica 3 you have to transmit everything two times over the storage network to sync it with other peers. > > I'm not really in that details, but if https://bugzilla.redhat.com/1673058 is really like it's described, we even have an 5x overhead with current gluster 5.x. > > This means that with a 1000 Mbps nic we cannot expect more than: > 1000 Mbps / 2 (other replicas) / 5 (overhead in Gluster 5.x ???) / 8 (bit per bytes) = 12.5 MByte per seconds and this is definitively enough to have sanlock failing especially because we don't have just the sanlock load as you can imagine. > > I'd strongly advice to move to 10 Gigabit Ethernet (nowadays with a few hundred dollars you can buy a 4/5 ports 10GBASE-T copper switch plus 3 nics and the cables just for the gluster network) or to bond a few 1 Gigabit Ethernet links. I didn't know that. So , with 1 Gbit network everyone should use replica 3 arbiter 1 volumes to minimize replication traffic. Best Regards, Strahil Nikolov

1 0

VM bandwidth limitations
by John Florian 05 Apr '19

05 Apr '19

In my oVirt deployment at home, I'm trying to minimize the amount of physical HW and its 24/7 power draw. As such I have the NFS server for my domain virtualized. This is not used for oVirt's SD, but rather the NFS server's back-end storage comes from oVirt's SD. To maximize the performance of my NFS server, do I still need to use bonded NICs to increase bandwidth like I would a physical server or does the VirtIO-SCSI stuff magically make this unnecessary? In my head I can argue it both ways, but have never seen it stated one way or the other, oddly. -- John Florian

3 5

Hosted-Engine constantly dies
by Strahil Nikolov 05 Apr '19

05 Apr '19

Hi Guys, As I'm still quite new in oVirt - I have some problems finding the problem on this one.My Hosted Engine (4.3.2) is constantly dieing (even when the Global Maintenance is enabled).My interpretation of the logs indicates some lease problem , but I don't get the whole picture ,yet. I'm attaching the output of 'journalctl -f | grep -Ev "Started Session|session opened|session closed"' after I have tried to power on the hosted engine (hosted-engine --vm-start). The nodes are fully updated and I don't see anything in the gluster v5.5 logs, but I can double check. Any hints are appreciated and thanks in advance. Best Regards,Strahil Nikolov

2 10

oVirt 4.3.2 Importing VMs from a detached domain not keeping cluster info
by Strahil Nikolov 05 Apr '19

05 Apr '19

Hello, can someone tell me if this is an expected behaviour: 1. I have created a data storage domain exported by nfs-ganesha via NFS2. Stop all VMs on the Storage domain 3. Set to maintenance and detached (without wipe) the storage domain3.2 All VMs are gone (which was expected)4. Imported the existing data domain via Gluster5. Wen to the Gluster domain and imported all templates and VMs5.2 Power on some of the VMs but some of them failed The reason for failure is that some of the re-imported VMs were automatically assigned to the Default Cluster , while they belonged to another one. Most probably this is not a supported activity, but can someone clarify it ? Thanks in advance. Best Regards,Strahil Nikolov

1 0

Upgrade 3.5 to 4.3
by Demeter Tibor 05 Apr '19

05 Apr '19

Hi All, I did began a very big project, I've started upgrade a cluster from 3.5 to 4.3... It was a mistake:( Since upgrade, I can't start the host. The UI seems to working fine. [root@virt ~]# service vdsm-network start Redirecting to /bin/systemctl start vdsm-network.service Job for vdsm-network.service failed because the control process exited with error code. See "systemctl status vdsm-network.service" and "journalctl -xe" for details. [root@virt ~]# service vdsm-network status Redirecting to /bin/systemctl status vdsm-network.service ● vdsm-network.service - Virtual Desktop Server Manager network restoration Loaded: loaded (/usr/lib/systemd/system/vdsm-network.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2019-04-04 15:03:44 CEST; 6s ago Process: 19325 ExecStart=/usr/bin/vdsm-tool restore-nets (code=exited, status=1/FAILURE) Process: 19313 ExecStartPre=/usr/bin/vdsm-tool --vvverbose --append --logfile=/var/log/vdsm/upgrade.log upgrade-unified-persistence (code=exited, status=0/SUCCESS) Main PID: 19325 (code=exited, status=1/FAILURE) Apr 04 15:03:44 virt.bolax.hu vdsm-tool[19325]: return tool_command[cmd]["command"](*args) Apr 04 15:03:44 virt.bolax.hu vdsm-tool[19325]: File "/usr/lib/python2.7/site-packages/vdsm/tool/restore_nets.py", line 41, in restore_command Apr 04 15:03:44 virt.bolax.hu vdsm-tool[19325]: exec_restore(cmd) Apr 04 15:03:44 virt.bolax.hu vdsm-tool[19325]: File "/usr/lib/python2.7/site-packages/vdsm/tool/restore_nets.py", line 54, in exec_restore Apr 04 15:03:44 virt.bolax.hu vdsm-tool[19325]: raise EnvironmentError('Failed to restore the persisted networks') Apr 04 15:03:44 virt.bolax.hu vdsm-tool[19325]: EnvironmentError: Failed to restore the persisted networks Apr 04 15:03:44 virt.bolax.hu systemd[1]: vdsm-network.service: main process exited, code=exited, status=1/FAILURE Apr 04 15:03:44 virt.bolax.hu systemd[1]: Failed to start Virtual Desktop Server Manager network restoration. Apr 04 15:03:44 virt.bolax.hu systemd[1]: Unit vdsm-network.service entered failed state. Apr 04 15:03:44 virt.bolax.hu systemd[1]: vdsm-network.service failed. Since, the host does not start. Apr 04 14:56:00 virt.bolax.hu libvirtd[17705]: 2019-04-04 12:56:00.764+0000: 17705: error : virNetSocketReadWire:1806 : End of file while reading data: Input/output error Apr 04 14:56:00 virt.bolax.hu libvirtd[17705]: 2019-04-04 12:56:00.965+0000: 17709: error : virNetSASLSessionListMechanisms:393 : internal error: cannot list SASL ...line 1757) Apr 04 14:56:00 virt.bolax.hu libvirtd[17705]: 2019-04-04 12:56:00.966+0000: 17709: error : remoteDispatchAuthSaslInit:3440 : authentication failed: authentication failed Apr 04 14:56:00 virt.bolax.hu libvirtd[17705]: 2019-04-04 12:56:00.966+0000: 17705: error : virNetSocketReadWire:1806 : End of file while reading data: Input/output error Apr 04 14:56:01 virt.bolax.hu libvirtd[17705]: 2019-04-04 12:56:01.167+0000: 17710: error : virNetSASLSessionListMechanisms:393 : internal error: cannot list SASL ...line 1757) Apr 04 14:56:01 virt.bolax.hu libvirtd[17705]: 2019-04-04 12:56:01.167+0000: 17710: error : remoteDispatchAuthSaslInit:3440 : authentication failed: authentication failed [root@virt ~]# service vdsm-network status Redirecting to /bin/systemctl status vdsm-network.service ● vdsm-network.service - Virtual Desktop Server Manager network restoration Loaded: loaded (/usr/lib/systemd/system/vdsm-network.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2019-04-04 15:00:39 CEST; 2min 49s ago Process: 19079 ExecStart=/usr/bin/vdsm-tool restore-nets (code=exited, status=1/FAILURE) Process: 19045 ExecStartPre=/usr/bin/vdsm-tool --vvverbose --append --logfile=/var/log/vdsm/upgrade.log upgrade-unified-persistence (code=exited, status=0/SUCCESS) Main PID: 19079 (code=exited, status=1/FAILURE) Also, I upgraded to until 4.0 , but it seems to same. I cant reinstall, and reactivate the host. Originally it was an AIO installation. Please help me solve this problem. Thanks in advance, R Tibor

3 2