[ovirt-users] Major screwup and now I can't bring anything up
I have a small home oVirt 4.5 deployment that was struggling a bit and I think I've only made things worse. I was seeing some SSL errors in various places but couldn't find any evidence of an expired cert though maybe I overlooked something. At present, it looks like the most immediate problem is that the engine.log is showing SyncNetworkProviderCommand fails saying EngineException: (Failed with error Unsupported or unrecognized SSL message and code 5050). For now, I'm only concerning myself to one Host that had been running VMs until I tried restarting everything from a power off. I take it that the sync failure prevents this Host from becoming active. I had successfully been using this setup for many years. I do have my own web cert on the engine signed by my CA. While I was getting this same "code 5050" error before with things like ovirt-imageio (what prompted my initial digging), now I'm afraid I've only made things more complex. See, I was running FreeIPA on a pair of VMs. In the past, this pair of VMs would auto-start once the oVirt Engine and Hosts were going and I had no issue. But now I wonder to what extent OSCP being unreachable might affect the SSL errors. What's the best/easiest/safest way out of this mess? Should I just wipe ovirt-engine of all the non-rpm provided files in /etc/pki/ovirt-engine/ and redo the engine-setup? I'm afraid of making things worse before I begin attempting that. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/WLRBA2EXHCC7V6HZM35UDH25MBPXSIOC/
[ovirt-users] Re: New virtual machine default properties
I was going to suggest Compute > Templates > Blank > Edit even though I figured that wouldn't allow editing and then was going to suggest making a derivative with the needed edits. Editing the Blank template is possible but you only get to choose how many monitors your console gets, not the emulated video card type. Checking another not-special template gave me no further options, so I'm stumped with you on this one. I would guess the property you seek is either read-only and not shown with the other base template details or is merged from another source. Good luck! John Florian On 2022-03-04 03:40, ravi k wrote: Hello, We are currently using oVirt version 4.3.10.4-1.0.22.el7. When we click on create new VM, the OS is selected as "other OS" and "optimized for" is desktop. I'm creating the VMs from Ansible. The problem is that the "video type" is defaulting to QXL due to which the VM is failing to start with an error " Exit message: unsupported configuration: this QEMU does not support 'qxl' video device." It used to default to VGA earlier because this playbook was working earlier. So I'm guessing some config would've been changed which is causing this. But I was not able to find where this default config is set. Can you please help? I checked to see if I can set it in the Ansible playbook. But Ansible's ovirt_vm module only provides headless_mode and protocol options. It would be nice if it provided the video type parameter as well. Is there any config file in the engine that I can tweak to set the default values for a new VM creation? Regards, Ravi ___ Users mailing list --users@ovirt.org To unsubscribe send an email tousers-le...@ovirt.org Privacy Statement:https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct:https://www.ovirt.org/community/about/community-guidelines/ List Archives:https://lists.ovirt.org/archives/list/users@ovirt.org/message/SCGRB67GVOW4TJ62Z5OQVPG566JXI4T7/___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/Q5ZG5FCX2IHCDKKMXHEHC5TSHEE7GG3F/
[ovirt-users] Re: Multiple dependencies unresolved
Ok, thanks for the info. I'm guessing the solution is to make ovirt-hosted-engine-setup compatible with ansible > 2.10.0 (or at least 2.12.2) so that c8s hosts can just upgrade to their newer ansible. I don't see a BZ for this filed against ovirt-hosted-engine-setup, so maybe few even know about this issue? John Florian On 2022-03-03 15:41, Klaas Demter wrote: As far as I know there is no solution yet, but the "problem" is not with the ovirt-release repos, c8s now ships ansible (in a version that is not tested with ovirt), c8s did not do that in past :) On 3/3/22 20:25, John Florian wrote: So that explains what happened but we still don't have a solution to make this go away, correct? FTR, I did try `dnf reinstall --disablerepo='*' https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm` but things are no different afterwards. John Florian On 2022-03-03 11:37, Klaas Demter wrote: https://lists.ovirt.org/archives/list/users@ovirt.org/message/OANKECW6C4SM6USKJP7DJIAHUN5RALFI/ On 3/3/22 17:20, John Florian wrote: FWIW, I'm getting what appears to be the same dependency errors on my oVirt Hosts that were installed new on C8S not all that long ago. I have to do upgrades manually with `dnf upgrade --no-best` otherwise I get: [root@orthosie ~]# dnf upgrade Last metadata expiration check: 1:24:59 ago on Thu 03 Mar 2022 09:52:40 AM EST. Error: Problem: package cockpit-ovirt-dashboard-0.15.1-1.el8.noarch requires ansible, but none of the providers can be installed - package ansible-2.9.27-2.el8.noarch conflicts with ansible-core > 2.11.0 provided by ansible-core-2.12.2-2.el8.x86_64 - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.27-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.27-1.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.17-1.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.18-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.20-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.21-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.23-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.24-2.el8.noarch - cannot install the best update candidate for package cockpit-ovirt-dashboard-0.15.1-1.el8.noarch - cannot install the best update candidate for package ansible-2.9.27-2.el8.noarch - package ansible-2.9.20-1.el8.noarch is filtered out by exclude filtering - package ansible-2.9.16-1.el8.noarch is filtered out by exclude filtering - package ansible-2.9.19-1.el8.noarch is filtered out by exclude filtering - package ansible-2.9.23-1.el8.noarch is filtered out by exclude filtering - package ansible-1:2.9.27-4.el8.noarch is filtered out by exclude filtering (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) [root@orthosie ~]# dnf repolist repo id repo name appstream CentOS Stream 8 - AppStream baseos CentOS Stream 8 - BaseOS dell-system-update_dependent dell-system-update_dependent dell-system-update_independent dell-system-update_independent extras CentOS Stream 8 - Extras ovirt-4.4 Latest oVirt 4.4 Release ovirt-4.4-centos-advanced-virtualization CentOS-8 - Advanced Virtualization ovirt-4.4-centos-ceph-pacific CentOS-8-stream - Ceph Pacific ovirt-4.4-centos-gluster8 CentOS-8-stream - Gluster 8 ovirt-4.4-centos-nfv-openvswitch CentOS-8 - NFV OpenvSwitch ovirt-4.4-centos-openstack-victoria CentOS-8 - OpenStack victoria ovirt-4.4-centos-opstools CentOS-8 - OpsTools - collectd ovirt-4.4-centos-opstools-vault CentOS-8 - OpsTools - collectd - vault ovirt-4.4-centos-ovirt44 CentOS-8 - oVirt 4.4 ovirt-4.4-copr:copr.fedorainfracloud.org:sac:gluster-ansible Copr repo for gluster-ansible owned by sac ovirt-4.4-copr:copr.fedorainfracloud.org:sbonazzo:EL8_collection Copr repo for EL8_collection owned by sbonazzo ovirt-4.4-epel Extra Packages for Enterprise Linux 8 - x86_64 ovirt-4.4-virtio-win-latest virtio-win builds roughly matching what will be shipped in upcoming RHEL powertools CentOS Stream 8 - PowerTools John Florian On 2022-02-21 08:05, Andrea Chierici wrote: Dear all, lately the engine started notifying me about some "errors": "Failed to check for available updates on host XYZ with message 'Task Ensure Python3 is installed for CentOS/RHEL8 hosts failed to execute. Please check logs for more details" I do understand this is not something that can impact my cluster stability, since
[ovirt-users] Re: Multiple dependencies unresolved
So that explains what happened but we still don't have a solution to make this go away, correct? FTR, I did try `dnf reinstall --disablerepo='*' https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm` but things are no different afterwards. John Florian On 2022-03-03 11:37, Klaas Demter wrote: https://lists.ovirt.org/archives/list/users@ovirt.org/message/OANKECW6C4SM6USKJP7DJIAHUN5RALFI/ On 3/3/22 17:20, John Florian wrote: FWIW, I'm getting what appears to be the same dependency errors on my oVirt Hosts that were installed new on C8S not all that long ago. I have to do upgrades manually with `dnf upgrade --no-best` otherwise I get: [root@orthosie ~]# dnf upgrade Last metadata expiration check: 1:24:59 ago on Thu 03 Mar 2022 09:52:40 AM EST. Error: Problem: package cockpit-ovirt-dashboard-0.15.1-1.el8.noarch requires ansible, but none of the providers can be installed - package ansible-2.9.27-2.el8.noarch conflicts with ansible-core > 2.11.0 provided by ansible-core-2.12.2-2.el8.x86_64 - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.27-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.27-1.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.17-1.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.18-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.20-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.21-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.23-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.24-2.el8.noarch - cannot install the best update candidate for package cockpit-ovirt-dashboard-0.15.1-1.el8.noarch - cannot install the best update candidate for package ansible-2.9.27-2.el8.noarch - package ansible-2.9.20-1.el8.noarch is filtered out by exclude filtering - package ansible-2.9.16-1.el8.noarch is filtered out by exclude filtering - package ansible-2.9.19-1.el8.noarch is filtered out by exclude filtering - package ansible-2.9.23-1.el8.noarch is filtered out by exclude filtering - package ansible-1:2.9.27-4.el8.noarch is filtered out by exclude filtering (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) [root@orthosie ~]# dnf repolist repo id repo name appstream CentOS Stream 8 - AppStream baseos CentOS Stream 8 - BaseOS dell-system-update_dependent dell-system-update_dependent dell-system-update_independent dell-system-update_independent extras CentOS Stream 8 - Extras ovirt-4.4 Latest oVirt 4.4 Release ovirt-4.4-centos-advanced-virtualization CentOS-8 - Advanced Virtualization ovirt-4.4-centos-ceph-pacific CentOS-8-stream - Ceph Pacific ovirt-4.4-centos-gluster8 CentOS-8-stream - Gluster 8 ovirt-4.4-centos-nfv-openvswitch CentOS-8 - NFV OpenvSwitch ovirt-4.4-centos-openstack-victoria CentOS-8 - OpenStack victoria ovirt-4.4-centos-opstools CentOS-8 - OpsTools - collectd ovirt-4.4-centos-opstools-vault CentOS-8 - OpsTools - collectd - vault ovirt-4.4-centos-ovirt44 CentOS-8 - oVirt 4.4 ovirt-4.4-copr:copr.fedorainfracloud.org:sac:gluster-ansible Copr repo for gluster-ansible owned by sac ovirt-4.4-copr:copr.fedorainfracloud.org:sbonazzo:EL8_collection Copr repo for EL8_collection owned by sbonazzo ovirt-4.4-epel Extra Packages for Enterprise Linux 8 - x86_64 ovirt-4.4-virtio-win-latest virtio-win builds roughly matching what will be shipped in upcoming RHEL powertools CentOS Stream 8 - PowerTools John Florian On 2022-02-21 08:05, Andrea Chierici wrote: Dear all, lately the engine started notifying me about some "errors": "Failed to check for available updates on host XYZ with message 'Task Ensure Python3 is installed for CentOS/RHEL8 hosts failed to execute. Please check logs for more details" I do understand this is not something that can impact my cluster stability, since it's only a matter of checking updates, anyway it annoys me a lot. I checked the logs and apparently the issue is related to some repos that are missing/unresolved. Right now on my hosts I have these repos: ovirt-release44-4.4.8.3-1.el8.noarch epel-release-8-13.el8.noarch centos-stream-release-8.6-1.el8.noarch puppet5-release-5.0.0-5.el8.noarch The problems come from: Error: Failed to download metadata for repo 'ovirt-4.4-centos-gluster8': Cannot prepare internal mirrorlist: No URLs in mirrorlist Error: Failed to download metadata for repo 'ovirt-4.4-centos-opstools': Cannot prepare internal mirrorlist: No URLs i
[ovirt-users] Re: Multiple dependencies unresolved
FWIW, I'm getting what appears to be the same dependency errors on my oVirt Hosts that were installed new on C8S not all that long ago. I have to do upgrades manually with `dnf upgrade --no-best` otherwise I get: [root@orthosie ~]# dnf upgrade Last metadata expiration check: 1:24:59 ago on Thu 03 Mar 2022 09:52:40 AM EST. Error: Problem: package cockpit-ovirt-dashboard-0.15.1-1.el8.noarch requires ansible, but none of the providers can be installed - package ansible-2.9.27-2.el8.noarch conflicts with ansible-core > 2.11.0 provided by ansible-core-2.12.2-2.el8.x86_64 - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.27-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.27-1.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.17-1.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.18-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.20-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.21-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.23-2.el8.noarch - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 provided by ansible-2.9.24-2.el8.noarch - cannot install the best update candidate for package cockpit-ovirt-dashboard-0.15.1-1.el8.noarch - cannot install the best update candidate for package ansible-2.9.27-2.el8.noarch - package ansible-2.9.20-1.el8.noarch is filtered out by exclude filtering - package ansible-2.9.16-1.el8.noarch is filtered out by exclude filtering - package ansible-2.9.19-1.el8.noarch is filtered out by exclude filtering - package ansible-2.9.23-1.el8.noarch is filtered out by exclude filtering - package ansible-1:2.9.27-4.el8.noarch is filtered out by exclude filtering (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) [root@orthosie ~]# dnf repolist repo id repo name appstream CentOS Stream 8 - AppStream baseos CentOS Stream 8 - BaseOS dell-system-update_dependent dell-system-update_dependent dell-system-update_independent dell-system-update_independent extras CentOS Stream 8 - Extras ovirt-4.4 Latest oVirt 4.4 Release ovirt-4.4-centos-advanced-virtualization CentOS-8 - Advanced Virtualization ovirt-4.4-centos-ceph-pacific CentOS-8-stream - Ceph Pacific ovirt-4.4-centos-gluster8 CentOS-8-stream - Gluster 8 ovirt-4.4-centos-nfv-openvswitch CentOS-8 - NFV OpenvSwitch ovirt-4.4-centos-openstack-victoria CentOS-8 - OpenStack victoria ovirt-4.4-centos-opstools CentOS-8 - OpsTools - collectd ovirt-4.4-centos-opstools-vault CentOS-8 - OpsTools - collectd - vault ovirt-4.4-centos-ovirt44 CentOS-8 - oVirt 4.4 ovirt-4.4-copr:copr.fedorainfracloud.org:sac:gluster-ansible Copr repo for gluster-ansible owned by sac ovirt-4.4-copr:copr.fedorainfracloud.org:sbonazzo:EL8_collection Copr repo for EL8_collection owned by sbonazzo ovirt-4.4-epel Extra Packages for Enterprise Linux 8 - x86_64 ovirt-4.4-virtio-win-latest virtio-win builds roughly matching what will be shipped in upcoming RHEL powertools CentOS Stream 8 - PowerTools John Florian On 2022-02-21 08:05, Andrea Chierici wrote: Dear all, lately the engine started notifying me about some "errors": "Failed to check for available updates on host XYZ with message 'Task Ensure Python3 is installed for CentOS/RHEL8 hosts failed to execute. Please check logs for more details" I do understand this is not something that can impact my cluster stability, since it's only a matter of checking updates, anyway it annoys me a lot. I checked the logs and apparently the issue is related to some repos that are missing/unresolved. Right now on my hosts I have these repos: ovirt-release44-4.4.8.3-1.el8.noarch epel-release-8-13.el8.noarch centos-stream-release-8.6-1.el8.noarch puppet5-release-5.0.0-5.el8.noarch The problems come from: Error: Failed to download metadata for repo 'ovirt-4.4-centos-gluster8': Cannot prepare internal mirrorlist: No URLs in mirrorlist Error: Failed to download metadata for repo 'ovirt-4.4-centos-opstools': Cannot prepare internal mirrorlist: No URLs in mirrorlist Error: Failed to download metadata for repo 'ovirt-4.4-openstack-victoria': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried If I disable these repos "yum update" can finish but then I get a large number of unresolved dependencies and "problems": Error: Problem 1: package cockpit-ovirt-dashboard-0.15.1-1.el8.noarch requires ansible, but none of the providers can
[ovirt-users] Re: upgrade dependency issues
On the engine: repo id repo name appstream CentOS Linux 8 - AppStream baseos CentOS Linux 8 - BaseOS doubledog doubledog on EL 8 - released epel Extra Packages for Enterprise Linux 8 - x86_64 epel-modular Extra Packages for Enterprise Linux Modular 8 - x86_64 extras CentOS Linux 8 - Extras local-AppStream doubledog mirror of CentOS-8 - AppStream local-BaseOS doubledog mirror of CentOS-8 - Base local-extras doubledog mirror of CentOS-8 - Extras ovirt-4.4 Latest oVirt 4.4 Release ovirt-4.4-advanced-virtualization Advanced Virtualization packages for x86_64 ovirt-4.4-centos-ceph-pacific Ceph packages for x86_64 ovirt-4.4-centos-gluster8 CentOS-8 - Gluster 8 ovirt-4.4-centos-nfv-openvswitch CentOS-8 - NFV OpenvSwitch ovirt-4.4-centos-opstools CentOS-8 - OpsTools - collectd ovirt-4.4-centos-ovirt44 CentOS-8 - oVirt 4.4 ovirt-4.4-copr:copr.fedorainfracloud.org:sac:gluster-ansible Copr repo for gluster-ansible owned by sac ovirt-4.4-copr:copr.fedorainfracloud.org:sbonazzo:EL8_collection Copr repo for EL8_collection owned by sbonazzo ovirt-4.4-epel Extra Packages for Enterprise Linux 8 - x86_64 ovirt-4.4-openstack-victoria OpenStack Victoria Repository ovirt-4.4-virtio-win-latest virtio-win builds roughly matching what will be shipped in upcoming RHEL powertools CentOS Linux 8 - PowerTools and on one of the hosts: repo id repo name appstream CentOS Linux 8 - AppStream baseos CentOS Linux 8 - BaseOS dell-system-update_dependent dell-system-update_dependent dell-system-update_independent dell-system-update_independent extras CentOS Linux 8 - Extras local-AppStream doubledog mirror of CentOS-8 - AppStream local-BaseOS doubledog mirror of CentOS-8 - Base local-extras doubledog mirror of CentOS-8 - Extras ovirt-4.4 Latest oVirt 4.4 Release ovirt-4.4-advanced-virtualization Advanced Virtualization packages for x86_64 ovirt-4.4-centos-ceph-pacific Ceph packages for x86_64 ovirt-4.4-centos-gluster8 CentOS-8 - Gluster 8 ovirt-4.4-centos-nfv-openvswitch CentOS-8 - NFV OpenvSwitch ovirt-4.4-centos-opstools CentOS-8 - OpsTools - collectd ovirt-4.4-centos-ovirt44 CentOS-8 - oVirt 4.4 ovirt-4.4-copr:copr.fedorainfracloud.org:sac:gluster-ansible Copr repo for gluster-ansible owned by sac ovirt-4.4-copr:copr.fedorainfracloud.org:sbonazzo:EL8_collection Copr repo for EL8_collection owned by sbonazzo ovirt-4.4-epel Extra Packages for Enterprise Linux 8 - x86_64 ovirt-4.4-openstack-victoria OpenStack Victoria Repository ovirt-4.4-virtio-win-latest virtio-win builds roughly matching what will be shipped in upcoming RHEL powertools CentOS Linux 8 - PowerTools The local-* repos are on-site mirrors. I've tried disabling them just to rule them out, but it made no difference. John Florian On 2021-10-25 15:07, Strahil Nikolov wrote: Hi, what is the output from: 'yum repolist' ? Best Regards, Strahil Nikolov В понеделник, 25 октомври 2021 г., 17:12:58 ч. Гринуич+3, John Florian написа: I recently upgrade my engine to 4.4.9 following the usual engine-setup procedure. Once that was done, I tried to do a dnf upgrade to get everything else and found: Error: Problem: cannot install the best update candidate for package ovirt-engine-metrics-1.4.3-1.el8.noarch - nothing provides rhel-system-roles >= 1.7.2-1 needed by ovirt-engine-metrics-1.4.4-1.el8.noarch(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) I was also trying to update my hosts thru the GUI and that was failing also. I couldn't find the right log with good details as to why, so I just tried to dnf upgrade from the shell to see what got reported and found: Error: Problem 1: cannot install the best update candidate for package ovirt-host-dependencies-4.4.8-1.el8.x86_64 - nothing provides rsyslog-openssl needed by ovirt-host-dependencies-4.4.9-2.el8.x86_64 Problem 2: cannot install the best update candidate for package ovirt-hosted-engine-setup-2.5.3-1.el8.noarch - nothing provides ovirt-host >= 4.5.0 needed by ovirt-hosted-engine-setup-2.5.4-1.el8.noarch - nothing provides vdsm-python >= 4.50 needed by ovirt-hosted-engine-setup-2.5.4-1.el8.noarch Problem 3: cannot install the best update candidate for package vdsm-4.40.80.5-1.el8.x86_64 - nothing provides libvirt-daemon-kvm >= 7.6.0-2 needed by vdsm-4.40.90.3-1.el8.x86_64 Problem 4: package ovirt-host-4.4.9-2.el8.x86_64 requires ovirt-host-dependencies = 4.4.9-2.el8, but none of the providers can be installed - cannot install the best update candidate for package ovirt-host-4.4.8-1.el8.x86_64 - nothing provides rsyslog-openssl needed by ovirt-host-dependencies-4.4.9-2.el8.x86_64 Problem 5: package vdsm-hook-fcoe-4.40.90.3-1.el8.noarch requires vdsm, but none of the providers can be installed - package vdsm-4.40.80.5-1.el8.x86_64 requires vdsm-http = 4.40.80.5-1.el8, but none of the providers can be installed - package vdsm-4.40.17-1.el8.x86_64 requires vdsm-http = 4.40.17-1.e
[ovirt-users] upgrade dependency issues
I recently upgrade my engine to 4.4.9 following the usual engine-setup procedure. Once that was done, I tried to do a dnf upgrade to get everything else and found: Error: Problem: cannot install the best update candidate for package ovirt-engine-metrics-1.4.3-1.el8.noarch - nothing provides rhel-system-roles >= 1.7.2-1 needed by ovirt-engine-metrics-1.4.4-1.el8.noarch (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) I was also trying to update my hosts thru the GUI and that was failing also. I couldn't find the right log with good details as to why, so I just tried to dnf upgrade from the shell to see what got reported and found: Error: Problem 1: cannot install the best update candidate for package ovirt-host-dependencies-4.4.8-1.el8.x86_64 - nothing provides rsyslog-openssl needed by ovirt-host-dependencies-4.4.9-2.el8.x86_64 Problem 2: cannot install the best update candidate for package ovirt-hosted-engine-setup-2.5.3-1.el8.noarch - nothing provides ovirt-host >= 4.5.0 needed by ovirt-hosted-engine-setup-2.5.4-1.el8.noarch - nothing provides vdsm-python >= 4.50 needed by ovirt-hosted-engine-setup-2.5.4-1.el8.noarch Problem 3: cannot install the best update candidate for package vdsm-4.40.80.5-1.el8.x86_64 - nothing provides libvirt-daemon-kvm >= 7.6.0-2 needed by vdsm-4.40.90.3-1.el8.x86_64 Problem 4: package ovirt-host-4.4.9-2.el8.x86_64 requires ovirt-host-dependencies = 4.4.9-2.el8, but none of the providers can be installed - cannot install the best update candidate for package ovirt-host-4.4.8-1.el8.x86_64 - nothing provides rsyslog-openssl needed by ovirt-host-dependencies-4.4.9-2.el8.x86_64 Problem 5: package vdsm-hook-fcoe-4.40.90.3-1.el8.noarch requires vdsm, but none of the providers can be installed - package vdsm-4.40.80.5-1.el8.x86_64 requires vdsm-http = 4.40.80.5-1.el8, but none of the providers can be installed - package vdsm-4.40.17-1.el8.x86_64 requires vdsm-http = 4.40.17-1.el8, but none of the providers can be installed - package vdsm-4.40.18-1.el8.x86_64 requires vdsm-http = 4.40.18-1.el8, but none of the providers can be installed - package vdsm-4.40.19-1.el8.x86_64 requires vdsm-http = 4.40.19-1.el8, but none of the providers can be installed - package vdsm-4.40.20-1.el8.x86_64 requires vdsm-http = 4.40.20-1.el8, but none of the providers can be installed - package vdsm-4.40.21-1.el8.x86_64 requires vdsm-http = 4.40.21-1.el8, but none of the providers can be installed - package vdsm-4.40.22-1.el8.x86_64 requires vdsm-http = 4.40.22-1.el8, but none of the providers can be installed - package vdsm-4.40.26.3-1.el8.x86_64 requires vdsm-http = 4.40.26.3-1.el8, but none of the providers can be installed - package vdsm-4.40.30-1.el8.x86_64 requires vdsm-http = 4.40.30-1.el8, but none of the providers can be installed - package vdsm-4.40.31-1.el8.x86_64 requires vdsm-http = 4.40.31-1.el8, but none of the providers can be installed - package vdsm-4.40.32-1.el8.x86_64 requires vdsm-http = 4.40.32-1.el8, but none of the providers can be installed - package vdsm-4.40.33-1.el8.x86_64 requires vdsm-http = 4.40.33-1.el8, but none of the providers can be installed - package vdsm-4.40.34-1.el8.x86_64 requires vdsm-http = 4.40.34-1.el8, but none of the providers can be installed - package vdsm-4.40.35-1.el8.x86_64 requires vdsm-http = 4.40.35-1.el8, but none of the providers can be installed - package vdsm-4.40.35.1-1.el8.x86_64 requires vdsm-http = 4.40.35.1-1.el8, but none of the providers can be installed - package vdsm-4.40.36-1.el8.x86_64 requires vdsm-http = 4.40.36-1.el8, but none of the providers can be installed - package vdsm-4.40.37-1.el8.x86_64 requires vdsm-http = 4.40.37-1.el8, but none of the providers can be installed - package vdsm-4.40.38-1.el8.x86_64 requires vdsm-http = 4.40.38-1.el8, but none of the providers can be installed - package vdsm-4.40.39-1.el8.x86_64 requires vdsm-http = 4.40.39-1.el8, but none of the providers can be installed - package vdsm-4.40.40-1.el8.x86_64 requires vdsm-http = 4.40.40-1.el8, but none of the providers can be installed - package vdsm-4.40.50.8-1.el8.x86_64 requires vdsm-http = 4.40.50.8-1.el8, but none of the providers can be installed - package vdsm-4.40.50.9-1.el8.x86_64 requires vdsm-http = 4.40.50.9-1.el8, but none of the providers can be installed - package vdsm-4.40.60.6-1.el8.x86_64 requires vdsm-http = 4.40.60.6-1.el8, but none of the providers can be installed - package vdsm-4.40.60.7-1.el8.x86_64 requires vdsm-http = 4.40.60.7-1.el8, but none of the providers can be installed - package vdsm-4.40.70.6-1.el8.x86_64 requires vdsm-http = 4.40.70.6-1.el8, but none of the providers can be installed - package vdsm-4.40.80.6-1.el8.x86_64 requires vdsm-http = 4.40.80.6-1.el8, but none of the providers can be installed - package vdsm-4.40.16-1.el8.x86_64
[ovirt-users] Re: Host reinstall: ModuleNotFoundError: No module named 'rpmUtils'
On 4/10/19 3:06 AM, Yedidyah Bar David wrote: > On Mon, Apr 8, 2019 at 1:06 AM John Florian wrote: >> After mucking around trying to use jumbo MTU for my iSCSI storage nets >> (which apparently I can't do because my Cisco 3560 switch only supports 1500 >> max for its vlan interfaces) I got one of my Hosts screwed up. I likely >> could rebuild it from scratch but I suspect that's overkill. I simply tried >> to do a reinstall via the GUI. That fails. Looking at the >> ovirt-host-deploy log I see several tracebacks with $SUBJECT. > Can you please share these logs? Here's an example. Please read ahead before digging into the log though. https://paste.fedoraproject.org/paste/956Bvf2UXzSwCSjxkD0OEQ/deactivate/vyLHHPInqQ2kz2Xr5KL55V2q2deoVEgmD1hNXtjcTtQQmljFU4gms2QoydmCTTvJ > >> Since Python pays my bills I figure this is an easy fix. Except ... I see >> this on the host: >> >> $ rpm -qf /usr/lib/python2.7/site-packages/rpmUtils/ >> yum-3.4.3-161.el7.centos.noarch >> $ python >> Python 2.7.5 (default, Oct 30 2018, 23:45:53) >> [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux2 >> Type "help", "copyright", "credits" or "license" for more information. >> Tab completion has been enabled. >>>>> import rpmUtils >>>>> >> I'm guessing this must mean the tracebacks are from Python 3 > Probably. Do you have it installed? Yes, the host has both python34-3.4.9-3.el7.x86_64 and python36-3.6.6-5.el7.x86_64. These are required for some of my local packages. > > In 4.3 we default to python3 if found. This is currently broken on > EL7, and we decided to not fix. See also: > > https://bugzilla.redhat.com/show_bug.cgi?id=1688811 > > This one is specifically about python34, and causes a different > backtrace than yours. Yup, but very informative just the same. For now, I'll just remove the extra stuff so that the host deploy can finish. I assume it's OK to have Python 3 installed for my things once the deploy is done. Is that a reasonable assumption? I mean, everything seemed to be running fine until I made the mess and tried using the host reinstall as a handy cleanup. > > Now that 4.3 is out, I don't mind reverting this decision (of > defaulting to python3) if it's considered premature, considering that > most developers probably use master branches (4.4) by now (and that > python3 support is still not finished :-(, although should work for > host-deploy on fedora). > >> since I can clearly see the module doesn't exist for either Python 3.4 or >> 3.6. So this smells like a packaging bug somehow related to upgrading from >> 4.2. I mean, I can't imagine a brand new install fails this blatantly. >> Either that or this import error has nothing to do with my reinstall failure. > It's not a packaging bug. The way 'Add host' works is: > > 1. The engine creates a tarfile containing otopi + all needed > modules/plugins (including host-deploy) and python libraries. This is > cached, and you can check it if you want, at: > /var/cache/ovirt-engine/ovirt-host-deploy.tar . > > 2. The engine ssh'es (is that a verb?) I think it should be. I use it all the time though it always sounds awkward. Text became a verb. Google became a verb. Why's this one so tough? :-\ Maybe its because it sounds like we trying to hush a crying baby. > to the host, copies there the > tar file, opens it, and runs it. Then, the code in it runs. You can > find in engine.log the (long) command line it runs on the host via > ssh. > > At this point, the code that runs there still can't do anything about > packaging. In particular, it can't Require: any specific versions of > anything, etc., because it's not installed by rpm but copied from the > engine. Good to know this! Just to make sure I read that right, you're saying that "host deploy code" that runs on the host is not rpm packaged, but when that code runs it is installing rpms. So once it's done, everything that makes a host a host is via rpm, just not the "how" it got there. Am I right? > > But this is not really relevant. If you think this is a real bug, > please (re)open one, and we'll think what we can do. Opinions/ideas > are obviously welcome :-) Well, it doesn't sound like a bug as much as an expectation. I guess when I color outside the lines by adding my own local packages all bets are off. Still, I'm a little surprised how this one manifests since this kind of thing doesn't usually matter. I'm mostly a victim of my age and long experience of "if you want that on Linux, build it!" All these fancy automation tools (e.g., install host) are almost more difficult than the manual way ... but really that's only when they go wrong ot
[ovirt-users] Host reinstall: ModuleNotFoundError: No module named 'rpmUtils'
After mucking around trying to use jumbo MTU for my iSCSI storage nets (which apparently I can't do because my Cisco 3560 switch only supports 1500 max for its vlan interfaces) I got one of my Hosts screwed up. I likely could rebuild it from scratch but I suspect that's overkill. I simply tried to do a reinstall via the GUI. That fails. Looking at the ovirt-host-deploy log I see several tracebacks with $SUBJECT. Since Python pays my bills I figure this is an easy fix. Except ... I see this on the host: $ rpm -qf /usr/lib/python2.7/site-packages/rpmUtils/ yum-3.4.3-161.el7.centos.noarch $ python Python 2.7.5 (default, Oct 30 2018, 23:45:53) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux2 Type "help", "copyright", "credits" or "license" for more information. Tab completion has been enabled. >>> import rpmUtils >>> I'm guessing this must mean the tracebacks are from Python 3 since I can clearly see the module doesn't exist for either Python 3.4 or 3.6. So this smells like a packaging bug somehow related to upgrading from 4.2. I mean, I can't imagine a brand new install fails this blatantly. Either that or this import error has nothing to do with my reinstall failure. -- John Florian ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/QQCEDUGH7JGZL3KMEOQ4I4QX76DJ3I2S/
[ovirt-users] Re: All hosts non-operational after upgrading from 4.2 to 4.3
This is sn iscsi storage domain. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/JG4WT4WCAVV4XJG4CHKDJARQ4L2NYU2V/
[ovirt-users] Re: All hosts non-operational after upgrading from 4.2 to 4.3
Doh! I am such an idiot !!! First of all, I meant to say I upgraded to 4.3.2 not 4.3.3. I only installed ovirt-release43.rpm on the engine. I've gotten too lazy with using the upgrade host feature in the GUI that I completely failed to think of doing this on each of the hosts. Worse, I've got a vague sense of deja vu like I've been in this same spot before, maybe with 4.1 -> 4.2. These bigger upgrades are just infrequent enough I forget important steps. It seems like this could be handled more gracefully though. Shouldn't this be caught and reported as user-friendly alert in the GUI? Also, I think it would be better if the release notes ... Change """If you're upgrading from oVirt Engine 4.2.8 you just need to execute:""" to """If you're upgrading from oVirt Engine 4.2.8 you just need to execute on your Engine and each Host:""". ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/KKLSZPARCOLMNLYS3YEKWWZ5OCYTDLNI/
[ovirt-users] Re: All hosts non-operational after upgrading from 4.2 to 4.3
> What kind of storage are you using? local? iSCSI ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/APCJ6BIYABSE4VJDUTZ4Z5RFZLHDESV4/
[ovirt-users] Re: All hosts non-operational after upgrading from 4.2 to 4.3
Also, I see in the notification drawer a message that says: Storage domains with IDs [ed4d83f8-41a2-41bd-a0cd-6525d9649edb] could not be synchronized. To synchronize them, please move them to maintenance and then activate. However, when I navigate to Compute > Data Centers > Default, the Maintenance option is greyed out. Activate in the button bar is also greyed out, but it looks like an option in the r-click context menu although selecting that shows "Error while executing action: Cannot activate Storage. There is no active Host in the Data Center.". I'm just stuck in an endless circle here. On Fri, Apr 5, 2019 at 12:04 PM John Florian wrote: > 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? > ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/A7XPDM3EFUJPXON3YCX3EK66NCMFI6SJ/
[ovirt-users] All hosts non-operational after upgrading from 4.2 to 4.3
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? ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/GJKJKVOKKZVTGKSNIU6RSOYUE5HUDWNN/
[ovirt-users] Re: VM bandwidth limitations
On 4/4/19 7:03 AM, Dominik Holler wrote: > On Sun, 10 Mar 2019 13:45:59 -0400 > John Florian wrote: > >> 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? > This depends on the scenario. > Bonding two VirtIO vNICs connected to the same network would be not > increase the throughput, since a single vNIC has by default no > artificial bandwidth limit. Thank you, this exactly what I wanted to know (and suspected). -- John Florian ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/6IC63X6GKXHOHZ7WXISRUM5MSXC3LWVP/
[ovirt-users] Re: VM bandwidth limitations
Meh! Is spam really the only response I'm going to get on this? On 3/10/19 1:45 PM, John Florian wrote: 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 ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/D7ZZXB7SFN5TTF3MT3TWKA7RJWBHVZ5R/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/MH6CSQUV6AXD3TSNY6BALGMKHCMHGX6H/
[ovirt-users] VM bandwidth limitations
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 ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/D7ZZXB7SFN5TTF3MT3TWKA7RJWBHVZ5R/
[ovirt-users] Re: Upgrade 4.2.8 to 4.3.1 failed: Constraint violation found in vm_interface (vmt_guid) |1
Done: https://bugzilla.redhat.com/show_bug.cgi?id=1684586 On 3/1/19 9:43 AM, Martin Perina wrote: On Fri, Mar 1, 2019 at 3:12 PM John Florian <mailto:jflor...@doubledog.org>> wrote: I tried to upgrade my engine and was running engine-setup when: [ INFO ] Checking the Engine database consistency [ ERROR ] Failed to execute stage 'Setup validation': Failed checking Engine database: an exception occurred while validating the Engine database, please check the logs for getting more info: Constraint violation found in vm_interface (vmt_guid) |1 I found https://bugzilla.redhat.com/show_bug.cgi?id=1528316 but that looks to have been resolved already. This seems like a new issue, could you please create new bug for that and attach engine logs (especially those from /var/log/ovirt-engine/setup? Thanks, Martin How should I proceed? ___ Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-le...@ovirt.org <mailto:users-le...@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/FD5GAOK6Y5X25IJNNQ56TCQOKEXCZBKT/ -- Martin Perina Associate Manager, Software Engineering Red Hat Czech s.r.o. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/7SMATXVAD3PJQJRMVODBXXOMJ4HQOQOR/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/CBSZ7VVD4CTRTDPEWBIUVEGA22JP6F7F/
[ovirt-users] Upgrade 4.2.8 to 4.3.1 failed: Constraint violation found in vm_interface (vmt_guid) |1
I tried to upgrade my engine and was running engine-setup when: [ INFO ] Checking the Engine database consistency [ ERROR ] Failed to execute stage 'Setup validation': Failed checking Engine database: an exception occurred while validating the Engine database, please check the logs for getting more info: Constraint violation found in vm_interface (vmt_guid) |1 I found https://bugzilla.redhat.com/show_bug.cgi?id=1528316 but that looks to have been resolved already. How should I proceed? ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/FD5GAOK6Y5X25IJNNQ56TCQOKEXCZBKT/
[ovirt-users] Re: Use public-signed SSL certs?
On 1/29/19 3:13 PM, John Florian wrote: > On 1/29/19 2:47 PM, Chris Adams wrote: >> Once upon a time, John Florian said: >>> On 1/29/19 1:30 PM, Chris Adams wrote: >>>> Can that be run non-interactively to do whatever is needed? >>>> I'm using a Let's Encrypt cert, which needs to have a 100% automated >>>> deployment. >>> Yes, I believe so. Look at the whole biz with the "answers" file >>> and the --config-append=file option. You should already have a >>> generated answers file laying around from when you ran engine-setup >>> before. See /var/lib/ovirt-engine/setup/answers IIRC. >> Hmm, that won't work - it looks like you can't run engine-setup on a >> hosted engine unless you first set hosted-engine HA to global >> maintenance. >> >> Is running engine-setup necessary to install/update certificates, or >> maybe is there a simpler way? > > I'm quite certain you can do it w/o engine-setup if you hit all the > right file locations. Just to follow up on this Chris, I have my puppet drop my CA cert in /etc/pki/ca-trust/source/anchors/, my self-signed cert in/etc/pki/ovirt-engine/certs/ and my key in /etc/pki/ovirt-engine/keys. I also manage /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf to have: ENGINE_HTTPS_PKI_TRUST_STORE="/etc/pki/java/cacerts" ENGINE_HTTPS_PKI_TRUST_STORE_PASSWORD="" I believe this gives me everything you seek. -- John Florian ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/QHWEL244HI4ZNZXDMSSG23UOL7RIBVGF/
[ovirt-users] Re: Use public-signed SSL certs?
On 1/29/19 2:47 PM, Chris Adams wrote: Once upon a time, John Florian said: On 1/29/19 1:30 PM, Chris Adams wrote: Can that be run non-interactively to do whatever is needed? I'm using a Let's Encrypt cert, which needs to have a 100% automated deployment. Yes, I believe so. Look at the whole biz with the "answers" file and the --config-append=file option. You should already have a generated answers file laying around from when you ran engine-setup before. See /var/lib/ovirt-engine/setup/answers IIRC. Hmm, that won't work - it looks like you can't run engine-setup on a hosted engine unless you first set hosted-engine HA to global maintenance. Is running engine-setup necessary to install/update certificates, or maybe is there a simpler way? I'm quite certain you can do it w/o engine-setup if you hit all the right file locations. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/23CSSA5MA22MFA7NZMOKA7RVRHQAHYUC/
[ovirt-users] Re: Use public-signed SSL certs?
On 1/29/19 1:30 PM, Chris Adams wrote: Can that be run non-interactively to do whatever is needed? I'm using a Let's Encrypt cert, which needs to have a 100% automated deployment. Yes, I believe so. Look at the whole biz with the "answers" file and the --config-append=file option. You should already have a generated answers file laying around from when you ran engine-setup before. See /var/lib/ovirt-engine/setup/answers IIRC. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/4V7XPHN63OD5LON365IBXH4KCBAV7XID/
[ovirt-users] Re: need network design advice for iSCSI
Okay, both the BZ and ML posts are interesting and helpful. I'm kind of surprised there seems to be so much trouble and confusion for what I would have thought to be a very common setup. Are most people using something else? I think this gives me what I need for my next stab at doing this but I"m still puzzled on how to tear down what I have in oVirt so that I can redo it. Specifically, I didn't see how to delete the existing iSCSI connections. I've read that this can only be done through the REST API. I have managed to redo the interfaces on my Hosts so that everything is now on just 2 NICs each, leaving 2 NICs free for a foothold on a new setup. From all of my experimentation, it would appear that my only option is to create a new storage domain and export/import each disk volume one by one. Maybe there's a migration option I have yet to see, but I don't see any way around creating a new storage domain here. On 1/21/19 7:12 AM, Vinícius Ferrão wrote: Hello people, in the past Maor Lipchuk (from RH) tried very hard to help me and Uwe but we was unable to converge on the solution. This was discussed a year ago and on my understanding it still and oVirt bug. As today, if you simple “DuckDuckGo” for “ovirt iscsi multipath not working” the third link points to this bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1474904 Which is the one I’ve mentioned and it’s extremely similar to John Florian case, which was my case too. @John, take a look at the bugzilla link and see if the desired topology match with your case. Regards, On 21 Jan 2019, at 05:21, Eitan Raviv <mailto:era...@redhat.com>> wrote: Shani, Can you help here with iSCSI bonding? Thanks On Mon, Jan 21, 2019 at 7:51 AM Uwe Laverenz <mailto:u...@laverenz.de>> wrote: Hi John, Am 20.01.19 um 18:32 schrieb John Florian: As for how to get there, whatever exactly that might look like, I'm also having troubles figuring that out. I figured I would transform the setup described below into one where each host has: * 2 NICs bonded with LACP for my ovirtmgmt and "main" net * 1 NIC for my 1st storage net * 1 NIC for my 2nd storage net This is exactly the setup I use. I have run this successfully with CentOS/LIO and FreeNAS iSCSI targets with good performance. In short: - 2 separate, isolated networks for iSCSI with dedicated adapters on hosts and iSCSI target - jumbo frames enabled - no VLANs config needed on hosts, untagged VLANs on switch - do _not_ use LACP, let multipathd handle failovers Same experience as Vinicius: what did _not_ work for me is the iSCSI-Bonding in OVirt. It seems to require that all storage IPs are reachable from all other IPs, which is not the case in every setup. To get multipathing to work I use multipath directly: https://www.mail-archive.com/users@ovirt.org/msg42735.html I will post a bonnie++ result later. If you need more details please let me know. cu, Uwe ___ Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-le...@ovirt.org <mailto:users-le...@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/E2QKV7CZR27NT6MRSNL352KLOQ5OAGDR/ ___ Users mailing list --users@ovirt.org To unsubscribe send an email tousers-le...@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/NSE5BCLJSIFDX2VDZRBRLODEH3ZCPYWN/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/G6GMNF3RU5IDEDM4OWG4RDXAFY5BHDSV/
[ovirt-users] Re: need network design advice for iSCSI
So just to make sure I follow: * I will want a distinct VLAN and IP address for each NIC acting as an iSCSI initiator. * In the middle the switch would be configured as basic access ports without any LACP. * Do I want the same for the target? The QNAP docs say that for MPIO I would want to use their port trunking feature and a single IP for both NICs on that end, which confuses me as it seems to contradict the idea of two (or more) completely independent channels. As for how to get there, whatever exactly that might look like, I'm also having troubles figuring that out. I figured I would transform the setup described below into one where each host has: * 2 NICs bonded with LACP for my ovirtmgmt and "main" net * 1 NIC for my 1st storage net * 1 NIC for my 2nd storage net To get there though, I need to remove the 4 existing logical storage nets from my hosts, pull 2 NICs out of the existing bond and so on. But when I've attempted that, I get things into a funky state where the hosts become non-operational because the old storage nets are "required". I unchecked that setting thinking that to be the right path. But I could never get much further towards the new setup because the existing storage domain as all the old connections and I see no way to "forget" them, at least through the engine -- I didn't try to fight it behind its back with iscsiadmin to do session logouts. Somewhere in all this mess I got into a Catch-22 where I couldn't do anything with the old SD because no host was suitable and no host could be made suitable because the SD couldn't be connected. I tried all sorts of things of varying levels of scariness but wound up putting things back to present for now since I clearly need some further advice. One option that struck me as a possibility, but exceeded my risk aversion threshold was to remove the storage domain entirely and create a new one pointing to the same LUNs. Is that what I need to do to forget the old connections? Is that safe to all my existing logical disks, etc? Does the engine just see an group of LUNs with oVirt "things" and magically reconstruct it all from what's there? I'm guessing that's the case because I have recreated an engine before and know that all the critical bits live in the SD, but I just want to be sure I don't commit to something really boneheaded. On 1/17/19 7:43 PM, Vinícius Ferrão wrote: > MPIO by concept is when you have two dedicated paths for iSCSI. > > So you don’t put iSCSI inside LACP, because it won’t do the MPIO > magic. Since it’s the same path with a single IP. > > The right approach is two subjects, completely segregated without > routing. You can use the same switch, it will not be redundant on the > switch part, but it will be on the connections and you have two paths > to follow load balancing between them. > > But to be honest I never get how oVirt handles MPIO. The iSCSI > Multipath button on the interface request that all points, on > different paths, to be reached, which doesn’t make sense for my > understanding. In the past I’ve opened a ticket about this but I > simply gave up. Ended using XenServer instead for this case > specifically, which I was trying to avoid. > > Sent from my iPhone > > On 17 Jan 2019, at 22:14, John Florian <mailto:jflor...@doubledog.org>> wrote: > >> I have an existing 4.2 setup with 2 hosts, both with a quad-gbit NIC >> and a QNAP TS-569 Pro NAS with twin gbit NIC and five 7k2 drives. At >> present, the I have 5 VLANs, each with their own subnet as: >> >> 1. my "main" net (VLAN 1, 172.16.7.0/24) >> 2. ovirtmgmt (VLAN 100, 192.168.100.0/24) >> 3. four storage nets (VLANs 101-104, 192.168.101.0/24 - >> 192.168.104.0/24) >> >> On the NAS, I enslaved both NICs into a 802.3ad LAG and then bound an >> IP address for each of the four storage nets giving me: >> >> * bond0.101@bond0: 192.168.101.101 >> * bond0.102@bond0: 192.168.102.102 >> * bond0.103@bond0: 192.168.103.103 >> * bond0.104@bond0: 192.168.104.104 >> >> The hosts are similar, but with all four NICs enslaved into a 802.3ad >> LAG: >> >> Host 1: >> >> * bond0.101@bond0: 192.168.101.203 >> * bond0.102@bond0: 192.168.102.203 >> * bond0.103@bond0: 192.168.103.203 >> * bond0.104@bond0: 192.168.104.203 >> >> Host 2: >> >> * bond0.101@bond0: 192.168.101.204 >> * bond0.102@bond0: 192.168.102.204 >> * bond0.103@bond0: 192.168.103.204 >> * bond0.104@bond0: 192.168.104.204 >> >> I believe my performance could be better though. While running >> bonnie++ on a VM, the NAS reports top disk throughput around 70MB/s >> and the network (both NICs) toppi
[ovirt-users] need network design advice for iSCSI
I have an existing 4.2 setup with 2 hosts, both with a quad-gbit NIC and a QNAP TS-569 Pro NAS with twin gbit NIC and five 7k2 drives. At present, the I have 5 VLANs, each with their own subnet as: 1. my "main" net (VLAN 1, 172.16.7.0/24) 2. ovirtmgmt (VLAN 100, 192.168.100.0/24) 3. four storage nets (VLANs 101-104, 192.168.101.0/24 - 192.168.104.0/24) On the NAS, I enslaved both NICs into a 802.3ad LAG and then bound an IP address for each of the four storage nets giving me: * bond0.101@bond0: 192.168.101.101 * bond0.102@bond0: 192.168.102.102 * bond0.103@bond0: 192.168.103.103 * bond0.104@bond0: 192.168.104.104 The hosts are similar, but with all four NICs enslaved into a 802.3ad LAG: Host 1: * bond0.101@bond0: 192.168.101.203 * bond0.102@bond0: 192.168.102.203 * bond0.103@bond0: 192.168.103.203 * bond0.104@bond0: 192.168.104.203 Host 2: * bond0.101@bond0: 192.168.101.204 * bond0.102@bond0: 192.168.102.204 * bond0.103@bond0: 192.168.103.204 * bond0.104@bond0: 192.168.104.204 I believe my performance could be better though. While running bonnie++ on a VM, the NAS reports top disk throughput around 70MB/s and the network (both NICs) topping out around 90MB/s. I suspect I'm being hurt by the load balancing across the NICs. I've played with various load balancing options for the LAGs (src-dst-ip and src-dst-mac) but with little difference in effect. Watching the resource monitor on the NAS, I can see that one NIC almost exclusive does transmits while the other is almost exclusively receives. Here's the bonnie report (my apologies to those reading plain-text here): Bonnie++ Benchmark results *Version 1.97* *Sequential Output* *Sequential Input* *Random Seeks* *Sequential Create* *Random Create* SizePer CharBlock Rewrite Per CharBlock Num Files Create ReadDelete Create ReadDelete K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU /sec% CPU /sec% CPU /sec% CPU /sec% CPU /sec% CPU /sec % CPU /sec % CPU unamed 4G 267 97 75284 21 22775 8 718 97 43559 7 189.5 8 16 678960 + +++ 24948 75 14792 86 + +++ 18163 51 Latency 69048us 754ms 898ms 61246us 311ms 1126ms Latency 33937us 1132us 1299us 528us 22us458us I keep seeing MPIO mentioned for iSCSI deployments and now I'm trying to get my head around how to best set that up or to even know if it would be helpful. I only have one switch (a Catalyst 3750g) in this small setup so fault tolerance at that level isn't a goal. So... what would the recommendation be? I've never done MPIO before but know where it's at in the web UI at least. -- John Florian ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/6PFUJFCL36VDEI6J6YUBGJNXTJHFQLYX/
[ovirt-users] Re: Missing step(s) after custom x509 certificates
On 2018-06-18 02:46, Yedidyah Bar David wrote: On Mon, Jun 18, 2018 at 9:19 AM, Tomas Jelinek wrote: On Mon, Jun 18, 2018 at 8:01 AM, Yedidyah Bar David wrote: On Sun, Jun 17, 2018 at 6:11 PM, John Florian wrote: I followed the docs at https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL/ and all works well from the usual web portal. Went to test moVirt and ran into a snag. It wants to download the CA using http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA, I never tried movirt, but the user's guide [1] says it can import user-supplied certs, so you can supply your own CA's cert, no? correct, you can supply your own certificate, movirt just by default grabs the one which is provided by engine at: http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA @Ravi: is it correct that after you provide your own CA that the http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA is still pointing to the old one? Yes - check this: https://ovirt.org/develop/release-management/features/infra/pki/#services It does not have a resource "apache-certificate" or anything like that. The assumption is that user that changes httpd's conf to use a 3rd-party CA, is in control of it, not the engine - so the engine can't handle it. This is even if the user followed the documentation, because in principle, the user can do other things - e.g. point SSLCACertificateFile at a different file instead of replacing the content of the existing apache-ca.pem (which defaults to a symlink to ca.pem, which _is_ controlled by the engine (as in "we do not have any documentation about how to replace it, and doing that will break many flows"). Okay, this is what threw me. The docs are written in such a way that I never touch httpd's conf, as if maybe I am not supposed to do that. The docs have me change the target of a symlink and do other swaps and avoids touching the conf, be it intentional or not. I may have inferred too much based on the approach. So my presumption was that the API should/might continue doing what it did before in providing the correct CA certificate. It would be nice if it did, because entering URLs on a phone is not my idea of fun and the moVirt feature to go fetch this directly is really handy. So, in my case where Puppet is co-managing my Engine, I take it that it would be acceptable for me to manage httpd's ssl.conf file? Anyway, patches (to either that web page or movirt, or both) are most welcome! Best regards, [1] https://github.com/oVirt/moVirt/wiki/User%27s-guide but that's grabbing the old CA issued by the engine rather than my custom CA. What else needs to be changed? I'm sure I can finagle my way to a fix here by telling moVirt to use a custom URL or file, but this looks like a bug in the docs that would probably best be fixed. -- John Florian ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/2DUNW4Y24HW4S5K4VGLIZRVR2K7BF37Z/ -- Didi ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/EXKTGCRWIYIGLWFVMWOHBDLAZCEGIOJG/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/BP74SDAVQNA7IJVKAWYHFCNHWOEQYITQ/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/KI3ZYUOEYKHMXHRA3ZBPEFEO46JIRHDK/
[ovirt-users] Re: remote-viewer Spice Problem on MacOS
On 2018-06-21 08:20, Michal Skrivanek wrote: Any connectivity issue should no really be dependent on what you do in guest Agreed Still, please bring that up to SPICE team -https://www.spice-space.org/support.html I was just trying to do so myself. If I do a Simple Search at https://bugs.freedesktop.org/query.cgi I can choose the "Spice" product, but I found nothing. So I attempted to file a new bug and I must pick a product on which to enter the bug, but there "Spice" is not an option. Huh? ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/ZZKIRK3CHZTJ6AAEQAOZOSXFFAGLIRE4/
[ovirt-users] Re: Missing step(s) after custom x509 certificates
On 2018-06-20 02:27, Yedidyah Bar David wrote: On Tue, Jun 19, 2018 at 5:35 PM, John Florian wrote: I already had the intermediate and root CA certs imported into Android, but it looks like moVirt ignores those as a general trust source. I'd say this might be a useful RFE to open on movirt, whatever its specific behavior currently is. It should be easy to make it trust the machine's trust store, perhaps by default. Done: https://github.com/oVirt/moVirt/issues/304 ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/T4AXKNAASESNTKSJD74IJDKR4BXL5XPU/
[ovirt-users] Re: Missing step(s) after custom x509 certificates
On 2018-06-19 02:57, Yedidyah Bar David wrote: > On Mon, Jun 18, 2018 at 4:19 PM, John Florian wrote: >> On 2018-06-18 02:46, Yedidyah Bar David wrote: >>> On Mon, Jun 18, 2018 at 9:19 AM, Tomas Jelinek >>> wrote: >>>> >>>> On Mon, Jun 18, 2018 at 8:01 AM, Yedidyah Bar David >>>> wrote: >>>>> On Sun, Jun 17, 2018 at 6:11 PM, John Florian >>>>> wrote: >>>>>> I followed the docs at >>>>>> https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL/ and >>>>>> all >>>>>> works well from the usual web portal. Went to test moVirt and ran into >>>>>> a >>>>>> snag. It wants to download the CA using >>>>>> >>>>>> >>>>>> http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA, >>>>> I never tried movirt, but the user's guide [1] says it can import >>>>> user-supplied certs, so you can supply your own CA's cert, no? >>>> >>>> correct, you can supply your own certificate, movirt just by default >>>> grabs >>>> the one which is provided by engine at: >>>> >>>> http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA >>>> >>>> @Ravi: is it correct that after you provide your own CA that the >>>> >>>> http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA >>>> is still pointing to the old one? >>> Yes - check this: >>> >>> https://ovirt.org/develop/release-management/features/infra/pki/#services >>> >>> It does not have a resource "apache-certificate" or anything like that. >>> The assumption is that user that changes httpd's conf to use a 3rd-party >>> CA, >>> is in control of it, not the engine - so the engine can't handle it. This >>> is >>> even if the user followed the documentation, because in principle, the >>> user >>> can do other things - e.g. point SSLCACertificateFile at a different file >>> instead of replacing the content of the existing apache-ca.pem (which >>> defaults >>> to a symlink to ca.pem, which _is_ controlled by the engine (as in "we do >>> not >>> have any documentation about how to replace it, and doing that will break >>> many >>> flows"). >> Okay, this is what threw me. The docs are written in such a way that I >> never touch httpd's conf, as if maybe I am not supposed to do that. The >> docs have me change the target of a symlink and do other swaps and avoids >> touching the conf, be it intentional or not. I may have inferred too much >> based on the approach. > I don't remember every exact detail in the docs, but I do know the relevant > code. > > The engine (itself) runs as user ovirt, and can't touch or do anything to your > httpd conf. > > engine-setup is basically the only thing [1] that runs as root and touches > httpd conf. It asks you some stuff, and does (currently) only these things: > > 1. Always add /etc/httpd/conf.d/z-ovirt-engine-proxy.conf . This file is > considered to be "owned" by engine-setup and can be changed as needed by > upgrades. So you are not supposed to touch it. > > 2. Optionally add /etc/httpd/conf.d/ovirt-engine-root-redirect.conf which > does a very simple redirect from '/' to '/ovirt-engine'. I am not aware of > anyone not doing this, and guess things might not work perfectly, and also > that it might be unsupported, but in principle you can reply 'no', and then > have other web apps on the engine machine. See also [2]. This is _not_ done > on upgrades - so if you reply 'yes', then remove the file, then run > 'engine-setup' again, it should not re-add the file. > > 3. Optionally edit ssl.conf, which is the subject of current thread. This > one also used to be not done on upgrades, but this recently changed [3][4]. > > This is considered mandatory and the only supported flow in production. > If you reply 'no', you are supposed to configure apache manually. > > However, for development, you can talk to jboss directly [5]. This used to > be possible also in production in very old releases, see e.g. [6]. > > So, to summarize: > > We (engine developers, engine-setup in particular) try to be "good citizens" > and not take control of the machine, allowing the admin do what s/he wants, > and still try hard to make the engine work nicely. But we default to do > "take over", and (IIRC) only document the defau
[ovirt-users] Re: remote-viewer Spice Problem on MacOS
Count me affected too, but like others here, only started having problems after upgrading from 4.1.8 to 4.2.3 . I've also noticed the it seems to affect mostly/only my CentOS (all 7.5) VMs, but only after they've been up for a while. I also have several Fedora 27/28 VMs and those don't seem to be affected. I'm running virt-viewer on Fedora 28 (virt-viewer-6.0-3.fc28.x86_64). I've had better luck with moVirt, but have been fighting an issue[0] there that may or may not be related. Again, the moVirt issue only appeared after upgrading to 4.2. [0] Console option not always available (https://github.com/oVirt/moVirt/issues/303) On 2018-06-18 15:21, Jeff Bailey wrote: > I've been seeing similar behavior but when running virt-viewer on > windows. I only noticed it after updating to 4.2 but for me it seems > to only happen with guests running CentOS 7.5 and then only after a > while like it's related to the console going blank from being idle. > Using aspice from movirt has no problem and using vnc also works fine. > Connecting with either of those, hitting a key and then disconnecting > and switching to the windows spice client fixes it for a while. > Updating to remote-viewer 6.0-256 made no difference. > > On 6/18/2018 5:09 AM, hpey...@plusline.net wrote: >> Hi all, >> >> we are currently experiencing a weird problem with oVirt and the >> spice console on MacOS: >> Occasionally when our Mac Users are connecting to a Spice Console of >> any oVirt VM it opens the usual window but just displays the message: >> "Connected to graphic server". When a Linux user now connects to it >> and closes the connection the Mac user can also connect again normally. >> >> I have tried https://www.spice-space.org/osx-client.html and >> https://rizvir.com/articles/ovirt-mac-console/ with exactly the same >> behaviour. The Issue appears on several different MacOS Versions and >> we believe it started after our upgrade to oVirt 4.2. >> >> MacOS Version: 10.13.5 >> oVirt Version: 4.2.3.8-1.el7 >> >> Any help or suggestion is greatly appreciated. >> >> Best regards, >> Hendrik >> ___ >> Users mailing list -- users@ovirt.org >> To unsubscribe send an email to users-le...@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/ZQS676FGIRSLSXKSMIUEJAKY4RAVVA6F/ >> > ___ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-le...@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/MWFTUGIDZ74ZS2U7ZVR45MXAD5YSWIIZ/ -- John Florian ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/PTKXOKH2KBDVS6D6APL6HA5ZAWDAEKVW/
[ovirt-users] Missing step(s) after custom x509 certificates
I followed the docs at https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL/ and all works well from the usual web portal. Went to test moVirt and ran into a snag. It wants to download the CA using http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA, but that's grabbing the old CA issued by the engine rather than my custom CA. What else needs to be changed? I'm sure I can finagle my way to a fix here by telling moVirt to use a custom URL or file, but this looks like a bug in the docs that would probably best be fixed. -- John Florian ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/2DUNW4Y24HW4S5K4VGLIZRVR2K7BF37Z/
[ovirt-users] Re: Upgrade from 4.1 to 4.2.3 failed
On 05/15/2018 01:26 AM, Sahina Bose wrote: > > > On Tue, May 15, 2018 at 5:02 AM, John Florian <jflor...@doubledog.org > <mailto:jflor...@doubledog.org>> wrote: > > When I run engine-setup, I get this error: > > [ ERROR ] Yum [u'Errors were encountered while downloading > packages.', u'gdeploy-2.0.6-1.el7.noarch: failure: > gdeploy-2.0.6-1.el7.noarch.rpm from ovirt-4.1-centos-gluster38: > [Errno 256] No more mirrors to > > try.\nhttp://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/gdeploy-2.0.6-1.el7.noarch.rpm > > <http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/gdeploy-2.0.6-1.el7.noarch.rpm>: > [Errno 14] HTTP Error 404 - Not Found'] > [ ERROR ] Failed to execute stage 'Package installation': > [u'Errors were encountered while downloading packages.', > u'gdeploy-2.0.6-1.el7.noarch: failure: > gdeploy-2.0.6-1.el7.noarch.rpm from ovirt-4.1-centos-gluster38: > [Errno 256] No more mirrors to > > try.\nhttp://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/gdeploy-2.0.6-1.el7.noarch.rpm > > <http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/gdeploy-2.0.6-1.el7.noarch.rpm>: > [Errno 14] HTTP Error 404 - Not Found'] > > If I go exploring with my browser, it doesn't appear that > http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8 > <http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8> > exists any more. The oldest there is 3.10. I didn't see any > mention of needing to revise this repo config, but I obviously > must have missed something. > > > This is discussed in thread > https://www.mail-archive.com/users@ovirt.org/msg48116.html > > You can edit the repo file to add the latest 3.12 gluster repo Seeing that the 3.12 repo was enabled as part of ovirt-release42-4.2.3-1.el7.centos.noarch I just disabled the unreachable repo for 3.8. That got my engine upgraded to 4.2.3. Now I'm trying to tackle my two hosts. I put the first into maintenance and then tried the upgrade through the web UI but this failed. I tried running a yum update from a shell on that host and found a similar problem, now with ovirt-4.1 repo. So I disabled that, retried the yum update and got/applied lots of updates to bring the host up to CentOS 7.5. I then retried the upgrade through the web UI and this is still failing and I'm having trouble figuring out why. What logs do I need to be looking at for host upgrades? -- John Florian ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org
[ovirt-users] Upgrading 4.1 to 4.2.3 -- which gluster repo?
I'm not using gluster, my storage is all via iSCSI. Given that http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8 is now causing yum failures when I try to run engine-setup, what should I do? -- John Florian ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org
[ovirt-users] Upgrade from 4.1 to 4.2.3 failed
When I run engine-setup, I get this error: [ ERROR ] Yum [u'Errors were encountered while downloading packages.', u'gdeploy-2.0.6-1.el7.noarch: failure: gdeploy-2.0.6-1.el7.noarch.rpm from ovirt-4.1-centos-gluster38: [Errno 256] No more mirrors to try.\nhttp://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/gdeploy-2.0.6-1.el7.noarch.rpm: [Errno 14] HTTP Error 404 - Not Found'] [ ERROR ] Failed to execute stage 'Package installation': [u'Errors were encountered while downloading packages.', u'gdeploy-2.0.6-1.el7.noarch: failure: gdeploy-2.0.6-1.el7.noarch.rpm from ovirt-4.1-centos-gluster38: [Errno 256] No more mirrors to try.\nhttp://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/gdeploy-2.0.6-1.el7.noarch.rpm: [Errno 14] HTTP Error 404 - Not Found'] If I go exploring with my browser, it doesn't appear that http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8 exists any more. The oldest there is 3.10. I didn't see any mention of needing to revise this repo config, but I obviously must have missed something. -- John Florian ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org
Re: [ovirt-users] Can I reduce the Java heap size of engine-backup???
On 12/31/2015 10:42 AM, Juan Hernández wrote: > On 12/31/2015 08:48 AM, Yedidyah Bar David wrote: >> On Wed, Dec 30, 2015 at 7:50 PM, John Florian <jflor...@doubledog.org> wrote: >>> On 12/29/2015 02:02 AM, Yedidyah Bar David wrote: >>>> On Tue, Dec 29, 2015 at 12:51 AM, John Florian <jflor...@doubledog.org> >>>> wrote: >>>>> I'm trying to run the engine-backup script via a Bacula job using the >>>>> RunScript option so that the engine-backup dumps its output someplace >>>>> where Bacula will collect it once engine-backup finishes. However the >>>>> job is failing and with enough digging I eventually learned the script >>>>> was writing the following in /tmp/hs_err_pid5789.log: >>>>> >>>>> # >>>>> # There is insufficient memory for the Java Runtime Environment to >>>>> continue. >>>>> # Native memory allocation (mmap) failed to map 2555904 bytes for >>>>> committing reserved memory. >>>>> # Possible reasons: >>>>> # The system is out of physical RAM or swap space >>>>> # In 32 bit mode, the process size limit was hit >>>>> # Possible solutions: >>>>> # Reduce memory load on the system >>>>> # Increase physical memory or swap space >>>>> # Check if swap backing store is full >>>>> # Use 64 bit Java on a 64 bit OS >>>>> # Decrease Java heap size (-Xmx/-Xms) >>>>> # Decrease number of Java threads >>>>> # Decrease Java thread stack sizes (-Xss) >>>>> # Set larger code cache with -XX:ReservedCodeCacheSize= >>>>> # This output file may be truncated or incomplete. >>>>> # >>>>> # Out of Memory Error (os_linux.cpp:2627), pid=5789, tid=140709998221056 >>>>> # >>>>> # JRE version: (8.0_65-b17) (build ) >>>>> # Java VM: OpenJDK 64-Bit Server VM (25.65-b01 mixed mode linux-amd64 >>>>> compressed oops) >>>>> # Failed to write core dump. Core dumps have been disabled. To enable >>>>> core dumping, try "ulimit -c unlimited" before starting Java again >>>>> # >>>>> >>>>> >>>>> So is there any good way to reduce the Java heap size? I mean I know >>>>> what -Xmx does, but where might I try setting it, ideally so that it >>>>> affects the engine-backup only? Any idea of good setting for a very >>>>> small environment with a dozen VMs? >>>> engine-backup does not directly call nor need java. >>>> >>>> AFAICS it only calls it indirectly as part of some other initialization >>>> by running java-home [1], which is a script that decides what JAVA_HOME >>>> to use for the engine. This script only runs 'java -version', which imo >>>> should not need that much memory. Perhaps there is something else I do >>>> not fully understand, such as bacula severely limiting available resources >>>> for the process it runs, or something like that. >>>> >>>> If you only want to debug it, and not as a recommended final solution, >>>> you can create a script [2] which only outputs the needed java home. >>>> Simply run [1] and make [2] echo the same thing. If [2] exists, [1] will >>>> only run it and nothing else, as you can see inside it. >>>> >>>> I do not think this will work - quite likely engine-backup will fail >>>> shortly later, if indeed it gets access to so little memory. Please >>>> report back. Thanks and good luck, >>>> >>>> [1] /usr/share/ovirt-engine/bin/java-home >>>> [2] /usr/share/ovirt-engine/bin/java-home.local >>> Thanks for the info and response Didi. Doing the above did allow the >>> backup to run successfully. >> OK. >> >>> I had also replaced the Bacula RunScript >>> with "bash -c ulimit" which reported unlimited but I don't play with >>> those types of limits enough to know if that's correctly reporting to >>> what engine-backup is constrained. >> And was this enough? >> >>> I did occur to me that perhaps a >>> better way to learn of any such constraints would be to query Bacula's >>> file daemon (the only necessary Bacula component running on client >>> systems that are getting backed up) since I suspect it must be this >>> component that's actually spawning the RunScript client side. F
Re: [ovirt-users] Can I reduce the Java heap size of engine-backup???
On 12/29/2015 02:02 AM, Yedidyah Bar David wrote:
> On Tue, Dec 29, 2015 at 12:51 AM, John Florian <jflor...@doubledog.org> wrote:
>> I'm trying to run the engine-backup script via a Bacula job using the
>> RunScript option so that the engine-backup dumps its output someplace
>> where Bacula will collect it once engine-backup finishes. However the
>> job is failing and with enough digging I eventually learned the script
>> was writing the following in /tmp/hs_err_pid5789.log:
>>
>> #
>> # There is insufficient memory for the Java Runtime Environment to continue.
>> # Native memory allocation (mmap) failed to map 2555904 bytes for
>> committing reserved memory.
>> # Possible reasons:
>> # The system is out of physical RAM or swap space
>> # In 32 bit mode, the process size limit was hit
>> # Possible solutions:
>> # Reduce memory load on the system
>> # Increase physical memory or swap space
>> # Check if swap backing store is full
>> # Use 64 bit Java on a 64 bit OS
>> # Decrease Java heap size (-Xmx/-Xms)
>> # Decrease number of Java threads
>> # Decrease Java thread stack sizes (-Xss)
>> # Set larger code cache with -XX:ReservedCodeCacheSize=
>> # This output file may be truncated or incomplete.
>> #
>> # Out of Memory Error (os_linux.cpp:2627), pid=5789, tid=140709998221056
>> #
>> # JRE version: (8.0_65-b17) (build )
>> # Java VM: OpenJDK 64-Bit Server VM (25.65-b01 mixed mode linux-amd64
>> compressed oops)
>> # Failed to write core dump. Core dumps have been disabled. To enable
>> core dumping, try "ulimit -c unlimited" before starting Java again
>> #
>>
>>
>> So is there any good way to reduce the Java heap size? I mean I know
>> what -Xmx does, but where might I try setting it, ideally so that it
>> affects the engine-backup only? Any idea of good setting for a very
>> small environment with a dozen VMs?
> engine-backup does not directly call nor need java.
>
> AFAICS it only calls it indirectly as part of some other initialization
> by running java-home [1], which is a script that decides what JAVA_HOME
> to use for the engine. This script only runs 'java -version', which imo
> should not need that much memory. Perhaps there is something else I do
> not fully understand, such as bacula severely limiting available resources
> for the process it runs, or something like that.
>
> If you only want to debug it, and not as a recommended final solution,
> you can create a script [2] which only outputs the needed java home.
> Simply run [1] and make [2] echo the same thing. If [2] exists, [1] will
> only run it and nothing else, as you can see inside it.
>
> I do not think this will work - quite likely engine-backup will fail
> shortly later, if indeed it gets access to so little memory. Please
> report back. Thanks and good luck,
>
> [1] /usr/share/ovirt-engine/bin/java-home
> [2] /usr/share/ovirt-engine/bin/java-home.local
Thanks for the info and response Didi. Doing the above did allow the
backup to run successfully. I had also replaced the Bacula RunScript
with "bash -c ulimit" which reported unlimited but I don't play with
those types of limits enough to know if that's correctly reporting to
what engine-backup is constrained. I did occur to me that perhaps a
better way to learn of any such constraints would be to query Bacula's
file daemon (the only necessary Bacula component running on client
systems that are getting backed up) since I suspect it must be this
component that's actually spawning the RunScript client side. From the
Bacula Director (server side) I queried the status of the client which
is my oVirt engine and it reports:
europa.doubledog.org-fd Version: 5.2.13 (19 February 2013)
x86_64-redhat-linux-gnu redhat (Core)
Daemon started 28-Dec-15 16:08. Jobs: run=2 running=0.
Heap: heap=32,768 smbytes=190,247 max_bytes=1,599,864 bufs=100
max_bufs=6,758
Sizeof: boffset_t=8 size_t=8 debug=0 trace=0
Alas, I know of no way to increase any of the bacula-fd limits. If I
dead-end here, perhaps I'll query the Bacula mailing lists.
Meanwhile I tried the following for a more permanent solution but this
failed same as before:
# diff -u java-home.orig-3.6.1.3 java-home
--- java-home.orig-3.6.1.3 2015-12-10 13:07:44.0 -0500
+++ java-home 2015-12-30 12:12:45.779462769 -0500
@@ -13,7 +13,7 @@
local ret=1
if [ -x "${dir}/bin/java" ]; then
- local version="$("${dir}/bin/java" -version 2>&1 | sed \
+ local version="$("${dir}/bin/java" -Xmx 8 -version 2>&1
| sed \
-e 's/^openjdk version "1\.8\.0.*/VERSION_OK/' \
[ovirt-users] Can I reduce the Java heap size of engine-backup???
I'm trying to run the engine-backup script via a Bacula job using the RunScript option so that the engine-backup dumps its output someplace where Bacula will collect it once engine-backup finishes. However the job is failing and with enough digging I eventually learned the script was writing the following in /tmp/hs_err_pid5789.log: # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 2555904 bytes for committing reserved memory. # Possible reasons: # The system is out of physical RAM or swap space # In 32 bit mode, the process size limit was hit # Possible solutions: # Reduce memory load on the system # Increase physical memory or swap space # Check if swap backing store is full # Use 64 bit Java on a 64 bit OS # Decrease Java heap size (-Xmx/-Xms) # Decrease number of Java threads # Decrease Java thread stack sizes (-Xss) # Set larger code cache with -XX:ReservedCodeCacheSize= # This output file may be truncated or incomplete. # # Out of Memory Error (os_linux.cpp:2627), pid=5789, tid=140709998221056 # # JRE version: (8.0_65-b17) (build ) # Java VM: OpenJDK 64-Bit Server VM (25.65-b01 mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # So is there any good way to reduce the Java heap size? I mean I know what -Xmx does, but where might I try setting it, ideally so that it affects the engine-backup only? Any idea of good setting for a very small environment with a dozen VMs? -- John Florian ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] 3.6.1 HE install on CentOS 7.2 resulted in unsync'd network
On 12/19/2015 05:53 AM, Gianluca Cecchi wrote: > On Sat, Dec 19, 2015 at 1:08 AM, John Florian <jflor...@doubledog.org > <mailto:jflor...@doubledog.org>> wrote: > > I'm trying to get a 3.6.1 HE setup going where I have 4 VLANs > (VIDs 101-104) for storage networks, 1 VLAN (VID 100) for > ovirtmgmt and 1 more (VID 1) for everything else. Because I know > of no way to manipulate the network configuration from the > management GUI once the HE is running and with only a single Host, > I made the OS configuration as close as possible to what I'd want > when done. This looks like: > > > Why do you think of this necessary pre-work? Because my storage is iSCSI and I need the VLAN configuration in place for the Host to access it on behalf of the HE. Otherwise, yes I agree it would be easier to let the hosted-engine script deal with the set up. I've done a workable setup before letting the script do everything, but the mode 4 bonding only gave me half the possible performance because in effect one NIC on the NAS did all the transmitting while the other NIC did all the receiving. So I really need all of the storage network setup in place prior to starting the HE deployment. It seems like it should be trivial to convince the engine that the two netmasks are indeed equivalent. I tried changing in /var/lib/vdsm/persistence/netconf/nets/ovirtmgmt the '"prefix": "24"' setting to '"netmask": "255.255.255.0"' and running /usr/share/vdsm/vdsm-restore-net-config but that didn't seem to change anything WRT the network being out of sync. > I configured (in 3.6.0) an environment with HE too on a single host > and I only preconfigured my bond1 in 802.3ad mode with the interfaces > I planned to use for ovirtmgmt and I left the other interfaces > unconfigured, so that all is not used by Network Manager. > During the "hosted-engine --deploy" setup I got this input: > >--== NETWORK CONFIGURATION ==-- > > Please indicate a nic to set ovirtmgmt bridge on: (em1, > bond1, em2) [em1]: bond1 > iptables was detected on your computer, do you wish setup to > configure it? (Yes, No)[Yes]: > Please indicate a pingable gateway IP address [10.4.168.254]: > > and then on preview of configuration to apply: > > --== CONFIGURATION PREVIEW ==-- > > Bridge interface : bond1 > Engine FQDN: ractorshe.mydomain.local > Bridge name: ovirtmgmt > > After setup I configured my vlan based networks for my VMS from the > GUI itself as in the usual way, so that now I have this bond0 created > by oVirt GUI on the other two interfaces (em1 and em2): > > [root@ractor ~]# cat /proc/net/bonding/bond0 > Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) > > Bonding Mode: IEEE 802.3ad Dynamic link aggregation > Transmit Hash Policy: layer2 (0) > MII Status: up > MII Polling Interval (ms): 100 > Up Delay (ms): 0 > Down Delay (ms): 0 > > 802.3ad info > LACP rate: fast > Min links: 0 > Aggregator selection policy (ad_select): stable > Active Aggregator Info: > Aggregator ID: 2 > Number of ports: 2 > Actor Key: 17 > Partner Key: 8 > Partner Mac Address: 00:01:02:03:04:0c > > Slave Interface: em1 > MII Status: up > Speed: 1000 Mbps > Duplex: full > Link Failure Count: 0 > Permanent HW addr: 00:25:64:ff:0b:f0 > Aggregator ID: 2 > Slave queue ID: 0 > > Slave Interface: em2 > MII Status: up > Speed: 1000 Mbps > Duplex: full > Link Failure Count: 0 > Permanent HW addr: 00:25:64:ff:0b:f2 > Aggregator ID: 2 > Slave queue ID: 0 > > And then "ip a" command returns: > > 9: bond0.65@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue master vlan65 state UP > link/ether 00:25:64:ff:0b:f0 brd ff:ff:ff:ff:ff:ff > 10: vlan65: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue > state UP > link/ether 00:25:64:ff:0b:f0 brd ff:ff:ff:ff:ff:ff > > with > [root@ractor ~]# brctl show > bridge namebridge idSTP enabledinterfaces > ;vdsmdummy;8000.no > ovirtmgmt8000.002564ff0bf4nobond1 > vnet0 > vlan658000.002564ff0bf0nobond0.65 > vnet1 > vnet2 > > vnet1 and vnet2 being the virtual network interfaces of my two running > VMs. > > The only note I can submit is that by default when you set a network > in oVirt GUI with mode=4 (802.3ad), it defaults to configuring it wit
[ovirt-users] 3.6.1 HE install on CentOS 7.2 resulted in unsync'd network
I'm trying to get a 3.6.1 HE setup going where I have 4 VLANs (VIDs 101-104) for storage networks, 1 VLAN (VID 100) for ovirtmgmt and 1 more (VID 1) for everything else. Because I know of no way to manipulate the network configuration from the management GUI once the HE is running and with only a single Host, I made the OS configuration as close as possible to what I'd want when done. This looks like: [root@orthosie ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovirtmgmt state UP link/ether 78:2b:cb:3c:da:02 brd ff:ff:ff:ff:ff:ff 3: em1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000 link/ether 78:2b:cb:3c:da:02 brd ff:ff:ff:ff:ff:ff 4: em2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000 link/ether 78:2b:cb:3c:da:02 brd ff:ff:ff:ff:ff:ff 5: em3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000 link/ether 78:2b:cb:3c:da:02 brd ff:ff:ff:ff:ff:ff 6: em4: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000 link/ether 78:2b:cb:3c:da:02 brd ff:ff:ff:ff:ff:ff 8: bond0.1@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 78:2b:cb:3c:da:02 brd ff:ff:ff:ff:ff:ff inet 172.16.7.8/24 brd 172.16.7.255 scope global bond0.1 valid_lft forever preferred_lft forever inet6 fe80::7a2b:cbff:fe3c:da02/64 scope link valid_lft forever preferred_lft forever 9: bond0.101@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 78:2b:cb:3c:da:02 brd ff:ff:ff:ff:ff:ff inet 192.168.101.203/24 brd 192.168.101.255 scope global bond0.101 valid_lft forever preferred_lft forever inet6 fe80::7a2b:cbff:fe3c:da02/64 scope link valid_lft forever preferred_lft forever 10: bond0.102@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 78:2b:cb:3c:da:02 brd ff:ff:ff:ff:ff:ff inet 192.168.102.203/24 brd 192.168.102.255 scope global bond0.102 valid_lft forever preferred_lft forever inet6 fe80::7a2b:cbff:fe3c:da02/64 scope link valid_lft forever preferred_lft forever 11: bond0.103@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 78:2b:cb:3c:da:02 brd ff:ff:ff:ff:ff:ff inet 192.168.103.203/24 brd 192.168.103.255 scope global bond0.103 valid_lft forever preferred_lft forever inet6 fe80::7a2b:cbff:fe3c:da02/64 scope link valid_lft forever preferred_lft forever 12: bond0.104@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 78:2b:cb:3c:da:02 brd ff:ff:ff:ff:ff:ff inet 192.168.104.203/24 brd 192.168.104.255 scope global bond0.104 valid_lft forever preferred_lft forever inet6 fe80::7a2b:cbff:fe3c:da02/64 scope link valid_lft forever preferred_lft forever 13: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 78:2b:cb:3c:da:02 brd ff:ff:ff:ff:ff:ff inet 192.168.100.102/24 brd 192.168.100.255 scope global ovirtmgmt valid_lft forever preferred_lft forever The hosted-engine deploy script got stuck near the end when it wanted the HA broker to take over. It said the ovirtmgmt network was unavailable on the Host and suggested trying to activate it within the GUI. Though I had my bonding and bridging all configured prior to any HE deployment attempt (as shown above), the GUI didn’t see it that way. It knew of the bond, and the 4 IFs of course, but it showed all 4 IFs as down and the required ovirtmgmt network was off on the right side – effectively not yet associated with the physical devices. I dragged the ovirtmgmt net over to the left to associate it the 4 IFs and pressed Save. The GUI now shows all 4 IFs up with ovirtmgmt assigned. But it is not in sync -- specifically the netmask property on the host is "255.255.255.0" while on the DC its "24". They're saying the same thing; just in different ways. Since I only have the one Host, how can I sync this? -- John Florian ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Problem with hosted engine setup - vsdmd does not start
On 12/17/2015 08:16 AM, Willard Dennis wrote: > I checked and we do have a custom /etc/sudoers set — > > > [root@ovirt-node-01 vdsm]# cat /etc/sudoers > # > # NECLA custom /etc/sudoers > # > # *** Managed by Ansible; do not edit manually, > # file will be rewritten on next Ansible run! *** > # > # Do NOT add sudoers directly to this file; add them to the "wheel" group in > /etc/group > # > > Defaultsrequiretty > Defaults !visiblepw > Defaultsalways_set_home > Defaultsenv_reset > Defaultsenv_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR > LS_COLORS" > Defaultsenv_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE" > Defaultsenv_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT > LC_MESSAGES" > Defaultsenv_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE" > Defaultsenv_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET > XAUTHORITY" > Defaultssecure_path = /sbin:/bin:/usr/sbin:/usr/bin > root ALL=(ALL) ALL > %wheelALL=(ALL) ALL > > > What is missing / needs to be changed here to allow vdsmd to start correctly? The first thing I'd do is to move that file aside and reinstall the default from the package, i.e., yum/dnf reinstall sudo. Make sure ansible doesn't squash this while you test again. If that resolves the problem start looking at the differences between yours and the default to isolate what & why. If it doesn't resolve the problem then you need to look elsewhere of course. -- John Florian ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Moving a Hosted Engine from Fedora 20 to CentOS 7
I'm getting better results now but still no success. My attempts at rebuilding my host "ophelia" had a number of issues related to networking which was no surprise given that ovirtmgmt wasn't present. I believe this all stemmed from the initial conditions of the host and especially the ifcfg files for the two NICs. I had started with a clean install and did minimal changes but it was seeing too many weird issues to try and sort out at once. Plus once vdsm starts doing its thing managing these it's hard to say from where exactly I was starting. So. time for a fresh slate. Here are those results: First off, the mail Subject is wholly wrong anymore since I ran into really difficult sounding problems on that path. There's no CentOS involved right now, just Fedora. I don't know which is worse, changing the subject or leaving it wrong or prolonging a mail thread. Anyway, my current situation is: GOOD: oVirt 3.5.4 hosted engine on enceladus-f20 atop F20 GOOD: oVirt 3.5.4 host on oberon (also F20) PROBLEMS: attempting oVirt 3.6 on ophelia atop F22 The battle plan for oVirt 3.6 on ophelia: * installed F22 using minimal install option * initial networking setup immediately after installing F22: [root@ophelia ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:1f:d0:dc:27:af brd ff:ff:ff:ff:ff:ff 3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 68:05:ca:2f:f4:7c brd ff:ff:ff:ff:ff:ff inet 172.16.7.7/24 brd 172.16.7.255 scope global enp4s0 valid_lft forever preferred_lft forever inet6 fe80::6a05:caff:fe2f:f47c/64 scope link valid_lft forever preferred_lft forever 4: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default link/ether 3a:67:d6:86:11:71 brd ff:ff:ff:ff:ff:ff [root@ophelia ~]# cat /etc/resolv.conf # Generated by NetworkManager search doubledog.org nameserver 172.16.7.6 nameserver 172.16.7.154 * dnf update * edited /etc/ssh/sshd_config to add necessary KexAlgorithms * systemctl restart sshd * setenforce permissive so that vdsm can start o The Release Notes mention this is necessary for gluster. I'm only doing ISCSI but I must use permissive otherwise vdsm will not start later. This lesson already learned so applied here to keep the logs void of any confusion from this aspect. * dnf install http://resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm * dnf install ovirt-hosted-engine-setup * hosted-engine --deploy I'm still seeing the SQL error (in the engine log) that I mentioned in prior mails, though none of the networking issues I had on earlier attempts. Thus I believe I've made some progress but need advice on what to dig into next for y'all. Rather than pasting parts of the logs here, I've just dropped them in their entirety where they should be easily retrievable here: http://www.doubledog.org/john/ovirt-3.6-install-logs/attempt-10/ If additional logs are needed, please let me know. Thanks for all the help with this!!! -- John Florian ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Moving a Hosted Engine from Fedora 20 to CentOS 7
On 11/10/2015 03:39 AM, Yedidyah Bar David wrote: > On Tue, Nov 10, 2015 at 2:16 AM, John Florian <jflor...@doubledog.org> wrote: >> On 11/09/2015 06:25 PM, John Florian wrote: >>> I don't think it has anything to do with name resolution either. I >>> believe the telltale clue is this bit... 2015-11-09 18:22:31,738 WARN >>> [org.apache.sshd.client.session.ClientSessionImpl] (pool-20-thread-3) >>> Exception caught: java.lang.IllegalStateException: Unable to negotiate >>> key exchange for kex algorithms (client: diffie-hellman-group1-sha1 / >>> server: >>> curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1) >>> As mentioned, I can ssh from my engine to the host just fine. It >>> appears that the Java-based ssh client however cannot. >> I got past the above problem by adding the following line to the >> /etc/ssh/sshd_config of the new F22 host: >> >> KexAlgorithms >> curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 >> >> This represents the defaults for F22 -- at least according to >> sshd_config(5) -- but with the addition of diffie-hellman-group1-sha1 >> that the Java-based ssh client seems insistent on using. >> > Adding Alon for this. Not sure if we can configure the java ssh client > and how. > >> However, all is not rosy. The deploy script ground to a halt with: >> [ INFO ] Waiting for the host to become operational in the engine. This >> may take several minutes... >> The host hosted_engine_2 is in non-operational state. >> Please try to activate it via the engine webadmin UI. >> Retry checking host status or ignore this and continue (Retry, >> Ignore)[Retry]? >> >> So I did as suggested and tried to activate the host from the webadmin >> UI. That didn't work either. The status message at the bottom of the >> browser page shows: >> >> Host hosted_engine_2 is installed with VDSM version () and >> cannot join cluster Default which is compatible with VDSM versions >> [4.13, 4.14, 4.9, 4.16, 4.11, 4.15, 4.12, 4.10]. >> >> The attempt to activate the host via the web UI also caused the >> following to be logged on the engine: >> >> 2015-11-09 19:12:39,828 INFO >> [org.ovirt.engine.core.bll.ActivateVdsCommand] (ajp--127.0.0.1-8702-7) >> [4bf460e8] Lock Acquired to object EngineLock [exclusiveLocks= key: >> fab55ebe-cc0f-4f95-87aa-fc3a5e08a5df value: VDS >> , sharedLocks= ] >> 2015-11-09 19:12:39,838 INFO >> [org.ovirt.engine.core.bll.ActivateVdsCommand] >> (org.ovirt.thread.pool-8-thread-49) [4bf460e8] Running command: >> ActivateVdsCommand internal: false. Entities affected : ID: >> fab55ebe-cc0f-4f95-87aa-fc3a5e08a5df Type: VDSAction group >> MANIPULATE_HOST with role type ADMIN >> 2015-11-09 19:12:39,851 INFO >> [org.ovirt.engine.core.bll.ActivateVdsCommand] >> (org.ovirt.thread.pool-8-thread-49) [4bf460e8] Before acquiring lock in >> order to prevent monitoring for host hosted_engine_2 from data-center >> Default >> 2015-11-09 19:12:39,856 INFO >> [org.ovirt.engine.core.bll.ActivateVdsCommand] >> (org.ovirt.thread.pool-8-thread-49) [4bf460e8] Lock acquired, from now a >> monitoring of host will be skipped for host hosted_engine_2 from >> data-center Default >> 2015-11-09 19:12:39,861 INFO >> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] >> (org.ovirt.thread.pool-8-thread-49) [4bf460e8] START, >> SetVdsStatusVDSCommand(HostName = hosted_engine_2, HostId = >> fab55ebe-cc0f-4f95-87aa-fc3a5e08a5df, status=Unassigned, >> nonOperationalReason=NONE, stopSpmFailureLogged=false), log id: 1d206899 >> 2015-11-09 19:12:39,870 INFO >> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] >> (org.ovirt.thread.pool-8-thread-49) [4bf460e8] FINISH, >> SetVdsStatusVDSCommand, log id: 1d206899 >> 2015-11-09 19:12:39,888 INFO >> [org.ovirt.engine.core.bll.ActivateVdsCommand] >> (org.ovirt.thread.pool-8-thread-49) Activate finished. Lock released. >> Monitoring can run now for host hosted_engine_2 from data-center Default >> 2015-11-09 19:12:39,892 INFO >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] >> (org.ovirt.thread.pool-8-thread-49) Correlation ID: 4bf460e8, Job ID: >> 08a2b1ad-1c1c-425c-b657-7739df72b764, Call Stack: null, Custom Event ID: >> -1, Message: Host hosted_engine_2 was activated by admin@internal. &
Re: [ovirt-users] Moving a Hosted Engine from Fedora 20 to CentOS 7
On 11/10/2015 03:45 AM, Alon Bar-Lev wrote: > > - Original Message - >> From: "Yedidyah Bar David" <d...@redhat.com> >> To: "John Florian" <jflor...@doubledog.org>, "Alon Bar-Lev" >> <alo...@redhat.com>, "Roy Golan" <rgo...@redhat.com>, >> "Eli Mesika" <emes...@redhat.com> >> Cc: "users" <users@ovirt.org> >> Sent: Tuesday, November 10, 2015 10:39:27 AM >> Subject: Re: [ovirt-users] Moving a Hosted Engine from Fedora 20 to CentOS 7 >> >> On Tue, Nov 10, 2015 at 2:16 AM, John Florian <jflor...@doubledog.org> wrote: >>> On 11/09/2015 06:25 PM, John Florian wrote: >>>> I don't think it has anything to do with name resolution either. I >>>> believe the telltale clue is this bit... 2015-11-09 18:22:31,738 WARN >>>> [org.apache.sshd.client.session.ClientSessionImpl] (pool-20-thread-3) >>>> Exception caught: java.lang.IllegalStateException: Unable to negotiate >>>> key exchange for kex algorithms (client: diffie-hellman-group1-sha1 / >>>> server: >>>> curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1) >>>> As mentioned, I can ssh from my engine to the host just fine. It >>>> appears that the Java-based ssh client however cannot. >>> I got past the above problem by adding the following line to the >>> /etc/ssh/sshd_config of the new F22 host: >>> >>> KexAlgorithms >>> curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 >>> >>> This represents the defaults for F22 -- at least according to >>> sshd_config(5) -- but with the addition of diffie-hellman-group1-sha1 >>> that the Java-based ssh client seems insistent on using. >>> >> Adding Alon for this. Not sure if we can configure the java ssh client >> and how. >> > I think that newer than apache-sshd-0.14 altered its behavior, can you please > try to downgrade to apache-sshd-0.13 and see if it helps, if it does we will > enforce it. Only in apache-sshd-1.1.0 (unreleased) we will be able to migrate > properly (I hope). This is my fault. I see now that this was mentioned in the 3.6.0 release notes as a Fedora 22 specific issue (see also https://bugzilla.redhat.com/show_bug.cgi?id=1225531). The work around is just exactly as I mentioned above, though I figured it out, then read the release notes; doh! I don't even see an apache-sshd package installed on my engine (or hosts). >>> However, all is not rosy. The deploy script ground to a halt with: >>> [ INFO ] Waiting for the host to become operational in the engine. This >>> may take several minutes... >>> The host hosted_engine_2 is in non-operational state. >>> Please try to activate it via the engine webadmin UI. >>> Retry checking host status or ignore this and continue (Retry, >>> Ignore)[Retry]? >>> >>> So I did as suggested and tried to activate the host from the webadmin >>> UI. That didn't work either. The status message at the bottom of the >>> browser page shows: >>> >>> Host hosted_engine_2 is installed with VDSM version () and >>> cannot join cluster Default which is compatible with VDSM versions >>> [4.13, 4.14, 4.9, 4.16, 4.11, 4.15, 4.12, 4.10]. >>> >>> The attempt to activate the host via the web UI also caused the >>> following to be logged on the engine: >>> >>> 2015-11-09 19:12:39,828 INFO >>> [org.ovirt.engine.core.bll.ActivateVdsCommand] (ajp--127.0.0.1-8702-7) >>> [4bf460e8] Lock Acquired to object EngineLock [exclusiveLocks= key: >>> fab55ebe-cc0f-4f95-87aa-fc3a5e08a5df value: VDS >>> , sharedLocks= ] >>> 2015-11-09 19:12:39,838 INFO >>> [org.ovirt.engine.core.bll.ActivateVdsCommand] >>> (org.ovirt.thread.pool-8-thread-49) [4bf460e8] Running command: >>> ActivateVdsCommand internal: false. Entities affected : ID: >>> fab55ebe-cc0f-4f95-87aa-fc3a5e08a5df Type: VDSAction group >>> MANIPULATE_HOST with role type ADMIN >>> 2015-11-09 19:12:39,851 INFO >>> [org.ovirt.engine.core.bll.ActivateVdsCommand] >>> (org.ovirt.thread.pool-8-thread-49) [4bf460e8] Before acquiring lock in >>> order to prevent monitoring for host hosted_engine_2 from data-center >>> Default >>> 2015-11-09 19:12:39,856 INFO >
Re: [ovirt-users] Moving a Hosted Engine from Fedora 20 to CentOS 7
On 11/09/2015 06:25 PM, John Florian wrote: > I don't think it has anything to do with name resolution either. I > believe the telltale clue is this bit... 2015-11-09 18:22:31,738 WARN > [org.apache.sshd.client.session.ClientSessionImpl] (pool-20-thread-3) > Exception caught: java.lang.IllegalStateException: Unable to negotiate > key exchange for kex algorithms (client: diffie-hellman-group1-sha1 / > server: > curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1) > As mentioned, I can ssh from my engine to the host just fine. It > appears that the Java-based ssh client however cannot. I got past the above problem by adding the following line to the /etc/ssh/sshd_config of the new F22 host: KexAlgorithms curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 This represents the defaults for F22 -- at least according to sshd_config(5) -- but with the addition of diffie-hellman-group1-sha1 that the Java-based ssh client seems insistent on using. However, all is not rosy. The deploy script ground to a halt with: [ INFO ] Waiting for the host to become operational in the engine. This may take several minutes... The host hosted_engine_2 is in non-operational state. Please try to activate it via the engine webadmin UI. Retry checking host status or ignore this and continue (Retry, Ignore)[Retry]? So I did as suggested and tried to activate the host from the webadmin UI. That didn't work either. The status message at the bottom of the browser page shows: Host hosted_engine_2 is installed with VDSM version () and cannot join cluster Default which is compatible with VDSM versions [4.13, 4.14, 4.9, 4.16, 4.11, 4.15, 4.12, 4.10]. The attempt to activate the host via the web UI also caused the following to be logged on the engine: 2015-11-09 19:12:39,828 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand] (ajp--127.0.0.1-8702-7) [4bf460e8] Lock Acquired to object EngineLock [exclusiveLocks= key: fab55ebe-cc0f-4f95-87aa-fc3a5e08a5df value: VDS , sharedLocks= ] 2015-11-09 19:12:39,838 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand] (org.ovirt.thread.pool-8-thread-49) [4bf460e8] Running command: ActivateVdsCommand internal: false. Entities affected : ID: fab55ebe-cc0f-4f95-87aa-fc3a5e08a5df Type: VDSAction group MANIPULATE_HOST with role type ADMIN 2015-11-09 19:12:39,851 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand] (org.ovirt.thread.pool-8-thread-49) [4bf460e8] Before acquiring lock in order to prevent monitoring for host hosted_engine_2 from data-center Default 2015-11-09 19:12:39,856 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand] (org.ovirt.thread.pool-8-thread-49) [4bf460e8] Lock acquired, from now a monitoring of host will be skipped for host hosted_engine_2 from data-center Default 2015-11-09 19:12:39,861 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (org.ovirt.thread.pool-8-thread-49) [4bf460e8] START, SetVdsStatusVDSCommand(HostName = hosted_engine_2, HostId = fab55ebe-cc0f-4f95-87aa-fc3a5e08a5df, status=Unassigned, nonOperationalReason=NONE, stopSpmFailureLogged=false), log id: 1d206899 2015-11-09 19:12:39,870 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (org.ovirt.thread.pool-8-thread-49) [4bf460e8] FINISH, SetVdsStatusVDSCommand, log id: 1d206899 2015-11-09 19:12:39,888 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand] (org.ovirt.thread.pool-8-thread-49) Activate finished. Lock released. Monitoring can run now for host hosted_engine_2 from data-center Default 2015-11-09 19:12:39,892 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-49) Correlation ID: 4bf460e8, Job ID: 08a2b1ad-1c1c-425c-b657-7739df72b764, Call Stack: null, Custom Event ID: -1, Message: Host hosted_engine_2 was activated by admin@internal. 2015-11-09 19:12:39,895 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand] (org.ovirt.thread.pool-8-thread-49) Lock freed to object EngineLock [exclusiveLocks= key: fab55ebe-cc0f-4f95-87aa-fc3a5e08a5df value: VDS , sharedLocks= ] 2015-11-09 19:12:40,263 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-12) [79b24fed] START, GetHardwareInfoVDSCommand(HostName = hosted_engine_2, HostId = fab55ebe-cc0f-4f95-87aa-fc3a5e08a5df, vds=Host[hosted_engine_2,fab55ebe-cc0f-4f95-87aa-fc3a5e08a5df]), log id: 7be846bb 2015-11-09 19:12:40,298 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-12) [79b24fed] FINISH, GetHardwareInfoVDSCommand, log id: 7be846bb 2015-11-09 19:12:40,326 INFO [org.ovirt.engine.core.bll.SetNonOperationalVdsCommand] (DefaultQuartzScheduler_Worker-12) [5569d8a6] Running command:
Re: [ovirt-users] Moving a Hosted Engine from Fedora 20 to CentOS 7
On 11/08/2015 04:16 AM, Yedidyah Bar David wrote: > On Sat, Nov 7, 2015 at 2:38 AM, John Florian <jflor...@doubledog.org> wrote: >> On 10/29/2015 05:49 AM, Roy Golan wrote: >> >> >> >> On Thu, Oct 29, 2015 at 11:39 AM, Roy Golan <rgo...@redhat.com> wrote: >>> >>> >>> On Wed, Oct 28, 2015 at 10:23 PM, John Florian <jflor...@doubledog.org> >>> wrote: >>>> Can somebody please point me to documentation or describe how I should >>>> proceed with this task? I see lots of pages for moving from a physical >>>> engine to a VM and vice-versa but am having no luck finding how to go >>>> about building a new HE to obsolete my original. >>>> >>> using ovirt-hosted-engine-setup you can choose a setup without using the >>> appliance. So you can scratch install your VM >> >> >> BTW the ovirt-engine-appliacnce we build [1] is Centos based. Seems like >> perfect candidate. >> >> #install the appliance >> yum install ovirt-engine-appliance >> >> #and then run the setup >> ovirt-hosted-engine-setup >> >> choose "disk" in this stage >> >> Please specify the device to boot the VM from (cdrom, disk, pxe) [cdrom]: >> disk >> >> it will suggest the downloaded appliance automatically >> >> See this wiki for reference >> http://www.ovirt.org/Features/HEApplianceFlow#Testing >> >> >> >> I'm afraid I'm lost here. Here's a map of my setup: >> >> oVirt 3.5.5 hosted engine is named enceladus-f20 (on Fedora 20) >> I have one oVirt 3.5.5 Host named oberon-f20 (also on Fedora 20) >> I previously had one other oVirt 3.5.5 Host named ophelia-f20 >> >> I took opehlia down, installed CentOS 7 on it and attempted a "hosted-engine >> --deploy". I can't remember if that was 3.5.5 or 3.6, but I could not add >> it to my cluster. From what I could gather enceladus-f20 provided an >> emulation type of pc1.0 while ophelia-c7 didn't seem to have anything that >> matched, the closest being just "pc". That looked hopelessly complicated to >> resolve so I thought I'd try again, but this time putting F22 on the ophelia >> and doing a 3.6 HE deploy saying yes to the redeploy prompt. This time I >> was met with: >> >> Checking for oVirt-Engine status at enceladus-f20.doubledog.org... >> >> [ INFO ] Engine replied: DB Up!Welcome to Health Status! >> >> [ ERROR ] Cannot automatically add the host to cluster Default: Cannot add >> Host. Connecting to host via SSH has failed, verify that the host is >> reachable (IP address, routable address etc.) You may refer to the >> engine.log file for further details. >> >> >> >> Please check Engine VM configuration. >> >> On enceladus-f20, I see: >> >> ==> /var/log/ovirt-engine/engine.log <== >> >> 2015-11-06 19:17:12,085 INFO >> [org.ovirt.engine.core.bll.aaa.LoginUserCommand] (ajp--127.0.0.1-8702-9) >> Running command: LoginUserCommand internal: false. >> >> 2015-11-06 19:17:12,128 INFO >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] >> (ajp--127.0.0.1-8702-9) Correlation ID: null, Call Stack: null, Custom Event >> ID: -1, Message: User admin@internal logged in. >> >> ==> /var/log/ovirt-engine/server.log <== >> >> 2015-11-06 19:17:13,654 INFO >> [org.apache.sshd.client.session.ClientSessionImpl] (pool-18-thread-1) Client >> session created >> >> 2015-11-06 19:17:13,663 INFO >> [org.apache.sshd.client.session.ClientSessionImpl] (pool-18-thread-2) Server >> version string: SSH-2.0-OpenSSH_6.9 >> >> 2015-11-06 19:17:13,667 WARN >> [org.apache.sshd.client.session.ClientSessionImpl] (pool-18-thread-3) >> Exception caught: java.lang.IllegalStateException: Unable to negotiate key >> exchange for kex algorithms (client: diffie-hellman-group1-sha1 / server: >> curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1) >> >> at >> org.apache.sshd.common.session.AbstractSession.negotiate(AbstractSession.java:1098) >> >> at >> org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:357) >> >> at >> org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:295) >> >> at >> org.apache.sshd.client.session.ClientSessionImpl.handleMessage(ClientSessionImpl.java:266) &g
Re: [ovirt-users] Moving a Hosted Engine from Fedora 20 to CentOS 7
On 10/29/2015 05:49 AM, Roy Golan wrote: > > > On Thu, Oct 29, 2015 at 11:39 AM, Roy Golan <rgo...@redhat.com > <mailto:rgo...@redhat.com>> wrote: > > > > On Wed, Oct 28, 2015 at 10:23 PM, John Florian > <jflor...@doubledog.org <mailto:jflor...@doubledog.org>> wrote: > > Can somebody please point me to documentation or describe how > I should > proceed with this task? I see lots of pages for moving from a > physical > engine to a VM and vice-versa but am having no luck finding > how to go > about building a new HE to obsolete my original. > > > using ovirt-hosted-engine-setup you can choose a setup without > using the appliance. So you can scratch install your VM > > > > BTW the ovirt-engine-appliacnce we build [1] is Centos based. Seems > like perfect candidate. > > #install the appliance > yum install ovirt-engine-appliance > > #and then run the setup > ovirt-hosted-engine-setup > > choose "disk" in this stage > Please specify the device to boot the VM from (cdrom, disk, pxe) [cdrom]: disk > > it will suggest the downloaded appliance automatically > See this wiki for reference > http://www.ovirt.org/Features/HEApplianceFlow#Testing > I'm afraid I'm lost here. Here's a map of my setup: oVirt 3.5.5 hosted engine is named enceladus-f20 (on Fedora 20) I have one oVirt 3.5.5 Host named oberon-f20 (also on Fedora 20) I previously had one other oVirt 3.5.5 Host named ophelia-f20 I took opehlia down, installed CentOS 7 on it and attempted a "hosted-engine --deploy". I can't remember if that was 3.5.5 or 3.6, but I could not add it to my cluster. From what I could gather enceladus-f20 provided an emulation type of pc1.0 while ophelia-c7 didn't seem to have anything that matched, the closest being just "pc". That looked hopelessly complicated to resolve so I thought I'd try again, but this time putting F22 on the ophelia and doing a 3.6 HE deploy saying yes to the redeploy prompt. This time I was met with: Checking for oVirt-Engine status at enceladus-f20.doubledog.org... [ INFO ] Engine replied: DB Up!Welcome to Health Status! [ ERROR ] Cannot automatically add the host to cluster Default: Cannot add Host. Connecting to host via SSH has failed, verify that the host is reachable (IP address, routable address etc.) You may refer to the engine.log file for further details. Please check Engine VM configuration. On enceladus-f20, I see: ==> /var/log/ovirt-engine/engine.log <== 2015-11-06 19:17:12,085 INFO [org.ovirt.engine.core.bll.aaa.LoginUserCommand] (ajp--127.0.0.1-8702-9) Running command: LoginUserCommand internal: false. 2015-11-06 19:17:12,128 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1-8702-9) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User admin@internal logged in. ==> /var/log/ovirt-engine/server.log <== 2015-11-06 19:17:13,654 INFO [org.apache.sshd.client.session.ClientSessionImpl] (pool-18-thread-1) Client session created 2015-11-06 19:17:13,663 INFO [org.apache.sshd.client.session.ClientSessionImpl] (pool-18-thread-2) Server version string: SSH-2.0-OpenSSH_6.9 2015-11-06 19:17:13,667 WARN [org.apache.sshd.client.session.ClientSessionImpl] (pool-18-thread-3) Exception caught: java.lang.IllegalStateException: Unable to negotiate key exchange for kex algorithms (client: diffie-hellman-group1-sha1 / server: curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1) at org.apache.sshd.common.session.AbstractSession.negotiate(AbstractSession.java:1098) at org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:357) at org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:295) at org.apache.sshd.client.session.ClientSessionImpl.handleMessage(ClientSessionImpl.java:266) at org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:720) at org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:277) at org.apache.sshd.common.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:54) at org.apache.sshd.common.io.nio2.Nio2Session$1.completed(Nio2Session.java:188) at org.apache.sshd.common.io.nio2.Nio2Session$1.completed(Nio2Session.java:174) at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) [rt.jar:1.7.0_79] at sun.nio.ch.Invoker$2.run(Invoker.java:218) [rt.jar:1.7.0_79] at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112) [rt.jar
Re: [ovirt-users] [ANN] oVirt 3.5.5 Final Release is now available
My hosts and engine are presently on Fedora 20 running oVirt 3.5.4 and I'd like to move to 3.5.5 on Fedora 21, but I don't see many of the rpms available. For example, where's ovirt-hosted-engine-setup-*.fc21.noarch? If I read this announcement correctly, this should be available, no? -- John Florian On 10/26/2015 07:51 AM, Sandro Bonazzola wrote: > The oVirt Project is pleased to announce the availability > of the oVirt 3.5.5 Final Release, as of October 26th, 2015. > > This release is available now for > Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar) and > Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar). > > This release supports Hypervisor Hosts running > Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar), > Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar) and > Fedora 21. > > This release of oVirt 3.5.5 includes updated packages for: > - oVirt Engine > - oVirt Hosted Engine HA > - oVirt Hosted Engine Setup > - VDSM > - oVirt Data Warehouse > - oVirt Reports > - oVirt Engine SDK > - oVirt Engine client > - QEMU KVM > > See the release notes [1] for a list of fixed bugs. > > Please refer to release notes [1] for Installation / Upgrade instructions. > a new oVirt Live ISO is already available [2]. > > Please note that mirrors[3] may need usually one day before being > synchronized. > > Please refer to the release notes for known issues in this release. > > [1] http://www.ovirt.org/OVirt_3.5.5_Release_Notes > [2] http://resources.ovirt.org/pub/ovirt-3.5/iso/ovirt-live/ > [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com <http://redhat.com> > > > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Moving a Hosted Engine from Fedora 20 to CentOS 7
On 10/29/2015 05:49 AM, Roy Golan wrote: > > > On Thu, Oct 29, 2015 at 11:39 AM, Roy Golan <rgo...@redhat.com > <mailto:rgo...@redhat.com>> wrote: > > > > On Wed, Oct 28, 2015 at 10:23 PM, John Florian > <jflor...@doubledog.org <mailto:jflor...@doubledog.org>> wrote: > > Can somebody please point me to documentation or describe how > I should > proceed with this task? I see lots of pages for moving from a > physical > engine to a VM and vice-versa but am having no luck finding > how to go > about building a new HE to obsolete my original. > > > using ovirt-hosted-engine-setup you can choose a setup without > using the appliance. So you can scratch install your VM > > > > BTW the ovirt-engine-appliacnce we build [1] is Centos based. Seems > like perfect candidate. > > #install the appliance > yum install ovirt-engine-appliance > > #and then run the setup > ovirt-hosted-engine-setup > > choose "disk" in this stage > Please specify the device to boot the VM from (cdrom, disk, pxe) [cdrom]: disk > > it will suggest the downloaded appliance automatically > See this wiki for reference > http://www.ovirt.org/Features/HEApplianceFlow#Testing > Neat! I was unaware of the HEA so I'm happy to learn of this offering. However, my concern is focused more on a procedure that I presently can only imagine looking something akin to: 1. hosted-engine --set-maintenance --mode=global 2. hosted-engine --vm-poweroff 3. ovirt-hosted-engine-setup ... 4. use the exact same host name and IP address 5. hosted-engine --vm-start 6. hosted-engine --set-maintenance --mode=none Or perhaps: 1. create a new guest 2. inside run foo to deploy the HE packages 3. configure it be aware of existing HE 4. run bar manually or wait for the two HE's to sync their state, sort of like a RAID mirror 5. power off the original HE guest and allow the new one to be the sole provider going forward My confusion may simply stem from having forgot much of the process when I deployed my HE back in January this year. But I thought it best to get started on the right foot for the simplest and/or best practice. -- John Florian ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Moving a Hosted Engine from Fedora 20 to CentOS 7
Can somebody please point me to documentation or describe how I should proceed with this task? I see lots of pages for moving from a physical engine to a VM and vice-versa but am having no luck finding how to go about building a new HE to obsolete my original. -- John Florian ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Must the Hosted Engine be upgraded before the Hosts?
The upgrade documentation states to do so by way of a list of steps, but it doesn't say that it must be that way from what can I see. Does it matter? -- John Florian ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] [moVirt] Failed to open console client.
Hi Tomas, Thanks for the help. Installing the from github as you suggested looks to get me closer. I first uninstalled both aSPICE and bVNC that I'd installed from the play store. It now appears that moVirt is starting aSPICE at least, but now I'm confronted with Unable to connect or authenticate, please check server address, password and cert authority and subject. Is this because I have moVirt using https for the connection? (I see the moVirt README mentions: *Note* moVirt/aSPICE does not support SPICE secured connections at the moment!) If that's the case, I guess I'll live w/o consoles on my phone for now. I'd rather not send my ovirt admin password in plain-text since that'd be like providing physical access to every one of my critical VMs -- but maybe I'm just interpreting that note wrongly. On 03/27/2015 02:16 AM, Tomas Jelinek wrote: Hi, well, consoles are a bit tricky in moVirt. 1: There is a nice chance the stock aSPICE does not work yet and you need a newer version with some patches. You can get it from here: https://github.com/iiordanov/remote-desktop-clients/releases/download/v3.7.7/freeaSPICE-3.7.7-final.apk (maybe it is in play store already but not sure... just try that one please) 2: If this is not the issue there is a nice chance that your hosts are on a different network than your moVirt thus aSPICE /bVNC can not connect. You could verify this by installing some app which is able to ping from phone and try to ping your host from it. If it will not ping them and you don't want to expose the hosts directly, than the consoles are not going to work, because: 1: you could use SPICE PROXY - unfortunately aSPICE does not support it 2: you could use websocket proxy and connect from web clients (SPICE HTML5 or noVNC) - but moVirt does not integrate them since they need a connection to websocket proxy and in order to make a connection to websocket proxy you need a ticket signed by the private certificate of the engine. And the functionality of providing this is not exposed to REST API (only GWT-RPC) so we can not consume it. There is some bug around it and also some work being done around it so I think it will make into 3.6. But 3.6 is far far away... Hope the problem is just old aSPICE :) Tomas - John Florian jflor...@doubledog.org wrote: I just started playing with moVirt after I first heard about it here on this list. Wow, that's so much easier to use on my Galaxy S5 than the regular web interface. :-) Of course, now I want the whole bag of chips but can't seem to get the console working. When I press the console button I see Failed to open console client. Check if aSPICE/bVNC is installed.. I had already installed aSPICE from the Play Store but when that didn't work installed bVNC in addition; still no luck. My engine.log shows this when I try: 2015-03-26 19:52:14,750 INFO [org.ovirt.engine.core.bll.SetVmTicketCommand] (ajp--127.0.0.1-8702-10) [7f6f1f09] Running command: SetVmTicketCommand internal: false. Entities affected : ID: 6ca4e6ae-a201-432b-b22a-2c6517fbd92c Type: VMAction group CONNECT_TO_VM with role type USER 2015-03-26 19:52:14,752 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (ajp--127.0.0.1-8702-10) [7f6f1f09] START, SetVmTicketVDSCommand(HostName = hosted_engine_1, HostId = e90e2ca0-e3b9-46d5-8fde-09fc1c5eed20, vmId=6ca4e6ae-a201-432b-b22a-2c6517fbd92c, ticket=pd2lTiu7w7Ra, validTime=7200,m userName=admin, userId=fdfc627c-d875-11e0-90f0-83df133b58cc), log id: 6257f73 2015-03-26 19:52:14,766 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (ajp--127.0.0.1-8702-10) [7f6f1f09] FINISH, SetVmTicketVDSCommand, log id: 6257f73 2015-03-26 19:52:14,846 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1-8702-10) [7f6f1f09] Correlation ID: 7f6f1f09, Call Stack: null, Custom Event ID: -1, Message: user admin@internal initiated console session for VM krypto_f21 What am doing wrong? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] [moVirt] Failed to open console client.
I just started playing with moVirt after I first heard about it here on this list. Wow, that's so much easier to use on my Galaxy S5 than the regular web interface. :-) Of course, now I want the whole bag of chips but can't seem to get the console working. When I press the console button I see Failed to open console client. Check if aSPICE/bVNC is installed.. I had already installed aSPICE from the Play Store but when that didn't work installed bVNC in addition; still no luck. My engine.log shows this when I try: 2015-03-26 19:52:14,750 INFO [org.ovirt.engine.core.bll.SetVmTicketCommand] (ajp--127.0.0.1-8702-10) [7f6f1f09] Running command: SetVmTicketCommand internal: false. Entities affected : ID: 6ca4e6ae-a201-432b-b22a-2c6517fbd92c Type: VMAction group CONNECT_TO_VM with role type USER 2015-03-26 19:52:14,752 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (ajp--127.0.0.1-8702-10) [7f6f1f09] START, SetVmTicketVDSCommand(HostName = hosted_engine_1, HostId = e90e2ca0-e3b9-46d5-8fde-09fc1c5eed20, vmId=6ca4e6ae-a201-432b-b22a-2c6517fbd92c, ticket=pd2lTiu7w7Ra, validTime=7200,m userName=admin, userId=fdfc627c-d875-11e0-90f0-83df133b58cc), log id: 6257f73 2015-03-26 19:52:14,766 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (ajp--127.0.0.1-8702-10) [7f6f1f09] FINISH, SetVmTicketVDSCommand, log id: 6257f73 2015-03-26 19:52:14,846 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1-8702-10) [7f6f1f09] Correlation ID: 7f6f1f09, Call Stack: null, Custom Event ID: -1, Message: user admin@internal initiated console session for VM krypto_f21 What am doing wrong? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Troubles starting hosted engine
I have lots of extra fun bringing up my hosted engine right now due to two issues. First, either during the hosted-engine --deploy or engine-setup (I can't remember) I was prompted for the IP address of my gateway. Since then that address has changed. I'm unable to start the engine VM if that address isn't reachable so my temporary workaround is to add this old address onto the current gateway. How/where do I change things so that this old address can be truly retired? My second issue might be harder. Again during the setup I was prompted for a location of an ISO file for installing the engine's OS. That location is served by NFS and is auto-mounted by /etc/fstab (and systemd). Here's the hitch: my NFS server is now a VM in my cluster. :-) Since I only have a single hypervisor host right now that ISO isn't reachable when I'm trying to start my engine VM so that I can also start the VM that provides the NFS share. I'm getting away with evil right now by touching an empty file at the same path, which gets obscured once the NFS share is mounted, but it's enough. It's not at all clear to me how I'm supposed to edit things for my hosted engine setup. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Poor iSCSI Performance
Hi all, I've been trying to resolve a storage performance issue but have had no luck in identifying the exact cause. I have my storage domain on iSCSI and I can get the expected performance (limited by the Gbit Ethernet) when running bonnie++ on: * a regular physical machine configured with the iSCSI initiator connected to a dedicated iSCSI test target -- thus oVirt and VM technology are completely out of the picture * my oVirt host with the initiator connected to that same dedicated target -- thus I have an iSCSI connection on the oVirt host but I'm not using the iSCSI connection provided by oVirt's storage domain * a VM (hosted by oVirt) with the initiator (inside the VM) connected to that target -- thus bypassing oVirt's storage domain and the virtual disk it provides this VM However, if I just use a regular virtual disk via oVirt's storage domain the performance is much worse. I've tried both VirtIO and VirtIO-SCSI and have found no appreciable difference. Here's a typical example of the poor performance I get (as tested with bonnie++) with the normal virtual disk setup: # bonnie++ -d . -r 2048 -u root:root snip Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP narvi-f21.double 4G 806 91 18507 1 15675 1 3174 56 33175 1 176.4 3 Latency 15533us8142ms2440ms 262ms1289ms 780ms Version 1.96 --Sequential Create-- Random Create narvi-f21.doubledog -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 13641 24 + +++ 22702 17 18919 31 + +++ + +++ Latency 27724us 247us 292us 71us 30us 172us For comparison, here's what I see if I run the same test, same VM, same host but this time the file system is mounted from a device obtained using iscsi-initiator-utils within the VM, i.e., the 3rd bullet config above: bonnie++ -d . -r 2048 -u root:root snip Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP narvi-f21.double 4G 2051 89 103877 4 36286 3 4803 88 88166 4 163.6 3 Latency 7724us 191ms 396ms 48734us 73004us 1645ms Version 1.96 --Sequential Create-- Random Create narvi-f21.doubledog -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 6531 18 + +++ 16388 20 5924 15 + +++ 17906 23 Latency 15623us 64us 92us1281us 14us 256us My host is Fedora 20 running oVirt 3.5 (hosted-engine). VM is running Fedora Server 21. Tonight I tried updating the host with the Fedora virt preview repo and I didn't see any significant change in the performance. Where should I look next? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
