> On June 16, 2014, 3:30 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. > > punith s wrote: > 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.
You should actually get hypervisor snapshots for "free." Now, CloudByte-specific snapshots are a different story, but hypervisor snapshots should just work with the changes I put in for managed storage. - Mike ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22631/#review45757 ----------------------------------------------------------- On June 17, 2014, 9:28 a.m., punith s wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/22631/ > ----------------------------------------------------------- > > (Updated June 17, 2014, 9:28 a.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 > >
