I''ve posted a version of our Xen requirements document at the following URL. http://www.ncultra.org/xen/xen_req.html I''m interested in comments from the community. We developed these requirements within IBM to guide our own prioritization, but have always intended to submit them to the community for review. If there is interest in maintaining a document like this in the community, I would be willing to continue working on it in conjunction with others. Mike -- Mike D. Day STSM and Architect, Open Virtualization IBM Linux Technology Center 3039 Cornwallis Road Research Triangle Park, NC 27709 Phone: (919) 543-4283 ncmike@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, 16 Apr 2005, Mike D. Day wrote:> http://www.ncultra.org/xen/xen_req.htmlThe spec looks good to me, just a few small comments: core.smp.guest.virtual - running with vcpus > #cpus seems to work already, I''m doing this on a regular basis to test for bugs ;) core.dynamic.memory - I''m not sure if it is possible yet to boot a domain with less memory than its maximum, and grow the domain''s memory later through the balloon driver we''re missing an io.device.virt.discovery - in order to be able to install into, and manage, a virtual machine, the OS needs the ability to discover what virtual devices are present - exporting through sysfs would work fine. Since this is a requirement for many system administration tools (eg. kudzu), this should probably be a Xen v3.0 target io.protocol.ipsec and io.protocol.ipv6 seem to just work, by virtue of Xen emulating ethernet instead of any particular protocol - at least ipv6 works in bridging mode, I haven''t tried routed mode yet, nor ipsec -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> core.dynamic.memory - I''m not sure if it is possible yet to > boot a domain with less memory than its maximum, and grow > the domain''s memory later through the balloon driverIt used to work but right now it seems to be broken (at least in the unstable tree).> we''re missing an io.device.virt.discovery - in order to > be able to install into, and manage, a virtual machine, > the OS needs the ability to discover what virtual devices > are present - exporting through sysfs would work fine. > Since this is a requirement for many system administration > tools (eg. kudzu), this should probably be a Xen v3.0 targetThey do appear in sysfs, though, don''t they? I remember that kudzu, anaconda, etc. didn''t recognise them but I never knew why...> io.protocol.ipsec and io.protocol.ipv6 seem to just work, > by virtue of Xen emulating ethernet instead of any particular > protocol - at least ipv6 works in bridging mode, I haven''t > tried routed mode yet, nor ipsecThey *should* all work ;-) Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, 17 Apr 2005, Mark Williamson wrote:> > core.dynamic.memory - I''m not sure if it is possible yet to > > boot a domain with less memory than its maximum, and grow > > the domain''s memory later through the balloon driver > > It used to work but right now it seems to be broken (at least in the > unstable tree).Hmmm, I''ll look into it once I have xen working again in rawhide - this is a part of the kernel I know well enough.> > we''re missing an io.device.virt.discovery - in order to > > be able to install into, and manage, a virtual machine, > > the OS needs the ability to discover what virtual devices > > are present - exporting through sysfs would work fine. > > Since this is a requirement for many system administration > > tools (eg. kudzu), this should probably be a Xen v3.0 target > > They do appear in sysfs, though, don''t they? I remember that kudzu, > anaconda, etc. didn''t recognise them but I never knew why...The thing is that a device only shows up in sysfs when a driver for it is already loaded. There is no "xen bus" that would allow kudzu to figure out which drivers to load... -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mike, The doc looks good and I think it will be useful to maintain such a document to track and prioritize development going forward. A couple of comments: 1) Since, we want all the I/O to be hosted in I/O domains (running some version of Linux or other OS hosting the drivers), you may want to cleanup chapter 4 - there is a lot of reference to Hypervisor supporting device I/O. 2) It may be useful to separately identify the management partition and list the set of requirements on the management partition. This could be both the Virtual machine management functionality that needs to be supported as well as the different access paradigms supported (for instance CIM based management). 3) core.virt_swap. Is this implying that we would support swapping/paging in the hypervisor? 4) We may want to have a separate section for real-time requirements. I have seen a fair amount of interest in using Xen for hosting real-time environments. The requirements go well beyond just the CPU scheduling support. K. Y>>> "Mike D. Day" <ncmike@us.ibm.com> 4/16/2005 2:21:15 PM >>>I''ve posted a version of our Xen requirements document at the following URL. http://www.ncultra.org/xen/xen_req.html I''m interested in comments from the community. We developed these requirements within IBM to guide our own prioritization, but have always intended to submit them to the community for review. If there is interest in maintaining a document like this in the community, I would be willing to continue working on it in conjunction with others. Mike -- Mike D. Day STSM and Architect, Open Virtualization IBM Linux Technology Center 3039 Cornwallis Road Research Triangle Park, NC 27709 Phone: (919) 543-4283 ncmike@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> core.dynamic.memory - I''m not sure if it is possible yet to > boot a domain with less memory than its maximum, and grow the > domain''s memory later through the balloon driverYep, if you set mem= on the kernel command line to more memory than the domain has at the time of creation, the mem_map is sized for the larger amount, and you can balloon more memory in.> we''re missing an io.device.virt.discovery - in order to be > able to install into, and manage, a virtual machine, the OS > needs the ability to discover what virtual devices are > present - exporting through sysfs would work fine. > Since this is a requirement for many system administration > tools (eg. kudzu), this should probably be a Xen v3.0 targetXenbus should handle this, and is a requirement for 3.0.> io.protocol.ipsec and io.protocol.ipv6 seem to just work, by > virtue of Xen emulating ethernet instead of any particular > protocol - at least ipv6 works in bridging mode, I haven''t > tried routed mode yet, nor ipsecThere''s no reason why ipv6 and ipsec shouldn''t just work. The only area that requires some thought is if the decryption routines decrypt-in-place in the skb data area then we should probably mark them to be scrubbed before recycling them as free buffers. Patch, anyone? Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel