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.

\

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!

Xen News

• Xen User Group LA Video – http://blog.xen.org/index.php/2010/08/26/xen-user-group-la-event-video/
• Xen Summit Asia – Call for Speakers – http://blog.xen.org/index.php/2010/08/24/xen-summit-asia-call-for-speakers/
• Project ThreeEyes Proposal for Review – http://blog.xen.org/index.php/2010/08/24/project-threeeyes-proposal-received/
• Why Xen? Brochure Available – http://blog.xen.org/index.php/2010/08/23/why-xen-brochure-available/
• Oracle Underground VM Manual – http://blog.xen.org/index.php/2010/08/23/the-underground-oracle-vm-manual/

Xen Events

• Poslovna Linux Konferenca – Sept 27-28, 2010 in Portoroz, Slovenia : George Dunlap, “Xen: Open Source and the Virtualization Revolution”
• Xen Directions South America – August 31 – September 1st in Sao Paulo, Brazil – http://blog.xen.org/index.php/2010/05/20/xen-directions-south-america/
• Xen Summit Asia – Nov 2 – 3, 2010
• Bring Xen.org to an event near year – Do you know of an event near you that would be served by having a Xen.org booth? If so, I have a proposal for working together to support that event; http://blog.xen.org/index.php/2010/01/28/bring-xen-org-to-your-local-event/

Xen Products

• Xen Developer Email Discussion – http://blog.xen.org/index.php/2010/08/13/xen-developer-email-discussion-6/
• Xen Hypervisor
  • Xen 4.01 Released – http://blog.xen.org/index.php/2010/08/25/xen-4-0-1-released/
  • Re-License Some Source Code – http://blog.xen.org/index.php/2010/08/23/re-license-libxc-under-lgpl/
  • Request for Comment – http://blog.xen.org/index.php/2010/08/25/rfc-handling-of-number-of-cores-the-guest-sees/

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

The Inaugural Xen User Group Los Angeles from The Bitsource on Vimeo.

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?

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

***********

We firmly believe it’s time for Xen.org to upgrade. We hereby propose a new system wherein Xen.org is reshaped as the centralized portal for the various scattered resources by incorporating the following:

1) LAMP stacks installed on top of the very latest Xen software running on a server supplied by Citrix.

2) Drupal as core CMS and feed aggregator. Drupal will channel all Xen-related info through Xen.org rather than forcing the user to look all over for it.

3) phpBB forum for community support. The mailing list will remain available for traditionalists, but forums are more effective in a larger community because everyone doesn’t get everyone else’s mail. Ideally, the forum is integrated with the mailing list.

4) OpenGrok to publish cross-referenced source code at Xen.org at frequent, regular intervals.

5) All content routed through Xen.org and globally searchable using Google Custom Search. The Google search engine will be kept apprised of content changes through automated sitemap generation.

6) Existing developer resources (source control, Bugzilla, LXR, mailing lists) remain as-is so the core development team can continue without interruption.

We recommend these strategies and technologies because of their open-source nature, best-in-class quality, robust support communities and suitability to the needs of the Xen site.

***********

If you are interested in seeing the complete proposal then email me for a copy. I also plan to begin discussing this project on the xen-community mailing list to allow for community input. I look forward to having a great new Xen.org site with community buy-in and support in creating the final deliverable.

• White Paper -  http://www.xen.org/files/Marketing/WhyXen.pdf
• Slides – http://www.slideshare.net/xen_com_mgr/why-xen-slides

As is standard, if you have any feedback or changes please let me know. I am also looking to get translated copies of these documents to reach a wider audience.

As previously discussed we would like to relicense libxc under the LGPL.

http://blog.xen.org/index.php/2010/07/26/xen-org-source-code-license-change-request/
http://lists.xensource.com/archives/html/xen-devel/2010-07/msg01378.html

We have now managed to track down all but one of the necessary contributors in order to make this change and all have given their OK to the change.

Due to the missing contributor (who we do not expect we will be able to find) we have taken the decision to remove the xc_ptrace functionality. It is currently unused, the last remaining user having been replaced by gdbsx. Should this code be required in the future it can be recovered from mercurial history and reinstated as a separate library.

There are two patches currently in review on xen-devel for this final change.