5:35 p.m.
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.
9:36 a.m.
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 :|
5:18 a.m.
New subject: [libvirt-users] Re: libvirt and linux-vserver
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
8:39 a.m.
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 :|
9:40 a.m.
New subject: [libvirt-users] Re: libvirt and linux-vserver
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
4753
days inactive
4757
days old
4 comments
3 participants
participants (3)
-
Christian Parpart -
Daniel P. Berrange -
Nicolas Sebrecht