[Users] [Fwd: Guest never gets removed]

[Karli Sjöberg]

Hi Noam!

tor 2013-05-16 klockan 06:23 -0400 skrev Noam Slomianko:


Hi Karli,
I don't know about reminding the engine of forgotten actions and sounds like the failure can originate from all sort of problems...
This means I don't have a good solution, but I do have "a" solution.


What is a man without backups?;)




Go to the host and manually remoove the VM:
If vdsClient is installed do "vdsClient 0 list table" and then "vdsClient 0 destroy <UUID>"
If not the use virsh to list the vms "virsh list" then using the id/name remove it "virsh destroy <id/name>"


No sign of that Guest using any of the above commands. I also checked whether it still had any "ghost" Virtual Disks so I guess SPM managed to clear that.




Then go to Ovirt DB and delete (cascade) the VM from vm_static


That´s where I could use the most guideance really. How exactly do I do that?




But remember that as always touching the inner working directly might be risky and prone to errors (no way to recover if you deleted the wrong VM)
So use with caution.

I hope this helps,
Noam.


----- Original Message -----
From: "Karli Sjöberg" <Karli.Sjoberg at slu.se<mailto:Karli.Sjoberg at slu.se>>
To: "users" <users at ovirt.org<mailto:users at ovirt.org>>
Sent: Wednesday, May 15, 2013 8:17:47 AM
Subject: [Users] [Fwd:  Guest never gets removed]

Hello everyone!

I think perhaps this question passed completly unnoticed so I´m trying to resend it to perhaps get some attention.

/Karli

-------- Vidarebefordrat meddelande --------


Från : Karli Sjöberg < Karli.Sjoberg at slu.se<mailto:Karli.Sjoberg at slu.se> >
Till : users < users at ovirt.org<mailto:users at ovirt.org> >
Ämne : [Users] Guest never gets removed
Datum : Wed, 8 May 2013 05:06:57 +0000

Hi,

yesterday I issued a remove of a Guest and then immediately afterwards engine started complaining about sync errors between database and storage metadata. To my surprise, both of my two data stores were marked as master in their storage metadata files. I had to change "MASTER_VERSION" and "ROLE", then tail the vdsm log on a Host and watch it complain that the checksum is wrong and how it is ${X} but should be ${Y} according to it´s logic, and copy/paste tbe correct checksum into storage metadata file as well. This had to be done for both data domains, and when done, I have one "Master"- and one "Regular" domain that works and equals what´s in the database.

The problem is that engine now apparently has forgotten about my Guest that it was supposed to remove before all of this... The operation is still listed in "Tasks", so it´s not quite finished yet. Since it´s changed state to "hourglass" and status "Image locked", I can´t click for removal again either...

Is there any way to "remind" engine of a job not done?


        --

Med Vänliga Hälsningar
-------------------------------------------------------------------------------
Karli Sjöberg
Swedish University of Agricultural Sciences
Box 7079 (Visiting Address Kronåsvägen 8)
S-750 07 Uppsala, Sweden
Phone: +46-(0)18-67 15 66
karli.sjoberg at slu.se<mailto:karli.sjoberg at slu.se>

        --

Med Vänliga Hälsningar
-------------------------------------------------------------------------------
Karli Sjöberg
Swedish University of Agricultural Sciences
Box 7079 (Visiting Address Kronåsvägen 8)
S-750 07 Uppsala, Sweden
Phone: +46-(0)18-67 15 66
karli.sjoberg at slu.se<mailto:karli.sjoberg at slu.se>

_______________________________________________
Users mailing list
Users at ovirt.org<mailto:Users at ovirt.org>
http://lists.ovirt.org/mailman/listinfo/users


--

Med Vänliga Hälsningar
-------------------------------------------------------------------------------
Karli Sjöberg
Swedish University of Agricultural Sciences
Box 7079 (Visiting Address Kronåsvägen 8)
S-750 07 Uppsala, Sweden
Phone:  +46-(0)18-67 15 66
karli.sjoberg at slu.se<mailto:karli.sjoberg at adm.slu.se>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20130516/ba8ec977/attachment-0001.html>