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.neelar...@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:lbarfi...@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.li...@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 >> >>
