So, we have thought about this a bit as well. Our solution, which we haven't actually implemented yet, was to create a "registerVirtualMachine" api call that would be similar to deployVirtualMachine but accept a "rootdiskid" and storage pool id. This would essentially enter a vm into the db but just copy the " rootdiskid" into the root volumes space rather than creating a new one. This would allow root disks to be created outside of cloudstack and then made known to cloudstack. It wouldn't be terribly difficult to implement (the current deploy only creates a root disk if it doesn't already exist so would be easy to short circuit), you would want to ensure the service offering matches the storage tags though.
A "registerVolume" would also be useful. On Sep 22, 2014 9:18 PM, "Will Stevens" <wstev...@cloudops.com> wrote: > ws: inline... > > Thanks for the response Mike. :) > > > *Will STEVENS* > Lead Developer > > *CloudOps* *| *Cloud Solutions Experts > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 > w cloudops.com *|* tw @CloudOps_ > > On Mon, Sep 22, 2014 at 7:39 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > > > 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. > > > > ws: so in this case the original VM would be managed by CS and the 3rd > party software would be backing it up and replicating it to other > zones/regions. technically, we should have all of the information we need > about the VM because CS will already know about the original VM which this > VM is getting spun up to replace. essentially this would be used for DR in > a different DC. if one DC goes down for some reason, this would basically > behave like a cold standby in a different DC. > > you did touch on a pipe dream of mine though (which I am still in the > process of thinking through). I want to be able to spin up a fresh CS > install and then discover an existing xen pool and then configure CS to > step in as an orchestration tool for the existing infra. I am still > thinking through how this would be possible, but this is outside the scope > of this specific problem, so I won't derail this topic. > > > > > #2 might be easier. > > > > ws: I agree that this might be an easier way to approach the problem. I > still need to think through where the gotchas are with this approach. > > > > > #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. > > > > ws: I think this is the worst solution for my specific situation (because > it still requires a copy), but as a general approach for simplifying this > process, I think it has the most potential. this approach would be useful > to a much wider audience and could potentially reduce the frustration and > migration time for onboarding and migrating customers to CS. > > > > > > > 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>*™* > > >
