Marcus - I think its possible even now in CS. I don¹t think we need another api. 1. You can create a vm using the deployvm api with flag startvm=false. This would create vm and its corresponding resources db records without actually creating them. You can give a dummy template for now as it still needs a templateid (we should remove this dependence in future). 2. You can then use updateVolume to update the volume with storage pool id and marking it ready. 3. Finally you use start vm api to start the vm. It would create all the resources and start the vm. Since the volume is already ready it won't go into creating the root volume.
Thanks, -Nitin On 22/09/14 10:08 PM, "Marcus" <shadow...@gmail.com> wrote: >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>** >> > >>
