Fedora Weekly News Issue 144
Welcome to Fedora Weekly News Issue 144 for the week ending September 20, 2008.
In this action packed issue Announcements reminds you of important Fedora 10 freeze dates and the latest on the post security scare clean-up. PlanetFedora muses on some "Legal" issues. Our new Marketing beat-writer Svetoslav Chukov unveils the "Beauty found in Fedora". Developments reveals "Fedora not Free Enough for GNU". News of imminent deadlines in Translations is brought to you by another new writer Runa Bhattacharjee. Infrastructure alerts you to "More Puppet Training!". Artwork offers "Freedom for a Game" and SecurityAdvisories brings you the weeks latest in one handy spot. Virtualization shares information on "Migration Support in Virt-manager GUI".
If you are interested in contributing to Fedora Weekly News, please see our 'join' page.
In this section, we cover announcements from the Fedora Project.
Contributing Writer: Max Spevack
Fedora 10 feature owners--rescue your unfinished feature pages!
John Poelstra reminded everyone that the feature freeze for Fedora 10 is coming soon, and that feature owners need to get their pages updated to ensure that the features that belong in F10 get in, and that the features that need to be deferred to F11 are deferred. "Please complete this as soon as possible so that we can prepare an accurate beta release announcement. FESCo will also be reviewing the complete feature list at its next meeting on Wednesday, September 17, 2008, and determining which incomplete features should remain."
Updates to Fedora Packaging Guidelines
Tom Callaway announced the most recent set of revisions to the Packaging Guidelines, including including Haskell, Lisp, and several other areas. For the full announcement, read the link below.
Fedora 10 and translations: String freeze and repackaging
Dimitris Glezos reminded us "that shipped packages for which Fedora is upstream for are string frozen since the Beta freeze of September 11: no translatable strings can be added or modified for Fedora 10."
Fedora intrustion update
Paul Frields issued his latest updated regarding the Fedora security breach that has been news during the past few weeks. "Work on the Fedora infrastructure has returned to normal at this point. Updates are once again available for Fedora 8 and Fedora 9, our current releases, using the new package signing key we've implemented."
For the full announcement, follow the link.
In this section, we cover the highlights of Planet Fedora - an aggregation of blogs from Fedora contributors worldwide.
Contributing Writer: Max Spevack
Warren Togami announced the creation of a new list for NSPluginWrapper. "NSPluginwrapper Development discussion with the goal of isolating issues and collaboratively working on solutions should go on this list. There was some interest from other Linux distributions and even Adobe to cooperate on the future of nspluginwrapper development."
Jesus Rodriguez announced the release of Spacewalk 0.2, the open-source upstream for Red Hat Satellite. There is a list of features, enhancements, bug fixes, and credits on Jesus' blog.
Greg DeKoenigsberg helped the OLPC folks recruit volunteers to be part of their growing infrastructure team. "OLPC builds a lot of packages. They are looking to set up and maintain an infrastructure that will allow them to meet their own unique packaging needs. They need a volunteer with a strong understanding of the Fedora packaging process -- one who either understands koji now, or can learn to understand it in fairly short order."
My favorite Planet post this week came from Fedora Board member Matt Domsch, and it is worth people's time to read the entire post, to gain a lot of insight into how Fedora's mass rebuilds work, and what triggers them.
"One challenge to self-hosting a project the size of Fedora (now with about 6200 source packages) is dealing with the interdependencies between packages. When a major component, such as the compiler or an often-used library, upgrades to a new version, you should rebuild all packages that depend upon that major component, to ensure they continue to work. Often, simply re-compiling or re-linking each package using the updated compiler or library is all that is needed. In some cases though, applications which once built, no longer do - bitrot has set in."
Tom Callaway wrote a lengthy post about the Mozilla EULA controversy, which reared its head again this week in the context of Ubuntu and Mozilla. However, Fedora dealt with this problem several months ago, at the end of the Fedora 9 release cycle.
Spot's entire post is worth reading, as is the commentary that follows it. Here is one excerpt:
"[The] goal was always to ensure that we could walk away with license terms from Mozilla that:
1. Permitted Fedora to continue using the Firefox trademarks 2. Clearly upheld the MPL as the valid software license terms for the Firefox binaries and source (not just for Fedora, but for everyone) 3. Meet the criteria for Free Software 4. Are presented to the user in a non-obtrusive, non-clickthrough agreement way"
Anthony Green wrote a post that referenced SGI's alteration of its Free B license, which has long been a thorn in the side of various distros.
Events & Ambassadors
The North American Fedora Ambassador Day is coming up at Ohio Linux Fest in October, and there were a few posts about it on Planet this week. Brian Powell gave an update on the organization, saying:
"There have been quite a few discussions and meetings recently in regards to FAD planning. There has been a lot of good progress and great ideas coming out of these. With time getting close, we are looking at finalizing the Agenda and Schedule for FADNA shortly.
If you are a North American Ambassador I would ask that you take a moment to look at what we have come up with so far and a 'tentative' schedule of events located at the FADNA2008 wiki page. If you have anything to add feel free to do so."
Additionally, Karsten Wade wrote a post about strategies for handling remote meetings, and making a physical gathering of a small number of people into a larger meeting that remotees can attend and still get value out of, whether that attendance is via IRC, telephone, or something collaborative like gobby.
"Think about your sessions and how it can help to interact with the rest of us. I recommend a minimum of: live video feed, live audio feed, and IRC, Gobby, and wiki editing projected on the wall. We can also keep a VoIP conference room open, but my instinct is to limit the flow on the incoming voices by subject matter. Beyond that recommendation, a live IRC and wiki-based abd/or Gobby note taking with many laptops in the in-person session is the bare bones, with regular usage of talk.fedoraproject.org."
David Nalley wrote up a trip report for Linux Demo Day in Charleston, SC. "About 60 people showed up. Charleston’s LUG is relatively new, and this was their first event. They seemed very pleased. I handed about 30 LiveCDs out and talked with a number of Fedora. In addition I spoke to 2-3 people who were intrigued with contributing to Fedora in one way or another. I’ll be following up with these individuals." This is a great example of an event -- low cost, but high touch!
In this section, we cover the Fedora Marketing Project.
Contributing Writer: Svetoslav Chukov
Video History of Fedora
The history of Fedora as recounted by GregDeKonigsberg is now available in video format
FUDCon Brno 2008
Max Spevack reported the result of FUDCon Brno 2008.
The Beauty Found in Fedora.
A very interesting point of view of a Fedora user.
Plug and Run Fedora on a TOSHIBA A300D laptop
This post recounted some adventures with Fedora and a very tricky laptop. It is always good to know about such success stories. Some laptops do not even start GNU/Linux at all! But this one seemed to work pretty well with Fedora.
First look at Fedora
The video article "First look at Fedora" showed what one can see for first time use. Very useful for novice users.
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
Removal of non-X Consoles (continued)
The furore over the future removal of text-mode consoles (see FWN#144 "Non-X System Consoles to be Removed") continued throughout the week. The original thread saw some support for the idea expressed by Nicolas Mailhot on the basis that "[...] non-X-console input is a mess [...] font support has fossilized, and support for modern high resolution screens is severely lacking [...]" Nicholas was especially concerned with the maintenance burden imposed by the text-mode console "[...] as someone who is an upstream maintainer for my language of some of the bits the console use[s]."
Upon being pressed by Dominik Mierzejewski for evidence of a lack of proper maintenance Nicolas listed a series of problems including the stagnation of the console layout database and the console font set. Dmitry Butskoy begged to separate the concepts of "console" and "serial tty" and also for the retention of the text-mode console. Dominik promised to try to find a colleague to shoulder the maintenance burden but Nicolas had already given up in disgust. In response elsewhere to Seth Vidal's argument that the text console did no harm and should be left alone Nicholas expanded on the maintenance costs of "all sorts of packaging rules designed to avoid hitting console limitations and problems" and bugs filed because of the confusion caused by two text stacks.
Les Mikesell got to the heart of the problem when he asked "I think I'm confused by the term 'non X consoles'. Is that something different than the native text mode you see before X starts?" He also recommended using FreeNX/NX instead of using the console. Nicolas responded that there were "[...]two different things. A VT to which you can attach an X session, a serial port, a remote SSH, mingetty... and the software stack used to display locally the VT text and collect user input." Nicolas saw the "low-level VT bit" as fundamentally sound but the "current console software stack" as "rotten." Les sought further clarification of this distinction between "[...] the low level part that works in character mode and expects some hardware to supply and render the fonts [...]" and "[...] software other than X that renders custom fonts[.]"
Denis Leroy wondered if there was "[...] an X-based mingetty replacement actually exists ? Something that's proven to be sufficiently fail-safe (will work even with half-broken X configurations and such?)" and although Nicolas did not know of one he speculated "[...] as soon as much of the hardware pocking is moved from xorg to the kernel and X can be run as a normal user "X-based mingetty replacement" will be just running a x term fullscreen in an autoconfigured X instance. Of course one could theoretically write a much lighter solution using only freetype (cairo, pango?) and an xkb-config parser." Denis's concern seemed to be that often a Ctrl+Alt+F1 to mingetty was the only way to kill hanging desktop applications. Colin Walters suggested making "[...] Ctrl-Alt-Backspace just break server grabs instead of killing the server (and of course fix the bugs in the apps that hang while holding a server grab)."
There were multiple expressions of disapprobation often coupled with use cases. Some of these led Chris Snook to exclaim "Unless I've missed something huge, virtual terminals aren't going away. What may or may not be going away is the x86 video BIOS text mode, to be replaced with a kernel framebuffer, which precludes the use of console fonts, which very few people ever mess with. The console itself will remain. Someone please correct me if I'm wrong." [[DaveAirlie|Dave Airlie] confirmed this understanding and added "[...] vga text mode will not be enabled by default, you will need to pass nomodeset if you want to use vga text mode. Welcome to the 1990s." Alan Cox made the correction that framebuffer console support fonts but that framebuffers did not work on all machines, screen reader technology and remote management cards.
OpenVPN and resolv.conf
Ahmed Kamal asked for help in scratching an itch and started a concise, meaty thread. His particular problem was that he wanted to overwrite /etc/resolv.conf with new DNS servers obtained over a vpn tunnel, this is apparently done automatically in "Windows".
The suggestion to use NetworkManager was made by Paul Wouters and Dan Williams agreed and added the explanation that it "[...] mediate[d] between services [including PPP, PPtP, DHCP, openvpn, and vpnc] that need to update your DNS information." The alternative is that each service needs to handle
The idea of a default caching daemon was floated by Simo Sorce. As he envisioned it, the services/tools, such as OpenVPN, would "[...] tell the caching daemon which IP ranges and which domains their provided forwarders should be consulted for. All dynamic so that as soon as one daemon goes away, the caching DNS will notice and revert queries to the default DNS.} Nils Philippsen agreed heartily and added that "[i]deally, it should be something which isn't restricted to class A/B/C like reverse DNS (seems to be), but which would route DNS requests based on arbitrary domain name or IP-range criteria to the desired name servers" and Paul Howarth provided the further reason that changes to /etc/resolv.conf are often not picked up by processes. This latter point spawned a discussion on the demerits of the glibc stub resolver (which is too simplistic) and the consequent use of the deprecated
gethostbyname in individual applications. Dan Williams recommended using
lwresd (a stripped-down, caching-only nameserver available to clients which use the BIND 9 lightweight resolver library) or for more complex setups a local caching nameserver. Although Simo Sorce disagreed with Dan that many applications were simply using
gethostbyname he agreed that "[a] caching nameserver that can be instructed what to do when conditions change is what we really need."
Ahmed asked whether
dnsmasq or other daemons were able to "[direct] name resolution to specific servers according to IP ranges and/or domain names, with the option of adding/removing servers on the fly?" and Richard W.M. Jones confirmed that this was indeed possible. Adam Tkac suggested that this could be done with
view statements in
BIND and the gauntlet of how to do this for CIDR and domain names was thrown down by Nils. A detailed sub-thread followed which indicated what while possible it was not pretty.
Adam Tkac shared the information that his TODO list includes the addition of
NetworkManager support to
BIND and Simo Sorce explained  that
nscd was not a solution for a local caching nameserver "[...] as not all type of queries can be fulfilled by the glibc interface. For example SRV/TXT records ... Also nscd is not smart enough to understand network condition and adapt it's behavior." Simo agreed that it would be nice if "[...] bind could consult different DNSs based 1) on the DNS name to be queried, and B) the reverse IP to be queried" so that on slow links only the necessary queries would be directed through the VPN.
Fedora 10 Feature Owner Request
John Poelstra requested all those owning a Feature to take some actions on their feature page so that the beta release notes and announcements are accurate. He provided a list of twenty one feature pages which "have not been updated since the Feature Freeze on 2008-09-11 and/or are not 100% complete."
Kevin Kofler was among those who had been watching the progress of OpenChange (see FWN#133 "Help Wanted: Samba4, Heimdahl, OpenChange") and noted that due to the decision of Andrew Bartlett to orphan the feature it needed a new owner if Fedora 11 was to offer OpenChange.
Another of the listed pages was that for the Echo icon theme and Luya Tshimbalanga asked if he should add a release note to the effect that
echo was now the default. Rahul Sundaram confirmed that this would be helpful.
The Eclipse-3.4 (Ganymede) page was updated by [JeffJohnston|Jeff Johnston]].
system-autodeath Becomes Reality
Seth Vidal announced that he had implemented his previously discussed (FWN#140 "System Autodeath") idea to automatically remove networking capabilities from machines which lacked system updates. The intent is to prevent non-maintained machines from being exploited.
Seth implemented the concept as a daily cronjob which tests a configured "death date" against the current time. For the week leading up to the "death date" log messages warn that on the specific date the default route will be deleted. He requested feedback and improvements.
Matt Miller was content but suggested beefing up the manpage with details of the consequences of removing the default route. Seth noted that he was happy to accept patches.
A fraught note was introduced when Stephen Warren declared that if this were a default then, in combination with the proposed textconsole removal (see this FWN#144 "Removal of non-X Consoles (continued)") and the modesetting changes, he was thinking about switching distros. Rahul Sundaram responded that modesetting was going to be a feature of all distros soon and the conversation veered into explaining that the replacement for
RHGB, named "Plymouth" had a sane text-mode fallback for unsupported chipsets. As much of Stephen's angst was due to a perceived abandonment of those using non-Free drivers Rahul pointed out that the
nouveau drivers might work. Richard Hughes listed 2-D and
xrandr as supported with kernel modesetting coming soon due to Maarten Maathuis's work. He warned: "Don't even try 3D yet. It does work, but only if the moon is waxing, and your pet cat is called Oliver."
Back on the main topic of the thread Seth stated that
system-autodeath was not intended to be part of the default install: "This is just a nicety for sysadmins or local-respin maintainers who would like to put a dropdead date on their releases." In response to Stephen's recollection Seth also stated this point clearly. A general disagreement with the idea of exposing such a feature was expressed by James Hubbard on the basis that the user should be forced to change a config file to prevent against accidental installation errors.
Fedora Not "Free" Enough for GNU?
A long-running thread which was started on 07-09-2008 by Michel Salim continues to attracted some heated discussion over the fact that Fedora is not recognized as a 100% Free software distribution by GNU although a derivative named "BLAG" (see also FWN#139) is recognized as FLOSS.
The central stumbling block seemed to be best stated by Gregory Maxwell as "[...] Fedora doesn't yet strip the binary firmware provided by the Linux kernel (and still provides some re-distributable binary firmware in other packages, the microcode package and alsa-firmware I think)." Gregory described the situation as unfortunate due to both the lack "[...] of acknowledgement it deserves, and the FSF is indirectly promoting Ubuntu, a distribution which is, as far as I can tell, a primary driving factor in new users using and depending on proprietary software." This latter being a reference to the recognition of gNewSense as FLOSS.
There had been previous very heated threads on this subject (during one of FWN's holidays) centered around the efforts of Alexandre Oliva to produce a "kernel-libre" and the interaction of this project with other efforts and approaches within the kernel community. David Woodhouse added the excellent news that "We are almost at the point where we can do a spin which remedies [the difficulties of stripping out the non-Free firmware]." He explained that soon a completely separate package instead of a sub-package of the normal kernel build will allow others to produce alternative packages of firmwares for which source code is available. Tom Callaway was worried that there was still firmware entangled in the kernel source code and noted the need for an audit. Rahul Sundaram supplied a link to a Debian inventory of firmwares.
Other interesting points in the discussion touched on the rationales which have been often advanced for refusing to supply source to firmwares. These involve regulatory compliance (often for radio devices). Alan Cox was suspicious of such arguments based on the history of examples such as ISDN code which "[...] was approved. You could change it but then it became unapproved and not permitted in some countries." He described this as a racket run by the phone companies which imploded once the need to ensure robustness became important (due to terrorist threats.) Ignacio Vazquez-Abrams listed some of the other rationales.
This section covers the news surrounding the Fedora Translation (L10n) Project.
Contributing Writer: Runa Bhattacharjee
2008-10-14 Declared Fedora 10 Package Translation Deadline
The last date for submission of translations for Fedora 10 packages was announced as 2008-10-14 (Tuesday). This announcement was made after an unanimous decision by the Fedora L10n Steering Committee (FLSCo) members. The last date for the translation of Documents remains as 2008-10-21 (Tuesday).
A request for rebuilding of packages post the translation freeze date, was also made to the @fedora-devel-announcement list.
"Maintainers of the above packages need to put a reminder to issue a new build *later* than this date and before the Development Freeze of 21/10. The closer to the development freeze the rebuild takes place, the better for our translators. If you have not received any translations since the last build, a rebuild is not necessary."
Renewed Call for Volunteers for the L10n Infrastructure
Another call was made at the FLSCo meeting held[ on 16th September 2008 seeking volunteers for the Fedora L10n infrastructure. The earlier call was made in April 2008.
Meanwhile, Asgeir Frimannsson announced a proposed plan for a new L10n infrastructure which is currently being discussed in various relevant mailing lists.
This section contains the discussion happening on the fedora-infrastructure-list
Contributing Writer: HuzaifaSidhpurwala
Planning a future L10N infrastructure (including Fedora)
Asgeir Frimannsson wrote on the @fedora-infrastructure-list  about his views on the current localisation infrastructure. He summarises the current infrastructure which is used by the localisation team, which includes the version control system and other online tools. He also discusses transifex. He also discusses the requirements for a system where the translation lifecycle would be managed within 'Translation Repositories'
Mike McGrath wrote on the @fedora-infrastructure-list  that he is going to hold a puppet training next wednesday. He also posted an ogg and the slide deck  to which his live training will be identical.
Fedora 10 Beta Release Planning Meeting
John Poelstra wrote on the @fedora-infrastructure-list  about the Fedora 10 Beta Release Planning Meeting. He has also posted the list of participants and the meeting logs.
Infrastructure update notice
Paul W. Frields wrote on the @fedora-infrastructure-list  about the announcement which went out on the fedora-announce-list . Paul confirmed that all of our services were back online now.
app2 disk space
Mike McGrath wrote on the @fedora-infrastructure-list about the recent disk alerts on app2. It seems that the host was not built with enough disk space similar to app1. It does raise a point about storage for transifex though. Basically each host running transifex or damned lies, keeps a local copy of every scm as part of its usage. For performance reasons that should not change but its something we'll want to figure out long term. So after the freeze the host is going to be rebuilt.
In this section, we cover the Fedora Artwork Project.
Contributing Writer: Nicu Buculei
Near to the Echo
Pursuing the declared goal of having the new Echo icon theme ready to be used as a default in Fedora 10, Martin Sourada and Luya Tshimbalanga continued the development and posted updates, while gathering feed-back and improvement proposals on @fedora-art. Martin even created an animated demo "also prepared animated gif (slideshow) so you can see all the icons in one batch" and blogged about it.
Freedom for a Game
Nicu Buculei relayed to @fedora-art a request from the Hans deGoede, of Games SIG fame: the
Project: Starfighter game, which used to be included in Fedora, was discovered to have some non-free graphic files and needed free replacements for them. Erick Henrique offered his help "I go to unpack the archive starfighter.pak and to study a form of I redesign everything in a new style" and Hans promised to code a needed utility "About recreating the .pak file I need to write a little utility for that, hopefully I'll have time for that this weekend."
Infrastructure Change for Fedora Art
After an IRC consultation with Mairin Duffy, Martin Sourada proposed using fedorahosted.org services for the Art team "it might be worth setting up a fedorahosted.org instance for the Fedora Art Team. Primary purpose would be to host our release graphics, but it could serve other purposes as well (e.g. using ticket system for design service come to my mind)[.]" This initiative was received with open arms by Luya Tshimbalanga and with some skepticism by Ian Weller "I'm personally all for the idea, but I knew there were some caveats that we should definitely look into before we even think about proceeding. I'd also like to see Mo's input, of course." and Nicu Buculei stated "I am strongly against something which would raise the barrier to entry, so a NO-NO would be to require git to upload sketches (proposals) for the upcoming release."
In this section, we cover Security Advisories from fedora-package-announce.
Contributing Writer: David Nalley
Fedora 9 Security Advisories
- tomcat5-5.5.27-0jpp.2.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00859.html
- fedora-package-config-smart-9-13.0.2.transitional - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00800.html
- fedora-package-config-apt-9-3.transitional - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00799.html
- ssmtp-2.61-11.6.fc9.1 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00768.html
Fedora 8 Security Advisories
- ssmtp-2.61-11.6.fc8.1 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00757.html
- fedora-package-config-apt-8-2.transitional - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00844.html
- fedora-package-config-smart-8-12.0.2.transitional - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00846.html
- tomcat5-5.5.27-0jpp.2.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00889.html
In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies.
Contributing Writer: Dale Bewley
Enterprise Management Tools List
This section contains the discussion happening on the et-mgmt-tools list
Virt-manager and Virtinst Closely Related
virt-manager to 0.6.0, Maikel Dollé received the error ImportError: cannot import name Storage. Cole Robinson explained
virt-manager is tied closely with
virtinst and installing
virtinst 0.400.0 would likely fix the problem.
Migration Support in Virt-manager GUI
Shigeki Sakamoto followed up on a previous request for comments on a patch, submitted by same, which works to allow the migration of domains from within the
virt-manager GUI. Daniel P. Berrange suggested using a submenu rather than a pop-up window, and commented on the sanity checks in libvirt.
Live Migration Sanity Checks were recently discussed on
list (see FWN #141 Live Migration Sanity Checks).
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
DomU Network Interface Problem Leads to Discussion of HVM Requirements
Guillaume asked about a paravirtualized domU which did not show any network interfaces. There was a suggestion made that this could be due to a lack of HVM support in the host hardware, which isn't the case. Paul Wouters cleared up such confusion by describing the main virtualization techniques used in Fedora. Quoting:
- Xen hypervisor for para_virt guests does not need HVM.
- Problem here is that Fedora 8 is the last release to support this setup on x86_64, though work is in progress to add this support to Fedora 9/10. Para_virt guests are booted via kernel= and rootfs images, or via pygrub, which is just a wrapper for grabbing kernel from bootable disk images.
- Qemu is a software emulator for various architectures including PC hardware.
- It requires no HVM instructions, but it can use them if they exist via the kernel "kvm" code. This is how Fedora9 does its VM's via the libvirt and virt-install. This does NOT [sic] use or require a xen hypervisor.
- Xenner is a software emulation for the Xen hypervisor.
- It requires HVM because it uses the kernel "kvm" code. The idea behind Xenner is that you can run VM's based on kernel-xen kernels (eg migration from Fedora8)
Paul went on to mention other virtualization technologies such as VirtualBox/Vmx, lguest, uml, virtuoso, and openvz.
In another post Paul suggested that Guillaume's domU may have an initrd which lacks
xennet, and pointed to a debate in the FC6 era concerning the
xenblk kernel module.
This section contains the discussion happening on the libvir-list.
Minimal Client-only Libvirt Build
Ben Guthro patched the
libvirt spec file to
allow for a minimal client-only build.
Access to CPU Flags
Ben Guthro needed to access CPU flags to determine if VMX
features were available, and suggested
src/nodeinfo.c would be
the place to parse this. This however raised a concern that adding to the nodeinfo struct breaks the API. Additionally, since this is an x86 specific change, Ben wondered if it would be acceptable.
Daniel P. Berrange stated "any struct or API in
include/libvirt/libvirt.h is immutable to preserve ABI",
and the API shouldn't be specifically x86. Daniel did offer that
the most likely place for exposing CPU flags would be in the
capabilities XML format. Where PAE, VMX, and SVM flags are already exposed.
Ben noted that Xen will report those flags, but oVirt running KVM does not,
and said "It seems to me that it might be useful for some sort of "node" info driver, where we might be able to share code for hypervisor independent info about the physical machine it is running on." Daniel pointed to
src/nodeinfo.c as "a place for this useful reusable node info code".
Anton Protopopov pointed to a previous thread on xml format for OpenVZ driver, and asked if libvirt supported the xml format for OpenVZ driver.
Evgeniy Sokolov replied that OpenVZ uses the XML format common for all libvirt drivers.
oVirt Devel List
This section contains the discussion happening on the ovirt-devel list.
Check back next week.