I followed the steps you mentioned on the bug using a software iSCSI target in a VM and could reproduce the problem. I do see INSUFFICIENT_SPACE exception being thrown when "xe snapshot-revert" is called by the vmopsSnapshot plug in. When this happens the plugin doesn't throw any exception or return any error.
The problem looks like this xe command is called via os.system module by the python plugin. xe is a different program and any error/exception thrown by this won't get propagated to the caller. To fix this os.system can be replaced by subprocess.call with a check for the return code. I tried this and this will return a non zero error code to the management server. It may still not return the child process's exception code. Let me know what you think. Thanks, Mandar On Fri, Mar 14, 2014 at 11:55 AM, Mandar Barve <mandar.ba...@sungard.com> wrote: > I tried to reproduce the issue the way you mentioned with few changes. I > don't have iSCSI SAN on my setup. I connected a 2 GB disk that I presented > as storage tagged NFS primary to CS. I created a 1GB disk offering and then > deployed a VM on this new primary. Took a couple of snapshots like you > mentioned and when tried to revert to one of them I did see an error in > vmops log that said revert_memory_snapshot returned NULL. Exception was > thrown with async job status result code 530 and text response as "Failed > to revert VM snapshot". I think this exception came later. The vmops > snapshot plugin code itself may not have landed into exception handling > path. I need to double check this. > > Is this what you are referring to? Could you attach snippets of SMlog and > mops.log when the failure happened to the JIRA? > > Thanks, > Mandar > > > On Tue, Mar 11, 2014 at 3:25 AM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> Here is the comment I just added in JIRA for this ticket. Thanks! >> >> Hi, >> >> Here is how I reproduced it: >> >> I created an iSCSI volume on my SAN that is only 2 GB. >> >> I created a XenServer SR based on this SAN volume. >> >> I created Primary Storage in CloudStack based on this XenServer SR. >> >> I created a Disk Offering that was storage tagged to use this Primary >> Storage. It will lead to the creation of a 1 GB volume when executed and >> attached to a VM for the first time. >> >> I executed the Disk Offering to create a CloudStack volume and attached >> this volume to a VM. >> >> I took two hypervisor snapshots of the VM, then reverted to the first >> hypervisor snapshot. >> >> I looked at the SR that should contain my CloudStack volume and its >> hypervisor snapshots. I saw two snapshots, but no active VDI. I should see >> two hypervisor snapshots and an active VDI. >> >> Thanks! >> >> >> On Mon, Mar 10, 2014 at 9:27 AM, Mike Tutkowski < >> mike.tutkow...@solidfire.com> wrote: >> >>> I did look at it, but haven't had a chance to try to repo. >>> >>> I should be able to try to repo it today. >>> >>> Thanks! >>> >>> >>> On Sun, Mar 9, 2014 at 10:05 PM, Mandar Barve <mandar.ba...@sungard.com> >>> wrote: >>> >>>> Hi Mike, >>>> Did you get a chance to look at this? >>>> >>>> Thanks, >>>> Mandar >>>> >>>> >>>> On Wed, Mar 5, 2014 at 10:12 AM, Mandar Barve <mandar.ba...@sungard.com >>>> > wrote: >>>> >>>>> I tested this with CS 4.3. >>>>> >>>>> Thanks, >>>>> Mandar >>>>> >>>>> >>>>> On Tue, Mar 4, 2014 at 9:09 PM, Mike Tutkowski < >>>>> mike.tutkow...@solidfire.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Can you tell me what release you tested this with? I noticed the >>>>>> problem while developing on CloudStack 4.3. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> On Tue, Mar 4, 2014 at 3:43 AM, Mandar Barve < >>>>>> mandar.ba...@sungard.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> I tried to reproduce the issue but couldn't get this to fail >>>>>>> for insufficient space. I then injected an exception trying to list >>>>>>> files >>>>>>> from a non existent path (added this code in the "try" block). This >>>>>>> landed >>>>>>> me into the exception handling code. It raised correct exception saying >>>>>>> "file not found" which was captured in the management server vmops log >>>>>>> file. It was not displayed by the GUI. GUI just reported Error (Are we >>>>>>> looking for GUI displaying error code?). The plugin code returns "0" >>>>>>> immediately after the line of code that raises exception but I think >>>>>>> this >>>>>>> applies only for successful execution of the plugin code that reverts >>>>>>> the >>>>>>> snapshot. >>>>>>> >>>>>>> If any exception is raised (e.g. in the reported case here >>>>>>> insufficient space) then the code should return appropriate error >>>>>>> message >>>>>>> to the caller as I found. In exception handling path return "0" wouldn't >>>>>>> execute. >>>>>>> >>>>>>> I don't see any problem here. Let me know if I am missing anything. >>>>>>> >>>>>>> Thanks, >>>>>>> Mandar >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Mike Tutkowski* >>>>>> *Senior CloudStack Developer, SolidFire Inc.* >>>>>> e: mike.tutkow...@solidfire.com >>>>>> o: 303.746.7302 >>>>>> Advancing the way the world uses the cloud >>>>>> <http://solidfire.com/solution/overview/?video=play>*™* >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> *Mike Tutkowski* >>> *Senior CloudStack Developer, SolidFire Inc.* >>> e: mike.tutkow...@solidfire.com >>> o: 303.746.7302 >>> Advancing the way the world uses the cloud >>> <http://solidfire.com/solution/overview/?video=play>*™* >>> >> >> >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the cloud >> <http://solidfire.com/solution/overview/?video=play>*™* >> > >
