You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Mike Tutkowski <mi...@solidfire.com> on 2013/12/19 23:10:03 UTC
Question about XenServer Snapshots
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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
Re: Question about XenServer Snapshots
Posted by Mike Tutkowski <mi...@solidfire.com>.
I went ahead and forwarded the message to the XenServer group, as well.
If anyone here does have knowledge about XenServer snapshots, it is also of
interest to note that deleting a VM snapshot (as long as I didn't do a
revert) works fine.
So, that means taking and deleting the VM snapshot is fine, but reverting
to the VM snapshot is what is failing.
On Thu, Dec 19, 2013 at 3:36 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:
> Good idea, Tim. Thanks
>
>
> On Thu, Dec 19, 2013 at 3:21 PM, Tim Mackey <tm...@gmail.com> wrote:
>
>> Mike, you might want to post this to xs-devel on XenServer.org. Some of
>> the storage engineers there would be in s better position to diagnose.
>> On Dec 19, 2013 5:10 PM, "Mike Tutkowski" <mi...@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
Re: Question about XenServer Snapshots
Posted by Mike Tutkowski <mi...@solidfire.com>.
Good idea, Tim. Thanks
On Thu, Dec 19, 2013 at 3:21 PM, Tim Mackey <tm...@gmail.com> wrote:
> Mike, you might want to post this to xs-devel on XenServer.org. Some of
> the storage engineers there would be in s better position to diagnose.
> On Dec 19, 2013 5:10 PM, "Mike Tutkowski" <mi...@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
Re: Question about XenServer Snapshots
Posted by Tim Mackey <tm...@gmail.com>.
Mike, you might want to post this to xs-devel on XenServer.org. Some of
the storage engineers there would be in s better position to diagnose.
On Dec 19, 2013 5:10 PM, "Mike Tutkowski" <mi...@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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *™*
>
Re: Question about XenServer Snapshots
Posted by Mike Tutkowski <mi...@solidfire.com>.
Hey Donal,
OK, I left the JIRA ticket for CloudStack:
https://issues.apache.org/jira/browse/CLOUDSTACK-5583
Thanks!
On Mon, Dec 23, 2013 at 3:01 AM, Donal Lafferty
<do...@citrix.com>wrote:
> 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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
RE: Question about XenServer Snapshots
Posted by Donal Lafferty <do...@citrix.com>.
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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*
Re: Question about XenServer Snapshots
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
Re: Question about XenServer Snapshots
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*