------=_NextPartTM-000-f97ca609-a0b3-4f45-9e40-6fc3b3ab4980 Content-Type: multipart/alternative; boundary="_000_12EF8D94C6F8734FB2FF37B9FBEDD1739B85F7E2EXCHANGEcollogi_" --_000_12EF8D94C6F8734FB2FF37B9FBEDD1739B85F7E2EXCHANGEcollogi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ala, that did not help. VDSM log tells me that the delta qcow2 file is missing: Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 873, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 49, in wrapper res =3D f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 3162, in getVolumeInfo volUUID=3DvolUUID).getInfo() File "/usr/share/vdsm/storage/sd.py", line 457, in produceVolume volUUID) File "/usr/share/vdsm/storage/fileVolume.py", line 58, in __init__ volume.Volume.__init__(self, repoPath, sdUUID, imgUUID, volUUID) File "/usr/share/vdsm/storage/volume.py", line 181, in __init__ self.validate() File "/usr/share/vdsm/storage/volume.py", line 194, in validate self.validateVolumePath() File "/usr/share/vdsm/storage/fileVolume.py", line 540, in validateVolume= Path raise se.VolumeDoesNotExist(self.volUUID) VolumeDoesNotExist: Volume does not exist: (u'c277351d-e2b1-4057-aafb-55d4b= 607ebae',) ... Thread-196::ERROR::2016-10-09 19:31:07,037::utils::739::root::(wrapper) Unh= andled exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 736, in wrapp= er return f(*a, **kw) File "/usr/share/vdsm/virt/vm.py", line 5264, in run self.update_base_size() File "/usr/share/vdsm/virt/vm.py", line 5257, in update_base_size self.drive.imageID, topVolUUID) File "/usr/share/vdsm/virt/vm.py", line 5191, in _getVolumeInfo (domainID, volumeID)) StorageUnavailableError: Unable to get volume info for domain 47202573-6e83= -42fd-a274-d11f05eca2dd volume c277351d-e2b1-4057-aafb-55d4b607ebae Do you have any idea? Markus ________________________ Von: Ala Hino [ahino@redhat.com] Gesendet: Donnerstag, 6. Oktober 2016 12:29 An: Markus Stockhausen Betreff: Re: [ovirt-users] Cleanup illegal snapshot Indeed, retry live merge. There is no harm in retrying live merge. As menti= oned, if the image deleted at storage side, retrying live merge should clea= n the engine side. On Thu, Oct 6, 2016 at 1:06 PM, Markus Stockhausen <stockhausen@collogia.de= <mailto:stockhausen@collogia.de>> wrote: Hi, we are on OVirt 4.0.4. As explained the situation is as follows: - On Disk we have the base image and the delata qcow2 file - Qemu runs only on the base image - The snapshot in Qemu is tagged as illegal So you say: "Just retry a live merge and everything will cleanup." Did I get it right? Markus ----------------------------------------------- Von: Ala Hino [ahino@redhat.com<mailto:ahino@redhat.com>] Gesendet: Donnerstag, 6. Oktober 2016 11:21 An: Markus Stockhausen Cc: Ovirt Users; Nir Soffer; Adam Litke Betreff: Re: [ovirt-users] Cleanup illegal snapshot Hi Markus, What's the version that you are using? In oVirt 3.6.6, illegal snapshots could be removed by retrying to live merg= e them again. Assuming the previous live merge of the snapshot successfully= completed but the engine failed to get the result, the second live merge s= hould do the necessary cleanups at the engine side. See https://bugzilla.re= dhat.com/1323629 Hope this helps, Ala On Thu, Oct 6, 2016 at 11:53 AM, Markus Stockhausen <stockhausen@collogia.d= e<mailto:stockhausen@collogia.de>> wrote: Hi Ala,
Von: Adam Litke [alitke@redhat.com<mailto:alitke@redhat.com>] Gesendet: Freitag, 30. September 2016 15:54 An: Markus Stockhausen Cc: Ovirt Users; Ala Hino; Nir Soffer Betreff: Re: [ovirt-users] Cleanup illegal snapshot
On 30/09/16 05:47 +0000, Markus Stockhausen wrote:
Hi,
if a OVirt snapshot is illegal we might have 2 situations.
1) qemu is still using it - lsof shows qemu access to the base raw and t= he delta qcow2 file. -> E.g. a previous live merge failed. In the past we successfully solved that situation by setting the status of the delta im= age in the database to OK.
2) qemu is no longer using it. lsof shows qemu access only to the the ba= se raw file -> E.g. a previous live merge succeded in qemu but Ovirt did no= t recognize.
How to clean up the 2nd situation?
It seems that you will have to first clean up the engine database to remove references to the snapshot that no longer exists. Then you will need to remove the unused qcow2 volume.
Unfortunately I cannot provide safe instructions for modifying the database but maybe Ala Hino (added to CC:) will be able to help with that.
Do you have some tip for me?
One you have fixed the DB you should be able to delete the volume using a vdsm verb on the SPM host:
# vdsClient -s 0 deleteVolume <sdUUID> <spUUID> <imgUUID> <volUUID>
--_000_12EF8D94C6F8734FB2FF37B9FBEDD1739B85F7E2EXCHANGEcollogi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" id=3D"owaParaStyle"></style> </head> <body fpstyle=3D"1" ocsi=3D"0"> <div style=3D"direction: ltr;font-family: Arial;color: #000000;font-size: 1= 0pt;">Hi Ala, <div><br> </div> <div>that did not help. <span style=3D"font-size: 10pt;">VDSM log tell= s me that the delta qcow2 file is missing:</span></div> <div><span style=3D"font-size: 10pt;"><br> </span></div> <div> <div>Traceback (most recent call last):</div> <div> File "/usr/share/vdsm/storage/task.py", line 873, in = _run</div> <div> return fn(*args, **kargs)</div> <div> File "/usr/share/vdsm/logUtils.py", line 49, in wrapp= er</div> <div> res =3D f(*args, **kwargs)</div> <div> File "/usr/share/vdsm/storage/hsm.py", line 3162, in = getVolumeInfo</div> <div> volUUID=3DvolUUID).getInfo()</div> <div> File "/usr/share/vdsm/storage/sd.py", line 457, in pr= oduceVolume</div> <div> volUUID)</div> <div> File "/usr/share/vdsm/storage/fileVolume.py", line 58= , in __init__</div> <div> volume.Volume.__init__(self, repoPath, sdUUID, imgUUID, = volUUID)</div> <div> File "/usr/share/vdsm/storage/volume.py", line 181, i= n __init__</div> <div> self.validate()</div> <div> File "/usr/share/vdsm/storage/volume.py", line 194, i= n validate</div> <div> self.validateVolumePath()</div> <div> File "/usr/share/vdsm/storage/fileVolume.py", line 54= 0, in validateVolumePath</div> <div> raise se.VolumeDoesNotExist(self.volUUID)</div> <div>VolumeDoesNotExist: Volume does not exist: (u'c277351d-e2b1-4057-aafb-= 55d4b607ebae',)</div> <div style=3D"font-size: 10pt;">...</div> </div> <div> <div> <div>Thread-196::ERROR::2016-10-09 19:31:07,037::utils::739::root::(wrapper= ) Unhandled exception</div> <div>Traceback (most recent call last):</div> <div> File "/usr/lib/python2.7/site-packages/vdsm/utils.py"= , line 736, in wrapper</div> <div> return f(*a, **kw)</div> <div> File "/usr/share/vdsm/virt/vm.py", line 5264, in run<= /div> <div> self.update_base_size()</div> <div> File "/usr/share/vdsm/virt/vm.py", line 5257, in upda= te_base_size</div> <div> self.drive.imageID, topVolUUID)</div> <div> File "/usr/share/vdsm/virt/vm.py", line 5191, in _get= VolumeInfo</div> <div> (domainID, volumeID))</div> <div>StorageUnavailableError: Unable to get volume info for domain 47202573= -6e83-42fd-a274-d11f05eca2dd volume c277351d-e2b1-4057-aafb-55d4b607ebae</d= iv> </div> <div><br> </div> <div>Do you have any idea?</div> <div><br> </div> <div>Markus</div> <div>________________________<br> <div><br> <div style=3D"font-family:Tahoma; font-size:13px"> <div style=3D"font-family:Tahoma; font-size:13px"> <div style=3D"font-family:Tahoma; font-size:13px"> <div style=3D"font-family:Tahoma; font-size:13px"> <div style=3D"font-family:Tahoma; font-size:13px"> <div> <div> <div><b style=3D"font-size: small;">Von:</b><span style=3D"font-size: small= ;"> Ala Hino [ahino@redhat.com]</span></div> </div> </div> </div> </div> </div> </div> </div> </div> <div style=3D"font-family: Times New Roman; color: #000000; font-size: 16px= "> <div id=3D"divRpF145670" style=3D"direction: ltr;"><font face=3D"Tahoma" si= ze=3D"2" color=3D"#000000"><b>Gesendet:</b> Donnerstag, 6. Oktober 2016 12:= 29<br> <b>An:</b> Markus Stockhausen<br> <b>Betreff:</b> Re: [ovirt-users] Cleanup illegal snapshot<br> </font><br> </div> <div></div> <div> <div dir=3D"ltr">Indeed, retry live merge. There is no harm in retrying liv= e merge. As mentioned, if the image deleted at storage side, retrying live = merge should clean the engine side.</div> <div class=3D"gmail_extra"><br> <div class=3D"gmail_quote">On Thu, Oct 6, 2016 at 1:06 PM, Markus Stockhaus= en <span dir=3D"ltr"> <<a href=3D"mailto:stockhausen@collogia.de" target=3D"_blank">stockhause= n@collogia.de</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex; border-left:1= px #ccc solid; padding-left:1ex"> <div> <div style=3D"direction:ltr; font-family:Arial; color:#000000; font-size:10= pt">Hi, <div><br> </div> <div>we are on OVirt 4.0.4. As explained the situation is as follows:</div> <div><br> </div> <div>- On Disk we have the base image and the delata qcow2 file</div> <div>- Qemu runs only on the base image</div> <div>- The snapshot in Qemu is tagged as illegal</div> <div><br> </div> <div>So you say: "Just retry a live merge and everything will cleanup.= "</div> <div>Did I get it right?</div> <div><br> </div> <div>Markus</div> <div><br> </div> <div>------------------------------<wbr>-----------------<br> <div><br> <div style=3D"font-family:Tahoma; font-size:13px"> <div style=3D"font-family:Tahoma; font-size:13px"> <div style=3D"font-family:Tahoma; font-size:13px"> <div style=3D"font-family:Tahoma; font-size:13px"> <div style=3D"font-family:Tahoma; font-size:13px"> <div> <div> <div><b style=3D"font-size:small">Von:</b><span style=3D"font-size:small"> = Ala Hino [<a href=3D"mailto:ahino@redhat.com" target=3D"_blank">ahino@redha= t.com</a>]</span></div> </div> </div> </div> </div> </div> </div> </div> </div> <div style=3D"font-family:Times New Roman; color:#000000; font-size:16px"> <div style=3D"direction:ltr"><font face=3D"Tahoma" size=3D"2" color=3D"#000= 000"><b>Gesendet:</b> Donnerstag, 6. Oktober 2016 11:21<br> <b>An:</b> Markus Stockhausen<br> <b>Cc:</b> Ovirt Users; Nir Soffer; Adam Litke <div> <div class=3D"h5"><br> <b>Betreff:</b> Re: [ovirt-users] Cleanup illegal snapshot<br> </div> </div> </font><br> </div> <div> <div class=3D"h5"> <div></div> <div> <div dir=3D"ltr">Hi Markus, <div><br> </div> <div>What's the version that you are using?</div> <div>In oVirt 3.6.6, illegal snapshots could be removed by retrying to live= merge them again. Assuming the previous live merge of the snapshot success= fully completed but the engine failed to get the result, the second live me= rge should do the necessary cleanups at the engine side. See <a href=3D"https://bugzilla.redhat.com/132362= 9" target=3D"_blank">https://bugzilla.redhat.<wbr>com/1323629</a></div> <div><br> </div> <div>Hope this helps,</div> <div>Ala</div> </div> <div class=3D"gmail_extra"><br> <div class=3D"gmail_quote">On Thu, Oct 6, 2016 at 11:53 AM, Markus Stockhau= sen <span dir=3D"ltr"> <<a href=3D"mailto:stockhausen@collogia.de" target=3D"_blank">stockhause= n@collogia.de</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex; border-left:1= px #ccc solid; padding-left:1ex"> Hi Ala,<br> <br> > Von: Adam Litke [<a href=3D"mailto:alitke@redhat.com" target=3D"_blank= ">alitke@redhat.com</a>]<br> > Gesendet: Freitag, 30. September 2016 15:54<br> > An: Markus Stockhausen<br> > Cc: Ovirt Users; Ala Hino; Nir Soffer<br> > Betreff: Re: [ovirt-users] Cleanup illegal snapshot<br> <span>><br> > On 30/09/16 05:47 +0000, Markus Stockhausen wrote:<br> > >Hi,<br> > ><br> > >if a OVirt snapshot is illegal we might have 2 situations.<br> > ><br> > >1) qemu is still using it - lsof shows qemu access to the base raw= and the<br> > >delta qcow2 file. -> E.g. a previous live merge failed. In the = past we<br> > >successfully solved that situation by setting the status of the de= lta image<br> > >in the database to OK.<br> > ><br> > >2) qemu is no longer using it. lsof shows qemu access only to the = the base<br> > >raw file -> E.g. a previous live merge succeded in qemu but Ovi= rt did not<br> > >recognize.<br> > ><br> > >How to clean up the 2nd situation?<br> ><br> > It seems that you will have to first clean up the engine database to<b= r> > remove references to the snapshot that no longer exists. Then yo= u<br> > will need to remove the unused qcow2 volume.<br> ><br> > Unfortunately I cannot provide safe instructions for modifying the<br> > database but maybe Ala Hino (added to CC:) will be able to help with<b= r> > that.<br> <br> </span>Do you have some tip for me?<br> <div> <div><br> ><br> > One you have fixed the DB you should be able to delete the volume<br> > using a vdsm verb on the SPM host:<br> ><br> > # vdsClient -s 0 deleteVolume <sdUUID> <spUUID> <imgUUI= D> <volUUID><br> </div> </div> </blockquote> </div> <br> </div> </div> </div> </div> </div> <div style=3D""></div> </div> </div> </div> </blockquote> </div> <br> </div> </div> </div> <div id=3D"ofmeet-extension-installed" style=3D"display: none;"></div> </div> </div> </div> </body> </html> --_000_12EF8D94C6F8734FB2FF37B9FBEDD1739B85F7E2EXCHANGEcollogi_-- ------=_NextPartTM-000-f97ca609-a0b3-4f45-9e40-6fc3b3ab4980 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-f97ca609-a0b3-4f45-9e40-6fc3b3ab4980--
Hi Markus, Few errors are expected. Do you still see the snapshot in the GUI? Can you please send engine logs as well. Thanks, Ala On Sun, Oct 9, 2016 at 8:33 PM, Markus Stockhausen <stockhausen@collogia.de> wrote:
Hi Ala,
that did not help. VDSM log tells me that the delta qcow2 file is missing:
Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 873, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 49, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 3162, in getVolumeInfo volUUID=volUUID).getInfo() File "/usr/share/vdsm/storage/sd.py", line 457, in produceVolume volUUID) File "/usr/share/vdsm/storage/fileVolume.py", line 58, in __init__ volume.Volume.__init__(self, repoPath, sdUUID, imgUUID, volUUID) File "/usr/share/vdsm/storage/volume.py", line 181, in __init__ self.validate() File "/usr/share/vdsm/storage/volume.py", line 194, in validate self.validateVolumePath() File "/usr/share/vdsm/storage/fileVolume.py", line 540, in validateVolumePath raise se.VolumeDoesNotExist(self.volUUID) VolumeDoesNotExist: Volume does not exist: (u'c277351d-e2b1-4057-aafb- 55d4b607ebae',) ... Thread-196::ERROR::2016-10-09 19:31:07,037::utils::739::root::(wrapper) Unhandled exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 736, in wrapper return f(*a, **kw) File "/usr/share/vdsm/virt/vm.py", line 5264, in run self.update_base_size() File "/usr/share/vdsm/virt/vm.py", line 5257, in update_base_size self.drive.imageID, topVolUUID) File "/usr/share/vdsm/virt/vm.py", line 5191, in _getVolumeInfo (domainID, volumeID)) StorageUnavailableError: Unable to get volume info for domain 47202573-6e83-42fd-a274-d11f05eca2dd volume c277351d-e2b1-4057-aafb- 55d4b607ebae
Do you have any idea?
Markus ________________________
*Von:* Ala Hino [ahino@redhat.com] *Gesendet:* Donnerstag, 6. Oktober 2016 12:29 *An:* Markus Stockhausen
*Betreff:* Re: [ovirt-users] Cleanup illegal snapshot
Indeed, retry live merge. There is no harm in retrying live merge. As mentioned, if the image deleted at storage side, retrying live merge should clean the engine side.
On Thu, Oct 6, 2016 at 1:06 PM, Markus Stockhausen < stockhausen@collogia.de> wrote:
Hi,
we are on OVirt 4.0.4. As explained the situation is as follows:
- On Disk we have the base image and the delata qcow2 file - Qemu runs only on the base image - The snapshot in Qemu is tagged as illegal
So you say: "Just retry a live merge and everything will cleanup." Did I get it right?
Markus
-----------------------------------------------
*Von:* Ala Hino [ahino@redhat.com] *Gesendet:* Donnerstag, 6. Oktober 2016 11:21 *An:* Markus Stockhausen *Cc:* Ovirt Users; Nir Soffer; Adam Litke
*Betreff:* Re: [ovirt-users] Cleanup illegal snapshot
Hi Markus,
What's the version that you are using? In oVirt 3.6.6, illegal snapshots could be removed by retrying to live merge them again. Assuming the previous live merge of the snapshot successfully completed but the engine failed to get the result, the second live merge should do the necessary cleanups at the engine side. See https://bugzilla.redhat.com/1323629
Hope this helps, Ala
On Thu, Oct 6, 2016 at 11:53 AM, Markus Stockhausen < stockhausen@collogia.de> wrote:
Hi Ala,
Von: Adam Litke [alitke@redhat.com] Gesendet: Freitag, 30. September 2016 15:54 An: Markus Stockhausen Cc: Ovirt Users; Ala Hino; Nir Soffer Betreff: Re: [ovirt-users] Cleanup illegal snapshot
Hi,
if a OVirt snapshot is illegal we might have 2 situations.
1) qemu is still using it - lsof shows qemu access to the base raw and the delta qcow2 file. -> E.g. a previous live merge failed. In the past we successfully solved that situation by setting the status of the delta image in the database to OK.
2) qemu is no longer using it. lsof shows qemu access only to the the
On 30/09/16 05:47 +0000, Markus Stockhausen wrote: base
raw file -> E.g. a previous live merge succeded in qemu but Ovirt did not recognize.
How to clean up the 2nd situation?
It seems that you will have to first clean up the engine database to remove references to the snapshot that no longer exists. Then you will need to remove the unused qcow2 volume.
Unfortunately I cannot provide safe instructions for modifying the database but maybe Ala Hino (added to CC:) will be able to help with that.
Do you have some tip for me?
One you have fixed the DB you should be able to delete the volume using a vdsm verb on the SPM host:
# vdsClient -s 0 deleteVolume <sdUUID> <spUUID> <imgUUID> <volUUID>
On Sun, Oct 9, 2016 at 8:33 PM, Markus Stockhausen <stockhausen@collogia.de> wrote:
Hi Ala,
that did not help. VDSM log tells me that the delta qcow2 file is missing:
Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 873, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 49, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 3162, in getVolumeInfo volUUID=volUUID).getInfo() File "/usr/share/vdsm/storage/sd.py", line 457, in produceVolume volUUID) File "/usr/share/vdsm/storage/fileVolume.py", line 58, in __init__ volume.Volume.__init__(self, repoPath, sdUUID, imgUUID, volUUID) File "/usr/share/vdsm/storage/volume.py", line 181, in __init__ self.validate() File "/usr/share/vdsm/storage/volume.py", line 194, in validate self.validateVolumePath() File "/usr/share/vdsm/storage/fileVolume.py", line 540, in validateVolumePath raise se.VolumeDoesNotExist(self.volUUID) VolumeDoesNotExist: Volume does not exist: (u'c277351d-e2b1-4057-aafb-55d4b607ebae',) ... Thread-196::ERROR::2016-10-09 19:31:07,037::utils::739::root::(wrapper) Unhandled exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 736, in wrapper return f(*a, **kw) File "/usr/share/vdsm/virt/vm.py", line 5264, in run self.update_base_size() File "/usr/share/vdsm/virt/vm.py", line 5257, in update_base_size self.drive.imageID, topVolUUID) File "/usr/share/vdsm/virt/vm.py", line 5191, in _getVolumeInfo (domainID, volumeID)) StorageUnavailableError: Unable to get volume info for domain 47202573-6e83-42fd-a274-d11f05eca2dd volume c277351d-e2b1-4057-aafb-55d4b607ebae
Hi Markus, I'm sorry for this confusing log, Vdsm is treating a missing volume as a horrible error is a bug, this is expected condition when you query volume info. We also log 2 exceptions instead of one. Would file a vdsm storage bug for these issues? Thanks, Nir
This is a multi-part message in MIME format. ------=_NextPartTM-000-4de4719a-55e3-4f08-a1f0-7cc250afc7fc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bug with logs attached:=0A= =0A= https://bugzilla.redhat.com/show_bug.cgi?id=3D1383084=0A= =0A= Best regards.=0A= =0A= Markus=0A= =0A= ____________________________=0A= =0A= Von: Nir Soffer [nsoffer@redhat.com]=0A= Gesendet: Sonntag, 9. Oktober 2016 20:37=0A= An: Markus Stockhausen=0A= Cc: Ala Hino; Ovirt Users=0A= Betreff: Re: [ovirt-users] Cleanup illegal snapshot=0A= =0A= On Sun, Oct 9, 2016 at 8:33 PM, Markus Stockhausen=0A= <stockhausen@collogia.de> wrote:=0A=
Hi Ala,=0A= =0A= that did not help. VDSM log tells me that the delta qcow2 file is missing= :=0A= =0A= Traceback (most recent call last):=0A= File "/usr/share/vdsm/storage/task.py", line 873, in _run=0A= return fn(*args, **kargs)=0A= File "/usr/share/vdsm/logUtils.py", line 49, in wrapper=0A= res =3D f(*args, **kwargs)=0A= File "/usr/share/vdsm/storage/hsm.py", line 3162, in getVolumeInfo=0A= volUUID=3DvolUUID).getInfo()=0A= File "/usr/share/vdsm/storage/sd.py", line 457, in produceVolume=0A= volUUID)=0A= File "/usr/share/vdsm/storage/fileVolume.py", line 58, in __init__=0A= volume.Volume.__init__(self, repoPath, sdUUID, imgUUID, volUUID)=0A= File "/usr/share/vdsm/storage/volume.py", line 181, in __init__=0A= self.validate()=0A= File "/usr/share/vdsm/storage/volume.py", line 194, in validate=0A= self.validateVolumePath()=0A= File "/usr/share/vdsm/storage/fileVolume.py", line 540, in=0A= validateVolumePath=0A= raise se.VolumeDoesNotExist(self.volUUID)=0A= VolumeDoesNotExist: Volume does not exist:=0A= (u'c277351d-e2b1-4057-aafb-55d4b607ebae',)=0A= ...=0A= Thread-196::ERROR::2016-10-09 19:31:07,037::utils::739::root::(wrapper)= =0A= Unhandled exception=0A= Traceback (most recent call last):=0A= File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 736, in=0A= wrapper=0A= return f(*a, **kw)=0A= File "/usr/share/vdsm/virt/vm.py", line 5264, in run=0A= self.update_base_size()=0A= File "/usr/share/vdsm/virt/vm.py", line 5257, in update_base_size=0A= self.drive.imageID, topVolUUID)=0A= File "/usr/share/vdsm/virt/vm.py", line 5191, in _getVolumeInfo=0A= (domainID, volumeID))=0A= StorageUnavailableError: Unable to get volume info for domain=0A= 47202573-6e83-42fd-a274-d11f05eca2dd volume=0A= c277351d-e2b1-4057-aafb-55d4b607ebae=0A= =0A= Hi Markus,=0A= =0A= I'm sorry for this confusing log, Vdsm is treating a missing volume=0A= as a horrible=0A= error is a bug, this is expected condition when you query volume info.=0A= =0A= We also log 2 exceptions instead of one.=0A= =0A= Would file a vdsm storage bug for these issues?=0A= =0A= Thanks,=0A= Nir=0A= ------=_NextPartTM-000-4de4719a-55e3-4f08-a1f0-7cc250afc7fc Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt"
**************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-4de4719a-55e3-4f08-a1f0-7cc250afc7fc--
participants (3)
-
Ala Hino -
Markus Stockhausen -
Nir Soffer