On Thu, 2006-11-30 at 21:18 +0100, Henning Sprang wrote:
>
> Finally, I think giving guarantees might be easier than the monitoring
> and measuring I intend - you can "simply" (much simplified, I have no
> ready solution but think it's easier) measure I/O throughput, and if a
> domain can't get to it's guaranteed level, (aasumed it's actually
> trying to use the ressources), the guarantee isn't met and measures
> need to be taken - other domains need to be scheduled down, or a
> migration to more powerful hardware is needed.
>
> Henning
>
I've been playing with this too. The scenario you describe works well
provided there is extra room in ram and under utilized CPU credit from
other guests.
I saw some work trying to make strides in open source disk QoS but I'm
not entirely sure how far its come.. but it seems to me the only
(responsible) way to manage this is with san / nas storage where the
bulk of the IO is handled elsewhere. Depending on how you access the
san/nas, conventional rate limiting can come into play.
If you virtualize a san (effectively making it several), then the fine
tuning would be on the credit scheduling on the guests's corresponding
attached storage, not on the guest itself. The two would have to work
together. However, doing this you (mildly) shoot your nas in the foot
from the word go and horribly complicate things.
So many variables come into play such as the speed of the disks (SCSI or
SATA, does the nas have a SODIMM cache, caching raid controller, etc)
that its nearly impossible to throw one "good" solution at it.
Henning, do you have a rough diagram of what you were thinking?
Best,
-Tim
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home