I have tested the kernel provided with commit ef754413085f5 and the bug
persists. The daemons do not stop if the integration services are being
disabled.

The kernel provided in comment #36 was not affected by the bug. That was
the first good commit.

Regarding comment #27, the kernel tested was reported as bad (the daemon
still remains running after the integration service is being disabled).

Just to make sure we got this right, there are 2 issues right now:

1. The daemons do not stop if the integration service is being disabled,
they remain running in the process list, but are not functional. This
issue is present in the kernels tested up to 4.4.0-2. This issue is NOT
present in kernel 4.4.0-3, here the daemons processes do stop if the
integration service is disabled. Regarding this issue, the kernel
provided in comment #36 is a good kernel.

2. The daemons do not automatically start after the integration service
is disabled and then enabled again. This is the initial bug discovered
in 16.04 and 17.04.

Kernel 4.4.0-3 does not have the first issue, but it has the second one.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1701222

Title:
  [Hyper-V] LIS daemons fail to start after disable/re-enable VM
  integration services

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Zesty:
  In Progress

Bug description:
  Issue description: Hyper-V daemons fail to start after disable/re-
  enable VM integration services.

  Platform: host independent
  Affected daemons - KVP, FCOPY and VSS.

  Distribution name and release: Ubuntu 16.04, Ubuntu 17.04
  Kernel version: 4.11.0-rc7-next-20170421 (for Ubuntu 16.04), 
4.10.0-19-generic (for Ubuntu 17.04)

  Repro rate: 100%

  Steps to reproduce:
  1.    Start VM with Guest Services enabled (FCopy daemon starts automatically)
  2.    Go to File > Settings > Integration Services, uncheck Guest Services 
and apply (FCopy daemon will stop at this point)
  3.    Re-enable Guest Services from VM Settings (Fcopy daemon is not running).
  This is the issue. systemd monitors for the service and if we have the hook 
for the Guest Service, it tries to start the daemon again.
  systemd attempt to start any of the LIS daemons will fail, but manually 
executing the daemon binary, it will start the daemon.

  Additional Info:
  - the steps above can be repro'd with KVP / Data Exchange integration service 
as well.
  - Manually starting hv_fcopy_daemon works fine.
  - other distros (RHEL) does not have this behavior, the LIS daemons are 
started automatically by systemd once we re-enable the integration service.

  On the upstream kernel and the upstream hv daemons, these messages are 
recorded in syslog, once we re-enable the Guest service:
  HV_FCOPY: pread failed: Bad file descriptor
  systemd[1]: hv-fcopy-daemon.service: Main process exited, code=exited, 
status=1/FAILURE
  systemd[1]: hv-fcopy-daemon.service: Unit entered failed state.
  systemd[1]: hv-fcopy-daemon.service: Failed with result 'exit-code'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1701222/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to