Launch a VM (not from a template)

[Will Stevens]

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_

Re: Launch a VM (not from a template)

[Mike Tutkowski]

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  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
*™*

Re: Launch a VM (not from a template)

[Will Stevens]

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 
> 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
> *™*
>

Re: Launch a VM (not from a template)

[Marcus]

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"  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 
> > 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.  Thi

Re: Launch a VM (not from a template)

[Nitin Mehta]

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"  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"  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 
>> > 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 underst

RE: Launch a VM (not from a template)

[Adrian Lewis]

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"  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"  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