The biggest problem I've noticed with selecting an EndPoint like this when
the storage for the template can be deployed on zone-wide primary storage
is that you won't necessarily select a host of the right hypervisor type to
deploy the template to (ex. you could have a template for XenServer and
select an ESX host as an EndPoint).
In my case, the zone-wide primary storage is a SAN and we carve out volumes
from it as needed. The SAN can be leveraged by different hypervisor types
across the zone.
It looks like I'll have to add logic to this EndPoint selection to confine
itself to a particular hypervisor type (in the zone-wide primary storage
case).
On Sat, Feb 1, 2014 at 12:02 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> Hi,
>
> In the copyObject method of AncientDataMotionStrategy, we have the
> following code to select an EndPoint:
>
> EndPoint ep = selector.select(srcForCopy, destData);
>
> if (ep == null) {
>
> String errMsg = "No remote endpoint to send command,
> check if host or ssvm is down?";
>
> s_logger.error(errMsg);
>
> answer = new Answer(cmd, false, errMsg);
>
> } else {
>
> answer = ep.sendMessage(cmd);
>
> }
> If you needed to know which EndPoint was going to be selected BEFORE this
> copyObject method was invoked, how could one do that?
>
> For example, I have a use case in 4.4 where I need to have CloudStack tell
> the storage driver in use to create a volume on its storage system.
> CloudStack then needs to tell the driver to grant hosts in a particular
> cluster access to this volume. After this, CloudStack needs to tell the
> hypervisor in use for the cluster to copy the template down to the recently
> created storage (this is a case where we are spinning up a VM based on a
> template that uses managed storage).
>
> The way I was planning on doing this was to select an EndPoint using
> similar logic to what's above and then pass that EndPoint in to both the
> method that grants hosts access to the recently created volume AND pass
> that same EndPoint in to the copyObject method (this necessitates creating
> a new method on the interface that AncientDataMotionStrategy implements).
>
> Thoughts on this? These are the steps in outline form:
>
> * CloudStack wants to deploy a VM that uses a template to managed storage
> (an example of managed storage is that the XenServer SR does not exist
> before we kick off the VM...the SR (and the VDI that represents the
> template) is created on the fly to house the root disk of the VM).
>
> * CloudStack tells the storage driver in use to create a volume on its
> storage system (this volume will be used for our XenServer SR).
>
> * CloudStack tells the storage driver to grant hosts in the applicable
> cluster access to the volume the driver just created (this is where we
> first need to know of a host in the applicable cluster).
>
> * CloudStack sends a command to a host in the applicable cluster to create
> an SR based on the volume the driver just created, then the host downloads
> a template to the SR.
>
> Once this has completed, you now have a single template as a root disk on
> a newly created SR. The volume the SR is on has guaranteed IOPS (Quality of
> Service is the reason we want only a single template on the SR). When the
> VM is expunged, its root disk (and the SR it was housed on) are destroyed.
>
> Thanks!
>
> --
> *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>
> *(tm)*
>
--
*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>
*(tm)*
