> On June 16, 2014, 9 p.m., Mike Tutkowski wrote:
> > I was curious about the resizing of the VDI to take up all of the space of
> > the SR.
> >
> > This is actually what I initially did in 4.2; however, it later dawned on
> > me that - if you want to take hypervisor snapshots - then you need to have
> > extra space left over in the SR. In other words, the VDI should be less
> > than the size of the SR.
> >
> > To support this, I added a new field in 4.3: hypervisor_ss_reserve. This
> > field is a percentage of the size of the CloudStack volume (the VDI).
> >
> > For example, if the user wants a 20 GB CloudStack volume (VDI) and the
> > hypervisor snapshot reserve field is set at 200%, the SR will be 60 GB (20
> > GB for the VDI + (20 GB * 2)).
> >
> > Please let me know if you'd like more clarification on this. You can also
> > examine the SolidFire plug-in to get a feel for how this new field is
> > utilized.
thanks mike, since i'm still implementing snapshot i forgot to take a look at
this field.
following your logic, now i'm resizing the vdi only to the cloudstack volume
size instead of SR size, hence not using the entire SR size which contains the
hypervisor snapshot reserve.
when a user resizes the volume, let the storage plugin resize the backend
provider volume using the given snapshot reserve.
eg: from your industry standard logic,
if the current offering is at 10G and 25% reserve, this equates to 12.5 G
volume in cloudbyte. but the cloudstack volume remains at 10G in the DB.
when the user resizes the volume to a different offering say 20G and 50%
reserve, this equates to 30G volume in cloudbyte and the cloudstack volume is
resized to 20G in the DB.
hence now i'm mapping the vdi size to cloudstack volume size.
thanks.
- punith
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22631/#review45757
-----------------------------------------------------------
On June 17, 2014, 2:58 p.m., punith s wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22631/
> -----------------------------------------------------------
>
> (Updated June 17, 2014, 2:58 p.m.)
>
>
> Review request for cloudstack, amit kumar das, edison su, and Mike Tutkowski.
>
>
> Repository: cloudstack-git
>
>
> Description
> -------
>
> currently managed storage only supports iscsi protocol.
>
> hence now adding support for nfs protocol and also resizing the vdi to the SR
> size, hence fully utilizing the SR space in managed storage.
>
> to support nfs, the getNfsSR method's signature has to changed similar to
> existing getIscsiSR method.
>
> SR will be created based on the volume's protocoltype.
>
> jira id - CLOUDSTACK-6916
>
>
> Diffs
> -----
>
> api/src/com/cloud/agent/api/to/DiskTO.java 5901367
>
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
> eea931e
>
> plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
> 9979802
> server/src/com/cloud/storage/VolumeApiServiceImpl.java 9b034e9
>
> Diff: https://reviews.apache.org/r/22631/diff/
>
>
> Testing
> -------
>
> system testing done.
>
>
> Thanks,
>
> punith s
>
>
