
On Mon, Jul 10, 2017 at 6:42 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Mon, Jul 10, 2017 at 4:38 PM, Yedidyah Bar David <didi@redhat.com> wrote:
Currently I have set the environment in global maintenance. Does it make sense to try to start the HostedEngine with an alternate vm.conf to crosscheck it it is then able to start ok?
Not sure. Depends on why you think it currently fails. Sorry but I didn't check your logs yet.
Because in 4.1.2 it started. During update to 4.1.3 I moved the engine vm without problems to the already updated hosts. But I suppose during migration the qemu-kvm command line is preserverd, isn't it? And only when I planned to update kernel of the engine vm so I had to power off it, I began to have problems....
I see that there is the file /var/run/ovirt-hosted-engine-ha/vm.conf that seems refreshed every minute
Indeed. In recent versions it's possible to change some of the HE VM configuration from the engine itself, just like any other VM, so HA has to update this file.
It seems that apparently I can copy it into another place, modify it and try to start engine with the modified file using
hosted-engine --vm-start --vm-conf=/alternate/path_vm.conf
is it correct?
Yes, as also written here:
https://www.ovirt.org/documentation/how-to/hosted-engine/#handle-engine-vm-b...
the modified file would be such that:
[root@ovirt02 images]# diff /var/run/ovirt-hosted-engine-ha/vm.conf /root/alternate_vm.conf 1,2c1,2 < cpuType=Broadwell < emulatedMachine=pc-i440fx-rhel7.3.0 ---
cpuType=qemu64 emulatedMachine=pc-i440fx-rhel7.2.0 [root@ovirt02 images]#
No idea about your specific issue or whether this can fix it, but you can try. Especially if you can test on a test env...
Best, -- Didi
And in fact the engine vm is now up again with the customized parameters How can I have it permanent? Frome where on shared storage are they read?
I think you are supposed to change such parameters from the engine ui, not by directly manipulating the shared storage using [1]. But I didn't try this myself, not sure if cpu type can be changed. [1] http://www.ovirt.org/develop/release-management/features/sla/hosted-engine-e...
Possibly the problems is generated by my nested environment:
L0 = ESXi 6.0 U2 on NUC6i5syh L1 are my oVirt hosts on this L0 L2 is my engine VM that doesn't start in 4.1.3
it seems that cpuType=Broadwell and/or emulatedMachine=pc-i440fx-rhel7.3.0 generates problems....
No idea about this, adding Michal. Best,
And I think I would have same problems with ordinary VMs, correct? Gianluca
-- Didi