Sorry...I somehow missed this e-mail. Yes, I think trying that approach sounds good.
Thanks! On Mon, Jul 7, 2014 at 8:11 AM, Mandar Barve <mandar.ba...@sungardas.com> wrote: > 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>*™* >>> >> >> > -- *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>*™*
