Change is inevitable – except from a vending machine
It is with great reluctance that I announce my departure from Xen.org as your community manager. Working with the many community members from around the world over the past three years has been a highlight in my career and I have learned so much from you that I can’t possibly thank you enough. Xen.org has an amazing group of dedicated developers, testers, administrators, champions, and technologists that together have created one of the great open source solutions available currently being leveraged by hundreds of millions of people. Having the opportunity to contribute my small part toward this great community was a privilege for me.
My last day as your community manager is September 10th at which time I will send my final blog posting. Although I am leaving Xen.org, I still expect to stay in close contact with the community in my new position. I look forward to watching Xen.org continue to grow and revolutionize the virtualization industry although I will be on the outside looking in.
Once again, thank you for your great support and commitment to Xen.org.
Xen Directions South America in Sao Paulo is underway with plenty of great speakers from Cloud Providers, Google, Citrix, and Ian Pratt giving his standard opening thoughts on the future of Xen.org and associated technologies. Many people are taking pictures so I will be sure to post links to these once I get the information from the Xen.org members taking pictures. In the meantime, here are two shots I took with my not very good iPhone:
The second shot is myself with some Xen.org leaders in South America. Prize to the first person who can name everyone in the picture in the comment!
Welcome to the Xen.org weekly newsletter with a variety of information to keep you updated on all things Xen. Please feel free to contact me with suggestions for the newsletter.
Xen Members in Action
- Xen.org Mailing Lists SuperStars – Fajar Nugraha, David Scott, Kouya Shimura
- Welcome to some new members to mailing lists – Daniel Matthew, Ilya Kozlov, Jonathan Taylor
Xen Weekly Stats
- Mailing Lists Stats: Xen-Devel (78 Patches, 33 Questions, 256 Responses) ; Xen-Users (56 Questions, 121 Responses); Xen-api (29 Patches)
- Project Golden Ratio Data for August released late next week
The complete newsletter with all data including the summary of all xen-users/xen-devel/xen-api mailing lists can be found at http://wiki.xen.org/xenwiki/XenUpdate20100827
From Andre Przywara:
while experimenting with guest NUMA configurations I realized that Xen injects the host’s core number into each guest.
I believe this behavior is wrong, the number of cores should somehow be dependent from the number of VCPUs.
Currently a CPUID decoding tool of mine gives me the following output for a 4 VCPU guest:
HTT: 1, CmpLegacy: 1, LogicalProcessorCount: 24 AMD decoding:
NC: 23, ApicIdCoreIdSize: 16
24 cores (legacy method)
24/16 cores (extended method)
(This is on a 12-core host CPU).
Applying my previous patch reduces the 24 to 12, but that still does not match the 4 VCPUs seen.
For proper NUMA functionality we need more sane values here, it seems that at least Linux does not care about the strange numbers as long as NUMA is not used. When a SRAT table is found, the guest kernel panics in the scheduler’s rebalancer with those bogus numbers.
How shall we solve this issue? I see several ways:
1. Always inject one core per processor. SMP guests are then n-way, the CPUID setup is trivial and works well. But we may run into licensing issues, as some software (MS Windows comes to mind) is limited by the number of processors, but not by the number of cores.
2. Inject exactly the same number of cores as there are VCPUs. This could lead to potentially strange core numbers, but software should cope with this (as there are 3-core, 6-core and 12-cores processors).
This would lead to problems with a NUMA setup, though.
3. Let the user specify the number of cores in the config file. Needs user interaction and can lead to problems if it somehow conflicts the number of VCPUs. But would be nice to have as an additional tuning parameter. I could implement this.
4. Implement solution 2), but tune the behavior if guest NUMA is enabled. We could make sure that the number of cores is not bigger than the number of VCPUs on one NUMA node.
What approach shall I use? Are there other concerns regarding the CPUID’s readout of the nubmer of cores?
RELEASE-4.0.1 has been tagged in http://xenbits.xen.org/xen-4.0-testing.hg
Browsing the above URL will show the mercurial changelog contains many many bug fixes since 4.0.0. We recommend all users to upgrade.
A source tarball will soon be available from http://www.xen.org/products/xen_source.html