- 1 Fedora Weekly News Issue 145
- 1.1 Marketing
- 1.2 Happy birthday Fedora!
- 1.3 Lessons learned from five years of Fedora
- 1.4 The sweet features of Fedora - Smolt
- 1.5 Plug and Run Fedora on a Toshiba A300D laptop, Part II
- 1.6 Developments
- 1.7 Documentation
- 1.8 Translation
- 1.9 Artwork
- 1.10 Security Advisories
- 1.11 Virtualization
- 1.11.1 Enterprise Management Tools List
- 1.11.2 Fedora Xen List
- 1.11.3 Libvirt List
- 1.11.4 oVirt Devel List
Fedora Weekly News Issue 145
Welcome to Fedora Weekly News Issue 145 for the week ending September 28, 2008.
This week's issue brings plenty of insights into the Fedora 10 theme decisions, as covered by longtime FWN writer, Nicu Buculei. Oisin Feeley updates us on Fedora development activity with deactivation of some dormant services and discussion of PackageKit. Jason Taylor highlights the many release notes completed for the upcoming Fedora 10 release. Dale Bewley brings us up to date on activity with four separate discussion lists in Fedora virtualization. Svetoslav Chukov, in the marketing beat, celebrates Fedora's fifth birthday with a wonderful, generous reflection of the project by OpenSUSE's community manager, Joe Brockmeier, and Runa Bhattacharjee covers the freeze activities surrounding translation and internationalization for Fedora 10.
If you are interested in contributing to Fedora Weekly News, please see our 'join' page.
In this section, we cover the Fedora Marketing Project.
Contributing Writer: Svetoslav Chukov
Happy birthday Fedora!
Five years ago this past week, the Fedora project became a reality, and it is amazing to see how far we have come. Happy birthday, Fedora!
Lessons learned from five years of Fedora
Rahul Sundaram highlighted  the OpenSUSE Community Manager, Joe Brockmeier, in his blog posting posting, "Lessons learned from five years of Fedora". Brockmeier reflects on building open source community projects, and the success Fedora has had in this regard. "The most valuable thing I’ve learned watching Fedora is this: Patience. It takes time and steady, incremental growth to build a solid community. If you’d asked me two years into Fedora’s development whether the project would succeed, I’d have been somewhat skeptical, but looking at the project five years down the road, I’m convinced."
The sweet features of Fedora - Smolt
The blog "Spread Fedora" offered a short story on Fedora's hardware profiler, Smolt. "It would be very beautiful and comfortable if there were some GNU/Linux distribution that keep track of used hardware of the users or just could provide information how the particular hardware would perform. I know such a distribution - Fedora. "
Plug and Run Fedora on a Toshiba A300D laptop, Part II
The blog "Spread Fedora" also offered part II of their experience installing and configuring Fedora on a Toshiba A300D laptop. Part I was highlighted in last week's FWN. In this week, configuring the USB to ethernet and sound card tweaking.
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
Default Deactivation of Services
Christoph Höger initiated this week's mammoth thread with a request to disable four services currently activated by default:
setroubleshootd. Christoph invited the list to "go on and punish me" after supplying some brief reasons for the deactivations.
Discussion mostly centered on the
sendmail problem with suggestions ranging from starting it asynchronously and late, as suggested by Alan Cox, to replacing it with one of the "send-only" MTAs such as
ssmtp. Part of the interest over this seemed to be stimulated by the information posted by Colin Walters that the "[...] desktop image no longer installs sendmail by default." This led to a need to distinguish between the desktop LiveCD and regular installs, as was done by Bill Nottingham. Some apparent legal threats posted by Matthew Woehlke led Seth Vidal to point him to the nearest convenient exit. Ralf Ertzinger noted the deeply entrenched nature of
sendmail: "Unfortunately, sendmail isn't just a program, it's an API. Calling /usr/lib/sendmail has been the way to get mail out (wherever out is) in UNIX for, well, as long as sendmail exists, which is quite some time."
The problem of lack of local delivery with the proposed replacements was brought up by Patrice Dumas. This was seen as a stumbling block because
cron needs it and led Jesse Keating to argue: "[W]e shouldn't be using local delivery for this stuff. Instead we should ask in firstboot where you'd want the mail delivered to." Matt Miller replied with a link to a bugzilla entry in which he had proposed just such a thing in 2004. Other aspects of the problem of disentangling potentially important log data from the mail delivery mechanism were touched upon in other parts of the thread. Deep in the thread Arjan van de Ven pointed to aliases generation as the reason for
sendmail being slow to start up.
The complaint about
setroubleshootd was addressed by Steve Grubb. He explained that he had intended it to be a plugin to
audispd it but had ended up being implemented as a standalone daemon by another author.
ip6tables was defended on two fronts. On the first Daniel P. Berrange explained how accessible IPv6 was and how likely it was that all machines on a network could automatically acquiring IPv6 addresses. Typical of the reaction on the other front Gregory Maxwell was startled at the idea of being exposed without firewalling upon plugging into an IPv6 enabled network. He added the statistic that "About 4% of the web browsers hitting English language Wikipedia are IPv6 enabled. IPv6 enabled web clients may even become more numerous than Linux desktops this year, almost certainly by next year, so be careful what you call rare. :)" Stephen John Smoogen also explained that if there were no IPv6 firewall a
ping6 -I eth0 ff02::1 would enable an attacker to "walk the hosts with no firewalls." He suggested that completely disabling IPv6 would be preferable but might affect
IPsec and related components.
No one seemed particularly concerned at the idea of disabling
isdn by default as it explicitly requires further configuration to be useful.
specspo and PackageKit
A quick query was posted by Richard Hughes asking whether
PackageKit should dump its dependency on
specspo. The advantage would be a savings of 27Mb installed size and 6.9Mb download size. Tim Lauridsen was against a hard dependency and argued that as
specspo was part of the @base group it would be installed by default on a normal desktop and could then be used, whereas on the LiveCD its absence was desired due to the space constraints.
 "specspo" is the rpm package which contains all the portable object catalogues which provide translations for Fedora packages.
An interesting discussion about alternate methods to provide translated package descriptions ensued when Seth Vidal suggested that instead of using
specspo "translating pkgs might best be served by translating the metadata in external files." In response to Bill Nottingham's skepticism that this was just moving bloat to a new location Seth explained that it would allow only the data specific to the requested language to be fetched. In a further explanation he provided an overview of the ideal mechanism which would allow translations only for the language in use to be installed. This involved
yum downloading translations from a language-segmented repodata and inserting those translations into the local
rpmdb. A further reason to find an alternative to
specspo was advanced by Stepan Kaspal when he drew attention to its lack of friendliness to third-party repositories: "the specspo solution is not extensible at all; if you add a third part repository, the messages just are not there. And the repository cannot install another catalogue, rpm uses just 'the catalogue'."
Bill Nottingham's objections seemed to involve both the resource intensiveness of doing this during the composition of the repodata and also that "[...] this is all stuff that exists."
Are Other Distros Controlling Fedora through PackageKit ?
A thread initiated by Thorsten Leemhuis explored some details on how information on packages is created and stored at the distribution level and the challenges this presents both to independent repositories and to tools which wish to use this data. One heated aspect of this discussion concerned the manner in which the
PackageKit application installer defines and presents groupings of packages.
PackageKit is designed to be a distribution-independent tool and it appeared to some in the discussion that its direction was inimical to the best release-engineering practices of the Fedora Project. The central issue appeared to be that
PackageKit developers were not spending time helping to refine the
comps.xml file which defines how packages are bundled during installation and is used by every other tool.
Thorsten asked a series of questions about the correct use of
comps.xml and how it interacted with
yum. Thorsten was concerned that there appeared to be 1711 packages missing from
comps.xml in order that "[...] people can find and select them right during install with anaconda. Do we care?"
After some investigation with the latest
PackageKit, which Rahul Sundaram pointed out uses
comps.xml, Thorsten deduced in discussion with Tim Lauridsen that "[...] adding packages to a group in comps.xml as '<packagereq type="optional">' is only worth the trouble if you want to make the package selectable in anaconda, as that information is not used by pk-application." Tim Lauridsen explained that
PackageKit used the comps.xml groups as "meta-packages" but James Antill disagreed that they were similar.
Alex Lancaster agreed with Thorsten's concern that many packagers were not using comps.xml and posted a link that showed that both he and Toshio Kuratomi had been thinking about using
PackageDB to generate
comps.xml for some time.
 See also http://fedoraproject.org/wiki/FWN/Issue136#Application.Installer..22Amber.22.Provides.Browser.Interface.to.Packages and http://fedoraproject.org/wiki/FWN/Issue82#Presto.Server.Back.Up...Interesting..25doc.Behaviour..Presto.Now.in.Extras.21
In sustained discussion with Kevin Kofler a defense of
PackageKit was mounted by Richard Hughes using the argument that it was intended to be a compliment to
yum rather than a replacement. Its intent is to occupy a very narrow niche for the specific type of user identified by "profiles" produced by the PackageKit developers.
James Antill had done some investigation of the difference between how PackageKit and
yum presented groups of packages and was not impressed: "In short it's arbitrarily different, hardcoded and just plain wrong. But hey, you've done "substantial user research" while we're just lowly developers, so feel free to keep ignoring us."
The evolution of
comps.xml to its current complexity was advanced by Nicolas Mailhot as the result of multiple constraints of engineering, maintenance and legality, he argued that "[i]t's always easy to present one-shot specialized solutions. The difficulty is scaling because separate maintenance of specialized overlapping package collections is not efficient). When you refuse to look at scaling problems you're missing the core of the problem."
When it seemed that
PackageKit was being designed to take the needs of other distributions into account and that this might have a negative effect on Fedora there was a great deal of disapprobation expressed by Jesse Keating: "If I'd known that upstream was actively looking to destroy our package classifications, rather than actually work with us to clean them up a bit maybe I would have joined the conversation. A heads up might have been in order. I fear that any conversation now will just be too little too late." Matthias Clasen characterized this as Jesse being more interested in confrontation than making things better but Nicolas Mailhot also saw the decisions being made about
PackageKit's design as "non-representative" of developers focused on Fedora. Interestingly he tied this in with an observation on "[...] desktop team mislike for the common distro communication channel [.]" A slight rapprochement seemed to be in effect towards the end of the thread as tempers cooled.
The issue of binary packages (several of which can be produced from any single source package) was attacked when Toshio Kuratomi listed
Fedora collection as all "[...] doing a subset of the work in this area." He asked for some clarity as to the storage, interface and presentation layers. Kevin Fenzi agreed but added
mash as another player and suggested that perhaps all the developers of the respective systems could meet to hash out some agreed plan. Jesse Keating confirmed Kevin's description and elaborated: "it's mash that pulls comps out of cvs and 'makes' it and uses it when generating repodata. Mash is used during rawhide production and during update repo generation. When we make releases, that uses pungi which consumes the comps data that mash generated and merges in data from any other repo pungi is configured to use. Then pungi calls repoview to create data based on that merged comps."
/sbin and /bin Linked to /usr/lib
Steve Grubb posted the output from a utility which he had authored to check whether applications in the
/sbin directories link against anything in the
/usr directory. In the ensuing discussion Bill Crawford suggested that one of the listed applications,
/bin/rpm was useful in its present location because of the "[...](admittedly quite odd situations) where you need to, say, reinstall grub or a kernel because you broke something[.]" He added that a "rescue"
initrd would help for machines without optical drives.
In this section, we cover the Fedora Documentation Project.
Contributing Writer: Jason Taylor
Release Notes Galore
With the approaching F10 release the Docs team spent time this week getting release note beats updated and organized. A lot of progress was made updating the beats to include pertinent package information as well as all the new features and it looks like there may be a new format for the release notes as well. There has also been a lot of work on getting the release-note structure to be compatible with publican. Once compatible with publican the release-notes will support additional formats (HTML, PDF, etc.).
Documentation Repository Changes
The Docs Project has been working to convert from CVS as the main repository for published documents to git. More progress on that front was made this week as the Install-Guide was moved over. The implementation of git and trac allows for better group communication and work flow management with contributors.
This section covers the news surrounding the Fedora Translation (L10n) Project.
Contributing Writer: Runa Bhattacharjee
String freeze breakage alarms
Noriko Mizumoto reported about suspected string freeze breakage for a few modules, during the week that modified the translation status figures. These modifications (except for one: comps) turned out to be the result of delayed creation of new template files which caused confusion about the string freeze. The template files are generally scheduled for creation by the respective package maintainers before the start of the string freeze period.
Fedora packages are currently string frozen for Fedora 10 i.e. no new translated messages can be added without the prior permission of the Fedora Localization Team as per the String Freeze Policy.
Fedora Docs moved to git repository
The Fedora documentation (including the Installation Guide, Release Notes etc.) were moved to the Fedora git repo. Translation submissions can be continued via the Transifex interface. However, Piotr Drag writes in that the statistics page will not be able to present the status for these documentation modules, as documents compiled with publican are not supported by Damned Lies yet. As per Dimitris Glezos, support for publican documents could be achieved if patches for this functionality can be developed by interested volunteers.
Translation schedule to be further discussed for clarity of tasks
John Poelstra and Dimitris Glezos are scheduled to meet on Monday 29th September 08, to discuss about the details of the Fedora 10 translation schedule to clearly define all the tasks and integrate them in the schedule. The meeting is open for others to join in.
In this section, we cover the Fedora Artwork Project.
Contributing Writer: Nicu Buculei
The desktop theme for Fedora 10 was chosen
Mairin Duffy announced the vote for the default theme in Fedora 10 on @fedora-art "Nigel Jones set up a vote for us to vote on round 3. You must be a member of the art group in the accounts system to be eligible to vote" and after the voting process ended, Michael Beckwith announced the winner, the Solar theme "We weren't feeling completely InvinXble. However, being the FOSS advocates we are, and with our support of Fedora, we were not afraid of of the unknown frontier. The Gears of time shown bright with a healthy Neon glow, but neither of these had very much effect on the course of destiny. Come join us as we sail into the Solar future for Fedora 10 later this year" and Max Spevack drew the conclusion: "They are all beautifully done pieces of artwork, and I really hope that everyone in the Art Team is proud of what the group has collectively achieved. I say 'congrats' to everyone on the Art Team."
The fight for the theme
As the vote for the Fedora 10 theme was closed to the members of the Art Team, a lot of people tried to vote even if they weren't members of the team, as Mairin Duffy noted: "Since i announced the F10 theme vote, we've received a deluge of art group membership requests, some clearly approveable but many not" and she reminded the requirements to become a member, which are listed on the project's page. David Nielsen tried an appeal on her blog "Maybe the solution is to open the vote, even if we are not inclined to contribute in your area of Fedora we might still have an opinion. Do you want other contributors to make decisions on the projects collective future without including you?" but Mairin remained firm "As an artist, I don't expect to have a vote on many technical decisions. I wonder how someone without both the experience and inclination to provide artwork for Fedora would have the expertise necessary to make an informed decision" and concluded "Everyone has an opinion. Not everyone is willing to put their money where their mouth is. It is a shame."
The theme soap opera
While the vote for the Fedora 10 theme was ongoing, Seth Kenlon reminded an old issue with one of the contenders and asked for an update "I am not clear, is this to be the final katana or is it still being swapped out with a newly photographed one? I recall there being an issue with licensing, and thought we would be seeing a different sword...but maybe I missed the thread in which all of this was solved" on which Nicu Buculei expressed his remaining doubts "Honestly, I have some doubts about that: sstorari *claimed* he remade the image using his own (Free) photo as a base and he posted the reference photo: http://www.flickr.com/photos/sstorari/2826852493/ While it looks pretty much like a katana (just like the photos used previously), the sword in the photo is not at the same angle as the sword in the wallpaper (so the hilt looks different), which make me have some doubts", which raised an angry answer from Samuele Storari, the theme author, who claimed innocence "If u take a look in the source before write something u can see that the problem was solved creatin' the blade from 0."
When the discuss started to look like a classic flamewar, Paul Frields dropped a bomb by showing a movie poster identical with the theme discussed "Samuele, I'm a big fan of Quentin Tarantino, and collected some desktop backgrounds when Kill Bill Vol. 1 was going to be released. One of the backgrounds features a katana sword which looks to me to be identical to the one in your source .XCF file" and outlined the importance of having all of the elements of a design Free in order to have the result Free "When we talk about having an entirely free desktop theme, it means that *all* the elements must be created from free sources."
As Samuele continued to deny any wrongdoing "the Blade wasn't the same cos the blade was totally recreated. Take a look to the source file and please post something similar", Nicu Buculei created and posted a short video revealing the similarities "What can I say? rotate the image 180 degrees and the resemblance is, uh..., uncanny"
During the heated debate, Martin Sourada expressed his doubts regarding the allegations against the two themes proposed by Samuele. "First, I have an impression that Mo and Nicu are somehow biased against Samuele's work. First, some weeks ago, Mo kept asking Samuele about Moon brushes in the Solar theme, when the Moons were already removed from the artwork, next there is the problem in katana. As nicu pointed out, the original design indeed resembles the Kill Bill poster, but even though I saw the .ogv file he provided, I am not 100% convinced Samuele used that katana" and "I believe both Mo and Nicu are just trying to prevent any legal issues that might arose in the future otherwise" but after seeing additional evidence provided by Mairin Duffy and Charlie Brej he changed his position "Mo and Nicu, I'd like to apologize for accusing you from being biased and pointing out outdated issues. It was me who was wrong and I should have checked the sources first. While part of the sword was replaced, the tilt was indeed from the same source image and I was wrong in arguing otherwise."
After the vote ended and after a long and heated debate, Samuele Storari apologised for his misunderstandings about licensing "First of all I want to apologize with all art-team and mailing list member for last two days mails. This is my first work in FOSS environment and I didn't understand all implication and I saw your continue checking on my work as a way to find something wrong" and started to work fixing his two themes proposals and remove a number of tainted graphic elements from them. At the moment of this report, Samuele is closely collaborating with other members of the team on this task and the Solar theme cleaned almost completely.
Lessons from the flamewar
In parallel with the debate surrounding the license of a couple of theme proposals for Fedora 10, Mairin Duffy opened a debate about the policy to apply when finding license infringements "Here are the options as I see them and/or as have been suggested to me: 1 - disqualify invinXble as a theme, even if invinXble wins, the 2nd-place winner will win 2 - if invinXble (or any theme that has photos we aren't able to source) wins, replace any sourced photographs in it with properly-licensed ones 3 - disqualify any themes that use images we cannot find properly-licensed photo source references for", she noted the pros and contras for each option and expressed her option for one of the first two. David Nielsen raised the case for a written policy "I would favor option 2 with the understanding that a proper policy be written and must be agreed upon when submitting artwork for Fedora in the future. This way we do not lose the two most developed themes this late in the game and we still get to correct the problem. This at least would be similar to what we have done in other parts of the distro when such unfortunate issues have arisen", a policy considered not needed by Nicu Buculei "Well, I propose a simple guideline: 'Don't like. When people ask about the source of your work, be honest and tell the truth.' That would have solved all of our problems *weeks* ago, but I think it is common-sense and we should not have to have this as a written guideline. "
As a lesson from the happening, Mairin Duffy asked on @fedora-art about unclarities some member of the team may have about licensing: "Did any of you joining the art team have doubts/questions/confusion over copyright law and licensing as it pertains to the usage of externally-sourced images used in artwork? Were you unsure of what licenses were acceptable to use in Fedora artwork? What kinds of questions / uncertainties did you have, if any?" and proposed a few measures, on which David Nielsen completed with a couple of simple guidelines "* Unsure about source licensing terms, don't use it. * Unable to document source licensing terms, don't use it."
Echo icon theme and Fedora 10
Bill Nottingham raised a cross-question to @fedora-art and @fedora-desktop about the status of the Echo icon theme "When we approved Echo as the default icon theme for F10, I was under the assumption that this was already more or less known as a feature to the Desktop group, and they were OK with the coverage provided and the experience given. Is that the case?" on which William Jon McCann expressed his opposition to the new theme "I strongly disagree with the decision to use the Echo icon theme. For one, there is simply not enough time before Fedora 10 to fix the problems that you point out. There is also the fact that the quality of the artwork is noticeably lower than the upstream GNOME and Tango icon themes" and preference for the Tango set "Encourage Fedora artists to become involved with the upstream GNOME and Tango artist communities" while Mairin Duffy pointed the inclusion of Echo as a default in Rawhide as a means to enable wider testing and accelerate development |I also was under the understanding that Echo was set as the default in rawhide to enable the folks working on it a chance to get fuller coverage, and that if it was deemed to not have appropriate coverage, it would be pulled."
Martin Sourada pointed that some of the concern raised in Bill's original questions are also valid for the current situation "With Mist, there are still new gnome styled icons, old gnome styled icons and bluecurve. In some places we reduced the old gnome and bluecurve to minimum, in others not yet. Check the System -> Administration menu as an example" and reminded there is still development time until the final decision about inclusion will be made "Our general idea is that some time around the final freeze it will be decided by art and desktop teams whether we are ready. If not, echo will be pulled back and submitted again for F11. I'd be for voting, enabled for art and desktop fas groups members regarding this issue" and Jaroslav Reznik showed the enthusiasm of the KDE SIG regarding the new set and his openness to work for getting it in a good shape "We (KDE SIG) are trying to use Echo theme as default for KDE but currently there are still some icons missing. We are preparing list of to-be-done icons. So can we fill it as ticket for echo-icon-theme and edit Todo on Wiki?"
In this section, we cover Security Advisories from fedora-package-announce.
Contributing Writer: David Nalley
Fedora 9 Security Advisories
- viewvc-1.0.6-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg01101.html
- initscripts-8.76.3-1 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg01135.html
- rkhunter-1.3.2-5.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg01204.html
- phpMyAdmin-184.108.40.206-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg01290.html
- phpMyAdmin-220.127.116.11-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg01228.html
Fedora 8 Security Advisories
- viewvc-1.0.6-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg01142.html
- phpMyAdmin-18.104.22.168-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg01137.html
- phpMyAdmin-22.214.171.124-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg01155.html
- rkhunter-1.3.2-5.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg01279.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
Maximum Number of Attached CDROMs in Xen
Alexander Todorov asked why only 3 CDROM devices could
be attached in
Cole Robinson replied "Xen uses a forked qemu for HVM device emulation" and the version on RHEL is limited to 4 IDE devices.
qemu found in Fedora 9 allow attaching SCSI disks and CDROMs, and thereby more devices. This ability already in
libvirt is not yet exposed in the
Parallel Port Support in virt-manager
VMWare VMX Output from virt-convert
Joey Boggs posted a patch which provides VMWare vmx output
virt-convert. "This will replace the virt-pack command and supplemental Unware.py file and integrate them into virt-convert directly as a module."
Disk Image Signature Verification
Joey Boggs posted patches for
virtinst and for
virt-convert that "will add in disk signature support for ISV's and others folks that wish to verify the disk has not been altered prior to running virt-image. Supports MD5 and SHA1 signatures."
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
Continued Trouble with 32bit Fedora 9 DomU on Fedora 8 Dom0
Fred Brier followed up on a thread from June 2008. It seems that on a 32bit system running Fedora 8 dom0, the shutdown or restart of a Fedora 9 domU results in that guest being inaccessible to libvirt tools until a dom0 reboot or xend restart. There are at least two similar bugs, filed for this issue.
This section contains the discussion happening on the libvir-list.
Libvirt 0.4.6 Released
Daniel Veillard announced the release of
libvirt 0.4.6. "There is no major change in this release, just the bug fixes a few
improvements and some cleanup".
- add storage disk volume delete (Cole Robinson)
- KVM dynamic max CPU detection (Guido Günther)
- spec file improvement for minimal builds (Ben Guthro)
- improved error message in XM configuration module (Richard Jones)
- network config in OpenVZ support (Evgeniy Sokolov)
- enable stopping a pool in logical storage backend and cleanup deletion of pool (Chris Lalancette)
Daniel Veillard responded it was unclear the release would fix anything for Xen users and "It was looking more risky than potentially useful to update there."
RFC: Events API
David Lively began a discusion on implementation of events in libvirtd.
Richard W.M. Jones pointed out that -- while not an official distribution -- binaries for
virsh.exe are available in the
oVirt Devel List
This section contains the discussion happening on the ovirt-devel list.
oVirt 0.93-1 Released
Perry N. Myers 
both the oVirt Node and oVirt Server Suite.
New features in this release include:
- Addition of 'Smart Pools' in the Web user interface for organizing pools on a per user basis.
- Additions to the Edit VM screen to allow re-provisioning of a guest as well editing other guest settings.
- oVirt Appliance manages VMs directly on the host it is running on. This eliminates the 'fake nodes' used in previous versions.
- oVirt API (Ruby Bindings)
- Support for configuring more than one NIC per Node. UI support for this will be integrated shortly.
- Support for bonding/failover of NICs. UI support for this will be integrated shortly.
- SELinux support on oVirt Node
- Rewrite of performance graphing visualization
Instructions for configuring yum to point to the ovirt.org repository: http://www.ovirt.org/download.html
Instructions for using the Appliance and Nodes: http://www.ovirt.org/install-instructions.html
Modeling LVM Storage
Chris Lalancette described the outcome of a IRC chat about carving up storage with LVM.
The existing StoragePool in the current model contains zero or more StorageVolumes. Chris described adding a StorageVolume of type LVM which contains one or more iSCSI StorageVolumes and presumably fiberchannel in the future.
After the model is modified and the backend "taskomatic" code is in place, then while provisioning a guest VM the user will either choose an entire LUN guest, choose an existing logical volume, or create a new volume.
Scott Seago clarified that "volumes must be of the same 'type' as the pool". An IscsiStoragePool contains IscsiStorageVolumes an LvmStoragePool contains LvmStorageVolumes. "In additon, for LvmStoragePools, we have a new association defined between it and StorageVolumes. an LvmStoragePool has 1 or more "source storage volumes""... "which for the moment must be IscsiStorageVolumes."
"When determining which storage volumes are available for guests, we'll have to filter out storage volumes which are connected to LvmStoragePools."
Steve Ofsthun asked how will oVirt distinguish between logical volumes created on a whole disk assigned to a guest versus volumes used by the host. Daniel P. Berrange suggested this could accomplished by creating a partition on the disk and assigning this to the guest, thereby making the guest LVM one step removed from the host.