unable to migrate hosted-engine to oVirt 4.3 updated nodes
I'm seeing migration failures for the hosted-engine VM from a 4.28 node to a 4.30 node so I can complete the node upgrades. In one case I tried to force an update on the last node and now have a cluster where the hosted-engine VM fails to start properly. Sometimes something thinks the VM is running, but clicking for details it seems to have no disk. I was so close to putting that one into production with working LDAP user logins and custom SSL cert and then Oops! with the upgrade. In both cases the hosted VM storage is on gluster. One hyperconverged oVirt nodes, the other two nodes with an external gluster 5 server cluster I will note that I had set the engines previously (while at 4.2.8) to use the gluster direct method enabling (libgfapi disk access level 4.2) instead of the default fuse client for improved performance. Other details.... Engine was updated first. Nodes were updated with yum install https://resources.ovirt.org/pub/ovirt-4.3/rpm/el7/noarch/ovirt-node-ng-image... I forgot to mention another symptom. On the hyperconverged cluster, the "gluster volume heal engine" command errors out on 4.3, but other gluster volumes accepted it. rolling back to 4.28 allows the heal command to succeed (nothing to do actually) on engine, but I'm still unable to start a working engine VM with hosted-engine --vm-start
On Thu, Feb 7, 2019 at 8:57 AM Edward Berger <edwberger@gmail.com> wrote:
I'm seeing migration failures for the hosted-engine VM from a 4.28 node to a 4.30 node so I can complete the node upgrades.
You may be running into https://bugzilla.redhat.com/show_bug.cgi?id=1641798. Can you check the version of libvirt used on the nodes?
In one case I tried to force an update on the last node and now have a cluster where the hosted-engine VM fails to start properly. Sometimes something thinks the VM is running, but clicking for details it seems to have no disk. I was so close to putting that one into production with working LDAP user logins and custom SSL cert and then Oops! with the upgrade.
In both cases the hosted VM storage is on gluster. One hyperconverged oVirt nodes, the other two nodes with an external gluster 5 server cluster
I will note that I had set the engines previously (while at 4.2.8) to use the gluster direct method enabling (libgfapi disk access level 4.2) instead of the default fuse client for improved performance.
Other details.... Engine was updated first. Nodes were updated with
yum install https://resources.ovirt.org/pub/ovirt-4.3/rpm/el7/noarch/ovirt-node-ng-image...
I forgot to mention another symptom. On the hyperconverged cluster, the "gluster volume heal engine" command errors out on 4.3, but other gluster volumes accepted it.
+Ravishankar Narayanankutty to check the heal failures
rolling back to 4.28 allows the heal command to succeed (nothing to do actually) on engine, but I'm still unable to start a working engine VM with hosted-engine --vm-start
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@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/HFHLP473CFIMIN...
Ok, I'll check. 4.2.8 nodes libvirt.x86_64 4.5.0-10.el7_6.3 installed 4.3.0 upgraded nodes libvirt.x86_64 4.5.0-10.el7_6.4 installed On Thu, Feb 7, 2019 at 12:03 AM Sahina Bose <sabose@redhat.com> wrote:
On Thu, Feb 7, 2019 at 8:57 AM Edward Berger <edwberger@gmail.com> wrote:
I'm seeing migration failures for the hosted-engine VM from a 4.28 node
to a 4.30 node so I can complete the node upgrades.
You may be running into https://bugzilla.redhat.com/show_bug.cgi?id=1641798. Can you check the version of libvirt used on the nodes?
In one case I tried to force an update on the last node and now have a
cluster where the hosted-engine VM fails to start properly. Sometimes something thinks the VM is running, but clicking for details it seems to have no disk. I was so close to putting that one into production with working LDAP user logins and custom SSL cert and then Oops! with the upgrade.
In both cases the hosted VM storage is on gluster. One hyperconverged
oVirt nodes, the other two nodes with an external gluster 5 server cluster
I will note that I had set the engines previously (while at 4.2.8) to
use the gluster direct method enabling (libgfapi disk access level 4.2) instead of the default fuse client for improved performance.
Other details.... Engine was updated first. Nodes were updated with
yum install
https://resources.ovirt.org/pub/ovirt-4.3/rpm/el7/noarch/ovirt-node-ng-image...
I forgot to mention another symptom. On the hyperconverged cluster, the "gluster volume heal engine" command
errors out on 4.3, but other gluster volumes accepted it.
+Ravishankar Narayanankutty to check the heal failures
rolling back to 4.28 allows the heal command to succeed (nothing to do
actually) on engine, but I'm still unable to start a working engine VM with hosted-engine --vm-start
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@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/HFHLP473CFIMIN...
This has been fixed by finding the gluster volume(s) which were owned by root instead of vdsm:kvm and chown-ing them to vdsm:kvm. Afterwards the engine was able to be migrated and the gluster volume heal engine operations were able to succeed. On Thu, Feb 7, 2019 at 12:03 AM Sahina Bose <sabose@redhat.com> wrote:
On Thu, Feb 7, 2019 at 8:57 AM Edward Berger <edwberger@gmail.com> wrote:
I'm seeing migration failures for the hosted-engine VM from a 4.28 node
to a 4.30 node so I can complete the node upgrades.
You may be running into https://bugzilla.redhat.com/show_bug.cgi?id=1641798. Can you check the version of libvirt used on the nodes?
In one case I tried to force an update on the last node and now have a
cluster where the hosted-engine VM fails to start properly. Sometimes something thinks the VM is running, but clicking for details it seems to have no disk. I was so close to putting that one into production with working LDAP user logins and custom SSL cert and then Oops! with the upgrade.
In both cases the hosted VM storage is on gluster. One hyperconverged
oVirt nodes, the other two nodes with an external gluster 5 server cluster
I will note that I had set the engines previously (while at 4.2.8) to
use the gluster direct method enabling (libgfapi disk access level 4.2) instead of the default fuse client for improved performance.
Other details.... Engine was updated first. Nodes were updated with
yum install
https://resources.ovirt.org/pub/ovirt-4.3/rpm/el7/noarch/ovirt-node-ng-image...
I forgot to mention another symptom. On the hyperconverged cluster, the "gluster volume heal engine" command
errors out on 4.3, but other gluster volumes accepted it.
+Ravishankar Narayanankutty to check the heal failures
rolling back to 4.28 allows the heal command to succeed (nothing to do
actually) on engine, but I'm still unable to start a working engine VM with hosted-engine --vm-start
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@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/HFHLP473CFIMIN...
On Sun, Feb 10, 2019 at 7:43 PM Edward Berger <edwberger@gmail.com> wrote:
This has been fixed by finding the gluster volume(s) which were owned by root instead of vdsm:kvm and chown-ing them to vdsm:kvm. Afterwards the engine was able to be migrated and the gluster volume heal engine operations were able to succeed.
OK, so still https://bugzilla.redhat.com/1666795
On Thu, Feb 7, 2019 at 12:03 AM Sahina Bose <sabose@redhat.com> wrote:
On Thu, Feb 7, 2019 at 8:57 AM Edward Berger <edwberger@gmail.com> wrote:
I'm seeing migration failures for the hosted-engine VM from a 4.28 node
to a 4.30 node so I can complete the node upgrades.
You may be running into https://bugzilla.redhat.com/show_bug.cgi?id=1641798. Can you check the version of libvirt used on the nodes?
In one case I tried to force an update on the last node and now have a
cluster where the hosted-engine VM fails to start properly. Sometimes something thinks the VM is running, but clicking for details it seems to have no disk. I was so close to putting that one into production with working LDAP user logins and custom SSL cert and then Oops! with the upgrade.
In both cases the hosted VM storage is on gluster. One hyperconverged
oVirt nodes, the other two nodes with an external gluster 5 server cluster
I will note that I had set the engines previously (while at 4.2.8) to
use the gluster direct method enabling (libgfapi disk access level 4.2) instead of the default fuse client for improved performance.
Other details.... Engine was updated first. Nodes were updated with
yum install
https://resources.ovirt.org/pub/ovirt-4.3/rpm/el7/noarch/ovirt-node-ng-image...
I forgot to mention another symptom. On the hyperconverged cluster, the "gluster volume heal engine" command
errors out on 4.3, but other gluster volumes accepted it.
+Ravishankar Narayanankutty to check the heal failures
rolling back to 4.28 allows the heal command to succeed (nothing to do
actually) on engine, but I'm still unable to start a working engine VM with hosted-engine --vm-start
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@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/HFHLP473CFIMIN...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@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/6J3KALX3P46RHC...
participants (3)
-
Edward Berger -
Sahina Bose -
Simone Tiraboschi