----- Original Message ----- > 于 2013年03月19日 16:58, Tomas Hozza 写道: > > ----- Original Message ----- > >>> -----Original Message----- > >>> From: Tomas Hozza [mailto:thozza@xxxxxxxxxx] > >>> Sent: Monday, March 18, 2013 11:39 AM > >>> To: KY Srinivasan > >>> Cc: Jason Wang > >>> Subject: Re: Can HyperV KVP daemon detect if running under > >>> Windows > >>> Server > >>> > >>> ----- Original Message ----- > >>>>> -----Original Message----- > >>>>> From: Tomas Hozza [mailto:thozza@xxxxxxxxxx] > >>>>> Sent: Monday, March 18, 2013 11:15 AM > >>>>> To: KY Srinivasan > >>>>> Cc: Jason Wang > >>>>> Subject: Re: Can HyperV KVP daemon detect if running under > >>>>> Windows > >>>>> Server > >>>>> > >>>>> I tested the hyperv KVP daemon on RHEL-6.4 running on libvirt > >>>>> KVM virtual machine. None of hv_* kmod-s was loaded. The daemon > >>>>> is running just fine and netlink_send() completes successfully > >>>>> even if proper drivers are not loaded. > >>>>> > >>>>> [root@localhost ~]# modprobe hv_vmbus > >>>>> FATAL: Error inserting hv_vmbus (/lib/modules/2.6.32- > >>>>> 358.el6.x86_64/kernel/drivers/hv/hv_vmbus.ko): No such device > >>>>> [root@localhost ~]# modprobe hv_utils > >>>>> FATAL: Error inserting hv_utils (/lib/modules/2.6.32- > >>>>> 358.el6.x86_64/kernel/drivers/hv/hv_utils.ko): No such device > >>>>> [root@localhost ~]# lsmod | grep hv > >>>>> [root@localhost ~]# service hypervkvpd start > >>>>> Starting Hyper-V KVP daemon [ > >>>>> OK ] > >>>>> [root@localhost ~]# service hypervkvpd status > >>>>> hv_kvp_daemon (pid 1509) is running... > >>>>> [root@localhost ~]# grep KVP /var/log/messages > >>>>> Mar 18 16:00:50 localhost KVP: KVP starting; pid is:1509 > >>>>> [root@localhost ~]# uname -a > >>>>> Linux localhost.localdomain 2.6.32-358.el6.x86_64 #1 SMP Tue > >>>>> Jan 29 > >>>>> 11:47:41 EST > >>>>> 2013 x86_64 x86_64 x86_64 GNU/Linux > >>>>> > >>>>> Maybe there could be some timeout for driver registration. > >>>>> After it the daemon would exit if it got no reply from > >>>>> kernel driver. > >>>> In that case, as you suggest maybe we can have a timeout on the > >>>> first > >>>> receive from the kernel. In the current code, once the daemon > >>>> registers, the kernel component sends the LIS version number and > >>>> this message is guaranteed to come soon after the daemon > >>>> registers. > >>>> If this does not happen, we can conclude that we are not on > >>>> Hyper-V. > >>>> > >>>>> After having a look on the kernel driver I know this can not > >>>>> be done before some issues in the kernel driver are fixed. > >>>>> > >>>>> The problem is that the kernel driver at the moment handles > >>>>> daemon registration only for the first time. On the other > >>>>> hand the daemon wants to register with the driver every time > >>>>> it is started. This can be real problem for example when > >>>>> the daemon is restarted (stopped and started). You can read > >>>>> my longer and more explanatory comment in Red Hat Bugzilla [1]. > >>>> Why would you want to stop/restart the daemon. Not having the > >>>> daemon, > >>>> can only create more problems since the kernel component holds > >>>> onto > >>>> the host transaction until the daemon registers. We should view > >>>> the > >>>> daemon as simply an extension of the kernel driver. > >>> If you update the hypervkvpd package the daemon is restarted. In > >>> the > >>> current daemon code the registration part is written as: > >>> > >>> ... > >>> if ((in_hand_shake) && (op == KVP_OP_REGISTER1)) { > >>> /* handle registration */ > >>> } > >>> ... > >>> > >>> so it is possible that you update the daemon, it is restarted and > >>> wants > >>> to register with the driver. It sends the registration message to > >>> driver. > >>> The driver ignores this message since it has no transaction > >>> active > >>> from > >>> the Host so it is not expecting any messages from Guest. The > >>> daemon > >>> ends up in a state when it is "in_hand_shake" and waiting for the > >>> registration > >>> to complete, BUT (because how the registration part is written) > >>> it > >>> will > >>> handle requests from the driver (Host). I think this is not very > >>> fortunate > >>> and it is kind of "design issue". User should NOT have to restart > >>> (or unload > >>> kernel modules and load them again) after he updated the daemon. > I agree that in_hand_shake snippet like this is not good enough to > guarantee a registration is mandatory and can't be skipped. > I thought code like below: > if (in_hand_shake) { > if (op == KVP_OP_REGISTER1) { > ... > in_hand_shake = 0; > } > if (in_hand_shake) { > continue; > } > } > is more reasonable and fault tolerable. > I suppose I've already encountered an issue like this -- kvp > receviced > messages sent by libcgroup, registration phase is skipped and fault > packets are regarded as kvp packets. > > to K. Y: > remind you on > http://driverdev.linuxdriverproject.org/pipermail/devel/2013-March/036306.html. > I updated it and asked Evgeniy Polyakov on how to subscribe group > using > connector, waiting his feedback. Thank you for your opinion. I agree that the registration phase should be made mandatory. Regarding the subscription group when using connector I already sent patches to Greg KH and they were merged into Greg's tree. See: http://driverdev.linuxdriverproject.org/pipermail/devel/2013-March/036284.html Regards, Tomas Hozza > > > Regards, > Vaughan > > >> True; but as I said the daemon is to be viewed as simply an > >> extension > >> of the kernel component. If this is done, then you would not be > >> updating the daemon independently of the kernel component. I guess > >> the problem you are running into is because you are viewing the > >> daemon as an independent component that can be updated > >> independently > >> of the kernel piece. Perhaps, this is a packaging issue. > >> > >> Regards, > >> > >> K. Y > > I see your point. It is true that we ship hyperv daemon as a > > separate > > package. I understand the daemon is just an extension to kernel > > driver > > and has no purpose without it. > > > > But I don't like the way it is now anyway. Even if you look at the > > daemon > > as just an extension to the kernel part user should not need to > > restart > > whole Guest to get it to an "initial" state of module and the > > daemon. > > There might be some bug in the daemon, but the driver can be just > > fine. > > In that case I would expect that the daemon can be updated without > > any > > problems and without restarting the system (or unloading and > > loading driver). > > > > I would like to know what other people think about this. CC-ing > > Haiyang Zhang and devel@xxxxxxxxxxxxxxxxxxxxxx. > > > > Regards, > > > > Tomas Hozza > > > >>> Regards, > >>> > >>> Tomas Hozza > >>> > >>>>> Regards, > >>>>> > >>>>> Tomas Hozza > >>>>> > >>>>> ----- Original Message ----- > >>>>>> Tomas, > >>>>>> > >>>>>> Sorry for the delayed response. The kernel driver only loads > >>>>>> when > >>>>>> Linux is running on Hyper-V. We could leverage this to not > >>>>>> have > >>>>>> the > >>>>>> daemon running when not hosted on Hyper-V. The current code > >>>>>> as it > >>>>>> stands, the daemon exits if the netlink_send() fails. When > >>>>>> not > >>>>>> running on Hyper-V, does the initial send that registers the > >>>>>> daemon > >>>>>> succeed. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> K. Y > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Tomas Hozza [mailto:thozza@xxxxxxxxxx] > >>>>>>> Sent: Monday, March 18, 2013 7:13 AM > >>>>>>> To: Jason Wang > >>>>>>> Cc: KY Srinivasan > >>>>>>> Subject: Fwd: Can HyperV KVP daemon detect if running under > >>>>>>> Windows > >>>>>>> Server > >>>>>>> Importance: High > >>>>>>> > >>>>>>> Hi. > >>>>>>> > >>>>>>> I got no response to my email I sent some time ago > >>>>>>> so I'm sending it again. Maybe you just overlooked > >>>>>>> it. Thank you in advance for the response. > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Tomas Hozza > >>>>>>> > >>>>>>> ----- Forwarded Message ----- > >>>>>>>> Hi. > >>>>>>>> > >>>>>>>> I'm wondering if there is any way for the hyperv kvp > >>>>>>>> daemon > >>>>>>>> detect if it is running as a guest on Windows Server host > >>>>>>>> or > >>>>>>>> not. And furthermore run only if it is a guest under > >>>>>>>> Windows > >>>>>>>> Server. Now hyperv kvp daemon is a default package in a > >>>>>>>> Virtualization group of packages on RHEL 6.4. Some people > >>>>>>>> are > >>>>>>>> not happy that it is installed and running by default > >>>>>>>> when > >>>>>>>> the Virtualization group is selected. > >>>>>>>> > >>>>>>>> Do you have any suggestions? I don't know how the kernel > >>>>>>>> driver > >>>>>>>> is working (one that hyperv kvp daemon registers with). > >>>>>>>> Would > >>>>>>>> it > >>>>>>>> be possible to get some useful information from it? > >>>>>>>> > >>>>>>>> Thank you. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Tomas Hozza > >>>>>> > >>>> > >> > > _______________________________________________ > > devel mailing list > > devel@xxxxxxxxxxxxxxxxxxxxxx > > http://driverdev.linuxdriverproject.org/mailman/listinfo/devel > > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
