If you did #1, how would you pick a relevant compute offering? You would probably need to look first to make sure at least one existed that could satisfy your requirement(s) and then make sure the resources could be marked in advance as if they were being consumed.
#2 might be easier. #3 could be really useful if storage vendors allow you to take snapshots that reside on their own SAN (instead of secondary storage). Then a template could be spun up from the SAN snapshot. On Mon, Sep 22, 2014 at 4:58 PM, Will Stevens <wstev...@cloudops.com> wrote: > Hey All, > I am looking for some advice on the following problem. I am fully aware > that I will probably have to build this functionality into CS, but I want > to get your ideas before I go too far down one path. > > *Intro:* > We have a backup/DR solution that can basically take stateful incremental > snapshots of our systems at a hypervisor level. It does a lot of other > magic, but I will limit the scope for now. It can also make the snapshots > available directly to the hypervisor (in multiple datacenters) so they can > be spun up almost instantly (if CS is not in the picture) by the > hypervisor. > > *Problem:* > If we spin up the VM directly on the hypervisor, CS will not know about it, > so that currently is not an option (although detecting that VM would be > ideal). > If we need to spin up the VM through CS, the current process is entirely > too inefficient. My understanding is that the only option would be to > import the snapshot as a template (over http) and then once uploaded, it > would then have to be transferred from secondary storage to primary storage > to get launched. For the sake of argument, if that template is 1TB in size > this process will take FOREVER. > > *Potential Solutions:* > 1) Let the backup tool spin the VM on the hypervisor and then update CS to > recognize the new VM as being managed by CS (this would be ideal). > 2) Enable CS to recognize the templates available on the hypervisor > directly so it could just launch the template directly from there without > having to do any copying. > 3) Develop a way to launch a VM from a remote location and skip secondary > storage completely. This would be something like launching from a LUN > exposed over Fibre Channel. In this case we would still have to do a copy > from that location to primary storage, but we have at least reduced the > transfer overhead some. > > Any other suggestions or ideas? > > Thanks, > > *Will STEVENS* > Lead Developer > > *CloudOps* *| *Cloud Solutions Experts > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 > w cloudops.com *|* tw @CloudOps_ > -- *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>*™*
