Re: Debian and Hyper-V VM drivers revisited
On Mon, 2012-08-27 at 17:47 +, Tom Hanrahan wrote: Ben, I know you worked with Mike Sterling earlier to integrate the Hyper-V device drivers into the Debian Wheezy release. We really appreciate the effort you took to do the work. Now that some customers (one in particular, Vyatta) are starting to pick them up we're finding that they (the users) are getting out-of-date bits. How can we best work with you to make sure we stay at pace with changes in the drivers further upstream in the kernel tree? Whenever there are bug fixes or new features that you think need to be backported, you should open a bug in the Debian BTS (http://bugs.debian.org) against package 'src:linux' and the version you know is missing them. Following the feature freeze of 'wheezy', the general policy is that only important bug fixes and new hardware support can be applied. So new paravirtualisation features probably won't be acceptable, but if the kernel version currently in testing is horribly broken on Hyper-V (including terrible performance) then that can be fixed. (Note also that we are very reluctant to apply changes that have not yet been accepted by the relevant subsystem maintainer, or backports of same.) The most helpful thing you could do would be to provide already-tested patch sets against our source packages. This would allow me (or other developers) to apply your changes with a minimum of delay. The Debian kernel handbook explains how to modify and build the kernel packages http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official and the installer internals manual http://d-i.alioth.debian.org/doc/internals/ch04.html explains how to build an installer with the new kernel. By the way, Mike has taken a new position within Microsoft. Abhishek Gupta is now the Program Manager for our Linux device driver project. He and I are looking forward to working with you. Bear in mind that I'm just one member of the Debian kernel team, and other developers may work on this as well. So in general you should send mail to the debian-kernel list (cc'd). All bug reports also automatically go to that list. So far I have had no access to Hyper-V and therefore no ability to test my work. I don't know if it's even possible to install under Hyper-V at present (considering commit cd006086fa5d91414d8ff9ff2b78fbb593878e3c 'ata_piix: defer disks to the Hyper-V drivers by default'). Is that something can that be tested in Azure (user providing installation images)? Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
RE: Debian and Hyper-V VM drivers
-Original Message- From: Ben Hutchings [mailto:b...@decadent.org.uk] Sent: Monday, June 25, 2012 9:10 PM To: KY Srinivasan Cc: Mike Sterling; Andy Whitcroft; debian-kernel@lists.debian.org; Ubuntu kernel team; Tom Hanrahan Subject: Re: Debian and Hyper-V VM drivers On Mon, 2012-06-25 at 15:32 +, KY Srinivasan wrote: Ben, Sorry to be top posting; since I got into this thread late and I was only commenting on one item, I felt top posting was appropriate. Thanks for the patches and the analysis. With regards to question 4, why do you say the protocol is not stable. The protocol is stable and is backward compatible. However, our implementation on the guest side has been incremental and with incomplete knowledge of the protocol. I mean the kernel-to-daemon connector protocol, not the host-to-guest protocol. Do you expect to change the connector protocol in future, and if so would the new daemon then be incompatible with old kernel versions? If so, then the daemon needs to be packaged in such a way that there can be multiple versions installed and we automatically start whichever matches the current kernel version. But if it will remain backward-compatible then we don't need to bother with that. Recently I sent out patches for IP injection based on our current code base. The patches are still in Greg's queue. Once Greg deals with these patches, we can work on getting your changes in. In the meantime, we can test your patches. Thanks. Ben. Ben, As I told you I am currently implementing IP injection via KVP. Is there standard for how the IP configuration will be persistently stored and flushed. As I look at current distros each of them have different files for saving this information. Regards, K. Y
Re: Debian and Hyper-V VM drivers
On Tue, 2012-06-26 at 22:31 +, KY Srinivasan wrote: [...] As I told you I am currently implementing IP injection via KVP. Is there standard for how the IP configuration will be persistently stored and flushed. As I look at current distros each of them have different files for saving this information. I'm afraid so. You could probably cover a lot of distributions by working with NetworkManager via D-Bus http://projects.gnome.org/NetworkManager/developers/. However, most Debian (and Ubuntu?) servers still rely on ifupdown, configured through /etc/network/interfaces. Older Red Hat and SUSE releases will also need different treatment. Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
RE: Debian and Hyper-V VM drivers
-Original Message- From: Ben Hutchings [mailto:b...@decadent.org.uk] Sent: Tuesday, June 26, 2012 7:28 PM To: KY Srinivasan Cc: Mike Sterling; Andy Whitcroft; debian-kernel@lists.debian.org; Ubuntu kernel team; Tom Hanrahan Subject: Re: Debian and Hyper-V VM drivers On Tue, 2012-06-26 at 22:31 +, KY Srinivasan wrote: [...] As I told you I am currently implementing IP injection via KVP. Is there standard for how the IP configuration will be persistently stored and flushed. As I look at current distros each of them have different files for saving this information. I'm afraid so. You could probably cover a lot of distributions by working with NetworkManager via D-Bus http://projects.gnome.org/NetworkManager/developers/. However, most Debian (and Ubuntu?) servers still rely on ifupdown, configured through /etc/network/interfaces. Older Red Hat and SUSE releases will also need different treatment. Thanks Ben. I am mostly interested in setting static IP addresses as part of this VM replication feature. I was under the impression that NetworkManager did not deal with static IP addresses. Is that not the case. Regards, K. Y
Re: Debian and Hyper-V VM drivers
On Wed, 2012-06-27 at 00:37 +, KY Srinivasan wrote: -Original Message- From: Ben Hutchings [mailto:b...@decadent.org.uk] Sent: Tuesday, June 26, 2012 7:28 PM To: KY Srinivasan Cc: Mike Sterling; Andy Whitcroft; debian-kernel@lists.debian.org; Ubuntu kernel team; Tom Hanrahan Subject: Re: Debian and Hyper-V VM drivers On Tue, 2012-06-26 at 22:31 +, KY Srinivasan wrote: [...] As I told you I am currently implementing IP injection via KVP. Is there standard for how the IP configuration will be persistently stored and flushed. As I look at current distros each of them have different files for saving this information. I'm afraid so. You could probably cover a lot of distributions by working with NetworkManager via D-Bus http://projects.gnome.org/NetworkManager/developers/. However, most Debian (and Ubuntu?) servers still rely on ifupdown, configured through /etc/network/interfaces. Older Red Hat and SUSE releases will also need different treatment. Thanks Ben. I am mostly interested in setting static IP addresses as part of this VM replication feature. I was under the impression that NetworkManager did not deal with static IP addresses. Is that not the case. Read the docs; I think it can. Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
RE: Debian and Hyper-V VM drivers
-Original Message- From: Ben Hutchings [mailto:b...@decadent.org.uk] Sent: Tuesday, June 26, 2012 8:54 PM To: KY Srinivasan Cc: Mike Sterling; Andy Whitcroft; debian-kernel@lists.debian.org; Ubuntu kernel team; Tom Hanrahan Subject: Re: Debian and Hyper-V VM drivers On Wed, 2012-06-27 at 00:37 +, KY Srinivasan wrote: -Original Message- From: Ben Hutchings [mailto:b...@decadent.org.uk] Sent: Tuesday, June 26, 2012 7:28 PM To: KY Srinivasan Cc: Mike Sterling; Andy Whitcroft; debian-kernel@lists.debian.org; Ubuntu kernel team; Tom Hanrahan Subject: Re: Debian and Hyper-V VM drivers On Tue, 2012-06-26 at 22:31 +, KY Srinivasan wrote: [...] As I told you I am currently implementing IP injection via KVP. Is there standard for how the IP configuration will be persistently stored and flushed. As I look at current distros each of them have different files for saving this information. I'm afraid so. You could probably cover a lot of distributions by working with NetworkManager via D-Bus http://projects.gnome.org/NetworkManager/developers/. However, most Debian (and Ubuntu?) servers still rely on ifupdown, configured through /etc/network/interfaces. Older Red Hat and SUSE releases will also need different treatment. Thanks Ben. I am mostly interested in setting static IP addresses as part of this VM replication feature. I was under the impression that NetworkManager did not deal with static IP addresses. Is that not the case. Read the docs; I think it can. Thanks; will do. K. Y Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway.
RE: Debian and Hyper-V VM drivers
Ben, Sorry to be top posting; since I got into this thread late and I was only commenting on one item, I felt top posting was appropriate. Thanks for the patches and the analysis. With regards to question 4, why do you say the protocol is not stable. The protocol is stable and is backward compatible. However, our implementation on the guest side has been incremental and with incomplete knowledge of the protocol. Recently I sent out patches for IP injection based on our current code base. The patches are still in Greg's queue. Once Greg deals with these patches, we can work on getting your changes in. In the meantime, we can test your patches. Regards, K. Y -Original Message- From: Mike Sterling Sent: Monday, June 25, 2012 12:08 AM To: Ben Hutchings Cc: Andy Whitcroft; debian-kernel@lists.debian.org; Ubuntu kernel team; KY Srinivasan; Tom Hanrahan Subject: RE: Debian and Hyper-V VM drivers (actually adding KY and Tom this time) -Original Message- From: Mike Sterling Sent: Sunday, June 24, 2012 9:07 PM To: 'Ben Hutchings' Cc: Andy Whitcroft; debian-kernel@lists.debian.org; Ubuntu kernel team Subject: RE: Debian and Hyper-V VM drivers On Saturday, June 23, 2012 9:37 PM, Ben Hutchings [mailto:b...@decadent.org.uk] wrote: On Sun, 2012-06-10 at 16:18 +0100, Ben Hutchings wrote: [...] The problems I've found so far (by inspection): 1. The daemon leaks a file handle on every configuration update. Fixed by the attached 'tools-hv-fix-file-handle-leak.patch' 2. It doesn't check for write failures, and it doesn't check correctly for read failures. Fixed by the attached 'tools-hv-check-for-read-write-errors.patch'. 3. It stores state in /var/opt/hyperv, which is only appropriate for programs installed in /opt. This should be configurable at build time. Changed by the attached 'tools-hv-fix-var-subdirectory.patch', but not made configurable (because I don't see the need). 4. The protocol between driver and daemon does not appear to be stable. Do they need to be upgraded in lockstep, or will either be backward- compatible with older versions of the other? Please answer this. 5. The daemon uses incorrect types for strings, resulting in a large number of compiler warnings when building with 'gcc -Wall' (which is generally good practice). Fixed by the attached 'tools-hv-fix-string-types.patch'. 6. When and how should the daemon be started? There is no init script (or upstart job) provided, either in the linux source or the Ubuntu packaging. I downloaded the Linux Integration Services from https://www.microsoft.com/en-us/download/details.aspx?id=28188 and found an init script in that. I also found https://launchpad.net/ubuntu/+source/hv-kvp-daemon-init, but this is not useful for Debian (we don't use upstart by default). [Less important:] 7. There is no Makefile, and the one added by Ubuntu is incorrect (make install doesn't respect $(DESTDIR)). Still TBD. 8. The daemon doesn't detect or parse the OS release correctly (even, so far as I can see, on the distributions which it has explicit support for). Fixed by the attached 'tools-hv-parse-etc-os-release.patch'. 9. Permissions of S_IRUSR | S_IWUSR | S_IROTH (octal 604) make no sense. Fixed by the attached 'tools-hv-fix-permissions.patch'. According to the manual page, 'This pairing allows the Hyper-V host to pass configuration information (such as IP addresses) to the guest...' but I don't see any sign that the daemon actually applies any configuration. Is this intended to be done by some other 'guest tool' distributed by Microsoft? Is that the reason for (3) and/or (6)? I'm assuming this is not the case, since the package I downloaded from MS did not contain any extra tools. So the manual page should probably be fixed too. I have *not* tested these changes beyond actually compiling, as I don't have a Hyper-V installation on which to test. Would you be able to test a binary package, or provide remote access to a suitable VM? It is still important that I get an answer to question 4. Hi Ben, Thanks for following up. I'm on holiday this week, and then I'll be starting in a new role. I'm adding two of my colleagues in the Open Source Group, KY Srinivasan (developer) and Tom Hanrahan (program manager) who will own this moving forward. KY will be best to answer #4, and we should be able to test a binary package or provide SSH access to a VM. However, without access to the host, there's not a lot of value in just having access to the VM.
Re: Debian and Hyper-V VM drivers
On Mon, 2012-06-25 at 15:32 +, KY Srinivasan wrote: Ben, Sorry to be top posting; since I got into this thread late and I was only commenting on one item, I felt top posting was appropriate. Thanks for the patches and the analysis. With regards to question 4, why do you say the protocol is not stable. The protocol is stable and is backward compatible. However, our implementation on the guest side has been incremental and with incomplete knowledge of the protocol. I mean the kernel-to-daemon connector protocol, not the host-to-guest protocol. Do you expect to change the connector protocol in future, and if so would the new daemon then be incompatible with old kernel versions? If so, then the daemon needs to be packaged in such a way that there can be multiple versions installed and we automatically start whichever matches the current kernel version. But if it will remain backward-compatible then we don't need to bother with that. Recently I sent out patches for IP injection based on our current code base. The patches are still in Greg's queue. Once Greg deals with these patches, we can work on getting your changes in. In the meantime, we can test your patches. Thanks. Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
RE: Debian and Hyper-V VM drivers
-Original Message- From: Ben Hutchings [mailto:b...@decadent.org.uk] Sent: Monday, June 25, 2012 9:10 PM To: KY Srinivasan Cc: Mike Sterling; Andy Whitcroft; debian-kernel@lists.debian.org; Ubuntu kernel team; Tom Hanrahan Subject: Re: Debian and Hyper-V VM drivers On Mon, 2012-06-25 at 15:32 +, KY Srinivasan wrote: Ben, Sorry to be top posting; since I got into this thread late and I was only commenting on one item, I felt top posting was appropriate. Thanks for the patches and the analysis. With regards to question 4, why do you say the protocol is not stable. The protocol is stable and is backward compatible. However, our implementation on the guest side has been incremental and with incomplete knowledge of the protocol. I mean the kernel-to-daemon connector protocol, not the host-to-guest protocol. Ok; this protocol has also suffered from our incomplete understanding of the host/guest protocol. I think this last round of cleanup that I have done should hopefully not need any further tweaking here. IP injection required that I generalize the kernel-to daemon protocol. Moving forward, I think it will make sense to evolve the protocol in a compatible fashion. Do you expect to change the connector protocol in future, and if so would the new daemon then be incompatible with old kernel versions? If so, then the daemon needs to be packaged in such a way that there can be multiple versions installed and we automatically start whichever matches the current kernel version. But if it will remain backward-compatible then we don't need to bother with that. Backward compatibility is my goal (once the IP injection patches go in). Regards, K. Y
Re: Debian and Hyper-V VM drivers
On Sun, 2012-06-10 at 16:18 +0100, Ben Hutchings wrote: [...] The problems I've found so far (by inspection): 1. The daemon leaks a file handle on every configuration update. Fixed by the attached 'tools-hv-fix-file-handle-leak.patch' 2. It doesn't check for write failures, and it doesn't check correctly for read failures. Fixed by the attached 'tools-hv-check-for-read-write-errors.patch'. 3. It stores state in /var/opt/hyperv, which is only appropriate for programs installed in /opt. This should be configurable at build time. Changed by the attached 'tools-hv-fix-var-subdirectory.patch', but not made configurable (because I don't see the need). 4. The protocol between driver and daemon does not appear to be stable. Do they need to be upgraded in lockstep, or will either be backward- compatible with older versions of the other? Please answer this. 5. The daemon uses incorrect types for strings, resulting in a large number of compiler warnings when building with 'gcc -Wall' (which is generally good practice). Fixed by the attached 'tools-hv-fix-string-types.patch'. 6. When and how should the daemon be started? There is no init script (or upstart job) provided, either in the linux source or the Ubuntu packaging. I downloaded the Linux Integration Services from https://www.microsoft.com/en-us/download/details.aspx?id=28188 and found an init script in that. I also found https://launchpad.net/ubuntu/+source/hv-kvp-daemon-init, but this is not useful for Debian (we don't use upstart by default). [Less important:] 7. There is no Makefile, and the one added by Ubuntu is incorrect (make install doesn't respect $(DESTDIR)). Still TBD. 8. The daemon doesn't detect or parse the OS release correctly (even, so far as I can see, on the distributions which it has explicit support for). Fixed by the attached 'tools-hv-parse-etc-os-release.patch'. 9. Permissions of S_IRUSR | S_IWUSR | S_IROTH (octal 604) make no sense. Fixed by the attached 'tools-hv-fix-permissions.patch'. According to the manual page, 'This pairing allows the Hyper-V host to pass configuration information (such as IP addresses) to the guest...' but I don't see any sign that the daemon actually applies any configuration. Is this intended to be done by some other 'guest tool' distributed by Microsoft? Is that the reason for (3) and/or (6)? I'm assuming this is not the case, since the package I downloaded from MS did not contain any extra tools. So the manual page should probably be fixed too. I have *not* tested these changes beyond actually compiling, as I don't have a Hyper-V installation on which to test. Would you be able to test a binary package, or provide remote access to a suitable VM? It is still important that I get an answer to question 4. Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. tools-hv-patches.tar.gz Description: application/compressed-tar signature.asc Description: This is a digitally signed message part
Re: Debian and Hyper-V VM drivers
On Mon, 2012-05-14 at 23:21 +0100, Ben Hutchings wrote: On Mon, May 14, 2012 at 08:33:23PM +, Mike Sterling wrote: [...] We've done a lot of work with Andy Whitcroft at Canonical to get the drivers integrated into Ubuntu 12.04 and higher. What we'd like to discuss is doing the same thing for Debian. What would be the best way to start or discuss this effort? The drivers were already updated (in 3.2.15-1). I have a to-do item to look at tools/hv and build those tools from the linux-tools source package, but it wouldn't hurt for you to open a bug report requesting it. If you can provide a patch then that would make it a lot easier to fix. Currently the linux-tools source package in Debian builds binary packages that are specific to upstream kernel versions (linux-kbuild-3.2, linux-tools-3.2), I assume tools/hv is not version-specific and therefore it would belong in a new package, say, 'linux-tools-common' (*not* 'linux-tools', which somewhat confusingly is a meta-package). So I've had a proper look at tools/hv now, and I'm not very impressed. The problems I've found so far (by inspection): 1. The daemon leaks a file handle on every configuration update. 2. It doesn't check for write failures, and it doesn't check correctly for read failures. 3. It stores state in /var/opt/hyperv, which is only appropriate for programs installed in /opt. This should be configurable at build time. 4. The protocol between driver and daemon does not appear to be stable. Do they need to be upgraded in lockstep, or will either be backward- compatible with older versions of the other? 5. The daemon uses incorrect types for strings, resulting in a large number of compiler warnings when building with 'gcc -Wall' (which is generally good practice). 6. When and how should the daemon be started? There is no init script (or upstart job) provided, either in the linux source or the Ubuntu packaging. [Less important:] 7. There is no Makefile, and the one added by Ubuntu is incorrect (make install doesn't respect $(DESTDIR)). 8. The daemon doesn't detect or parse the OS release correctly (even, so far as I can see, on the distributions which it has explicit support for). 9. Permissions of S_IRUSR | S_IWUSR | S_IROTH (octal 604) make no sense. According to the manual page, 'This pairing allows the Hyper-V host to pass configuration information (such as IP addresses) to the guest...' but I don't see any sign that the daemon actually applies any configuration. Is this intended to be done by some other 'guest tool' distributed by Microsoft? Is that the reason for (3) and/or (6)? Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
RE: Debian and Hyper-V VM drivers
On Wed, 2012-05-16 at 15:11 +, Mike Sterling wrote: On Tuesday, May 15, 2012 6:52 PM, Ben Hutchings [mailto:b...@decadent.org.uk] wrote: On Wed, 2012-05-16 at 01:37 +, Mike Sterling wrote: Great, thanks. We've done some investigation into the current status of Wheezy on Hyper-V, and as of 3.2.0-2, there's about a five patch differential between linux-next and the 3.2.0-2 kernel. How can I update to the 3.2.15-1 kernel? I installed Wheezy using the latest testing ISO, but apt-get doesn't want to show a new kernel. [...] In wheezy the current version is 3.2.16-1. The kernel version string doesn't match this because it's used as an ABI version and we try to avoid frequent ABI changes. [...] Thanks for the clarification. There have been a couple of patches that have gone in upstream that we'd like to make sure get applied to the Wheezy kernel. Is there a date or upstream commit ID that you're using to generate the kernel sources that we can use as a base to automatically generate all the accepted upstream patches? You can get our current source from git://anonscm.debian.org/kernel/linux-2.6.git, wheezy branch (note, this branch is subject to rebasing). Each backported commit has an upstream commit reference. Essentially we have everything up to v3.4-rc1. Ben. -- Ben Hutchings All extremists should be taken out and shot. signature.asc Description: This is a digitally signed message part
RE: Debian and Hyper-V VM drivers
On Tuesday, May 15, 2012 6:52 PM, Ben Hutchings [mailto:b...@decadent.org.uk] wrote: On Wed, 2012-05-16 at 01:37 +, Mike Sterling wrote: Great, thanks. We've done some investigation into the current status of Wheezy on Hyper-V, and as of 3.2.0-2, there's about a five patch differential between linux-next and the 3.2.0-2 kernel. How can I update to the 3.2.15-1 kernel? I installed Wheezy using the latest testing ISO, but apt-get doesn't want to show a new kernel. [...] In wheezy the current version is 3.2.16-1. The kernel version string doesn't match this because it's used as an ABI version and we try to avoid frequent ABI changes. [...] Thanks for the clarification. There have been a couple of patches that have gone in upstream that we'd like to make sure get applied to the Wheezy kernel. Is there a date or upstream commit ID that you're using to generate the kernel sources that we can use as a base to automatically generate all the accepted upstream patches? Thanks, -M
RE: Debian and Hyper-V VM drivers
On Wed, 2012-05-16 at 01:37 +, Mike Sterling wrote: On Monday, May 14, 2012 3:22 PM, Ben Hutchings [mailto:b...@decadent.org.uk] wrote: Let me introduce myself - my team is part of the Open Source Technology Center at Microsoft, and we're responsible for a set of drivers in the Linux kernel to provide an optimized experience for running paravirtualized Linux on top of Microsoft's hypervisor, Hyper-V. The drivers have exited the kernel as of 3.4 and now exist in the following locations: /drivers/hv (core Hyper-V bus driver, provides communication between Dom0 and DomU, as well as the hv_utils driver, which provides time synchronization, heartbeat, and integrated shutdown) /drivers/scsi/storvsc_drv.c (storage driver) /drivers/net/hyperv (network driver) /tools/hv (KVP - key value pair exchange, a way to pass messages and datagrams between virtual machines and the root) We've done a lot of work with Andy Whitcroft at Canonical to get the drivers integrated into Ubuntu 12.04 and higher. What we'd like to discuss is doing the same thing for Debian. What would be the best way to start or discuss this effort? The drivers were already updated (in 3.2.15-1). Great, thanks. We've done some investigation into the current status of Wheezy on Hyper-V, and as of 3.2.0-2, there's about a five patch differential between linux-next and the 3.2.0-2 kernel. How can I update to the 3.2.15-1 kernel? I installed Wheezy using the latest testing ISO, but apt-get doesn't want to show a new kernel. [...] In wheezy the current version is 3.2.16-1. The kernel version string doesn't match this because it's used as an ABI version and we try to avoid frequent ABI changes. This is explained in: http://kernel-handbook.alioth.debian.org/ch-versions.html#s-version-types Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
RE: Debian and Hyper-V VM drivers
On Monday, May 14, 2012 3:22 PM, Ben Hutchings [mailto:b...@decadent.org.uk] wrote: Let me introduce myself - my team is part of the Open Source Technology Center at Microsoft, and we're responsible for a set of drivers in the Linux kernel to provide an optimized experience for running paravirtualized Linux on top of Microsoft's hypervisor, Hyper-V. The drivers have exited the kernel as of 3.4 and now exist in the following locations: /drivers/hv (core Hyper-V bus driver, provides communication between Dom0 and DomU, as well as the hv_utils driver, which provides time synchronization, heartbeat, and integrated shutdown) /drivers/scsi/storvsc_drv.c (storage driver) /drivers/net/hyperv (network driver) /tools/hv (KVP - key value pair exchange, a way to pass messages and datagrams between virtual machines and the root) We've done a lot of work with Andy Whitcroft at Canonical to get the drivers integrated into Ubuntu 12.04 and higher. What we'd like to discuss is doing the same thing for Debian. What would be the best way to start or discuss this effort? The drivers were already updated (in 3.2.15-1). Great, thanks. We've done some investigation into the current status of Wheezy on Hyper-V, and as of 3.2.0-2, there's about a five patch differential between linux-next and the 3.2.0-2 kernel. How can I update to the 3.2.15-1 kernel? I installed Wheezy using the latest testing ISO, but apt-get doesn't want to show a new kernel. I have a to-do item to look at tools/hv and build those tools from the linux- tools source package, but it wouldn't hurt for you to open a bug report requesting it. If you can provide a patch then that would make it a lot easier to fix. Currently the linux-tools source package in Debian builds binary packages that are specific to upstream kernel versions (linux-kbuild-3.2, linux-tools- 3.2), I assume tools/hv is not version-specific and therefore it would belong in a new package, say, 'linux-tools-common' (*not* 'linux-tools', which somewhat confusingly is a meta-package). I'm going to sync with my developers to see if we can get a patch created - but in the meantime I'll open a bug. Thanks! -M mike sterling | program manager open source technology center http://www.microsoft.com/opensource/ t: +1 425 707 7730 f: +1 425 708 1799 e: mike.sterl...@microsoft.com t: http://twitter.com/mikester01 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/a19259d4d4d02a429e578f34e2857f9d51c63...@tk5ex14mbxc287.redmond.corp.microsoft.com
Re: Debian and Hyper-V VM drivers
On Mon, May 14, 2012 at 08:33:23PM +, Mike Sterling wrote: Hi Ben, Let me introduce myself - my team is part of the Open Source Technology Center at Microsoft, and we're responsible for a set of drivers in the Linux kernel to provide an optimized experience for running paravirtualized Linux on top of Microsoft's hypervisor, Hyper-V. The drivers have exited the kernel as of 3.4 and now exist in the following locations: /drivers/hv (core Hyper-V bus driver, provides communication between Dom0 and DomU, as well as the hv_utils driver, which provides time synchronization, heartbeat, and integrated shutdown) /drivers/scsi/storvsc_drv.c (storage driver) /drivers/net/hyperv (network driver) /tools/hv (KVP - key value pair exchange, a way to pass messages and datagrams between virtual machines and the root) We've done a lot of work with Andy Whitcroft at Canonical to get the drivers integrated into Ubuntu 12.04 and higher. What we'd like to discuss is doing the same thing for Debian. What would be the best way to start or discuss this effort? The drivers were already updated (in 3.2.15-1). I have a to-do item to look at tools/hv and build those tools from the linux-tools source package, but it wouldn't hurt for you to open a bug report requesting it. If you can provide a patch then that would make it a lot easier to fix. Currently the linux-tools source package in Debian builds binary packages that are specific to upstream kernel versions (linux-kbuild-3.2, linux-tools-3.2), I assume tools/hv is not version-specific and therefore it would belong in a new package, say, 'linux-tools-common' (*not* 'linux-tools', which somewhat confusingly is a meta-package). Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514222150.gl4...@decadent.org.uk
