[libvirt-users] libvirt and linux-vserver
Hi, I was just googling around for linux-vserver support in libvirt, however, only found sad ppl complaining about the fact, that there is still no linux-vserver support in libbirt. Despite the fact, that there was some kind of lag in review by more than one person, why isn't it still in? so... merely two years after? I think once the patched would have been applied, ppl would start using it, and then also report bugs in case there were some not yet found by the author nor the single reviewer :) Best regards, Christian Parpart.
On Sat, Nov 19, 2011 at 12:35:47AM +0100, Christian Parpart wrote:
Hi,
I was just googling around for linux-vserver support in libvirt, however, only found sad ppl complaining about the fact, that there is still no linux-vserver support in libbirt. Despite the fact, that there was some kind of lag in review by more than one person, why isn't it still in? so... merely two years after? I think once the patched would have been applied, ppl would start using it, and then also report bugs in case there were some not yet found by the author nor the single reviewer :)
We're always open to accepting new drivers - we have almost every major HV technology covered to some degreee now. There was a patch for vserver posted here: https://www.redhat.com/archives/libvir-list/2008-January/msg00097.html with some review of the code, but there were not any followup postings for it. So what's lacking is someone motivated todo the work to finish it off & update to latest libvirt coding standards for drivers. Volunteers are welcome to submit vserver support to libvir-list again.... Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
The 21/11/11, Daniel P. Berrange wrote:
We're always open to accepting new drivers - we have almost every major HV technology covered to some degreee now. There was a patch for vserver posted here:
https://www.redhat.com/archives/libvir-list/2008-January/msg00097.html
with some review of the code, but there were not any followup postings for it. So what's lacking is someone motivated todo the work to finish it off & update to latest libvirt coding standards for drivers. Volunteers are welcome to submit vserver support to libvir-list again....
I would have to second such a call until I realized the last Windows KVM virtio drivers are not freely available anymore (v1.2.0 & v1.3.3 of the drivers are distributed with a proprietary license instead of the GPLv2 for the previous versions). Looks like Redhat is going to close contributions in the virtualization world. -- Nicolas Sebrecht
On Tue, Nov 22, 2011 at 12:18:26PM +0100, Nicolas Sebrecht wrote:
The 21/11/11, Daniel P. Berrange wrote:
We're always open to accepting new drivers - we have almost every major HV technology covered to some degreee now. There was a patch for vserver posted here:
https://www.redhat.com/archives/libvir-list/2008-January/msg00097.html
with some review of the code, but there were not any followup postings for it. So what's lacking is someone motivated todo the work to finish it off & update to latest libvirt coding standards for drivers. Volunteers are welcome to submit vserver support to libvir-list again....
I would have to second such a call until I realized the last Windows KVM virtio drivers are not freely available anymore (v1.2.0 & v1.3.3 of the drivers are distributed with a proprietary license instead of the GPLv2 for the previous versions). Looks like Redhat is going to close contributions in the virtualization world.
There is in fact *not* an attempt by Red Hat to keep the Windows drivers closed-source, but there are a couple of factors which might have mistakenly given that impression. The KVM wiki link to the GIT repository was outdated. The master GIT repository now lives on GIT Hub: https://github.com/YanVugenfirer/kvm-guest-drivers-windows I have updated the wiki accordingly: http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers For reasons I don't understand, the binary releases published to Fedora download page are (unfortunately) using a different version numbering scheme to the RHEL binaries. So while Fedora shows release 1.1.16, RHEL will show 1.4. They both ultimately come from source in the same GIT repo I mention above. The Fedora link is on the download page above Finally, although the source code is GPL, the binary signed & WHQL'd drivers provided for RHEL are not under the GPL. This is due to license restrictions of the MicroSoft WHQL certification process :-( This is one of the reasons why we can't distribute the drivers in Fedora YUM repos directly. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
The 22/11/11, Daniel P. Berrange wrote:
On Tue, Nov 22, 2011 at 12:18:26PM +0100, Nicolas Sebrecht wrote:
There is in fact *not* an attempt by Red Hat to keep the Windows drivers closed-source, but there are a couple of factors which might have mistakenly given that impression.
The KVM wiki link to the GIT repository was outdated. The master GIT repository now lives on GIT Hub:
https://github.com/YanVugenfirer/kvm-guest-drivers-windows
I have updated the wiki accordingly:
http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers
For reasons I don't understand, the binary releases published to Fedora download page are (unfortunately) using a different version numbering scheme to the RHEL binaries. So while Fedora shows release 1.1.16, RHEL will show 1.4. They both ultimately come from source in the same GIT repo I mention above. The Fedora link is on the download page above
Finally, although the source code is GPL, the binary signed & WHQL'd drivers provided for RHEL are not under the GPL. This is due to license restrictions of the MicroSoft WHQL certification process :-( This is one of the reasons why we can't distribute the drivers in Fedora YUM repos directly.
Alright. I'm surprised you've found alone all of the factors that gave me this impression. Thank you for fixing and keeping the head up to this issue. -- Nicolas Sebrecht
participants (3)
-
Christian Parpart -
Daniel P. Berrange -
Nicolas Sebrecht