Hi, just to briefly add to this discussion. On stock install OpenVZ environments, you can get away with just a "tar" duplication if you want, as a means to 'clone' the VM data; although vzdump is probably a slightly cleaner way to do this / automate the steps.
Note that the vz config files for a given VEID OpenVZ VHOST reside in /etc/vz/conf/VEID.conf
Likely you won't want to play with much of the content in this file, but the last section/stanza will be relevant to change the name and IP of the virtual host:
(for example, from a fresh created test CentOS 5 virtual host ...)
--paste--
100 cd /etc/vz/conf
...
106 more 108.conf
top ~90% of file cropped... then ...
# CPU fair sheduler parameter
CPUUNITS="1000"
CPUS="1"
VE_ROOT="/var/lib/vz/root/$VEID"
VE_PRIVATE="/var/lib/vz/private/$VEID"
OSTEMPLATE="centos-5-standard_5.2-1_i386"
ORIGIN_SAMPLE="pve.auto"
IP_ADDRESS="127.0.0.1"
HOSTNAME="centos-test-host.test.domain"
DESCRIPTION="CentOS 5 (standard)"
NAMESERVER="10.1.1.1"
SEARCHDOMAIN="test.domain"
--endpaste--
If you want to do as little as possible via command line, then your 'easy' way to do this might be,
-- take a dump of your 'golden copy' vzhost using 'vzdump' as root user on console of the 'source' ProxVE host.
-- on a ProxVE host where you intend to deploy a clone openvz host: create via web interface a new openvz VHOST to act as a 'place holder'
-- then start a bit of work on the root console of the 'target' ProxVE host / as root:
-- bring a copy of the 'golden copy' vzdump file over to this 'target' ProxVE host (via scp )
-- use vzdump with the 'restore' flag option to extract the VM data
-- manually destroy via command line the private data for the 'place holder' VM and put the 'real content' as derived from your vzdump-restore golden image -- in its place (simpy 'mv' the directory to the appropriate location)
-- edit the vz config file in /etc/vz/conf for your VHOST to reflect its new ID
(IP address, hostname, etc)
To force regeneration of ssh keys, I believe hints are sitting inside the /etc/init.d/sshd init script file; it looks to me that the sshd startup script will auto-generate keys if there are none present on the filesystem. So it likely is a matter of just starting the vhost, deleting the existing ssh keys, and then restarting the host - to force it to regenerate fresh keys for this instance of the vhost.
(there appear to be 3 keyfiles, stored ~ @ /etc/ssh/ssh_host_key ... type file names)
Clearly if you have other apps installed in your vhost which need to be adjusted / re-keyed in the same manner - I suspect a similar process will be possible, depending on what those apps are. (Database, etc - maybe need default passwords changed ?)
Hope this helps slightly,
Tim