Thanks for all the replies, we seem to be making some progress and I'm starting 
to understand the actual issues. 

If in order to implement this, the feature had to be literally magic and take 
care of every possible software scenario then it would never happen. I was 
coming from a place where this is an advanced feature which requires a little 
knowledge on the CT guest to use. The CT has to be manually prepared (which as 
the whole process of creating the CT with the required config/ software/ etc. 
is manual anyway, I don't see the problem).

I have only seen one constructive problem raised which is point 1 of Dietmar's 
email. What other problems are there to implementing this?

> > >Installing software that way is a bad idea. I always create debian
> > >packages before installing something.
> > 
> > That is not correct. One example is any software from Oracle.com - it needs
> > to be installed using the Oracle installer because it makes many config 
> > files
> > which are specific to the target environment.
> 
> Oracle should really provide packages.

Do you think you could let them know? ;)

> 
> >  In addition, what if the target
> > CT is not Debian? 
> 
> Then you need an RPM package.
> 
> > The same issue exists with RPMs btw. Using a Debian
> > package would not be supported by the vendor as a method of install and be
> > a huge undertaking to do in the first place.
> > 
> > >> So are you saying that
> > >> because there is nothing written down on OpenVZ, Proxmox will not
> > >> support this feature? I basically want to create a template from an 
> > >> existing
> > CT.
> > 
> > >IMHO creating a OpenVZ template is always a manual process, because you
> > >need to carefully remove unwanted files/data/daemons.
> > 
> > If it's created from an existing template, what is there to remove? I'm not
> > talking about creating a template from scratch here - as that's not really
> > possible anyway using just a CT. I'm talking about creating a new template
> > from an existing CT.
> 
> secret keys, passwords, unique ids, IPs, logs, ....

Obviously, anything you leave on the machine will be replicated to the next CT 
created from the template. This is a feature, and not a problem. Creating a 
template will require a couple of IQ points - and for the scenario you mention 
they should use backup and not create a template. This is the same if you do it 
manually - they will need to be removed if you do not wish them to be in the 
Template. 

> 
> > I'd really like to get this feature available in Proxmox as every time I 
> > create a
> > new template I have to SSH to the box and tar the CT folder. It's such a
> > simple process and it drives me crazy every time I have to SSH to the box.
> > 
> > Is there any way of getting this feature into Proxmox - even if it means
> > completely changing how it's implemented, or is this just a no-go from the
> > start?
> 
> I see the following problems with this approach:
> 
> 1.) Our security model assumes the OpenVZ templates do not contain secrets 
> (templates
> are readable by all storage users). So a simply copy of existing VMs is likely
> to leak passwords and other secret data!

I agree - I didn't realise that template storage was not protected. Perhaps we 
could create a new storage role which would be used for templates? 

> 
> 2.) Many software packages (and admins) copy IP addresses or hostname into
> configuration files. This will lead to non-functional templates.

This would be a problem whichever way you look at it. Your 'supported' way of 
creating a backup and restoring it would have the same trouble. 

> 
> 3.) Containers can contain custom network configs (veth, ...). . This will 
> also 
> lead to non-functional templates.

Again, this would be an issue with your supported method. 

> 
> Point 1 is a no-go for me.

 


_______________________________________________
pve-devel mailing list
[email protected]
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Reply via email to