On Thu, 2004-11-11 at 20:01, Mark A. Williamson wrote:
> > If the anti-spoof isn't what I think is it, would using something like
> > ebtables be usable to provide what I want to do?
>
> I don't know about the antispoof stuff but ebtables should work fine.
> Anything that'll work with a normal Linux ethernet device should Just Work
> (TM) for a virtual interface.
>
Ok, ebtables is it then.
> > My problem is it looks
> > like the bridge interface is based on the domain id and domain id's are
> > still dynamically assigned (poor IMHO). What is the status on static
> > domain id's?
>
> The /etc/xen/scripts/vif-bridge script is used to configure firewalling, etc
> for each VIF that's created, so you don't need to statically specify
> interface names rules. You can make a derivative of this script and tell
> xend-config.sxp where to find it.
>
> I agree that it might be nice to just set up a static set of rules but with
> appropriate script magic, using dynamic configuration can probably be made
> just as easy.
>
I have only looked at this real quick, but it looks like this should do
it:
iptables ${iptcmd} FORWARD -m physdev --physdev-in ${vif} -s ${addr} -j
ACCEPT
if not, I guess i'd just have to add a ebtables line right below it.
I'll have to experiment some more.
> > It'd be good for many things, another problem is the
> > telnet console is based off of the domain id... if I handed a Xen server
> > off to a customer i'd have to basically write an interface that they'd
> > have to log in to to find out what port they should use since the last
> > server reboot, it'd be easier to just say "telnet to this host on port
> > 9605 to gain access".
>
> You can specify a console port using a console= entry in your domain
> configuration file. This is missing from the docs at the moment... *note to
> self...*
>
> Whilst you mention it, telnet is not as good as xencons for this: with
> telnet,
> console resizing (and some other stuff) don't work properly. With xencons,
> it's just like being there ;-)
Ah... I didn't even know xencons existed. Yes, it is much better.. I
had many problems with telnet dependent on the terminal emulation. Does
anyone see a problem with creating a user account for each domain in
domain0 whose shell runs xencons connecting to localhost with their
console port? Since it's technically the login shell it shouldn't pose
a security problem? I'd prefer that anyhow since it would be over ssh.
>
> > 2) CPU QoS - This looks good, even though this is for selling a service
> > where each customer should receive their guaranteed amount it looks like
> > the atropos scheduler is broken and it's better to use BVT for now.
>
> Yeah, sorry. This ought to be working by the 2.1 release (it's on my "fix
> this on a slow weekend") list.
Ok... that's great, but any input as far as BVT
values/meaning/docs/examples?
>
> > What i'm confused on is how to break down the numbers based on what kind
> > of priority each domain should get. ie. If I want the base accounts to
> > get a priority of 1 out of 4, next 2 out of 4 (total units). That
> > doesn't even make complete sense to many of you as i'm really that
> > confused as to what to set these variables to. Are there any more
> > specific documents or example configs for using the CPU schedulers?
>
> > 3) HyperThreading - Good or bad with Xen? I'd be using the 2.6 kernel
>
> Hmmmm. Depends what you're doing with it. We found an improvement in
> networking performance when running domains on separate HyperThreads on a UP
> box, compared to disabling HT. Not everyone has found this, however - it'll
> depend on your processor model and workload.
Yes.. I read that thread. These are Xeon's (only 512k) cache, I believe
the consensus was HT on a regular P4 was poor, but it helped on Xeon's.
>
> > for domain0 which I believe has full SMT support so I would assume
> > good. Also, since each domain is assign 1 CPU this would make the
> > possibilities out of 4 instead of 2 so i'm not sure if that benefits
> > over the SMT scheduler or if domains are even threaded so they benefit
> > from having the extra logical CPU's and it just makes the load un-even
> > and increases scheduling latency.
> Xen will allow you to run a uniprocessor domain on each HyperThread. The
> domains won't see an HT processor. I'm skeptical over the benefits of this,
> since the domains on each core will compete for cache space, etc. This
> hasn't been benchmarked so YMMV.
>
> You can use the hyperthreads to provide performance isolation - e.g. if a
> domain is blocking lots and ends up letting by a CPU intensive domain hog the
> processor, a quick fix is to just give them a hyperthread each.
This is exactly what I was thinking, regarding the cache coherency and
CPU intensive domains. It seems it is both a pro and a con depending on
the workload.
>
> > 4) I/O QoS - This is just round robin for now? I see it on the
> > roadmap. I have already envisioned the scenario with someone purchasing
> > a server with 64MB physical ram and adding a 512MB swap file inside
> > their server and just completely thrashing the disks. Is the current
> > system good enough to handle this (assuming some good SCSI disks are
> > being used) ?
>
> For network, you should be able to use any standard Linux QoS tools you want.
>
> For block IO, the requests are batched and serviced in a round robin fashion.
>
> This (obviously) doesn't provide service differentiation, or accounting. I
> think this is still on the roadmap and would certainly be cool to have.
>
That's what I thought also... I know for a fact the domain swapping a
lot will happen so there should definitely be a way to penalize for it
rather than having it slow down the other domains. At least there is
_something_ in place now though.
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home