- Devel - oVirt List Archives

Problems with iso domain
by Richard Chapman 17 Jul '18

17 Jul '18

Hi, I've got a problem trying to 'import or create the ISO domain. My setup. - Everything is CentOS 7.4 minimal iso using oVirt 4.2.latest I have one box which I installed just the engine to (Not a hosted engine). It never asked me to create the iso domain as part of engine-setup as the install instructions outlines. I have reinstalled both OS and engine more than 8 times (due to other issues I've worked around) and each time I'm never asked. So I have 7 hosts how all registered with the engine but now I'm trying to create/import an iso domain. I'm hosting a number of storage domains on one of the hosts and I can register in those data domain without any problems however when I import an iso domain using a nfs (I through I read the iso domain should be created if it's not there) path I get "There is no storage domain under the specified path. Check event pane for more details." a) Nothing appears in the event pane and b) looking through engine.log it appears that the engine is querying the host for the iso domain and failing it. So my question is how do I in fact create an iso domain? Help? Chapman....

1 0

Fwd: [CentOS-announce] Announcing the release of Gluster 4.1 on CentOS Linux 7 x86_64
by Sandro Bonazzola 17 Jul '18

17 Jul '18

Hi, as you can read below Gluster 4.1 LTM release is available in CentOS. We are currently using 3.12 in oVirt 4.2 but this release is going EOL in 6 months. I would suggest to move 4.3 / Master to Gluster 4.1 now. Any objection? If no objection I will start pushing patches for it on Monday, July 16th. ---------- Forwarded message ---------- From: Niels de Vos <ndevos(a)redhat.com> Date: 2018-06-27 16:42 GMT+02:00 Subject: [CentOS-announce] Announcing the release of Gluster 4.1 on CentOS Linux 7 x86_64 To: centos-announce(a)centos.org I am happy to announce the General Availability of Gluster 4.1 for CentOS 7 on x86_64. These packages are following the upstream Gluster Community releases, and will receive monthly bugfix updates. Gluster 4.1 is a Long-Term-Maintenance release, and will receive updates for approximately 18 months. The difference between Long-Term-Maintenance and Short-Term-Maintenance releases is explained on the Gluster release schedule page: https://www.gluster.org/community/release-schedule/ Users of CentOS 7 can now simply install Gluster 4.1 with only these two commands: # yum install centos-release-gluster # yum install glusterfs-server The centos-release-gluster package is delivered via CentOS Extras repos. This contains all the metadata and dependency information, needed to install Gluster 4.1. The actual package that will get installed is centos-release-gluster41. Users of the now End-Of-Life Short-Term-Maintenance Gluster 4.0 will automatically get the update to Gluster 4.1, whereas users of Gluster 3.12 can stay on that Long-Term-Maintenance release for an other six months. Users of Gluster 3.10 will need to manually upgrade by uninstalling the centos-release-gluster310 package, and replacing it with either the Gluster 4.1 or 3.12 version. Additional details about the upgrade process are linked in the announcement from the Gluster Community: https://lists.gluster.org/pipermail/announce/2018-June/000102.html We have a quickstart guide specifically built around the packages are available, it makes for a good introduction to Gluster and will help get you started in just a few simple steps, this quick start is available at https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart More details about the packages that the Gluster project provides in the Storage SIG is available in the documentation: https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster The centos-release-gluster* repositories offer additional packages that enhance the usability of Gluster itself. Utilities and tools that were working with previous versions of Gluster are expected to stay working fine. If there are any problems, or requests for additional tools and applications to be provided, just send us an email with your suggestions. The current list of packages that is (planned to become) available can be found here: https://wiki.centos.org/SpecialInterestGroup/Storage/ Gluster/Ecosystem-pkgs We welcome all feedback, comments and contributions. You can get in touch with the CentOS Storage SIG on the centos-devel mailing list (https://lists.centos.org ) and with the Gluster developer and user communities at https://www.gluster.org/mailman/listinfo , we are also available on irc at #gluster on irc.freenode.net, and on twitter at @gluster . Cheers, Niels de Vos Storage SIG member & Gluster maintainer _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

3 3

ovirt-system-tests_he-basic-iscsi-suite-master fails due to timeout waiting for StoragePool to go up after vdsmd restart
by Sandro Bonazzola 16 Jul '18

16 Jul '18

Failing job is: https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-iscsi-suite-maste… My findings: 2018-07-06 03:28:05,461::008_restart_he_vm.py::_shutdown_he_vm::123::root::INFO:: * VM is down. 2018-07-06 03:28:05,461::008_restart_he_vm.py::_restart_services::127::root::INFO:: * Restarting services... 2018-07-06 03:28:05,729::log_utils.py::__exit__::611::lago.ssh::DEBUG::end task:f7db7960-b541-4d18-9a73-45b3d0677f03:Get ssh client for lago-he-basic-iscsi-suite-master-host-0: 2018-07-06 03:28:06,031::ssh.py::ssh::58::lago.ssh::DEBUG::Running 98d0de9e on lago-he-basic-iscsi-suite-master-host-0: systemctl restart vdsmd ovirt-ha-broker ovirt-ha-agent 2018-07-06 03:28:22,887::ssh.py::ssh::81::lago.ssh::DEBUG::Command 98d0de9e on lago-he-basic-iscsi-suite-master-host-0 returned with 0 it then waits for engine to be up again till it gives up 10 minutes later: 2018-07-06 03:38:20,979::log_utils.py::__enter__::600::lago.ssh::DEBUG::start task:f44bb656-dfe3-4f57-a6c8-e7e208863054:Get ssh client for lago-he-basic-iscsi-suite-master-host-0: 2018-07-06 03:38:21,290::log_utils.py::__exit__::611::lago.ssh::DEBUG::end task:f44bb656-dfe3-4f57-a6c8-e7e208863054:Get ssh client for lago-he-basic-iscsi-suite-master-host-0: 2018-07-06 03:38:21,591::ssh.py::ssh::58::lago.ssh::DEBUG::Running 07b7f08a on lago-he-basic-iscsi-suite-master-host-0: hosted-engine --vm-status 2018-07-06 03:38:21,637::ssh.py::ssh::81::lago.ssh::DEBUG::Command 07b7f08a on lago-he-basic-iscsi-suite-master-host-0 returned with 1 2018-07-06 03:38:21,637::ssh.py::ssh::89::lago.ssh::DEBUG::Command 07b7f08a on lago-he-basic-iscsi-suite-master-host-0 output: The hosted engine configuration has not been retrieved from shared storage. Please ensure that ovirt-ha-agent is running and the storage server is reachable. On host 0, vdsm.log shows it's restarting: 2018-07-05 23:28:19,646-0400 INFO (MainThread) [vds] Exiting (vdsmd:171) 2018-07-05 23:28:23,514-0400 INFO (MainThread) [vds] (PID: 19942) I am the actual vdsm 4.30.0-465.git1ad18aa.el7 lago-he-basic-iscsi-suite-master-host-0 (3.10.0-862.2.3.el7.x86_64) (vdsmd:149) vdsm then stays for the 10 minutes above mentioned waiting for the storage pool to go up: 2018-07-05 23:38:20,739-0400 INFO (vmrecovery) [vds] recovery: waiting for storage pool to go up (clientIF:704) while the ha agent try to get the hosted engine stats 2018-07-05 23:38:30,363-0400 WARN (vdsm.Scheduler) [Executor] Worker blocked: <Worker name=jsonrpc/7 running <Task <JsonRpcTask {'params': {}, 'jsonrpc': '2.0', 'method': u'Host.getStats', 'id': u'cddde340-37a8-4f72-a471-b5bc40c06a16'} at 0x7f262814ae90> timeout=60, duration=600.00 at 0x7f262815c050> task#=0 at 0x7f262834b810>, traceback: File: "/usr/lib64/python2.7/threading.py", line 785, in __bootstrap self.__bootstrap_inner() File: "/usr/lib64/python2.7/threading.py", line 812, in __bootstrap_inner self.run() File: "/usr/lib64/python2.7/threading.py", line 765, in run self.__target(*self.__args, **self.__kwargs) File: "/usr/lib/python2.7/site-packages/vdsm/common/concurrent.py", line 195, in run ret = func(*args, **kwargs) File: "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 301, in _run self._execute_task() File: "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 315, in _execute_task task() File: "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 391, in __call__ self._callable() File: "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 261, in __call__ self._handler(self._ctx, self._req) File: "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 304, in _serveRequest response = self._handle_request(req, ctx) File: "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 344, in _handle_request res = method(**params) File: "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line 202, in _dynamicMethod result = fn(*methodArgs) File: "<string>", line 2, in getStats File: "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 49, in method ret = func(*args, **kwargs) File: "/usr/lib/python2.7/site-packages/vdsm/API.py", line 1409, in getStats multipath=True)} File: "/usr/lib/python2.7/site-packages/vdsm/host/api.py", line 78, in get_stats ret['haStats'] = _getHaInfo() File: "/usr/lib/python2.7/site-packages/vdsm/host/api.py", line 176, in _getHaInfo stats = instance.get_all_stats() File: "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", line 94, in get_all_stats stats = broker.get_stats_from_storage() File: "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", line 135, in get_stats_from_storage result = self._proxy.get_stats() File: "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__ return self.__send(self.__name, args) File: "/usr/lib64/python2.7/xmlrpclib.py", line 1591, in __request verbose=self.__verbose File: "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request return self.single_request(host, handler, request_body, verbose) File: "/usr/lib64/python2.7/xmlrpclib.py", line 1303, in single_request response = h.getresponse(buffering=True) File: "/usr/lib64/python2.7/httplib.py", line 1113, in getresponse response.begin() File: "/usr/lib64/python2.7/httplib.py", line 444, in begin version, status, reason = self._read_status() File: "/usr/lib64/python2.7/httplib.py", line 400, in _read_status line = self.fp.readline(_MAXLINE + 1) File: "/usr/lib64/python2.7/socket.py", line 476, in readline data = self._sock.recv(self._rbufsize) (executor:363) Andrej, I see the test has been added by you in commit e8d32f7375f2033b73544f47c1e1ca67abe8d35a I'm not sure about the purpose of this test but I don't understand why we are restarting the services on the host. Nir, Tal, any idea on why the storage pool is not getting up? I see vdsm is in recovery mode, I'm not sure if this was what the test was supposed to do or if the intention was to cleanly shutdown vdsm and cleanly restart it. -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

4 3

Re: [Spice-devel] Ongoing migration: gitlab.com/spice -> gitlab.freedesktop.org/spice
by Victor Toso 16 Jul '18

16 Jul '18

Hi, JFYI, CC'ing: * qemu-devel * virt-tools-list * devel(a)ovirt.org If nobody complains, I'll finish whatever is pending next Monday morning (GMT+2). Cheers, toso On Thu, Jul 12, 2018 at 02:12:43PM +0200, Victor Toso wrote: > Hi, > > The official repository for Spice components should stay in > gitlab.freedesktop.org/spice - As suggested in the previous > thread [0], instead of closing gitlab.com/spice we can keep it > read-only mirror from Freedesktop's gitlab instance. > > [0] https://lists.freedesktop.org/archives/spice-devel/2018-July/044664.html > > Please, read the email below to see what's going on :) > > At this moment, I've only changed components that were already a > mirror of gitlab.freedesktop.org, the first part of this email is > about the projects that are not a mirror. > > This email's intent is to inform, discuss and give some time to > let contributors know about the change. People CC'ed are to be > affected. > > [*] Components to be created in gitlab.freedesktop.org/spice and > mirrored from there. > > * https://gitlab.com/spice/x11spice > * https://gitlab.com/spice/spice-space > * https://gitlab.com/spice/spice-space-pages > * https://gitlab.com/spice/spice-streaming-agent > > * https://gitlab.com/spice/virtio-gpu-wddm/virtio-gpu-wddm-dod > - Taking the opportunity, should we move this under win32 > subgroup or create the virtio-gpu-wddm subgroup once more? > - Migrate issue #1 > > * https://gitlab.com/spice/qxl-wddm-dod > - Update and mirror from https://gitlab.freedesktop.org/spice/win32/qxl-wddm-dod > - The mirrored in gitlab will also be moved into win32 subgroup > > * https://gitlab.com/spice/spice-nsis > - Update and mirror from https://gitlab.freedesktop.org/spice/spice-nsis > - Should we also include under win32 subgroup or stay outside? > > [*] Components I'm ignoring on this mirroring due too old or > untouched or unrelated (qemu?) code > > * win32/usbclerk > * win32/vdi_port > * qemu > * slirp > * spicec > * vdesktop > > > [*] Components that are already mirrored, some updates around > them below: > > * The mirrored components will be always overwritten when > branches diverge, please don't push to gitlab.com - about > read-only option: > - https://gitlab.com/gitlab-org/gitlab-ce/issues/40891 > > * Added common description: "Read only repository, mirror from > Freedesktop's instance of Gitlab" > > * General permissions > - Visibility: Public > - Issues, Merge request, Wiki, etc: Disabled > > No problems seen: > * spice [ https://gitlab.com/spice/spice ] > * spice-protocol [ https://gitlab.com/spice/spice-protocol ] > * spice-common [ https://gitlab.com/spice/spice-common ] > * usbredir [ https://gitlab.com/spice/usbredir ] > * spice-jhbuild [ https://gitlab.com/spice/spice-jhbuild ] > * spice-html5 [ https://gitlab.com/spice/spice-html5 ] > * libcacard [ https://gitlab.com/spice/libcacard ] > > Small problem but fixed: > * Spice-gtk [ https://gitlab.com/spice/spice-gtk ] > - I had to delete and mirror again due some ongoing failure to > pull from freedesktop.org > > * linux/vd_agent [ https://gitlab.com/spice/linux/vd_agent ] > - I had to create the linux subgroup and clone a new instance > - removed spice/vdagent one (previous) > > * win32/vd_agent [ https://gitlab.com/spice/win32/vd_agent ] > - I had to create the win32 subgroup and clone a new instance > - removed spice/vdagent-win (previous) > > * win32/usbdk [ https://gitlab.com/spice/win32/usbdk ] > - Moved to win32 subgroup (delete + clone again) > - removed spice/usbdk (previous) > > * win32/qxl [ https://gitlab.com/spice/win32/qxl ] > - Moved to win32 subgroup (delete + clone again) > - removed spice/qxl-win (previous) > > I hope all is good to have everything migrated early next week :) > PS: Let me know if I forgot something. > > Cheers, > toso > _______________________________________________ > Spice-devel mailing list > Spice-devel(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/spice-devel

1 1

Build fail stopping docker containers
by Nir Soffer 15 Jul '18

15 Jul '18

Seen this failure today: *16:16:05* Stopping and removing all running containers*16:16:05* Stopping and removing name=unnamed, id=b1d61f20b7fd4746ed83f308ab292b1d53a02de2271965268890b35c1344da04*16:16:40* Stopping and removing name=unnamed, id=22a8ace28d96e469bfc8177ee6afb52d6ca7b4578c27475c92862465253caa2b*16:17:16* Stopping and removing name=unnamed, id=5bab561632b6c179446df56dd3aadf10402989047564202f86c6b3989551820c*16:17:28* Stopping and removing name=unnamed, id=4c04d87ec8b55a774c9e6558a814b944d665b4c0984d6677972285209c5eea7c*16:17:41* Stopping and removing name=unnamed, id=5b40e3237c00cb56897b75fbac500d22b81e53894683ff1a872e4f9e4a48fc1d*16:17:41* Traceback (most recent call last):*16:17:41* File "/home/jenkins/workspace/ovirt-imageio_4.2_check-patch-el7-x86_64/jenkins/scripts/docker_cleanup.py", line 290, in <module>*16:17:41* main()*16:17:41* File "/home/jenkins/workspace/ovirt-imageio_4.2_check-patch-el7-x86_64/jenkins/scripts/docker_cleanup.py", line 34, in main*16:17:41* stop_all_running_containers(client)*16:17:41* File "/home/jenkins/workspace/ovirt-imageio_4.2_check-patch-el7-x86_64/jenkins/scripts/docker_cleanup.py", line 125, in stop_all_running_containers*16:17:41* _remove_container(client, container)*16:17:41* File "/home/jenkins/workspace/ovirt-imageio_4.2_check-patch-el7-x86_64/jenkins/scripts/docker_cleanup.py", line 152, in _remove_container*16:17:41* client.stop(container)*16:17:41* File "/usr/lib/python2.7/site-packages/docker/utils/decorators.py", line 21, in wrapped*16:17:41* return f(self, resource_id, *args, **kwargs)*16:17:41* File "/usr/lib/python2.7/site-packages/docker/api/container.py", line 403, in stop*16:17:42* self._raise_for_status(res)*16:17:42* File "/usr/lib/python2.7/site-packages/docker/client.py", line 173, in _raise_for_status*16:17:42* raise errors.NotFound(e, response, explanation=explanation)*16:17:42* docker.errors.NotFound: 404 Client Error: Not Found ("{"message":"No such container: 5b40e3237c00cb56897b75fbac500d22b81e53894683ff1a872e4f9e4a48fc1d"}") Looks like we need to handle docker.errors.NotFound - it is expected error. https://jenkins.ovirt.org/job/ovirt-imageio_4.2_check-patch-el7-x86_64/551/… Nir

3 3

blog on asking questions
by Greg Sheremeta 13 Jul '18

13 Jul '18

wanted to share :) "Software folk are very good at putting their headphones on and living in their own little bubbles. This reinforces the idea that software development is some sort of mythical or sacred practice that should never be interrupted, and it makes people second guess whether they should ask for help. This isn’t what you want in a team. You want people to be comfortable asking for help – that can be the difference between a successful & productive team who ask for help as soon as they’re stuck, and an unproductive team who struggle with their work in silence." from https://wildlyinaccurate.com/becoming-a-team-lead-a-survival-guide/ I love helping everyone, and I know most people love to help, but my usual first reaction to needing help is to resist asking. After 5 years on the team I'm starting to get more comfortable lol :) -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>

2 2

Error adding host to ovirt-engine in local development environment
by Kaustav Majumder 13 Jul '18

13 Jul '18

Hi, I am trying to setup ovirt engine dev environment in my local Fedora 28 machine.I have followed this guide -> https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob_plain;f=README.ad… When I am trying to add a new host (Centos 7) ,it is failing with the following error. [35eb76d9] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing Host 10.70.43.157. Connected to host 10.70.43.157 with SSH key fingerprint: SHA256:rZfUGylVh3PLqfH2Siey0+CA9RUctK2ITQ2UGtV5ggA. 2018-07-10 15:47:50,447+05 INFO [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (EE-ManagedThreadFactory-engine-Thread-4188) [35eb76d9] Installation of 10.70.43.157. Executing command via SSH umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar --warning=no-timestamp -C "${MYTMP}" -x && "${MYTMP}"/ovirt-host-deploy DIALOG/dialect=str:machine DIALOG/customization=bool:True < /home/kaustavmajumder/work/ovirt-engine-builds/07-07/var/cache/ovirt-engine/ovirt-host-deploy.tar 2018-07-10 15:47:50,447+05 INFO [org.ovirt.engine.core.utils.archivers.tar.CachedTar] (EE-ManagedThreadFactory-engine-Thread-4188) [35eb76d9] Tarball '/home/kaustavmajumder/work/ovirt-engine-builds/07-07/var/cache/ovirt-engine/ovirt-host-deploy.tar' refresh 2018-07-10 15:47:50,471+05 INFO [org.ovirt.engine.core.uutils.ssh.SSHDialog] (EE-ManagedThreadFactory-engine-Thread-4188) [35eb76d9] SSH execute 'root(a)10.70.43.157' 'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar --warning=no-timestamp -C "${MYTMP}" -x && "${MYTMP}"/ovirt-host-deploy DIALOG/dialect=str:machine DIALOG/customization=bool:True' 2018-07-10 15:47:50,676+05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [35eb76d9] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during installation of Host 10.70.43.157: Python is required but missing. 2018-07-10 15:47:50,685+05 ERROR [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy) [35eb76d9] Error during deploy dialog 2018-07-10 15:47:50,686+05 ERROR [org.ovirt.engine.core.uutils.ssh.SSHDialog] (EE-ManagedThreadFactory-engine-Thread-4188) [35eb76d9] SSH error running command root(a)10.70.43.157:'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar --warning=no-timestamp -C "${MYTMP}" -x && "${MYTMP}"/ovirt-host-deploy DIALOG/dialect=str:machine DIALOG/customization=bool:True': IOException: Command returned failure code 1 during SSH session 'root(a)10.70.43.157' 2018-07-10 15:47:50,690+05 ERROR [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (EE-ManagedThreadFactory-engine-Thread-4188) [35eb76d9] Error during host 10.70.43.157 install 2018-07-10 15:47:50,697+05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-4188) [35eb76d9] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during installation of Host 10.70.43.157: Command returned failure code 1 during SSH session 'root(a)10.70.43.157'. 2018-07-10 15:47:50,698+05 ERROR [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (EE-ManagedThreadFactory-engine-Thread-4188) [35eb76d9] Error during host 10.70.43.157 install, preferring first exception: Unexpected connection termination 2018-07-10 15:47:50,698+05 ERROR [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-4188) [35eb76d9] Host installation failed for host '3a52f700-a1d3-47b0-9518-f7f94231a874', '10.70.43.157': Unexpected connection termination 2018-07-10 15:47:50,700+05 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (EE-ManagedThreadFactory-engine-Thread-4188) [35eb76d9] START, SetVdsStatusVDSCommand(HostName = 10.70.43.157, SetVdsStatusVDSCommandParameters:{hostId='3a52f700-a1d3-47b0-9518-f7f94231a874', status='InstallFailed', nonOperationalReason='NONE', stopSpmFailureLogged='false', maintenanceReason='null'}), log id: 48d6c653 2018-07-10 15:47:50,704+05 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (EE-ManagedThreadFactory-engine-Thread-4188) [35eb76d9] FINISH, SetVdsStatusVDSCommand, return: , log id: 48d6c653 2018-07-10 15:47:50,710+05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-4188) [35eb76d9] EVENT_ID: VDS_INSTALL_FAILED(505), Host 10.70.43.157 installation failed. Unexpected connection termination. I have tried installing it several times and it has failed. Thanks, Kaustav

4 15

Adding a supported distro
by bob.bownes＠oracle.com 12 Jul '18

12 Jul '18

dumb q. I have a distro I'd like to add to the supported list. (private labeled version of a rhel 7.5) I tried grabbing an unclaimed ID, putting that plus the output of osinfo-query —fields=name os short-id='my_shortid' and derivedFrom.value= well_known_distro into osinfo-defaults.properties and restarting ovirt-engine, but I still come up with install failed because '$MYNAME' is not supported. Am I missing something obvious? Entry looks like this: os.my_7x86.id.value = 34 os.my_7x86.name.value = My Linux 7.5 os.my_7x86.derivedFrom.value = rhel_6x64 ideas? Thanks!

4 6

ovirt-system-tests_he-node-ng-suite-master is failing on not enough memory to run VMs
by Sandro Bonazzola 10 Jul '18

10 Jul '18

https://jenkins.ovirt.org/job/ovirt-system-tests_he-node-ng-suite-master/16… Cannot run VM. There is no host that satisfies current scheduling constraints. See below for details:, The host lago-he-node-ng-suite-master-host-0 did not satisfy internal filter Memory because its available memory is too low (656 MB) to run the VM. -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

4 3

[CQ Failure Report] [oVirt Master ovirt-engine-wildfly] [3/7/18] [ovirt-system-tests_basic-suite-master_deploy-scripts_setup_engine.sh]
by Ehud Yonasi 09 Jul '18

09 Jul '18

Suspected patch: https://gerrit.ovirt.org/#/c/91555/ Link to job: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8542/ Link to all logs: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8542/artifact… Relevant error snippet: Error: ovirt-engine-wildfly-overlay conflicts with ovirt-engine-wildfly-13.0.0-1.el7.x86_64

5 14