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
-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
-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
-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
