On Sat, 2007-01-13 at 13:44 +0530, Ligesh wrote:
> On Sat, Jan 13, 2007 at 03:24:33PM +0800, Tim Post wrote:
> >
> > Why would TCP be a bad idea, if the daemon had its own built in
> > deny/allow functionality and ignored everything (including localhost)
> > but dom-0 talking to it?
> >
>
> How will you uniquely identify a domU using ipaddress?
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.
> What if the domU doesn't have network configured at all?
Very unlikely in most settings, but yes, this has to be taken into
consideration.
> 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.
I think it should be either / or / both, up to the user.
> 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.
> It is possible that the user might want to configure a firewall or something
> else that might prevent network communication.
> Even otherwise, we have to find a channel that will not interfer with the
> normal working AT ALL.
> It should be completely separate from services that people normally use and
> that includes TCP.
> If you can convert your daemon to PPP, then I am all for it. YOu need a
> kernel module to make sure
> that the daemon is always running though, but I think we can have a monitor
> in the dom0 to keep pinging
> the daemon and alert the administrator if it is not running.
My question is this, lets say we have a farm of 20 servers , all running
xen, each supporting 50 or so guests. That basically describes one of my
Xen farms.
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
Best,
--Tim
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|