Answers in line. Thanks for asking the questions.

Mon, Aug 22, 2011 at 09:03:07PM -0500, Jim Perrin wrote:

On Mon, Aug 22, 2011 at 8:46 PM, Peter J. Pouliot <[1]peter@pouliot.net> wrote:

 I would like have the work we have done for building RHEL 6 rpms used to
 create offical "Centos" signed packages for the LIS included in the
 centos-plus perminately as well as have an offical
 "Centos" media or boot options on the current install media for
 installing as an enlighented guest on hyperv.

A few questions if you don't mind

Are these similar to the packages available here -> [2]http://download.opensuse.org/repositories/isv:/microsoft/

That's older packaging work we did for RHEL5. Newer packages are being tested for RHEL6. Currently there are MSFT contractors maintaining that specific channel in the SUSE OBS. The RHEL 6 Packages were built one of my other SUSE collegues and have not yet been integrated into that channel by the MSFT folks.

We can have additional discussion around LIS packaging as I am currently in process to bring control of this into the community instead, with an end goal of providing automated nightly builds/packaging for most distros.

Can these drivers be loaded (or be made to load) via the driver disk option to the installer? ([3]http://permalink.gmane.org/gmane.linux.kernel.dkms.devel/744) and if so is this an acceptable method to you for loading them?

This could be a viable option, however integration into install media which utilizes the plus repo might be cleaner user experience not requiring additional user interaction or install time parameters.

What license are these drivers covered under?

GPL v2.

The drivers are currently in staging on the mainline kernel. My goal, note I am not speaking for the company of I work for (SUSE), or the company who pays for the room I sit in (MSFT), is to help get the work our team has done for the last five years integrated into all linux distributions.

As you know politics can have a nasty way of working into everything. This is my attempt at approaching this without any of the corporate politics involved. I reach out as an individual looking to better the experience of linux on hyperv regardless of distro.

So here's what I have to offer to assist in the process. I run a complete datacenter (100+ servers, san, blades, etc), which I have FULL control of, outside of either corporate network. I am willing to both provide and host resources for the community to make this occur. In addition, we have recently built an openstack infrastructure upon hyperv which we are using as the basis for large scale testing of the LIS, I would like to include centos as part of this. Also, I would like to possibily tie into any of the community processes for testing/validation to provide coverage to enable centos to run as a viable guest on hyperv.

I know there has been heavy politics between MS and RH around this, and I know that politically RH is not likely to ever include the LIS. That's why I'm asking for addition to centos-plus and the install media.

I do not want to cause political unrest or for this to be taken out of context. Once again, my goal is to help provide a better experience for linux users running on HyperV regardless of distro. If I can reach out to the great opensource community and provide resources to assist in making this happen, hopefully we'll bypass any corporate political agenda, and end up with a win for linux users running on HyperV that was complete driven by the community and not by MSFT.

Thanks for the time.

p

 Also for the record, it is impossible to install an enlighened centos
 guest on HyperV using your method. Your method would require installing
 via emulated drivers on emulated devices then recreating the vm using
 the same disk image and all new synthetic (paravirt) devices rather than
 just installing on synthetic devices from the start to take advantage of
 the paravirt/enlightened I/O during install.

 Cheers,

 p
 On Mon, Aug 22, 2011 at 05:50:13PM -0700, James Peltier wrote:
 > If you have your own RPMS why not just create your own repo
 (createrepo) and include that repo as part of your kickstart?

-- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell

References

Visible links

1. mailto:peter@pouliot.net
2. http://download.opensuse.org/repositories/isv:/microsoft/
3. http://permalink.gmane.org/gmane.linux.kernel.dkms.devel/744

---

CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

On Tue, Aug 23, 2011 at 07:59:56AM -0500, Jim Perrin wrote:

On Mon, Aug 22, 2011 at 10:14 PM, Peter J. Pouliot <[1]peter@pouliot.net> wrote:

 That's older packaging work we did for RHEL5. �Newer packages are being
 tested for RHEL6. �Currently there are MSFT contractors maintaining that
 specific channel in the SUSE OBS.
 The RHEL 6 Packages were built one of my other SUSE collegues and have
 not yet been integrated into that channel by the MSFT folks.

Okay, so similar kit, just updated/newer versions. Fair enough.�

�

 We can have additional discussion around LIS packaging as I am currently
 in process to bring control of this into the community instead, with an
 end goal of providing automated nightly builds/packaging for most
 distros.

Automated/nightly build should in my opinion be a separate channel/repository all by itself. I would much prefer to see a 'stable known reliable' package set and a separate nightly build set.

Just to be clear, this is a high level of discussion. Your points are extremely valid, yet specific details, we can work out what should be offered as resources to enhance the development/adoption efforts.

�

 >
 > � �Can these drivers be loaded (or be made to load) via the driver
 disk
 > � �option to the installer?
 �

 This could be a viable option, however integration into install media
 which utilizes the plus repo might be cleaner user experience not
 requiring additional user interaction or install time parameters.

I understand this desire, but it runs somewhat counter to the mandate that CentOS strives to follow, of being 100% binary compatible with upstream. Basically anything that changes the installer away from a default should be done with extreme consideration, and while what you are pitching is good, I don't see/hear enough drive from the user community to warrant a change from the standard. The hyper-v usage (identified via googling hyper-v on [2]lists.centos.org) seems relatively low, so if I'm mistaken, please correct me.

�

Currently HyperV market share is on the rise, simple due to the fact that it is a cheaper alternative to VMware.

Currently it is estimated that it will reach 30% of overall hypervisor market by the end of the year.

One large segment of virtualization usage is currently rhel/epl on vmware. I specifically know of extremely large deployments (thousands of epl vms) currently evaluating HyperV and considering a hypervisor switch due to cost.

 >
 > � �What license are these drivers covered under?
 GPL v2.

 The drivers are currently in staging on the mainline kernel. � My goal,
 note I am not speaking for the company of I work for (SUSE), or the
 company who pays for the room I sit in (MSFT), is to help get the work
 our team has done for the last five years integrated into all linux
 distributions.

So long as they are GPLv2, and your company/code copyright holder is willing to provide something showing there's no danger of lawsuit/DMCA infringement for distribution I see no issues with providing them.

I'll look into this.

�

 As you know politics can have a nasty way of working into everything. �
 This is my attempt at approaching this without any of the corporate
 politics involved. �I reach out as an individual looking to better the
 experience of linux on hyperv regardless of distro.

Eh, my theory is that political arguing is for people who don't have work to do. I tend to lose interest during those sorts of discussions, because it's usually the end user who gets hurt.�

I agree.

�

 So here's what I have to offer to assist in the process. � I run a
 complete datacenter (100+ servers, san, blades, etc), which I have FULL
 control of, outside of either corporate network. �I am willing to both
 provide and host resources for the community to make this occur. �In
 addition, we have recently built an openstack infrastructure upon hyperv
 which we are using as the basis for large scale testing of the LIS, I
 would like to include centos as part of this. �Also, I would like to
 possibily tie into any of the community processes for testing/validation
 to provide coverage to enable centos to run as a viable guest on hyperv.

 I know there has been heavy politics between MS and RH around this, and
 I know that politically RH is not likely to ever include the LIS. �
 That's why I'm asking for addition to centos-plus and the install media.

� If it successfully goes into the mainline kernel, and there's a market for it I don't see why they wouldn't include it. The only reason I could think for them to deny it would be that it conflicts/competes with their own virtualization suite with KVM and RHEV.

I am not comfortable with the idea of adding it to the install media directly, but I'm not the one who produces that so I'll let others weigh in. I could see supplying it as a driver disk image, via the centosplus repo, or possibly a separate installer image similar to the server iso we used to ship. I'd like to hear some opinions from others on this.

I'm open to this idea as well. If it's a way for centos users to running on hyperv to install enlightened natively, i'm all for it.

�

 I do not want to cause political unrest or for this to be taken out of
 context. �Once again, my goal is to help provide a better experience for
 linux users running on HyperV regardless of distro. �If I can reach out
 to the great opensource community and provide resources to assist in
 making this happen, hopefully we'll bypass any corporate political
 agenda, and end up with a win for linux users running on HyperV that was
 complete driven by the community and not by MSFT.

So far I don't see any political unrest, and it's nice to see someone putting some effort into this. Interoperability works both ways in my mind, so thanks for the work you're doing� (now can we get some good GPL'd� MAPI libraries so I can talk to exchange easier? :-P)

hahaha, help me do this and that will be next on the list....

;)

�

 Thanks for the time.

Thanks for yours.

-- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell

References

Visible links

1. mailto:peter@pouliot.net
2. http://lists.centos.org/

---

CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

On Tue, Aug 23, 2011 at 09:43:06AM -0500, Les Mikesell wrote:

On 8/23/2011 9:02 AM, Peter J. Pouliot wrote:

...

...

I am not comfortable with the idea of adding it to the install media
directly, but I'm not the one who produces that so I'll let others weigh
in. I could see supplying it as a driver disk image, via the centosplus
repo, or possibly a separate installer image similar to the server iso we
used to ship. I'd like to hear some opinions from others on this.

I'm open to this idea as well. If it's a way for centos users to running on hyperv to install enlightened natively, i'm all for it.

Can hyperv provide a 2nd virtualized device (cd/floppy) pointed at a host/network file during the install for the drivers?

Well it would be unecessary to do this in at the hyperv layer since we can handle this in the installer.

However one could supply a file as a floppy/cd etc if they wanted.

p

-- Les Mikesell lesmikesell@gmail.com

---

CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

On 23/08/11 13:59, Jim Perrin wrote:

On Mon, Aug 22, 2011 at 10:14 PM, Peter J. Pouliotpeter@pouliot.netwrote:

...

...

What license are these drivers covered under?

GPL v2.

The drivers are currently in staging on the mainline kernel. My goal, note I am not speaking for the company of I work for (SUSE), or the company who pays for the room I sit in (MSFT), is to help get the work our team has done for the last five years integrated into all linux distributions.

So long as they are GPLv2, and your company/code copyright holder is willing to provide something showing there's no danger of lawsuit/DMCA infringement for distribution I see no issues with providing them.

The driver source is already included in the RHEL6 kernel, in drivers/staging/hv but because it's still in staging Red Hat chose not to enable it by default.

We built the drivers from the RHEL6 code but they seem badly broken:

http://elrepo.org/bugs/view.php?id=165

There were a large number of patches submitted for inclusion in kernel-3.0 (still in staging) but backporting this code to RHEL6 is not trivial.

As it's not enabled by default, I would guess the chances of Red Hat backporting fixes to RHEL6 are less than zero, regardless of the politics.

To start with I guess we would need working code that builds on RHEL6 :-)

On 23/08/11 20:25, Peter J. Pouliot wrote:

On Tue, Aug 23, 2011 at 08:03:26PM +0100, Ned Slider wrote:

...

On 23/08/11 13:59, Jim Perrin wrote:

...

On Mon, Aug 22, 2011 at 10:14 PM, Peter J. Pouliotpeter@pouliot.netwrote:

...

...

 What license are these drivers covered under?

GPL v2.

The drivers are currently in staging on the mainline kernel. My goal, note I am not speaking for the company of I work for (SUSE), or the company who pays for the room I sit in (MSFT), is to help get the work our team has done for the last five years integrated into all linux distributions.

So long as they are GPLv2, and your company/code copyright holder is willing to provide something showing there's no danger of lawsuit/DMCA infringement for distribution I see no issues with providing them.

The driver source is already included in the RHEL6 kernel, in drivers/staging/hv but because it's still in staging Red Hat chose not to enable it by default.

We built the drivers from the RHEL6 code but they seem badly broken:

http://elrepo.org/bugs/view.php?id=165

Unfortunately I know. I am still trying to organize the current process so that we can provide more community testing and hopefully provide coverage so that this doesn't happen.

...

There were a large number of patches submitted for inclusion in kernel-3.0 (still in staging) but backporting this code to RHEL6 is not trivial.

I know. We have individuals who have already done parts of the backporting that are currently going through testing.

...

As it's not enabled by default, I would guess the chances of Red Hat backporting fixes to RHEL6 are less than zero, regardless of the politics.

To start with I guess we would need working code that builds on RHEL6 :-)

I can definately provide this.

Great - do you have a git repo or such where we can pull the code from please?