Netapp: create_volume_from_snapshot of a different size

Bug #1098581 reported by Brano Zarnovican on 2013-01-11
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description


Netapp driver currently does not support creating volume from snapshot of a different size:

        if vol_size != snap_size:
            msg = _('Cannot create volume of size %(vol_size)s from '
                'snapshot of size %(snap_size)s')
            raise exception.Error(msg % locals())

Attached patch (for Folsom) allows you to create bigger volume from the original snapshot. Eg, 20G volume out of 10G snapshot:

# euca-describe-snapshots snap-00000042
SNAPSHOT snap-00000042 vol-0000045a available 2013-01-11T10:29:13.000Z 100% 103a49bb861e485ea05aa78f9b0216bd 10

# euca-create-volume -z --snapshot snap-00000042 -s 20
VOLUME vol-00000462 20 snap-00000042 creating 2013-01-11T11:18:42.587Z

# euca-describe-volumes vol-00000462
VOLUME vol-00000462 20 snap-00000042 available 2013-01-11T11:18:42.000Z

> lun show
 /vol/OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-0000045a/snap-00000042 10g (10737418240) (r/w, online)
 /vol/OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-0000045a/vol-0000045a 10g (10737418240) (r/w, online, mapped)
 /vol/OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-00000462/vol-00000462 20g (21474836480) (r/w, online)

Creating volume of _smaller_ size than the original snapshot will produce an error.

# euca-create-volume -z --snapshot snap-00000042 -s 5
VOLUME vol-00000463 5 snap-00000042 creating 2013-01-11T11:27:14.464Z
# euca-describe-volumes vol-00000463
VOLUME vol-00000463 5 snap-00000042 error 2013-01-11T11:27:14.000Z

2013-01-11 12:27:14 TRACE nova.rpc.amqp raise exception.Error(msg % locals())
2013-01-11 12:27:14 TRACE nova.rpc.amqp Error: Cannot create volume of size 5 from snapshot of size 10
2013-01-11 12:27:14 TRACE nova.rpc.amqp


Brano Zarnovican

Brano Zarnovican (zarnovican) wrote :

We just discovered an issue with this feature implementation.

When the original snapshot was too small (eg. 6G) compared to the new volume size (100G), create_volume_from_snapshot() method fails with a stacktrace. It is due to LUN resize failing on target filer:

> lun resize /vol/OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-00000521/vol-00000521 100g
lun resize: New size exceeds this LUN's initial geometry
lun resize: max size: 65535m (68718428160)

Right at this moment I don't know how to implement the feature to work with arbitrary sizes, sorry..

Rushi Agrawal (rushiagr) wrote :

Hi Brano, I was able to reproduce the issue which you mentioned, about not able to resize LUN. I noticed that the number '65535' is 2^16-1, which I think is some kind of limit on the filer, which we cannot change (or maybe we can, would look into it).

When I tested on another filer which has less than 64GB space, I found similar error, saying not enough space on filer.

BTW, thanks for reporting.

Brano Zarnovican (zarnovican) wrote :

This issue is not related to remaining/free space. It has something to do with drive's tracks/cylinders/heads/etc.

You can resize LUNs with <6G only up to 64G. LUNs with >6G up to 10x of its original size. Google for "netapp lun resize 10x".

> priv set diag
> lun create -s 10m -t linux /vol/.../foo1
> lun geometry /vol/.../foo1
        10485760 device size (10 MB)
     68718428160 max resize size (65535 MB)

> lun create -s 40g -t linux /vol/.../foo2
> lun geometry /vol/.../foo2
     42953867264 device size (40964 MB)
    481028997120 max resize size (458745 MB)

Proper implementation should based on these rules either clone & resize or do a completely new LUN (create & copy?).

Rushi Agrawal (rushiagr) on 2013-01-30
Changed in cinder:
assignee: nobody → Rushi Agrawal (rushiagr)
status: New → In Progress
Mike Perez (thingee) on 2013-03-09
tags: added: drivers
removed: driver
Changed in cinder:
assignee: Rushi Agrawal (rushiagr) → Ben Swartzlander (bswartz)
Navneet (singn) on 2013-08-28
Changed in cinder:
assignee: Ben Swartzlander (bswartz) → Navneet (singn)

Fix proposed to branch: master

Changed in cinder:
assignee: Navneet (singn) → Ben Swartzlander (bswartz)
Changed in cinder:
assignee: Ben Swartzlander (bswartz) → Navneet (singn)

Submitter: Jenkins
Branch: master

commit 204c3a30afd5c4d2f9e595a7c64b187e1a0531c2
Author: Navneet Singh <email address hidden>
Date: Tue Jul 30 11:04:20 2013 +0530

    NetApp fix create vol different size than snapshot

    This fixes the issue of creating vol of different
    size than snapshot and creating cloned vol of
    different size than original.

    This change adds a lot of additional LUN geometry
    and sub-LUN cloning code which is neccesary to
    support extreme resizes, since normal resize
    operations are limitted to be within a certain factor
    of the original LUN size.


    Change-Id: I8652bfaa67c12c790fa80650a051497f70279b9c

Changed in cinder:
status: In Progress → Fix Committed
Ben Swartzlander (bswartz) wrote :

The change that fixes this in Havana also implements volume resizing. If we backport the fix to grizzly, we need to remove the volume resize logic and just fix the create-volume-from-snapshot-of-different-size bug.

tags: added: grizzly-backport-netapp-potential
tags: added: grizzly-backport-potential
removed: grizzly-backport-netapp-potential
Navneet (singn) on 2013-10-03
tags: added: navneet-netapp-backport
Thierry Carrez (ttx) on 2013-10-04
Changed in cinder:
milestone: none → havana-rc1
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2013-10-17
Changed in cinder:
milestone: havana-rc1 → 2013.2
Alan Pevec (apevec) on 2014-03-31
Changed in cinder:
importance: Undecided → Low
tags: removed: grizzly-backport-potential
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers