Orphaned record in the engine DB prevents host removal
Hello People: I am trying to remove a host from ovirt-engine but I have found that a orphaned record in the engine DB prevents the removal of the host. The host is in maintenance mode, it doesn't have vm's running on it. The engine logs says that there is a reference to the id of the host (vds_id in the table vds_static) in the field "migrating_to_vds" in the table "dynamic_vds". Obviously this is a orphaned record, but a constraint in the table "dynamic_vds" prevents the removal of the host. How can I solve this? Someone that knows the internals of engine's DB that can confirm if I can remove the problematic registry in order to remove the host?? Another solution? I really need to remove this host. Please help and Thanks!
Is there a migration of this VM in progress? Did it migrate recently? I suggest to attach the engine log here as well, if possible, for examination. Cc-ing some guys that might help but bare in mind that for some of them it is already weekend. Oved On Jul 4, 2014 6:07 PM, Federico Alberto Sayd <fsayd@uncu.edu.ar> wrote:
Hello People:
I am trying to remove a host from ovirt-engine but I have fouHello People:
I am trying to remove a host from ovirt-engine but I have found that a orphaned record in the engine DB prevents the removal of the host. The host is in maintenance mode, it doesn't have vm's running on it. The engine logs says that there is a reference to the id of the host (vds_id in the table vds_static) in the field "migrating_to_vds" in the table "dynamic_vds". Obviously this is a orphaned record, but a constraint in the table "dynamic_vds" prevents the removal of the host. How can I solve this? Someone that knows the internals of engine's DB that can confirm if I can remove the problematic registry in order to remove the host?? Another solution? I really need to remove this host. Please help and Thanks! _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 04/07/14 14:45, Oved Ourfali wrote:
Is there a migration of this VM in progress? Did it migrate recently? Thank you Oved, I have already solved the problem, I have posted the solution to the list.
However I don't understand how the data is recorded in the table "vm_dyanmic". I guess that in this table the engine records the current status data of the vm's in the datacenter. In my engine DB almost all the registries in the "vm_dynamic" table have a vm id in the "migrating_to_vds" field, this id is the same in the "run_on_vds" field. Is it right that the "migrating_to_vds" field have a value after the vm has been migrated?? My setup: oVirt Engine Version: 3.4.0-1.el6 Nodes (vds's, hosts, etc.): Centos 6.5 ovirt-node 3.4, vdsm-4.14.6-0.el6 Thank you, and happy weekend! Federico
I suggest to attach the engine log here as well, if possible, for examination. Cc-ing some guys that might help but bare in mind that for some of them it is already weekend.
Oved
Hello People:
I am trying to remove a host from ovirt-engine but I have fouHello People: I am trying to remove a host from ovirt-engine but I have found that a orphaned record in the engine DB prevents the removal of the host. The host is in maintenance mode, it doesn't have vm's running on it. The engine logs says that there is a reference to the id of the host (vds_id in the table vds_static) in the field "migrating_to_vds" in the
On Jul 4, 2014 6:07 PM, Federico Alberto Sayd <fsayd@uncu.edu.ar> wrote: table "dynamic_vds". Obviously this is a orphaned record, but a constraint in the table "dynamic_vds" prevents the removal of the host. How can I solve this? Someone that knows the internals of engine's DB that can confirm if I can remove the problematic registry in order to remove the host?? Another solution?
I really need to remove this host. Please help and
Thanks! _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Hi Federico, If we are to debug this issue engine.log should be helpful, as Oved suggested. Please attach it if you still have it. Vered ----- Original Message -----
From: "Federico Alberto Sayd" <fsayd@uncu.edu.ar> To: "Oved Ourfali" <oourfali@redhat.com> Cc: "Arik Hadas" <ahadas@redhat.com>, "users" <users@ovirt.org>, "Michal Skrivanek" <mskrivan@redhat.com> Sent: Friday, July 4, 2014 11:56:18 PM Subject: Re: [ovirt-users] Orphaned record in the engine DB prevents host removal
On 04/07/14 14:45, Oved Ourfali wrote:
Is there a migration of this VM in progress? Did it migrate recently? Thank you Oved, I have already solved the problem, I have posted the solution to the list.
However I don't understand how the data is recorded in the table "vm_dyanmic".
I guess that in this table the engine records the current status data of the vm's in the datacenter. In my engine DB almost all the registries in the "vm_dynamic" table have a vm id in the "migrating_to_vds" field, this id is the same in the "run_on_vds" field.
Is it right that the "migrating_to_vds" field have a value after the vm has been migrated??
My setup:
oVirt Engine Version: 3.4.0-1.el6 Nodes (vds's, hosts, etc.): Centos 6.5 ovirt-node 3.4, vdsm-4.14.6-0.el6
Thank you, and happy weekend!
Federico
I suggest to attach the engine log here as well, if possible, for examination. Cc-ing some guys that might help but bare in mind that for some of them it is already weekend.
Oved
Hello People:
I am trying to remove a host from ovirt-engine but I have fouHello People: I am trying to remove a host from ovirt-engine but I have found that a orphaned record in the engine DB prevents the removal of the host. The host is in maintenance mode, it doesn't have vm's running on it. The engine logs says that there is a reference to the id of the host (vds_id in the table vds_static) in the field "migrating_to_vds" in the
On Jul 4, 2014 6:07 PM, Federico Alberto Sayd <fsayd@uncu.edu.ar> wrote: table "dynamic_vds". Obviously this is a orphaned record, but a constraint in the table "dynamic_vds" prevents the removal of the host. How can I solve this? Someone that knows the internals of engine's DB that can confirm if I can remove the problematic registry in order to remove the host?? Another solution?
I really need to remove this host. Please help and
Thanks! _______________________________________________ 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
----- Original Message -----
On 04/07/14 14:45, Oved Ourfali wrote:
Is there a migration of this VM in progress? Did it migrate recently? Thank you Oved, I have already solved the problem, I have posted the solution to the list.
However I don't understand how the data is recorded in the table "vm_dyanmic".
I guess that in this table the engine records the current status data of the vm's in the datacenter. In my engine DB almost all the registries in the "vm_dynamic" table have a vm id in the "migrating_to_vds" field, this id is the same in the "run_on_vds" field.
Is it right that the "migrating_to_vds" field have a value after the vm has been migrated??
Yes, we're about to fix it. Note that there is an open bug for this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1112359 If you will be able to provide the info I've asked for there, it could help us to solve it faster :) Arik
My setup:
oVirt Engine Version: 3.4.0-1.el6 Nodes (vds's, hosts, etc.): Centos 6.5 ovirt-node 3.4, vdsm-4.14.6-0.el6
Thank you, and happy weekend!
Federico
I suggest to attach the engine log here as well, if possible, for examination. Cc-ing some guys that might help but bare in mind that for some of them it is already weekend.
Oved
Hello People:
I am trying to remove a host from ovirt-engine but I have fouHello People: I am trying to remove a host from ovirt-engine but I have found that a orphaned record in the engine DB prevents the removal of the host. The host is in maintenance mode, it doesn't have vm's running on it. The engine logs says that there is a reference to the id of the host (vds_id in the table vds_static) in the field "migrating_to_vds" in the
On Jul 4, 2014 6:07 PM, Federico Alberto Sayd <fsayd@uncu.edu.ar> wrote: table "dynamic_vds". Obviously this is a orphaned record, but a constraint in the table "dynamic_vds" prevents the removal of the host. How can I solve this? Someone that knows the internals of engine's DB that can confirm if I can remove the problematic registry in order to remove the host?? Another solution?
I really need to remove this host. Please help and
Thanks! _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
------=_=-_OpenGroupware_org_NGMime-3187-1404830461.613421-22------ content-type: text/html; charset=utf-8 content-length: 3748 content-transfer-encoding: 7bit <br /><br />El Domingo, 6 de Julio de 2014 07.06 CLT, Arik Hadas <ahadas@redhat.com> Ha escrito:<br /> <blockquote><br /><br />----- Original Message -----<br />> On 04/07/14 14:45, Oved Ourfali wrote:<br />> > Is there a migration of this VM in progress? Did it migrate recently?<br />> Thank you Oved, I have already solved the problem, I have posted the<br />> solution to the list.<br />><br />> However I don't understand how the data is recorded in the table<br />> "vm_dyanmic".<br />><br />> I guess that in this table the engine records the current status data of<br />> the vm's in the datacenter. In my engine DB almost all the registries in<br />> the "vm_dynamic" table have a vm id in the "migrating_to_vds" field,<br />> this id is the same in the "run_on_vds" field.<br />><br />> Is it right that the "migrating_to_vds" field have a value after the vm<br />&g t; has been migrated??<br /><br />Yes, we're about to fix it.<br /><br />Note that there is an open bug for this issue:<br />https://bugzilla.redhat.com/show_bug.cgi?id=1112359<br />If you will be able to provide the info I've asked for there,<br />it could help us to solve it faster :)<br /><br />Arik<br /><br />><br />> My setup:<br />><br />> oVirt Engine Version: 3.4.0-1.el6<br />> Nodes (vds's, hosts, etc.): Centos 6.5 ovirt-node 3.4, vdsm-4.14.6-0.el6<br />><br />> Thank you, and happy weekend!<br />><br />> Federico<br />> > I suggest to attach the engine log here as well, if possible, for<br />> > examination. Cc-ing some guys that might help but bare in mind that for<br />> > some of them it is already weekend.<br />> ><br />> > Oved<br />> ><br />> > On Jul 4, 2014 6:07 PM, Federico Alberto Sayd wrote:<br />> >> Hello People:<br />> >><br />> >> I am trying t o remove a host from ovirt-engine but I have fouHello People:<br />> > I am trying to remove a host from ovirt-engine but I have found that a<br />> > orphaned record in the engine DB prevents the removal of the host.<br />> > The host is in maintenance mode, it doesn't have vm's running on it.<br />> > The engine logs says that there is a reference to the id of the host<br />> > (vds_id in the table vds_static) in the field "migrating_to_vds" in the<br />> > table "dynamic_vds". Obviously this is a orphaned record, but a<br />> > constraint in the table "dynamic_vds" prevents the removal of the host.<br />> > How can I solve this?<br />> > Someone that knows the internals of engine's DB that can confirm if I<br />> > can remove the problematic registry in order to remove the host??<br />> > Another solution?<br />> ><br />> > I really need to remove this h ost. Please help and<br />> ><br />> > Thanks!<br />> > _______________________________________________<br />> > Users mailing list<br />> > Users@ovirt.org<br />> > http://lists.ovirt.org/mailman/listinfo/user</blockquote><br />Indeed, you are right, is the same bug. I didn't find this bug when googled the problem. I have attached an extract of the logs when I tried to remove the host, it looks identical to the logs reported in the bug except that postgres transactions are logged in Spanish.<br />I will try to find the log entry when the vm was migrated and the value was not correctly updated in the "migrating_to_vds" field. I think that that is the more critical bug.<br /><br />Thank you<br /><br />Federico<br /> ------=_=-_OpenGroupware_org_NGMime-3187-1404830461.613421-22------ content-type: text/x-log content-transfer-encoding: base64 content-length: 13736 content-disposition: attachment; filename="engine.log" OiBmYWxzZS4gRW50aXRpZXMgYWZmZWN0ZWQgOiAgSUQ6IGMyMTJjMGE5LWE3ODQtNDk1OC1i YWQxLWViM2E5NWI4YzlkYSBUeXBlOiBWRFMKMjAxNC0wNy0wMyAxNjoxNDo1OSw3NjggSU5G TyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuU2V0VmRzU3RhdHVzVkRTQ29t bWFuZF0gKG9yZy5vdmlydC50aHJlYWQucG9vbC02LXRocmVhZC0xOCkgWzQ4ZWM4MDdiXSBT VEFSVCwgU2V0VmRzU3RhdHVzVkRTQ29tbWFuZChIb3N0TmFtZSA9IG92LW5vZG8yLCBIb3N0 SWQgCj0gYzIxMmMwYTktYTc4NC00OTU4LWJhZDEtZWIzYTk1YjhjOWRhLCBzdGF0dXM9UHJl cGFyaW5nRm9yTWFpbnRlbmFuY2UsIG5vbk9wZXJhdGlvbmFsUmVhc29uPU5PTkUsIHN0b3BT cG1GYWlsdXJlTG9nZ2VkPXRydWUpLCBsb2cgaWQ6IDUyMjBiMGNiCjIwMTQtMDctMDMgMTY6 MTQ6NTksNzc0IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLlNldFZk c1N0YXR1c1ZEU0NvbW1hbmRdIChvcmcub3ZpcnQudGhyZWFkLnBvb2wtNi10aHJlYWQtMTgp IFs0OGVjODA3Yl0gRklOSVNILCBTZXRWZHNTdGF0dXNWRFNDb21tYW5kLCBsb2cgaWQ6IDUy MjBiMGNiCjIwMTQtMDctMDMgMTY6MTQ6NTksODUxIElORk8gIFtvcmcub3ZpcnQuZW5naW5l LmNvcmUuYmxsLk1haW50ZW5hbmNlVmRzQ29tbWFuZF0gKG9yZy5vdmlydC50aHJlYWQucG9v bC02LXRocmVhZC0xOCkgWzQ4ZWM4MDdiXSBSdW5uaW5nIGNvbW1hbmQ6IE1haW50ZW5hbmNl VmRzQ29tbWFuZCBpbnRlcm5hbDogdHJ1ZS4gRW50aXRpZXMgYQpmZmVjdGVkIDogIElEOiBj MjEyYzBhOS1hNzg0LTQ5NTgtYmFkMS1lYjNhOTViOGM5ZGEgVHlwZTogVkRTCjIwMTQtMDct MDMgMTY6MTQ6NTksODYzIElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJv a2VyLmF1ZGl0bG9naGFuZGxpbmcuQXVkaXRMb2dEaXJlY3Rvcl0gKG9yZy5vdmlydC50aHJl YWQucG9vbC02LXRocmVhZC0xOCkgWzQ4ZWM4MDdiXSBDb3JyZWxhdGlvbiBJRDogNDhlYzgw N2IsIEpvYiBJRDogOGQzOGRkYjQtZQo2OGYtNGQwYy04M2Q3LWUyZWJkMDg1ZjMzNywgQ2Fs bCBTdGFjazogbnVsbCwgQ3VzdG9tIEV2ZW50IElEOiAtMSwgTWVzc2FnZTogSG9zdCBvdi1u b2RvMiB3YXMgc3dpdGNoZWQgdG8gTWFpbnRlbmFuY2UgbW9kZSBieSBmc2F5ZC4KMjAxNC0w Ny0wMyAxNjoxNTowMSw5NDMgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9r ZXIuVmRzVXBkYXRlUnVuVGltZUluZm9dIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtl ci0zKSBVcGRhdGVkIHZkcyBzdGF0dXMgZnJvbSBQcmVwYXJpbmcgZm9yIE1haW50ZW5hbmNl IHRvIE1haW50ZW5hbmNlIGluIGRhdGFiCmFzZSwgIHZkcyA9IGMyMTJjMGE5LWE3ODQtNDk1 OC1iYWQxLWViM2E5NWI4YzlkYSA6IG92LW5vZG8yCjIwMTQtMDctMDMgMTY6MTU6MDEsOTYz IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmlyc2Jyb2tlci5JcnNC cm9rZXJDb21tYW5kXSAob3JnLm92aXJ0LnRocmVhZC5wb29sLTYtdGhyZWFkLTM2KSBDbGVh cmluZyBjYWNoZSBvZiBwb29sOiBhNjg2ZGE2NC1hZjQ2LTQzNWEtYTdlOS0zZjU5N2U5ZGE4 MDIgZm9yIHByb2JsZW1hdGljIGVudGl0aWVzIG9mIFZEUzogb3Ytbm9kbzIuCjIwMTQtMDct MDMgMTY6MTU6MDEsOTY5IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2Vy LnZkc2Jyb2tlci5EaXNjb25uZWN0U3RvcmFnZVBvb2xWRFNDb21tYW5kXSAoRGVmYXVsdFF1 YXJ0elNjaGVkdWxlcl9Xb3JrZXItMykgU1RBUlQsIERpc2Nvbm5lY3RTdG9yYWdlUG9vbFZE U0NvbW1hbmQoSG9zdE5hbWUgPSBvdi1ub2RvMiwgSG9zdElkID0gYzIxMmMwYTktYTc4NC00 OTU4LWJhZDEtZWIzYTk1YjhjOWRhLCBzdG9yYWdlUG9vbElkID0gYTY4NmRhNjQtYWY0Ni00 MzVhLWE3ZTktM2Y1OTdlOWRhODAyLCB2ZHNfc3BtX2lkID0gMiksIGxvZyBpZDogNzNlODJi YTgKMjAxNC0wNy0wMyAxNjoxNTowNSw0NTYgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29y ZS5ibGwuUmVtb3ZlVmRzQ29tbWFuZF0gKGFqcC0tMTI3LjAuMC4xLTg3MDItMjkpIFs3ZjMx MzljN10gTG9jayBBY3F1aXJlZCB0byBvYmplY3QgRW5naW5lTG9jayBbZXhjbHVzaXZlTG9j a3M9IGtleTogYzIxMmMwYTktYTc4NC00OTU4LWJhZDEtZWIzYTk1YjhjOWRhIHZhbHVlOiBW RFMKLCBzaGFyZWRMb2Nrcz0gXQoyMDE0LTA3LTAzIDE2OjE1OjA1LDQ2NyBJTkZPICBbb3Jn Lm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5SZW1vdmVWZHNDb21tYW5kXSAob3JnLm92aXJ0LnRo cmVhZC5wb29sLTYtdGhyZWFkLTIxKSBbN2YzMTM5YzddIFJ1bm5pbmcgY29tbWFuZDogUmVt b3ZlVmRzQ29tbWFuZCBpbnRlcm5hbDogZmFsc2UuIEVudGl0aWVzIGFmZmVjdGVkIDogIElE OiBjMjEyYzBhOS1hNzg0LTQ5NTgtYmFkMS1lYjNhOTViOGM5ZGEgVHlwZTogVkRTCjIwMTQt MDctMDMgMTY6MTU6MDUsNDg0IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudXRpbHMu dHJhbnNhY3Rpb24uVHJhbnNhY3Rpb25TdXBwb3J0XSAob3JnLm92aXJ0LnRocmVhZC5wb29s LTYtdGhyZWFkLTIxKSBbN2YzMTM5YzddIHRyYW5zYWN0aW9uIHJvbGxlZCBiYWNrCjIwMTQt MDctMDMgMTY6MTU6MDUsNDg1IEVSUk9SIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLlJl bW92ZVZkc0NvbW1hbmRdIChvcmcub3ZpcnQudGhyZWFkLnBvb2wtNi10aHJlYWQtMjEpIFs3 ZjMxMzljN10gQ29tbWFuZCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLlJlbW92ZVZkc0Nv bW1hbmQgdGhyb3cgZXhjZXB0aW9uOiBvcmcuc3ByaW5nZnJhbWV3b3JrLmRhby5EYXRhSW50 ZWdyaXR5VmlvbGF0aW9uRXhjZXB0aW9uOiBDYWxsYWJsZVN0YXRlbWVudENhbGxiYWNrOyBT UUwgW3tjYWxsIGRlbGV0ZXZkc3N0YXRpYyg/KX1dOyBFUlJPUjogdXBkYXRlIG8gZGVsZXRl IGVuIMKrdmRzX3N0YXRpY8K7IHZpb2xhIGxhIGxsYXZlIGZvcsOhbmVhIMKrdmRzX3N0YXRp Y192bV9keW5hbWljX23CuyBlbiBsYSB0YWJsYSDCq3ZtX2R5bmFtaWPCuwogIERldGFpbDog TGEgbGxhdmUgKHZkc19pZCk9KGMyMTJjMGE5LWE3ODQtNDk1OC1iYWQxLWViM2E5NWI4Yzlk YSkgdG9kYXbDrWEgZXMgcmVmZXJpZGEgZGVzZGUgbGEgdGFibGEgwqt2bV9keW5hbWljwrsu CiAgV2hlcmU6IHNlbnRlbmNpYSBTUUw6IMKrREVMRVRFIEZST00gdmRzX3N0YXRpYyBXSEVS RSB2ZHNfaWQgPSAgJDEgwrsKUEwvcGdTUUwgZnVuY3Rpb24gImRlbGV0ZXZkc3N0YXRpYyIg bGluZSAxMSBhdCBzZW50ZW5jaWEgU1FMOyBuZXN0ZWQgZXhjZXB0aW9uIGlzIG9yZy5wb3N0 Z3Jlc3FsLnV0aWwuUFNRTEV4Y2VwdGlvbjogRVJST1I6IHVwZGF0ZSBvIGRlbGV0ZSBlbiDC q3Zkc19zdGF0aWPCuyB2aW9sYSBsYSBsbGF2ZSBmb3LDoW5lYSDCq3Zkc19zdGF0aWNfdm1f ZHluYW1pY19twrsgZW4gbGEgdGFibGEgwqt2bV9keW5hbWljwrsKIERldGFpbDogTGEgbGxh dmUgKHZkc19pZCk9KGMyMTJjMGE5LWE3ODQtNDk1OC1iYWQxLWViM2E5NWI4YzlkYSkgdG9k YXbDrWEgZXMgcmVmZXJpZGEgZGVzZGUgbGEgdGFibGEgwqt2bV9keW5hbWljwrsuCiAgV2hl cmU6IHNlbnRlbmNpYSBTUUw6IMKrREVMRVRFIEZST00gdmRzX3N0YXRpYyBXSEVSRSB2ZHNf aWQgPSAgJDEgwrsKUEwvcGdTUUwgZnVuY3Rpb24gImRlbGV0ZXZkc3N0YXRpYyIgbGluZSAx MSBhdCBzZW50ZW5jaWEgU1FMOyBuZXN0ZWQgZXhjZXB0aW9uIGlzIG9yZy5wb3N0Z3Jlc3Fs LnV0aWwuUFNRTEV4Y2VwdGlvbjogRVJST1I6IHVwZGF0ZSBvIGRlbGV0ZSBlbiDCq3Zkc19z dGF0aWPCuyB2aW9sYSBsYSBsbGF2ZSBmb3LDoW5lYSDCq3Zkc19zdGF0aWNfdm1fZHluYW1p Y19twrsgZW4gbGEgdGFibGEgwqt2bV9keW5hbWljwrsKICBEZXRhaWw6IExhIGxsYXZlICh2 ZHNfaWQpPShjMjEyYzBhOS1hNzg0LTQ5NTgtYmFkMS1lYjNhOTViOGM5ZGEpIHRvZGF2w61h IGVzIHJlZmVyaWRhIGRlc2RlIGxhIHRhYmxhIMKrdm1fZHluYW1pY8K7LgogIFdoZXJlOiBz ZW50ZW5jaWEgU1FMOiDCq0RFTEVURSBGUk9NIHZkc19zdGF0aWMgV0hFUkUgdmRzX2lkID0g ICQxIMK7ClBML3BnU1FMIGZ1bmN0aW9uICJkZWxldGV2ZHNzdGF0aWMiIGxpbmUgMTEgYXQg c2VudGVuY2lhIFNRTAogICAgICAgIGF0IG9yZy5zcHJpbmdmcmFtZXdvcmsuamRiYy5zdXBw b3J0LlNRTEVycm9yQ29kZVNRTEV4Y2VwdGlvblRyYW5zbGF0b3IuZG9UcmFuc2xhdGUoU1FM RXJyb3JDb2RlU1FMRXhjZXB0aW9uVHJhbnNsYXRvci5qYXZhOjI0NSkgW3NwcmluZy1qZGJj LmphcjozLjEuMS5SRUxFQVNFXQogICAgICAgIGF0IG9yZy5zcHJpbmdmcmFtZXdvcmsuamRi Yy5zdXBwb3J0LkFic3RyYWN0RmFsbGJhY2tTUUxFeGNlcHRpb25UcmFuc2xhdG9yLnRyYW5z bGF0ZShBYnN0cmFjdEZhbGxiYWNrU1FMRXhjZXB0aW9uVHJhbnNsYXRvci5qYXZhOjcyKSBb c3ByaW5nLWpkYmMuamFyOjMuMS4xLlJFTEVBU0VdCiAgICAgICAgYXQgb3JnLnNwcmluZ2Zy YW1ld29yay5qZGJjLmNvcmUuSmRiY1RlbXBsYXRlLmV4ZWN1dGUoSmRiY1RlbXBsYXRlLmph dmE6MTAzMCkgW3NwcmluZy1qZGJjLmphcjozLjEuMS5SRUxFQVNFXQogICAgICAgIGF0IG9y Zy5zcHJpbmdmcmFtZXdvcmsuamRiYy5jb3JlLkpkYmNUZW1wbGF0ZS5jYWxsKEpkYmNUZW1w bGF0ZS5qYXZhOjEwNjQpIFtzcHJpbmctamRiYy5qYXI6My4xLjEuUkVMRUFTRV0KICAgICAg ICBhdCBvcmcuc3ByaW5nZnJhbWV3b3JrLmpkYmMuY29yZS5zaW1wbGUuQWJzdHJhY3RKZGJj Q2FsbC5leGVjdXRlQ2FsbEludGVybmFsKEFic3RyYWN0SmRiY0NhbGwuamF2YTozODgpIFtz cHJpbmctamRiYy5qYXI6My4xLjEuUkVMRUFTRV0KICAgICAgICBhdCBvcmcuc3ByaW5nZnJh bWV3b3JrLmpkYmMuY29yZS5zaW1wbGUuQWJzdHJhY3RKZGJjQ2FsbC5kb0V4ZWN1dGUoQWJz dHJhY3RKZGJjQ2FsbC5qYXZhOjM1MSkgW3NwcmluZy1qZGJjLmphcjozLjEuMS5SRUxFQVNF XQogICAgICAgIGF0IG9yZy5zcHJpbmdmcmFtZXdvcmsuamRiYy5jb3JlLnNpbXBsZS5TaW1w bGVKZGJjQ2FsbC5leGVjdXRlKFNpbXBsZUpkYmNDYWxsLmphdmE6MTgxKSBbc3ByaW5nLWpk YmMuamFyOjMuMS4xLlJFTEVBU0VdCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3Jl LmRhbC5kYmJyb2tlci5TaW1wbGVKZGJjQ2FsbHNIYW5kbGVyLmV4ZWN1dGVJbXBsKFNpbXBs ZUpkYmNDYWxsc0hhbmRsZXIuamF2YToxMzcpIFtkYWwuamFyOl0KICAgICAgICBhdCBvcmcu b3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLlNpbXBsZUpkYmNDYWxsc0hhbmRsZXIu ZXhlY3V0ZU1vZGlmaWNhdGlvbihTaW1wbGVKZGJjQ2FsbHNIYW5kbGVyLmphdmE6NzQpIFtk YWwuamFyOl0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFvLlZkc1N0YXRp Y0RBT0RiRmFjYWRlSW1wbC5yZW1vdmUoVmRzU3RhdGljREFPRGJGYWNhZGVJbXBsLmphdmE6 MTEwKSBbZGFsLmphcjpdCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhby5W ZHNTdGF0aWNEQU9EYkZhY2FkZUltcGwucmVtb3ZlKFZkc1N0YXRpY0RBT0RiRmFjYWRlSW1w bC5qYXZhOjIwKSBbZGFsLmphcjpdCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3Jl LmJsbC5SZW1vdmVWZHNDb21tYW5kLlJlbW92ZVZkc1N0YXRpY0Zyb21EYihSZW1vdmVWZHND b21tYW5kLmphdmE6MTQ3KSBbYmxsLmphcjpdCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2lu ZS5jb3JlLmJsbC5SZW1vdmVWZHNDb21tYW5kLmFjY2VzcyQyMDAoUmVtb3ZlVmRzQ29tbWFu ZC5qYXZhOjM2KSBbYmxsLmphcjpdCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3Jl LmJsbC5SZW1vdmVWZHNDb21tYW5kJDEucnVuSW5UcmFuc2FjdGlvbihSZW1vdmVWZHNDb21t YW5kLmphdmE6NzUpIFtibGwuamFyOl0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNv cmUuYmxsLlJlbW92ZVZkc0NvbW1hbmQkMS5ydW5JblRyYW5zYWN0aW9uKFJlbW92ZVZkc0Nv bW1hbmQuamF2YTo2OSkgW2JsbC5qYXI6XQogICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUu Y29yZS51dGlscy50cmFuc2FjdGlvbi5UcmFuc2FjdGlvblN1cHBvcnQuZXhlY3V0ZUluTmV3 VHJhbnNhY3Rpb24oVHJhbnNhY3Rpb25TdXBwb3J0LmphdmE6MjEwKSBbdXRpbHMuamFyOl0K ICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLlJlbW92ZVZkc0NvbW1hbmQu ZXhlY3V0ZUNvbW1hbmQoUmVtb3ZlVmRzQ29tbWFuZC5qYXZhOjY5KSBbYmxsLmphcjpdCiAg ICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5Db21tYW5kQmFzZS5leGVjdXRl V2l0aG91dFRyYW5zYWN0aW9uKENvbW1hbmRCYXNlLmphdmE6MTEyMykgW2JsbC5qYXI6XQog ICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuQ29tbWFuZEJhc2UuZXhlY3V0 ZUFjdGlvbkluVHJhbnNhY3Rpb25TY29wZShDb21tYW5kQmFzZS5qYXZhOjEyMDgpIFtibGwu amFyOl0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLkNvbW1hbmRCYXNl LnJ1bkluVHJhbnNhY3Rpb24oQ29tbWFuZEJhc2UuamF2YToxODg0KSBbYmxsLmphcjpdCiAg ICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnV0aWxzLnRyYW5zYWN0aW9uLlRyYW5z YWN0aW9uU3VwcG9ydC5leGVjdXRlSW5TdXBwcmVzc2VkKFRyYW5zYWN0aW9uU3VwcG9ydC5q YXZhOjE3NCkgW3V0aWxzLmphcjpdCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3Jl LnV0aWxzLnRyYW5zYWN0aW9uLlRyYW5zYWN0aW9uU3VwcG9ydC5leGVjdXRlSW5TY29wZShU cmFuc2FjdGlvblN1cHBvcnQuamF2YToxMTYpIFt1dGlscy5qYXI6XQogICAgICAgIGF0IG9y Zy5vdmlydC5lbmdpbmUuY29yZS5ibGwuQ29tbWFuZEJhc2UuZXhlY3V0ZShDb21tYW5kQmFz ZS5qYXZhOjEyMjgpIFtibGwuamFyOl0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNv cmUuYmxsLkNvbW1hbmRCYXNlLmV4ZWN1dGVBY3Rpb24oQ29tbWFuZEJhc2UuamF2YTozNTEp IFtibGwuamFyOl0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLk11bHRp cGxlQWN0aW9uc1J1bm5lci5leGVjdXRlVmFsaWRhdGVkQ29tbWFuZChNdWx0aXBsZUFjdGlv bnNSdW5uZXIuamF2YToxODkpIFtibGwuamFyOl0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5n aW5lLmNvcmUuYmxsLk11bHRpcGxlQWN0aW9uc1J1bm5lci5ydW5Db21tYW5kcyhNdWx0aXBs ZUFjdGlvbnNSdW5uZXIuamF2YToxNTYpIFtibGwuamFyOl0KICAgICAgICBhdCBvcmcub3Zp cnQuZW5naW5lLmNvcmUuYmxsLk11bHRpcGxlQWN0aW9uc1J1bm5lciQyLnJ1bihNdWx0aXBs ZUFjdGlvbnNSdW5uZXIuamF2YToxNjUpIFtibGwuamFyOl0KICAgICAgICBhdCBvcmcub3Zp cnQuZW5naW5lLmNvcmUudXRpbHMudGhyZWFkcG9vbC5UaHJlYWRQb29sVXRpbCRJbnRlcm5h bFdyYXBwZXJSdW5uYWJsZS5ydW4oVGhyZWFkUG9vbFV0aWwuamF2YTo5NykgW3V0aWxzLmph cjpdCiAgICAgICAgYXQgamF2YS51dGlsLmNvbmN1cnJlbnQuRXhlY3V0b3JzJFJ1bm5hYmxl QWRhcHRlci5jYWxsKEV4ZWN1dG9ycy5qYXZhOjQ3MSkgW3J0LmphcjoxLjcuMF81MV0KICAg ICAgICBhdCBqYXZhLnV0aWwuY29uY3VycmVudC5GdXR1cmVUYXNrLnJ1bihGdXR1cmVUYXNr LmphdmE6MjYyKSBbcnQuamFyOjEuNy4wXzUxXQogICAgICAgIGF0IGphdmEudXRpbC5jb25j dXJyZW50LlRocmVhZFBvb2xFeGVjdXRvci5ydW5Xb3JrZXIoVGhyZWFkUG9vbEV4ZWN1dG9y LmphdmE6MTE0NSkgW3J0LmphcjoxLjcuMF81MV0KICAgICAgICBhdCBqYXZhLnV0aWwuY29u Y3VycmVudC5UaHJlYWRQb29sRXhlY3V0b3IkV29ya2VyLnJ1bihUaHJlYWRQb29sRXhlY3V0 b3IuamF2YTo2MTUpIFtydC5qYXI6MS43LjBfNTFdCiAgICAgICAgYXQgamF2YS5sYW5nLlRo cmVhZC5ydW4oVGhyZWFkLmphdmE6NzQ0KSBbcnQuamFyOjEuNy4wXzUxXQpDYXVzZWQgYnk6 IG9yZy5wb3N0Z3Jlc3FsLnV0aWwuUFNRTEV4Y2VwdGlvbjogRVJST1I6IHVwZGF0ZSBvIGRl bGV0ZSBlbiDCq3Zkc19zdGF0aWPCuyB2aW9sYSBsYSBsbGF2ZSBmb3LDoW5lYSDCq3Zkc19z dGF0aWNfdm1fZHluYW1pY19twrsgZW4gbGEgdGFibGEgwqt2bV9keW5hbWljwrsKICBEZXRh aWw6IExhIGxsYXZlICh2ZHNfaWQpPShjMjEyYzBhOS1hNzg0LTQ5NTgtYmFkMS1lYjNhOTVi OGM5ZGEpIHRvZGF2w61hIGVzIHJlZmVyaWRhIGRlc2RlIGxhIHRhYmxhIMKrdm1fZHluYW1p Y8K7LgogIFdoZXJlOiBzZW50ZW5jaWEgU1FMOiDCq0RFTEVURSBGUk9NIHZkc19zdGF0aWMg V0hFUkUgdmRzX2lkID0gICQxIMK7ClBML3BnU1FMIGZ1bmN0aW9uICJkZWxldGV2ZHNzdGF0 aWMiIGxpbmUgMTEgYXQgc2VudGVuY2lhIFNRTAogICAgICAgIGF0IG9yZy5wb3N0Z3Jlc3Fs LmNvcmUudjMuUXVlcnlFeGVjdXRvckltcGwucmVjZWl2ZUVycm9yUmVzcG9uc2UoUXVlcnlF eGVjdXRvckltcGwuamF2YToyMTAzKQogICAgICAgIGF0IG9yZy5wb3N0Z3Jlc3FsLmNvcmUu djMuUXVlcnlFeGVjdXRvckltcGwucHJvY2Vzc1Jlc3VsdHMoUXVlcnlFeGVjdXRvckltcGwu amF2YToxODM2KQogICAgICAgIGF0IG9yZy5wb3N0Z3Jlc3FsLmNvcmUudjMuUXVlcnlFeGVj dXRvckltcGwuZXhlY3V0ZShRdWVyeUV4ZWN1dG9ySW1wbC5qYXZhOjI1NykKICAgICAgICBh dCBvcmcucG9zdGdyZXNxbC5qZGJjMi5BYnN0cmFjdEpkYmMyU3RhdGVtZW50LmV4ZWN1dGUo QWJzdHJhY3RKZGJjMlN0YXRlbWVudC5qYXZhOjUxMikKICAgICAgICBhdCBvcmcucG9zdGdy ZXNxbC5qZGJjMi5BYnN0cmFjdEpkYmMyU3RhdGVtZW50LmV4ZWN1dGVXaXRoRmxhZ3MoQWJz dHJhY3RKZGJjMlN0YXRlbWVudC5qYXZhOjM4OCkKICAgICAgICBhdCBvcmcucG9zdGdyZXNx bC5qZGJjMi5BYnN0cmFjdEpkYmMyU3RhdGVtZW50LmV4ZWN1dGUoQWJzdHJhY3RKZGJjMlN0 YXRlbWVudC5qYXZhOjM4MSkKICAgICAgICBhdCBvcmcuamJvc3MuamNhLmFkYXB0ZXJzLmpk YmMuQ2FjaGVkUHJlcGFyZWRTdGF0ZW1lbnQuZXhlY3V0ZShDYWNoZWRQcmVwYXJlZFN0YXRl bWVudC5qYXZhOjI5NykKICAgICAgICBhdCBvcmcuamJvc3MuamNhLmFkYXB0ZXJzLmpkYmMu V3JhcHBlZFByZXBhcmVkU3RhdGVtZW50LmV4ZWN1dGUoV3JhcHBlZFByZXBhcmVkU3RhdGVt ZW50LmphdmE6NDA0KQogICAgICAgIGF0IG9yZy5zcHJpbmdmcmFtZXdvcmsuamRiYy5jb3Jl LkpkYmNUZW1wbGF0ZSQ2LmRvSW5DYWxsYWJsZVN0YXRlbWVudChKZGJjVGVtcGxhdGUuamF2 YToxMDY2KSBbc3ByaW5nLWpkYmMuamFyOjMuMS4xLlJFTEVBU0VdCiAgICAgICAgYXQgb3Jn LnNwcmluZ2ZyYW1ld29yay5qZGJjLmNvcmUuSmRiY1RlbXBsYXRlJDYuZG9JbkNhbGxhYmxl U3RhdGVtZW50KEpkYmNUZW1wbGF0ZS5qYXZhOjEpIFtzcHJpbmctamRiYy5qYXI6My4xLjEu UkVMRUFTRV0KICAgICAgICBhdCBvcmcuc3ByaW5nZnJhbWV3b3JrLmpkYmMuY29yZS5KZGJj VGVtcGxhdGUuZXhlY3V0ZShKZGJjVGVtcGxhdGUuamF2YToxMDE0KSBbc3ByaW5nLWpkYmMu amFyOjMuMS4xLlJFTEVBU0VdCiAgICAgICAgLi4uIDMwIG1vcmUKCjIwMTQtMDctMDMgMTY6 MTU6MDUsNTExIElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLmF1 ZGl0bG9naGFuZGxpbmcuQXVkaXRMb2dEaXJlY3Rvcl0gKG9yZy5vdmlydC50aHJlYWQucG9v bC02LXRocmVhZC0yMSkgWzdmMzEzOWM3XSBDb3JyZWxhdGlvbiBJRDogN2YzMTM5YzcsIENh bGwgU3RhY2s6IG51bGwsIEN1c3RvbSBFdmVudCBJRDogLTEsIE1lc3NhZ2U6IEZhaWxlZCB0 byByZW1vdmUgSG9zdCBvdi1ub2RvMiAoVXNlcjogZnNheWQpLgoyMDE0LTA3LTAzIDE2OjE1 OjA1LDUxNCBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5SZW1vdmVWZHNDb21t YW5kXSAob3JnLm92aXJ0LnRocmVhZC5wb29sLTYtdGhyZWFkLTIxKSBbN2YzMTM5YzddIExv Y2sgZnJlZWQgdG8gb2JqZWN0IEVuZ2luZUxvY2sgW2V4Y2x1c2l2ZUxvY2tzPSBrZXk6IGMy MTJjMGE5LWE3ODQtNDk1OC1iYWQxLWViM2E5NWI4YzlkYSB2YWx1ZTogVkRTCiwgc2hhcmVk TG9ja3M9IF0= ------=_=-_OpenGroupware_org_NGMime-3187-1404830461.613421-22--------
----- Original Message -----
El Domingo, 6 de Julio de 2014 07.06 CLT, Arik Hadas <ahadas@redhat.com> Ha escrito:
----- Original Message -----
On 04/07/14 14:45, Oved Ourfali wrote:
Is there a migration of this VM in progress? Did it migrate recently? Thank you Oved, I have already solved the problem, I have posted the solution to the list.
However I don't understand how the data is recorded in the table "vm_dyanmic".
I guess that in this table the engine records the current status data of the vm's in the datacenter. In my engine DB almost all the registries in the "vm_dynamic" table have a vm id in the "migrating_to_vds" field, this id is the same in the "run_on_vds" field.
Is it right that the "migrating_to_vds" field have a value after the vm &g t; has been migrated??
Yes, we're about to fix it.
Note that there is an open bug for this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1112359 If you will be able to provide the info I've asked for there, it could help us to solve it faster :)
Arik
My setup:
oVirt Engine Version: 3.4.0-1.el6 Nodes (vds's, hosts, etc.): Centos 6.5 ovirt-node 3.4, vdsm-4.14.6-0.el6
Thank you, and happy weekend!
Federico
I suggest to attach the engine log here as well, if possible, for examination. Cc-ing some guys that might help but bare in mind that for some of them it is already weekend.
Oved
Hello People:
I am trying t o remove a host from ovirt-engine but I have fouHello People: I am trying to remove a host from ovirt-engine but I have found that a orphaned record in the engine DB prevents the removal of the host. The host is in maintenance mode, it doesn't have vm's running on it. The engine logs says that there is a reference to the id of the host (vds_id in the table vds_static) in the field "migrating_to_vds" in the
On Jul 4, 2014 6:07 PM, Federico Alberto Sayd wrote: table "dynamic_vds". Obviously this is a orphaned record, but a constraint in the table "dynamic_vds" prevents the removal of the host. How can I solve this? Someone that knows the internals of engine's DB that can confirm if I can remove the problematic registry in order to remove the host?? Another solution?
I really need to remove this h ost. Please help and
Thanks! _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/user
Indeed, you are right, is the same bug. I didn't find this bug when googled the problem. I have attached an extract of the logs when I tried to remove the host, it looks identical to the logs reported in the bug except that postgres transactions are logged in Spanish.
Thanks
I will try to find the log entry when the vm was migrated and the value was not correctly updated in the "migrating_to_vds" field. I think that that is the more critical bug.
I was able to reproduce it on 3.4 branch and to understand the problem. On master it was fixed by: http://gerrit.ovirt.org/#/c/24799/ I'll backport this patch and it will solve it on 3.4 as well.
Thank you
Federico
On 04/07/14 12:07, Federico Alberto Sayd wrote:
Hello People:
I am trying to remove a host from ovirt-engine but I have found that a orphaned record in the engine DB prevents the removal of the host. The host is in maintenance mode, it doesn't have vm's running on it. The engine logs says that there is a reference to the id of the host (vds_id in the table vds_static) in the field "migrating_to_vds" in the table "dynamic_vds". Obviously this is a orphaned record, but a constraint in the table "dynamic_vds" prevents the removal of the host. How can I solve this? Someone that knows the internals of engine's DB that can confirm if I can remove the problematic registry in order to remove the host?? Another solution?
I really need to remove this host. Please help and
Thanks! _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Well, I solved the problem of host removal, some of reverse engineering over the DB structure and I can solve the problem. For any reason that I don't know, I migrated a vm from a host to other host in the cluster, but in the table vm_dynamic that apparently contains the dynamic values of vm's, the field "migrating_to_vds" was not updated and still held the id of the vds (node, hypervisor, host, etc.) which was migrated from. Same host that I had put in maintenance in order to remove it. I guess that the right behaviour is update the "migrating_to_vds" field with the vm_guid of the vds (node, hypervisor) to which the vm is being migrated. But, I don't know what was wrong when the vm was migrated and therefore the value was not updated. Simply I took the vds id from the error in engine.log, searched in the vd_dynamic table a row with this value in the field "migrating_to_vds" then I retrieved from the same row the value of the vm id from the field "vm_guid", then I searched in the table "vd_static" the name of the vm with such vm_guid. Then from the engine interface I migrated again this vm and the value in the field "migrating_to_vds" was correctly updated with the guid of the destination host. Then, the engine doesn't complaint anymore and I could remove the host. The question is, why did not the migration update the value of "migrating_to_vds" field in the table vm_dynamic or did incorrectly update it?? Sorry if you don't understand all above, I don't write very well in English, and it is a bit painful to try to explain this situation in other language..! Regards Federico
participants (5)
-
Arik Hadas -
Federico Alberto Sayd -
Federico Sayd
-
Oved Ourfali -
Vered Volansky