Please forgive me if this has been asked recently, is there support or plans for disk accounting and/or throttling? e.g., certain domains can only read/write so much/so often to certain disks/partitions? Thanks! Tim p.s., congratulations on the release! ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
There are plans for some improved disk QoS (I think it''s on the roadmap). The current mode of disk scheduling doesn''t differentiate different service qualities. I don''t *think* it does accounting yet (this''d likely be added at the same time). Unlike for network, there wasn''t a standard Linux way to do this. Maybe the pluggable Linux IO schedulers framework (possible merge in 2.6.10) would help with this work. HTH, Mark On Thursday 11 Nov 2004 17:26, Tim Freeman wrote:> Please forgive me if this has been asked recently, is there support or > plans for disk accounting and/or throttling? e.g., certain domains can > only read/write so much/so often to certain disks/partitions? > > Thanks! > > Tim > > p.s., congratulations on the release! > > > ------------------------------------------------------- > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Mark A. Williamson wrote:> There are plans for some improved disk QoS (I think it''s on the roadmap). The > current mode of disk scheduling doesn''t differentiate different service > qualities. I don''t *think* it does accounting yet (this''d likely be added at > the same time). > > Unlike for network, there wasn''t a standard Linux way to do this. Maybe the > pluggable Linux IO schedulers framework (possible merge in 2.6.10) would help > with this work. >Has the plan of turning Xen into a next-gen BIOS been scrapped? It seems Xen is becoming more and more dependent on having a specific version of Linux as dom0? Jacob ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Has the plan of turning Xen into a next-gen BIOS been scrapped? It seems > Xen is becoming more and more dependent on having a specific version of > Linux as dom0?Our proposed next-gen architecture now consists of: * Safe Hardware Interface - restricted access to machine resources (memory, IO regions...). Provided by Xen itself. * Next gen "BIOS controller" - general machine management... It runs all the time rather than just at bootup. * Driver domains - device drivers scheduled pre-emptively, with restricted hardware access * Virtual machines - run user applications Currently, the duties of the next gen BIOS controller and driver domains are both in dom0 but these functions can be split into separate domains if desired. But both Xen and the dom0 functionality is now notionally part of the "BIOS" (obviously you might not want ot use a full featured Linux in dom0 if you were really using this as a BIOS!!!) in the model. It''s not clear that the pluggable schedulers framework would give us the functionality we''d want anyhow. If it was useful, it wouldn''t make dom0 dependent on a specific version of Linux - it''d just mean the 2.6 port offered more functionality as a dom0. If it wasn''t useful and we rolled our own, it may well end up in 2.4 too. Cheers, Mark ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Mark A. Williamson wrote:>>Has the plan of turning Xen into a next-gen BIOS been scrapped? It seems >>Xen is becoming more and more dependent on having a specific version of >>Linux as dom0? > > > Our proposed next-gen architecture now consists of: > * Safe Hardware Interface - restricted access to machine resources (memory, IO > regions...). Provided by Xen itself. > * Next gen "BIOS controller" - general machine management... It runs all the > time rather than just at bootup. > * Driver domains - device drivers scheduled pre-emptively, with restricted > hardware access > * Virtual machines - run user applicationsIn this setup, where would stuff like the net filter be placed? In the network driver domain? How would one register the IP address of a new domain? It would be really cool to be able to run without a full Linux just for drivers. How much work do you think it would be to port one of the pre-NGIO Xen drivers to run in a separate VM? I know you guys focus primarily on server-class machines, but I am dreaming of running Xen on a 1000+ node cluster we have here, and with the current mem usage of dom0 (according to postings on this list it has a hard time coping on 32megs or less), this would waste at least 32 gigabytes of mem, just for dom0s. Jacob ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> In this setup, where would stuff like the net filter be placed? In the > network driver domain? How would one register the IP address of a new > domain?The driver is probably the best place to put filtering from a performance standpoint. IP setup could be done by defining some new control messages and sending them directly to the driver domain. You can (in theory) run a net frontend and a backend in the same domain, which would allow you to construct something like: (user VM [vif front]) <-> ([vif back] net filtering VM [vif front]) <-> ([vif back] driver domain [hardware]) So there''s a intermediary third VM doing the filtering. This would unfortunately cost you some performance, although I don''t have any numbers. I think some groundwork has been laid for doing this already but I''m not sure if it can actually be done yet.> It would be really cool to be able to run without a full Linux just for > drivers. How much work do you think it would be to port one of the > pre-NGIO Xen drivers to run in a separate VM?Well, the pre-NGIO drivers are basically just Linux drivers with some (varying quantity of) tweaks. Xen provided them with a Linux-like environment to make porting easy. There was talk of modifying the mini-OS to pull in enough of a Linux env to support some drivers in a very small memory footprint, which might be a good way of tackling this. Driver domains could run in 3meg anyhow if they don''t have any userspace, so this isn''t going to get huge savings.> I know you guys focus primarily on server-class machines, but I am > dreaming of running Xen on a 1000+ node cluster we have here, and with > the current mem usage of dom0 (according to postings on this list it has > a hard time coping on 32megs or less), this would waste at least 32 > gigabytes of mem, just for dom0s.Woah! Really cool ;-) And yes, the 32 gig memory footprint is scary. OTOH, you''ve probably got a couple of terabytes of ram! I guess the best way if you really want to save memory would be a lightweight (possibly more specialised) Xend, to enable much smaller dom0s. Cheers, Mark ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Has the plan of turning Xen into a next-gen BIOS been scrapped? It seems > Xen is becoming more and more dependent on having a specific version of > Linux as dom0?As you know, Xen itself isn''t dependent on anything much -- but a machine with just Xen and no domain 0 doesn''t actually do anything. Any domain 0 which can provide the requisite functionality (control tools and backends mainly) is fine -- we''re currently using linux 2.6.9 for this as it seems the logical choice (lots of functionality, mature code base, widespread user knowledge). If someone wants to write a ''custom'' OS for dom0 to address some perceived overhead, then they should feel free to. It probably could be quite a lot smaller than linux. Even in this case, however, we''re extremely likely to retain linux 2.6.x as a recommended backend platform due to the wide-ranging hardware support. The 1.2-style notion of writing new drivers to run within Xen is effectively untenable unless folks are prepared to spend a hell of a lot of time writing + testing driver code... cheers, S. ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> I know you guys focus primarily on server-class machines, but I am > dreaming of running Xen on a 1000+ node cluster we have here, and with > the current mem usage of dom0 (according to postings on this list it has > a hard time coping on 32megs or less), this would waste at least 32 > gigabytes of mem, just for dom0s.Yes, but it''s still the same fraction of total memory. If you can afford a 1000-node cluster with terabytes of RAM then 32GB is utterly inconsequential. -- Keir ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel