Re: Template management

[Dag Sonstebo]

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"  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.sonst...@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"  
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.sonst...@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"  
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.sonst...@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 

AW: Template management

[S . Brüseke - proIO GmbH]

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.sonst...@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"  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.sonst...@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"  
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.sonst...@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"  
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?
  

Re: Template management

[Dag Sonstebo]

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"  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.sonst...@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"  
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.sonst...@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"  
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:m...@renemoser.net] 
Gesendet: Donnerstag, 19. Januar 2017 11:03
An: 

RE: Secondary storage 0KB in dashboard.

[조대형]

Hi, All
I finally figured it out.
I should have mount the secondary storage at Management Server. Then download 
the system VM. 
When I created the Zone, system VM was started then secondary storage displayed 
its capacity.


Thanks, 



-Original Message-
From: 조대형 [mailto:carl...@renet.kr] 
Sent: Monday, January 23, 2017 4:31 PM
To: 'users@cloudstack.apache.org'
Subject: Secondary storage 0KB in dashboard.

Thanks for the tips, Dag

I have performed the fresh installation with 4.9 Cloustack. 

But, the result is same

Secondary Storage
0.00 KB / 0.00 KB

 Error on Cloudstack : Unable to restart s-10-VM which was running on host name:
   Console proxy up in zone: xxx lproxy: v-9-VMpublic 
IP: nullprivate IP: N/A

Management log attached as well.

Thanks, 

-Original Message-
From: Dag Sonstebo [mailto:dag.sonst...@shapeblue.com] 
Sent: Friday, January 20, 2017 9:13 PM
To: users@cloudstack.apache.org
Subject: Re: Secondary storage 0KB in dashboard.

Hi Carlcho,

You discussed this in a different thread earlier in the week – and we’re still 
not clear what your circumstances are. Paul Angus suggested you may have issues 
with your SSVMs – have you confirmed this is running? Is this a brand new 
install? If so we would probably advise you to use 4.9.2 instead. 

Can you also confirm you have definitely seeded your system VM templates on 
your secondary storage before adding this?

If you can give us a bit more information about your configuration we should 
hopefully be able to assist.

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 20/01/2017, 07:04, "조대형"  wrote:

Permalink 
Raw Message
Hi, All


I have install cloudstack 4.7on new centos 6.xwith latest kernel. I manage
to make cloudstack management up and running. I have success adding primary
storage . When I try to add secondary storage from same nfs server,
from dashboard it show 0 KB. But using same nfs same server no problem on
primary. I'm still confused.
Any solutions?



dag.sonst...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
  
 

AW: Template management

[S . Brüseke - proIO GmbH]

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.sonst...@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"  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.sonst...@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"  
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:m...@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

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. 
Wenn Sie nicht der richtige Adressat sind