Content analysis details: (-1.0 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
Subject: Re: [ovirt-users] took the plunge to 4.2 but not so sure it was a
good idea
X-BeenThere: users(a)ovirt.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Main users mailing list for oVirt <users.ovirt.org>
List-Unsubscribe: <
http://lists.ovirt.org/mailman/options/users>,
<mailto:users-request@ovirt.org?subject=unsubscribe>
List-Archive: <
http://lists.ovirt.org/pipermail/users/>
List-Post: <mailto:users@ovirt.org>
List-Help: <mailto:users-request@ovirt.org?subject=help>
List-Subscribe: <
http://lists.ovirt.org/mailman/listinfo/users>,
<mailto:users-request@ovirt.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Dec 2017 02:34:20 -0000
On 12/23/2017 5:38 PM, Jason Keltz wrote:
Hi..
I took the plunge to 4.2, but I think maybe I should have waited a bit...
Initially, after upgrade to 4.2, the status of many of my hosts
changed from "server" to "desktop". That's okay - I can change
them
back.
My first VM, "archive", I had the ability to access console after the
upgrade. I rebooted archive, and I lost the ability (option is grayed
out). The VM boots, but I need access to the console.
My second VM is called "dist". That one, ovirt says is running, but
I can't access it, can't ping it, and there's no console either, so I
literally can't get to it. I can reboot it, and shut it down, but it
would be helpful to be able to access it. What to do?
I reinstalled "dist" because I needed the VM to be accessible on the
network. I was going to try detatching the disk from the existing dist
server, and attaching it to a new dist VM, but I ended up inadvertently
deleting the disk image. I can't believe that under "storage" you can't
detatch a disk from a VM - you can only delete the disk.
After reinstalling dist, I got back console, and network access! I
tried rebooting it several times, and console remains... so the loss of
console has something to do with switching from a 4.1 VM to 4.2.
I've very afraid to reboot my engine because it seems like when I
reboot hosts, I lose access to console.
I rebooted one more VM for which I had console access, and again, I've
lost it (at least network access remains). Now that this situation is
repeatable, I'm going one of the ovirt gurus can send me the magical DB
command to fix it. Probably not a solution to reinstall my 37 VMs
from kickstart.. that would be a headache.
In addition, when I try to check for "host updates", I get
an error
that it can't check for host updates. I ran a yum update on the hosts
(after upgrading repo to 4.2 and doing a yum update) and all I'm
looking for it to do is clear status, but it doesn't seem to work.
The error in engine.log when I try to update any of the hosts is:
2017-12-23 19:11:36,479-05 INFO
[org.ovirt.engine.core.bll.hostdeploy.HostUpgradeCheckCommand] (default
task-156) [ae11a704-3b40-45d3-9850-932f6ed91ed9] Running command:
HostUpgradeCheckCommand internal: false. Entities affected : ID:
45f8b331-842e-48e7-9df8-56adddb93836 Type: VDSAction group
EDIT_HOST_CONFIGURATION with role type ADMIN
2017-12-23 19:11:36,496-05 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-156) [] EVENT_ID: HOST_AVAILABLE_UPDATES_STARTED(884),
Started to check for available updates on host virt1.
2017-12-23 19:11:36,500-05 INFO
[org.ovirt.engine.core.bll.hostdeploy.HostUpgradeCheckInternalCommand]
(EE-ManagedThreadFactory-commandCoordinator-Thread-7)
[ae11a704-3b40-45d3-9850-932f6ed91ed9] Running command:
HostUpgradeCheckInternalCommand internal: true. Entities affected : ID:
45f8b331-842e-48e7-9df8-56adddb93836 Type: VDS
2017-12-23 19:11:36,504-05 INFO
[org.ovirt.engine.core.common.utils.ansible.AnsibleExecutor]
(EE-ManagedThreadFactory-commandCoordinator-Thread-7)
[ae11a704-3b40-45d3-9850-932f6ed91ed9] Executing Ansible command:
ANSIBLE_STDOUT_CALLBACK=hostupgradeplugin [/usr/bin/ansible-playbook,
--check, --private-key=/etc/pki/ovirt-engine/keys/engine_id_rsa,
--inventory=/tmp/ansible-inventory1039100972039373314,
/usr/share/ovirt-engine/playbooks/ovirt-host-upgrade.yml] [Logfile: null]
2017-12-23 19:11:37,897-05 INFO
[org.ovirt.engine.core.common.utils.ansible.AnsibleExecutor]
(EE-ManagedThreadFactory-commandCoordinator-Thread-7)
[ae11a704-3b40-45d3-9850-932f6ed91ed9] Ansible playbook command has
exited with value: 4
2017-12-23 19:11:37,897-05 ERROR
[org.ovirt.engine.core.bll.host.HostUpgradeManager]
(EE-ManagedThreadFactory-commandCoordinator-Thread-7)
[ae11a704-3b40-45d3-9850-932f6ed91ed9] Failed to run check-update of
host 'virt1-mgmt'.
2017-12-23 19:11:37,897-05 ERROR
[org.ovirt.engine.core.bll.hostdeploy.HostUpdatesChecker]
(EE-ManagedThreadFactory-commandCoordinator-Thread-7)
[ae11a704-3b40-45d3-9850-932f6ed91ed9] Failed to check if updates are
available for host 'virt1' with error message 'Failed to run
check-update of host 'virt1-mgmt'.'
2017-12-23 19:11:37,904-05 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-commandCoordinator-Thread-7)
[ae11a704-3b40-45d3-9850-932f6ed91ed9] EVENT_ID:
HOST_AVAILABLE_UPDATES_FAILED(839), Failed to check for available
updates on host virt1 with message 'Failed to run check-update of host
'virt1-mgmt'.'.
Jason.