You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@cloudstack.apache.org by "S. Brüseke - proIO GmbH" <s....@proio.com> on 2017/01/19 09:04:13 UTC

Template management

Hey guys,

I have a question regarding templates and how you manage these in you CS installation.

We are planning to create a new template for Debian, CentOS and Ubuntu each month to keep them up2date, because we have a short lifecycle for servers. Does anybody do the same or has other workflows for that?

One big downside of that is that (as far as I understand CS) our primary storage (we are using XenServer) is getting filled up with templates. CS is not deleting a template until all VMs created by this template are expunged. Can somebody confirm this?

I am really interested in other solutions and workflows, so please shoot. :-)

Mit freundlichen Grüßen / With kind regards,

Swen

- proIO GmbH -
Geschäftsführer: Swen Brüseke
Sitz der Gesellschaft: Frankfurt am Main

USt-IdNr. DE 267 075 918
Registergericht: Frankfurt am Main - HRB 86239

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error) please notify
the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Re: Template management

Posted by Dag Sonstebo <Da...@shapeblue.com>.

Hi Swen,

Yes appreciate this – this is why shared storage is better for this scenario – no merging of disks.

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 23/01/2017, 11:37, "S. Brüseke - proIO GmbH" <s....@proio.com> wrote:

Hi Dag,

good point! Thank you for bringing it up.
Our situation is that we need to use storage live migration to do XenServer updates anyway.

Mit freundlichen Grüßen / With kind regards,

Swen

-----Ursprüngliche Nachricht-----
Von: Dag Sonstebo [mailto:Dag.Sonstebo@shapeblue.com]
Gesendet: Montag, 23. Januar 2017 12:28
An: users@cloudstack.apache.org
Betreff: Re: Template management

Hi Swen,

Keep in mind what you are doing during this process – the migration effectively merges the disk chain for each VM to a single bigger disk, which will now take up a lot more space on the destination than on the source storage pool. This won’t matter with a single VM – but if you have multiple VMs using the same template you lose all the benefits of the space saving in the linked clone disk chains. Every VM you do this to now use the full size merged disk – no disk chains – as a result you are using a lot more space in your estate.

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 23/01/2017, 08:35, "S. Brüseke - proIO GmbH" <s....@proio.com> wrote:

I did some testing and want to share my findings:
When using local storage a way to delete old templates which are stuck because of a XenServer chain is to perform a live migration and move the vm to another host. The chain will be deleted and after the clean up job of CS did run the template will be deleted too. Any idea how we can use this?

Mit freundlichen Grüßen / With kind regards,

Swen

-----Ursprüngliche Nachricht-----
Von: Dag Sonstebo [mailto:Dag.Sonstebo@shapeblue.com]
Gesendet: Donnerstag, 19. Januar 2017 15:34
An: users@cloudstack.apache.org
Betreff: Re: Template management

Hi Swen,

Assuming you are using advanced zones my idea below would involve:

1) Create a patching account in your CloudStack environment.
2) Spin up your repo clone boxes in this account – and configure these with some sort of nightly synch with the RHEL / Ubuntu / CentOS / etc yum etc repositories.
3) On the public IP address for the patching account configure firewalling / NATing to allow anyone from the same public IP range to access the repo boxes.
4) Configure a DNS entry for this IP address on the DNS servers used by your CloudStack infrastructure.
5) Configure cloud-init or similar to check for updates on the DNS server name – either on reboot or with a cron type job on a specific date of the month.

Just one idea, there will be many ways to do this. The synched repo boxes don’t need to be hosted in CloudStack, they could just be hosted externally on an IP address accessible from your public range.
The other thing is you probably want your end users to be able to opt in or out of this mechanism, so you may want to put in place some user key/values to control this. If you wanted you could also rig up some automation where the VM is snapshot’ed prior to patching so users have a rollback point.

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 19/01/2017, 14:09, "S. Brüseke - proIO GmbH" <s....@proio.com> wrote:

Hi Dag,

how can I provide connection to an internal repo for all networks in my CS installation by default?

Mit freundlichen Grüßen / With kind regards,

Swen

-----Ursprüngliche Nachricht-----
Von: Dag Sonstebo [mailto:Dag.Sonstebo@shapeblue.com]
Gesendet: Donnerstag, 19. Januar 2017 14:41
An: users@cloudstack.apache.org
Betreff: Re: Template management

Hi Swen,

If you wanted to do this on boot with cloud-init or a similar mechanism you would actually engineer the solution such that an internet connection wasn’t required. If you have every VM updating over the internet you end up paying for a lot of unnecessary bandwidth. You would instead make sure you have internal cloned patch repositories which you synchronize hourly/daily - which means all user VMs only pull patches on the internal network. You could even “eat your own dogfood/drink your own champagne” and host this on one of the accounts in the same CloudStack infrastructure – then simply set up connection on the public network. That way the update traffic isn’t ever leaving your switches per se.

Not sure how AWS etc. do this, but they have deep pockets…

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 19/01/2017, 13:31, "S. Brüseke - proIO GmbH" <s....@proio.com> wrote:

@Dag: Thanks for the confirmation and for the link.

@Rene: Of course it is the user's responsibility, but we want to provide a VM with the latest updates each time you deploy a new VM. :-) I know that cloud-init can do this on boot, but what if the network has no internet connection?

Does anybody know how AWS or DigitalOcean is handling this?

Mit freundlichen Grüßen / With kind regards,

Swen

-----Ursprüngliche Nachricht-----
Von: Rene Moser [mailto:mail@renemoser.net]
Gesendet: Donnerstag, 19. Januar 2017 11:03
An: users@cloudstack.apache.org
Betreff: Re: Template management

Hi Swen

On 01/19/2017 10:04 AM, S. Brüseke - proIO GmbH wrote:

> I am really interested in other solutions and workflows, so please
> shoot. :-)

We decided to not doing or minimize (1-2 updates per year) templates updates for "system updates" for two main reasons:

1. It is the user's responsibility to keep systems up to date anyway.
2. Using cfg management and/or cloud-init is more than easy to update systems.

Regards
René

- proIO GmbH -
Geschäftsführer: Swen Brüseke
Sitz der Gesellschaft: Frankfurt am Main

USt-IdNr. DE 267 075 918
Registergericht: Frankfurt am Main - HRB 86239

Dag.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue