I'm glad to see that there's a potential workaround for this. Perhaps this should be somehow incorporated in the installation process to allow smaller setups to be implemented on hypervisors with existing VMs. The main benefit in my mind though is as the OP suggests - DRaAS.
I think that having a "registerVolume" that would import the VM's metadata and register it into CS management, including renaming to suit the conventions would be a great addition. As the OP has already mentioned, this would also open up the possibility of using a number of backup and DR tools already on the market with minimal effort to integrate with CS - it would bring the RTO down significantly if the volumes were already in primary storage, ready to be fired up at will. This would certainly gain favour in scenarios where CS operators are looking to run BDR as a service for clients (such as ourselves, the OP and a growing number of managed service providers currently just offering backup as a service but not DR). I'm pretty sure that vCloud Director has a few commercial BDR software options that currently won’t work easily with CS due to this, or at least the perception by software vendors that it can't easily be done. Simplifying the process of importing existing VMs would definitely be something that would increase takeup of CS in certain use-cases and at the same time boost CS's public visibility through it's 'ecosystem' of partners. If the 'product' is made as partner friendly as possible, they in turn help the marketing efforts. Vision's DoubleTake had a CS integration but from what I can tell it's largely been forgotten as it is no longer supported with 4.3 or 4.4 and there doesn’t seem to be a roadmap for this update. Adrian -----Original Message----- From: Nitin Mehta [mailto:nitin.me...@citrix.com] Sent: 23 September 2014 07:15 To: dev@cloudstack.apache.org Subject: Re: Launch a VM (not from a template) 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>*�* >> > >>
