On Sat, Jan 13, 2007 at 04:42:13PM +0800, Tim Post wrote:
>
> In the networks I maintain and setup, each guest gets a static public
> IP, and static MAC, so this is not an issue for me.
>
> I do however see your point. It would have to work over the serial
> redirect.
With serial port, there is no need to bother about security. You don't need
chroot, you don't need anything actually. In fact, the daemon should simply
execute it without any checks and return the output. If the dom0 is
compromized, then the domUs are goners anyway, so the daemon can just execute
everything it receives.
> > Again, we need hard science. :-) It should just work, and I shouldn't have
> > to first muck around
> > with all the network configuration.
>
> Agreed, ideally its a module that (could) make use of some helper
> applications. Similar to how AoE can use a userspace module (kvblade) or
> helper (vblade) to export block devices.
The point is, there shouldn't be any checking necessary. If it waits on the
serial port, then it becomes part of the system, and a simple feature, rather
than tacky addon that has to have a huge security heuristics, and will not work
unless another optional subsystem--that is network--is up.
> > hyperVM actually configures network automatically inside a virtual machine
> > from the outside,
> > and does it for almost all the popular distros, but even afterwards, it is
> > very difficult to keep
> > track of the ip and the vps, and also one can never be sure with the
> > network.
>
> One had better be sure :) But I understand your point. This should not
> rely on anything dynamic that can change outside of dom-0 to identify a
> VM. I.e., its possible to change an IP or MAC from within a dom-u, but
> not the domname.
Network communication is not at all an option here. THe biggest problem is all
the security stuff you had to implement, which is simply unaccetable level of
complexity. It should just work.
> I want to centralize backups, not just where they are deposited but also
> scheduling them. Or perhaps I want them stored locally on each dom-0,
> but still want centralized scheduling. How would we accomplish this? It
> seems a three part, not two part system would be best.
>
> I agree, if we're going to do it lets do it right .. and in the spirit
> of that I've just thrown another wrench into the gears :P
My system is part of hyperVM and while extremely simple, is only possible
because of hyperVM's specific architecture--that is, the entire data is stored
in a central mysql database and everything is controlled from a central node
called master. the steps are like this:
> The master connects to the backup server and gets the ssh dsa key.
> master connects to the slave and saves this key on the slave, so that the
> backup server can connect without password
> Master sends a command to the slave to create the snapshot and mount it and
> get the mount location.
> Master sends the mount location and slave's address to the script in the
> backup server through ssh.
> The backups server now has the slaves address and the directory and takes
> the backup directly.
> The master sends a command to the slave to unmount and remove the snapshot.
> Master removes the ssh dsa key from the slave.
And of course, the templates are already untarred on the backup server, so
the full backup is taken only PER Distro and not PER VM. Another advantage is
that the load is directly shared between the backup server and the slave, and
master just co-ordinates everything. SO there isn't any overhead involved. And
of course, you can simply keep adding slaves without bothering about backup,
since everything is done transparently--even the ssh key generation. The
simplicity actually comes from the core architecture which was designed from
the start to work as a multi-server system.
You can see the _entire_ php source for the above here.
http://download.lxlabs.com/vpsbackup.phps
top_level_central_backup actually prepares the vps. Stops, takes the
snapshot, and restarts for xen, and just stops for openvz.
top_level_central_backup_cleanup removes the LVM snapshot in case of Xen and
restarts the vps in case of openvz.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home