That might have been a misunderstanding. I was referring to a group of contributors who happened to work for Citrix.
Since there they were clearing JIRA tickets, I thought it a good idea to create one for the issue. DL > -----Original Message----- > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > Sent: 20 December 2013 16:05 > To: dev@cloudstack.apache.org > Subject: Re: Question about XenServer Snapshots > > Donal mentioned that this is actually code written by the XenServer group, so > I will need to remove the CloudStack ticket I opened and open one for the > XenServer group. > > > On Thu, Dec 19, 2013 at 10:11 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > > > It looks like I found the issue: Insufficient space in the storage > > repository. > > > > From the XenServer vmopsSnapshot plug-in's revert_memory_snapshot > > method (which is invoked by the XenServer server resource): > > > > [root@XenServer-6 ~]# xe snapshot-revert > > snapshot-uuid=82e33f6d-59f3-a26d-4171-d51cd58716d8 > > Error code: SR_BACKEND_FAILURE_44 > > Error parameters: , There is insufficient space, > > > > I'm thinking an error should be returned from the plug-in instead of "0". > > > > I can log a JIRA ticket. > > > > > > On Thu, Dec 19, 2013 at 3:10 PM, Mike Tutkowski < > > mike.tutkow...@solidfire.com> wrote: > > > >> Hi, > >> > >> I have been experimenting with VM snapshots on XenServer and have > >> noticed a problem that I hope someone might be able to shed some light > on. > >> > >> In a normal flow of taking a VM snapshot, reverting to it, then > >> deleting the VM snapshot, I have observed the following (which looks just > fine): > >> > >> *SR:* > >> > >> uuid ( RO) : 2a061111-a8c8-11db-4a8b-f8d519f9ac3e > >> name-label ( RW): Test > >> name-description ( RW): iSCSI SR [10.10.8.108 > >> (iqn.2010-01.com.solidfire:3y8w.test.15; LUN 0: > >> 337938770000000ff47acc0100000000: 93.1 GB (SolidFir))] > >> host ( RO): XenServer-6.1-Tut-2 > >> type ( RO): lvmoiscsi > >> content-type ( RO): > >> > >> > >> - *Before VM snap:* > >> > >> > >> *Active:* > >> > >> uuid ( RO) : b4587018-9679-4fe7-ba72-5523cb988cec > >> name-label ( RW): i-2-21-VM-DATA > >> name-description ( RW): > >> sr-uuid ( RO): 2a061111-a8c8-11db-4a8b-f8d519f9ac3e > >> virtual-size ( RO): 16106127360 > >> sharable ( RO): false > >> read-only ( RO): false > >> > >> > >> - *After VM snap:* > >> > >> > >> *Base copy (contains the data of the previously active VDI):* > >> > >> uuid ( RO) : d167952d-deb4-4942-9ea8-c8b3777d885e > >> name-label ( RW): base copy > >> name-description ( RW): > >> sr-uuid ( RO): 2a061111-a8c8-11db-4a8b-f8d519f9ac3e > >> virtual-size ( RO): 16106127360 > >> sharable ( RO): false > >> read-only ( RO): true > >> > >> *Snapshot:* > >> > >> uuid ( RO) : 613dc799-cf69-445a-a2fe-611653e0b0c9 > >> name-label ( RW): i-2-21-VM-DATA > >> name-description ( RW): > >> sr-uuid ( RO): 2a061111-a8c8-11db-4a8b-f8d519f9ac3e > >> virtual-size ( RO): 16106127360 > >> sharable ( RO): false > >> read-only ( RO): false > >> > >> *Active (has the same UUID as the previously active VDI):* > >> > >> uuid ( RO) : b4587018-9679-4fe7-ba72-5523cb988cec > >> name-label ( RW): i-2-21-VM-DATA > >> name-description ( RW): > >> sr-uuid ( RO): 2a061111-a8c8-11db-4a8b-f8d519f9ac3e > >> virtual-size ( RO): 16106127360 > >> sharable ( RO): false > >> read-only ( RO): false > >> > >> > >> - *After revert to VM snap:* > >> > >> > >> *Base copy:* > >> > >> uuid ( RO) : d167952d-deb4-4942-9ea8-c8b3777d885e > >> name-label ( RW): base copy > >> name-description ( RW): > >> sr-uuid ( RO): 2a061111-a8c8-11db-4a8b-f8d519f9ac3e > >> virtual-size ( RO): 16106127360 > >> sharable ( RO): false > >> read-only ( RO): true > >> > >> *Snapshot (this VDI is un-touched):* > >> > >> uuid ( RO) : 613dc799-cf69-445a-a2fe-611653e0b0c9 > >> name-label ( RW): i-2-21-VM-DATA > >> name-description ( RW): > >> sr-uuid ( RO): 2a061111-a8c8-11db-4a8b-f8d519f9ac3e > >> virtual-size ( RO): 16106127360 > >> sharable ( RO): false > >> read-only ( RO): false > >> > >> *Active (this is a new VDI - the old active VDI was deleted):* > >> > >> uuid ( RO) : b21284fa-347a-459a-a8bf-0fcd7717a134 > >> name-label ( RW): i-2-21-VM-DATA > >> name-description ( RW): > >> sr-uuid ( RO): 2a061111-a8c8-11db-4a8b-f8d519f9ac3e > >> virtual-size ( RO): 16106127360 > >> sharable ( RO): false > >> read-only ( RO): false > >> > >> > >> - *After deleting VM snap:* > >> > >> > >> *Active (the snapshot is gone as is the base copy...the base copy was > >> rolled up into this VDI):* > >> > >> uuid ( RO) : b21284fa-347a-459a-a8bf-0fcd7717a134 > >> name-label ( RW): i-2-21-VM-DATA > >> name-description ( RW): > >> sr-uuid ( RO): 2a061111-a8c8-11db-4a8b-f8d519f9ac3e > >> virtual-size ( RO): 16106127360 > >> sharable ( RO): false > >> read-only ( RO): false > >> > >> Now, in my case, where I create an SR on the fly (in response to > >> attaching a CloudStack volume to a VM on XenServer for the first > >> time) to house a single VDI (which has guaranteed IOPS), I see the > >> following erroneous behavior when it comes to hypervisor snapshots: > >> > >> *SR:* > >> > >> uuid ( RO) : 70e06f08-2c9d-f9cf-4e64-2f064c11325a > >> name-label ( RW): /iqn.2010-01.com.solidfire:3y8w.test.19/0 > >> name-description ( RW): /iqn.2010-01.com.solidfire:3y8w.test.19/0 > >> host ( RO): XenServer-6.1-Tut-2 > >> type ( RO): lvmoiscsi > >> content-type ( RO): user > >> > >> > >> - *Before VM snap:* > >> > >> > >> *Active:* > >> > >> uuid ( RO) : 067572a8-fa4d-45b5-9365-2d7790a4b202 > >> name-label ( RW): i-2-21-VM-DATA > >> name-description ( RW): > >> sr-uuid ( RO): 70e06f08-2c9d-f9cf-4e64-2f064c11325a > >> virtual-size ( RO): 10737418240 > >> sharable ( RO): false > >> read-only ( RO): false > >> > >> > >> - *After VM snap (this appears just fine):* > >> > >> > >> *Base copy:* > >> > >> uuid ( RO) : 71d39b5b-6c90-4aa9-adbf-71b226652081 > >> name-label ( RW): base copy > >> name-description ( RW): > >> sr-uuid ( RO): 70e06f08-2c9d-f9cf-4e64-2f064c11325a > >> virtual-size ( RO): 10737418240 > >> sharable ( RO): false > >> read-only ( RO): true > >> > >> *Snapshot:* > >> > >> uuid ( RO) : afc66ec7-5493-4772-9318-6f72c9d971f8 > >> name-label ( RW): i-2-21-VM-DATA > >> name-description ( RW): > >> sr-uuid ( RO): 70e06f08-2c9d-f9cf-4e64-2f064c11325a > >> virtual-size ( RO): 10737418240 > >> sharable ( RO): false > >> read-only ( RO): false > >> > >> *Active:* > >> > >> uuid ( RO) : 067572a8-fa4d-45b5-9365-2d7790a4b202 > >> name-label ( RW): i-2-21-VM-DATA > >> name-description ( RW): > >> sr-uuid ( RO): 70e06f08-2c9d-f9cf-4e64-2f064c11325a > >> virtual-size ( RO): 10737418240 > >> sharable ( RO): false > >> read-only ( RO): false > >> > >> > >> - *After a failed revert to VM snap:* > >> > >> > >> uuid ( RO) : afc66ec7-5493-4772-9318-6f72c9d971f8 > >> name-label ( RW): i-2-21-VM-DATA > >> name-description ( RW): > >> sr-uuid ( RO): 70e06f08-2c9d-f9cf-4e64-2f064c11325a > >> virtual-size ( RO): 10737418240 > >> sharable ( RO): false > >> read-only ( RO): false > >> > >> Somehow the base copy and active VDI have both been deleted and the > >> snapshot VDI is the only remaining VDI. > >> > >> I would have expected the active VDI to be deleted and a new VDI > >> (which is initially empty) to take its place as the active VDI. The > >> snapshot should not be touched and the base copy should not be > deleted. > >> > >> Does anyone have any insight as to why this may be happening? > >> > >> Thanks! > >> > >> -- > >> *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> > >> *(tm)* > >> > > > > > > > > -- > > *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> > > *(tm)* > > > > > > -- > *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> > *(tm)*
