cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Logan Barfield <lbarfi...@tqhosting.com>
Subject Re: Cross Zone Templates
Date Tue, 27 Jan 2015 16:08:41 GMT
This is on CloudStack 4.4.

I'm thinking the necessary fixes are:
- If using region-wide (Swift/S3) secondary storage make the "Copy"
function set the "cross_zones" field to "1" for the selected template,
and add an entry for each zone to the template_zone_ref table.
- If using region-wide (Swift/S3) secondary storage all templates
(created with register template, create template from snapshot, create
template from volume) should automatically be set as cross_zone, and
have entries added to template_zone_ref upon creation.

These two changes will allow easy migrations from a single-site to a
multi-site setup, and allow everything to work as it should by
default.  The region-wide qualifier is important, since right now the
assumption that users shouldn't be able to create cross_zone templates
by default DOES make sense for zone-wide secondary storage scenarios.

Overall so far I'm finding the multi-site support (both functionality
and documentation) extremely lacking for CloudStack.  I'm still
testing it's behavior before expanding our production environment, but
both the secondary storage logic, and the multi-zone/remote datacenter
logic seem way too prone to catastrophic failure.

Thank You,

Logan Barfield
Tranquil Hosting


On Mon, Jan 26, 2015 at 11:54 PM, Sanjeev Neelarapu
<sanjeev.neelarapu@citrix.com> wrote:
> Which version of CS it is? I remember the similar issue in 4.2 and I think it got fixed
in later versions.
>
> -Sanjeev
>
> -----Original Message-----
> From: Logan Barfield [mailto:lbarfield@tqhosting.com]
> Sent: Tuesday, January 27, 2015 4:16 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Cross Zone Templates
>
> Ilya,
>
> The problem is that this doesn't work with the "region-wide" storage model for S3.  Right
now it's impossible to copy templates when using
> S3 storage for the reasons I mentioned in my last response.  It's also apparently impossible
(without database editing) to make a template cross-zone when creating it from a snapshot
or volume.  Only allowing cross-zone templates when registering them from a URL is stupid.
>
> Thank You,
>
> Logan Barfield
> Tranquil Hosting
>
>
> On Mon, Jan 26, 2015 at 5:36 PM, ilya musayev <ilya.mailing.lists@gmail.com> wrote:
>> As you know, when template is imported as "all zones" template, it has
>> an ID that is same on all zones. If you delete a cross zone template
>> on 1 zone, it will be removed from all.
>>
>> The moment you break away from this model and load templates as unique
>> entities in each zone, the ID will change from zone to zone.
>>
>> You can also try clonning the template in the UI to a different zone,
>> i'm not certain if ID is preserved - but you can give it a try.
>>
>> If you abstract cloudstack with your own frontend. You can fetch the
>> template ID by using name and zone id.
>>
>> Regards,
>> ilya
>>
>> On 1/26/15 1:48 PM, Logan Barfield wrote:
>>>
>>> I'm setting up a test zone for a multi-site deployment, and I've thus
>>> far been unable to deploy a VM from our existing templates.
>>>
>>> We're using S3 for secondary storage, and we have set up an NFS
>>> staging server in the remote zone.  The management server is able to
>>> mount the NFS store over the site-to-site VPN.
>>>
>>> When we attempt to deploy a VM in the new zone, we get "Template <id>
>>> is not available."
>>>
>>> It appears that this is because our templates are not set up as
>>> "Cross Zone Templates."
>>>
>>> We originally created these templates from existing volumes (e.g.,
>>> installed via ISO, configured, shut down VM, created template from
>>> volume).  I did not see any option in the UI or API to specify it as
>>> a cross zone template, nor do I see a way to update it after the fact
>>> (other than manually editing the database).  This functionality only
>>> seems to be available when Registering a template via a URL, which
>>> isn't any help here.
>>>
>>> Is there a reason for this weirdness?
>>>
>>>
>>> Thank You,
>>>
>>> Logan Barfield
>>> Tranquil Hosting
>>
>>

Mime
View raw message