[Kernel-packages] [Bug 1779640] Re: [Hyper-V] KVP daemon crashes at startup

2018-07-05 Thread Ionut Lenghel
We haven't seen it in Xenial, but we managed to reproduce it back to the
daily Bionic build from the 2nd of March. We haven't tested Bionic daily
builds before the 2nd of March, nor did I try to reproduce it on Zesty
or or Artful.

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

Title:
  [Hyper-V] KVP daemon crashes at startup

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Bionic:
  In Progress

Bug description:
  While testing Bionic daily build with kernel 4.15.0-20-generic we saw
  the following issue with the KVP daemon:

  KVP daemon crashes after approximatively 2 minutes of uptime and it enters in 
a failed state. The daemon can be manually started and it enters back in active 
(running) state.
  The error messages from /var/log/syslog after the daemon enters the failed 
state are the following:

  Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with 
result 'exit-code'.
  Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon.

  Note: There was a simmilar issue discussed on this thread
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the
  fixing commit seems to be inclued in this Bionic build.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640/+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


[Kernel-packages] [Bug 1766857] Re: [Hyper-V] KVP daemon fails to start

2018-07-02 Thread Ionut Lenghel
I have opened a different bug for the first issue:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640

Regarding the second issue, as mentioned in comment #13, the tested
kernels did not exhibit issue #2.

** Description changed:

  While testing Bionic daily build with kernel 4.15.0-20-generic we saw
  that there are 2 issues with the KVP daemon:
  
- 1. KVP daemon crashes after approximatively 2 minutes of uptime and it enters 
in a failed state. The daemon can be manually started and it enters back in 
active (running) state.
- The error messages from /var/log/syslog after the daemon enters the failed 
state are the following:
- 
- Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor
- Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
- Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with 
result 'exit-code'.
- Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon.
- 
- Note: There was a simmilar issue discussed on this thread
- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the
- fixing commit seems to be inclued in this Bionic build.
+ 1. KVP daemon crash after boot. Opened a different bug for this:
+ https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640
  
  2. After the KVP daemon is being started the following messages appear:
  
  Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
  Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found
  
  The above binaries are present on the system, but the their actual path
  is /usr/sbin/hv_get_dns_info and /usr/sbin/hv_get_dhcp_info. Either the
  hv_get_dhcp_info and hv_get_dns_info binaries should be placed in the
  location where the daemon is looking for (/usr/libexec/hypervkvpd/), or
  the daemon should be set to search for the binaries in the /usr/sbin
  directory.

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

Title:
  [Hyper-V] KVP daemon fails to start

Status in linux package in Ubuntu:
  In Progress
Status in linux-azure package in Ubuntu:
  Invalid
Status in linux source package in Bionic:
  In Progress
Status in linux-azure source package in Bionic:
  Invalid

Bug description:
  While testing Bionic daily build with kernel 4.15.0-20-generic we saw
  that there are 2 issues with the KVP daemon:

  1. KVP daemon crash after boot. Opened a different bug for this:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640

  2. After the KVP daemon is being started the following messages
  appear:

  Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
  Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found

  The above binaries are present on the system, but the their actual
  path is /usr/sbin/hv_get_dns_info and /usr/sbin/hv_get_dhcp_info.
  Either the hv_get_dhcp_info and hv_get_dns_info binaries should be
  placed in the location where the daemon is looking for
  (/usr/libexec/hypervkvpd/), or the daemon should be set to search for
  the binaries in the /usr/sbin directory.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766857/+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


[Kernel-packages] [Bug 1779640] Re: [Hyper-V] KVP daemon crashes at startup

2018-07-02 Thread Ionut Lenghel
I have tested this on kernel 4.15.0-24.26 and linux-cloud-tools
4.15.0-24.26 and the issue persists.

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

Title:
  [Hyper-V] KVP daemon crashes at startup

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  While testing Bionic daily build with kernel 4.15.0-20-generic we saw
  the following issue with the KVP daemon:

  KVP daemon crashes after approximatively 2 minutes of uptime and it enters in 
a failed state. The daemon can be manually started and it enters back in active 
(running) state.
  The error messages from /var/log/syslog after the daemon enters the failed 
state are the following:

  Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with 
result 'exit-code'.
  Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon.

  Note: There was a simmilar issue discussed on this thread
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the
  fixing commit seems to be inclued in this Bionic build.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640/+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


[Kernel-packages] [Bug 1779640] Re: [Hyper-V] KVP daemon crashes at startup

2018-07-02 Thread Ionut Lenghel
** Package changed: linux-azure (Ubuntu) => linux (Ubuntu)

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

Title:
  [Hyper-V] KVP daemon crashes at startup

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  While testing Bionic daily build with kernel 4.15.0-20-generic we saw
  the following issue with the KVP daemon:

  KVP daemon crashes after approximatively 2 minutes of uptime and it enters in 
a failed state. The daemon can be manually started and it enters back in active 
(running) state.
  The error messages from /var/log/syslog after the daemon enters the failed 
state are the following:

  Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with 
result 'exit-code'.
  Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon.

  Note: There was a simmilar issue discussed on this thread
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the
  fixing commit seems to be inclued in this Bionic build.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640/+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


[Kernel-packages] [Bug 1779640] [NEW] [Hyper-V] KVP daemon crashes at startup

2018-07-02 Thread Ionut Lenghel
Public bug reported:

While testing Bionic daily build with kernel 4.15.0-20-generic we saw
the following issue with the KVP daemon:

KVP daemon crashes after approximatively 2 minutes of uptime and it enters in a 
failed state. The daemon can be manually started and it enters back in active 
(running) state.
The error messages from /var/log/syslog after the daemon enters the failed 
state are the following:

Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor
Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with 
result 'exit-code'.
Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon.

Note: There was a simmilar issue discussed on this thread
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the
fixing commit seems to be inclued in this Bionic build.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  [Hyper-V] KVP daemon crashes at startup

Status in linux package in Ubuntu:
  New

Bug description:
  While testing Bionic daily build with kernel 4.15.0-20-generic we saw
  the following issue with the KVP daemon:

  KVP daemon crashes after approximatively 2 minutes of uptime and it enters in 
a failed state. The daemon can be manually started and it enters back in active 
(running) state.
  The error messages from /var/log/syslog after the daemon enters the failed 
state are the following:

  Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with 
result 'exit-code'.
  Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon.

  Note: There was a simmilar issue discussed on this thread
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the
  fixing commit seems to be inclued in this Bionic build.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640/+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


[Kernel-packages] [Bug 1766857] Re: [Hyper-V] KVP daemon fails to start

2018-06-13 Thread Ionut Lenghel
Regarding comment #11:
I have tested both kernels provided with the following results:

- 4.14 Bionic kernel (4.14.0-16-generic) does NOT exhibit issue #2
(missing files), but it does exhibit issue #1 (KVP daemon failure after
boot). Linux-cloud-tools version installed is 4.14.0-16.19.

- 4.15 Bionic kernel (4.15.0-9-generic) behaves the same as 4.14,
meaning that issue #2 (missing files) is NOT present, but issue #1 (KVP
daemon failure after boot) shows up. Linux-cloud-tools version is
4.15.0-9.10.


Regarding comment #12:
I have tested the kernel from the link and it seems that this kernel does NOT 
exhibit issue #2 (but it does exhibit issue #1).

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

Title:
  [Hyper-V] KVP daemon fails to start

Status in linux package in Ubuntu:
  In Progress
Status in linux-azure package in Ubuntu:
  Invalid
Status in linux source package in Bionic:
  In Progress
Status in linux-azure source package in Bionic:
  Invalid

Bug description:
  While testing Bionic daily build with kernel 4.15.0-20-generic we saw
  that there are 2 issues with the KVP daemon:

  1. KVP daemon crashes after approximatively 2 minutes of uptime and it enters 
in a failed state. The daemon can be manually started and it enters back in 
active (running) state.
  The error messages from /var/log/syslog after the daemon enters the failed 
state are the following:

  Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with 
result 'exit-code'.
  Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon.

  Note: There was a simmilar issue discussed on this thread
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the
  fixing commit seems to be inclued in this Bionic build.

  2. After the KVP daemon is being started the following messages
  appear:

  Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
  Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found

  The above binaries are present on the system, but the their actual
  path is /usr/sbin/hv_get_dns_info and /usr/sbin/hv_get_dhcp_info.
  Either the hv_get_dhcp_info and hv_get_dns_info binaries should be
  placed in the location where the daemon is looking for
  (/usr/libexec/hypervkvpd/), or the daemon should be set to search for
  the binaries in the /usr/sbin directory.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766857/+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


[Kernel-packages] [Bug 1766857] Re: [Hyper-V] KVP daemon fails to start

2018-06-07 Thread Ionut Lenghel
I have tested Bionic with kernel 4.15.0-22-generic, linux-cloud-
tools-4.15.0-22.24 and linux-tools-4.15.0-22.24 and both issues still
occur.

While testing the above mentioned kernel, I saw the following behavior:

1. Right after booting the system the KVP daemon reports it is active
(running). The command "systemctl status hv-kvp-daemon" returns the
following output:

hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon
   Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Thu 2018-06-07 11:43:22 UTC; 55s ago
 Main PID: 1363 (hv_kvp_daemon)
Tasks: 1 (limit: 4496)
   CGroup: /system.slice/hv-kvp-daemon.service
   └─1363 /usr/lib/linux-tools/4.15.0-22-generic/hv_kvp_daemon -n

Jun 07 11:43:22 bionic systemd[1]: Started Hyper-V KVP Protocol Daemon.
Jun 07 11:43:22 bionic KVP[1363]: KVP starting; pid is:1363
Jun 07 11:43:22 bionic KVP[1363]: KVP LIC Version: 3.1

2. After approximately 2 minutes the KVP daemon enters in the failed state 
(issue 1).
3. Manually starting the daemon with the command "systemctl start 
hv-kvp-daemon" works perfectly fine.
4. "systemctl status hv-kvp-daemon" will now show the second issue:

hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon
   Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Thu 2018-06-07 11:47:29 UTC; 8s ago
 Main PID: 1995 (hv_kvp_daemon)
Tasks: 1 (limit: 4496)
   CGroup: /system.slice/hv-kvp-daemon.service
   └─1995 /usr/lib/linux-tools/4.15.0-22-generic/hv_kvp_daemon -n

Jun 07 11:47:29 bionic systemd[1]: Started Hyper-V KVP Protocol Daemon.
Jun 07 11:47:29 bionic KVP[1995]: KVP starting; pid is:1995
Jun 07 11:47:29 bionic KVP[1995]: KVP LIC Version: 3.1
Jun 07 11:47:36 bionic hv_kvp_daemon[1995]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
Jun 07 11:47:36 bionic hv_kvp_daemon[1995]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found
Jun 07 11:47:36 bionic hv_kvp_daemon[1995]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
Jun 07 11:47:36 bionic hv_kvp_daemon[1995]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found
Jun 07 11:47:36 bionic hv_kvp_daemon[1995]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
Jun 07 11:47:36 bionic hv_kvp_daemon[1995]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found

5. Rebooting the system after this point will no longer trigger the
first issue, only the second one. Even stopping the VM and turning it
back ON does NOT trigger the first issue again.

Could it be that while the hv-kvp-daemon service shows the two files
(hv_get_dns_info and hv_get_dhcp_info) are not found, it will not enter
in the failed state? Meaning that the two apparently separate issues,
are actually related. I am not 100% sure about this.

In order to trigger the first issue again, the Integration Service
corresponding to the KVP daemon has to be disabled and re-enabled, and
the VM has to be rebooted. This is just the way I managed to reproduce
the first issue again, I am not sure if there are other ways to trigger
it again.

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

Title:
  [Hyper-V] KVP daemon fails to start

Status in linux package in Ubuntu:
  In Progress
Status in linux-azure package in Ubuntu:
  Invalid
Status in linux source package in Bionic:
  In Progress
Status in linux-azure source package in Bionic:
  Invalid

Bug description:
  While testing Bionic daily build with kernel 4.15.0-20-generic we saw
  that there are 2 issues with the KVP daemon:

  1. KVP daemon crashes after approximatively 2 minutes of uptime and it enters 
in a failed state. The daemon can be manually started and it enters back in 
active (running) state.
  The error messages from /var/log/syslog after the daemon enters the failed 
state are the following:

  Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with 
result 'exit-code'.
  Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon.

  Note: There was a simmilar issue discussed on this thread
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the
  fixing commit seems to be inclued in this Bionic build.

  2. After the KVP daemon is being started the following messages
  appear:

  Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
  Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found

  The above binaries are present on the system, but the their actual
  path is /usr/sbin/hv_get_dns_info and 

[Kernel-packages] [Bug 1766857] Re: [Hyper-V] KVP daemon fails to start

2018-04-25 Thread Ionut Lenghel
I tested back to the daily build from 2nd of March and I can confirm the
second issue (regarding the binaries path), but not the first one
(regarding the daemon crash). On the build from the 2nd of March the
linux-tools and linux-cloud-tools version is 4.15.0-10.11

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

Title:
  [Hyper-V] KVP daemon fails to start

Status in linux package in Ubuntu:
  Confirmed
Status in linux-azure package in Ubuntu:
  New
Status in linux source package in Bionic:
  Confirmed
Status in linux-azure source package in Bionic:
  New

Bug description:
  While testing Bionic daily build with kernel 4.15.0-20-generic we saw
  that there are 2 issues with the KVP daemon:

  1. KVP daemon crashes after approximatively 2 minutes of uptime and it enters 
in a failed state. The daemon can be manually started and it enters back in 
active (running) state.
  The error messages from /var/log/syslog after the daemon enters the failed 
state are the following:

  Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with 
result 'exit-code'.
  Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon.

  Note: There was a simmilar issue discussed on this thread
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the
  fixing commit seems to be inclued in this Bionic build.

  2. After the KVP daemon is being started the following messages
  appear:

  Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
  Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found

  The above binaries are present on the system, but the their actual
  path is /usr/sbin/hv_get_dns_info and /usr/sbin/hv_get_dhcp_info.
  Either the hv_get_dhcp_info and hv_get_dns_info binaries should be
  placed in the location where the daemon is looking for
  (/usr/libexec/hypervkvpd/), or the daemon should be set to search for
  the binaries in the /usr/sbin directory.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766857/+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


[Kernel-packages] [Bug 1766857] [NEW] [Hyper-V] KVP daemon fails to start

2018-04-25 Thread Ionut Lenghel
Public bug reported:

While testing Bionic daily build with kernel 4.15.0-20-generic we saw
that there are 2 issues with the KVP daemon:

1. KVP daemon crashes after approximatively 2 minutes of uptime and it enters 
in a failed state. The daemon can be manually started and it enters back in 
active (running) state.
The error messages from /var/log/syslog after the daemon enters the failed 
state are the following:

Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor
Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with 
result 'exit-code'.
Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon.

Note: There was a simmilar issue discussed on this thread
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the
fixing commit seems to be inclued in this Bionic build.

2. After the KVP daemon is being started the following messages appear:

Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found

The above binaries are present on the system, but the their actual path
is /usr/sbin/hv_get_dns_info and /usr/sbin/hv_get_dhcp_info. Either the
hv_get_dhcp_info and hv_get_dns_info binaries should be placed in the
location where the daemon is looking for (/usr/libexec/hypervkvpd/), or
the daemon should be set to search for the binaries in the /usr/sbin
directory.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Incomplete


** Tags: bionic

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

Title:
  [Hyper-V] KVP daemon fails to start

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  While testing Bionic daily build with kernel 4.15.0-20-generic we saw
  that there are 2 issues with the KVP daemon:

  1. KVP daemon crashes after approximatively 2 minutes of uptime and it enters 
in a failed state. The daemon can be manually started and it enters back in 
active (running) state.
  The error messages from /var/log/syslog after the daemon enters the failed 
state are the following:

  Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with 
result 'exit-code'.
  Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon.

  Note: There was a simmilar issue discussed on this thread
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the
  fixing commit seems to be inclued in this Bionic build.

  2. After the KVP daemon is being started the following messages
  appear:

  Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
  Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found

  The above binaries are present on the system, but the their actual
  path is /usr/sbin/hv_get_dns_info and /usr/sbin/hv_get_dhcp_info.
  Either the hv_get_dhcp_info and hv_get_dns_info binaries should be
  placed in the location where the daemon is looking for
  (/usr/libexec/hypervkvpd/), or the daemon should be set to search for
  the binaries in the /usr/sbin directory.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766857/+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


[Kernel-packages] [Bug 1756129] [NEW] [Hyper-V] Dynamic Memory HotAdd memory demand increases very fast to maximum and logs show call trace messages

2018-03-15 Thread Ionut Lenghel
Public bug reported:

Issue description: Memory demand increases very fast up to the maximum
available memory, call traces show up in /var/log/syslog, the VM becomes
unresponsive during the memory consumption, but it becomes responsive
right after stress-ng ends its execution, therefore we can say the issue
might be in the Dynamic Memory feature.

Platform: host independent

Distribution name and release: 
- Bionic (4.15.0-10-generic) 
- Linux Azure kernel (4.13.0-1012-azure)

Repro rate: 100%

VM configuration:
Kernel: 4.13.0-1012-azure
CPU: 8 cores
RAM: 2048 MB
Enable Dynamic Memory: Yes
Minimum RAM: 512 MB
Maximum RAM: 8192 MB
Memory buffer: 20%
Memory weight: 100%

Repro steps:
1. Start the VM with the above configuration.
2. Run stress-ng with the following parameters:
stress-ng -m 16 -vm-bytes 256M -t 200 --backoff 1000
3. In less than 60 seconds the entire memory is consumed.

Additional info:
1. We also tested this on Xenial with default kernel and the issue does 
not occur.
2. The call trace message from syslog can be seen below.


Mar 14 08:42:17 xenial kernel: [  257.120261] Call Trace:
Mar 14 08:42:17 xenial kernel: [  257.120267]  dump_stack+0x63/0x82
Mar 14 08:42:17 xenial kernel: [  257.120271]  dump_header+0x97/0x225
Mar 14 08:42:17 xenial kernel: [  257.120276]  ? 
security_capable_noaudit+0x4b/0x70
Mar 14 08:42:17 xenial kernel: [  257.120277]  oom_kill_process+0x219/0x420
Mar 14 08:42:17 xenial kernel: [  257.120279]  out_of_memory+0x11d/0x4b0
Mar 14 08:42:17 xenial kernel: [  257.120282]  
__alloc_pages_slowpath+0xd32/0xe10
Mar 14 08:42:17 xenial kernel: [  257.120284]  
__alloc_pages_nodemask+0x263/0x280
Mar 14 08:42:17 xenial kernel: [  257.120289]  alloc_pages_vma+0x88/0x1e0
Mar 14 08:42:17 xenial kernel: [  257.120292]  shmem_alloc_page+0x70/0xc0
Mar 14 08:42:17 xenial kernel: [  257.120295]  ? __radix_tree_insert+0x45/0x230
Mar 14 08:42:17 xenial kernel: [  257.120297]  
shmem_alloc_and_acct_page+0x73/0x1b0
Mar 14 08:42:17 xenial kernel: [  257.120298]  ? find_get_entry+0x1e/0xe0
Mar 14 08:42:17 xenial kernel: [  257.120300]  shmem_getpage_gfp+0x18f/0xbf0
Mar 14 08:42:17 xenial kernel: [  257.120303]  shmem_fault+0x9d/0x1e0
Mar 14 08:42:17 xenial kernel: [  257.120306]  ? file_update_time+0x60/0x110
Mar 14 08:42:17 xenial kernel: [  257.120309]  __do_fault+0x24/0xd0
Mar 14 08:42:17 xenial kernel: [  257.120311]  __handle_mm_fault+0x983/0x1080
Mar 14 08:42:17 xenial kernel: [  257.120314]  ? set_next_entity+0xd9/0x220
Mar 14 08:42:17 xenial kernel: [  257.120316]  handle_mm_fault+0xcc/0x1c0
Mar 14 08:42:17 xenial kernel: [  257.120319]  __do_page_fault+0x258/0x4f0
Mar 14 08:42:17 xenial kernel: [  257.120320]  do_page_fault+0x22/0x30
Mar 14 08:42:17 xenial kernel: [  257.120323]  ? page_fault+0x36/0x60
Mar 14 08:42:17 xenial kernel: [  257.120325]  page_fault+0x4c/0x60
Mar 14 08:42:17 xenial kernel: [  257.120327] RIP: 0033:0x4493ad
Mar 14 08:42:17 xenial kernel: [  257.120328] RSP: 002b:7ffd3ff927b0 
EFLAGS: 00010286
Mar 14 08:42:17 xenial kernel: [  257.120329] RAX: c6a6a9e7 RBX: 
0001a8ae9d07 RCX: 21b83c00
Mar 14 08:42:17 xenial kernel: [  257.120330] RDX: 7f2ad911d000 RSI: 
271ea9e7 RDI: 271e9660
Mar 14 08:42:17 xenial kernel: [  257.120331] RBP: 7f2adab7 R08: 
1bda3103 R09: 48373eca
Mar 14 08:42:17 xenial kernel: [  257.120331] R10: 48373eca R11: 
7f2acab7 R12: 
Mar 14 08:42:17 xenial kernel: [  257.120332] R13: 8309310348373eca R14: 
56b63c1fe6166568 R15: 7f2acab7
Mar 14 08:42:17 xenial kernel: [  257.120333] Mem-Info:
Mar 14 08:42:17 xenial kernel: [  257.120337] active_anon:249563 
inactive_anon:83607 isolated_anon:65
Mar 14 08:42:17 xenial kernel: [  257.120337]  active_file:54 inactive_file:74 
isolated_file:0
Mar 14 08:42:17 xenial kernel: [  257.120337]  unevictable:2561 dirty:0 
writeback:68 unstable:0
Mar 14 08:42:17 xenial kernel: [  257.120337]  slab_reclaimable:10707 
slab_unreclaimable:16622
Mar 14 08:42:17 xenial kernel: [  257.120337]  mapped:132260 shmem:332303 
pagetables:2888 bounce:0
Mar 14 08:42:17 xenial kernel: [  257.120337]  free:12983 free_pcp:493 
free_cma:0
Mar 14 08:42:17 xenial kernel: [  257.120340] Node 0 active_anon:998252kB 
inactive_anon:334428kB active_file:216kB inactive_file:296kB 
unevictable:10244kB isolated(anon):260kB isolated(file):0kB mapped:529040kB 
dirty:0kB writeback:272kB shmem:1329212kB shmem_thp: 0kB shmem_pmdmapped: 0kB 
anon_thp: 0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
Mar 14 08:42:17 xenial kernel: [  257.120341] Node 0 DMA free:7404kB min:392kB 
low:488kB high:584kB active_anon:5616kB inactive_anon:2384kB active_file:0kB 
inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB 
managed:15908kB mlocked:0kB kernel_stack:0kB pagetables:64kB 

[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-25 Thread Ionut Lenghel
I have tested the proposed kernel, but with this version both bugs are
showing up.

Could it be that the bug is not in the kernel, but in systemd?
Below is a comparison of the strace command ran on RHEL 7.3 and Ubuntu 16.04.1, 
when trying to re-enable the Data Exchange integration service: 
http://pastebin.ubuntu.com/25615867/

Since manually starting the daemon after re-enabling the integration service 
works fine, could it be that systemd doesn't handle the daemon starting process 
when it receives the call to do so?
Is there any way to see how systemd handles the call to start the daemon?

-- 
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
Status in linux source package in Artful:
  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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-25 Thread Ionut Lenghel
I have tested Xenial back to 4.2.0-16 from here: https://launchpad.net
/~canonical-kernel-team/+archive/ubuntu/ppa/+build/8099555

The second issue is still present.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-21 Thread Ionut Lenghel
I have tested 4.4.0-2.16 from here:
https://launchpad.net/ubuntu/+source/linux/4.4.0-2.16/+build/8908724

In this case, the daemon remains running when the integration service is
being disabled. systemctl status shows the daemon running and active,
but the daemon is not working actually. Re-enabling the service does not
make the daemon to work properly. Manually starting a new instance of
the daemon results in the daemon actually working, but with two
different PIDs in the process list.

To sum it up, yes, it has the second issue as well.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-21 Thread Ionut Lenghel
I have tested the mainline kernel provided with the compiled daemons
form linux-next. In this case, the daemons do stop when the integration
service is being disabled, but do not automatically start after we re-
enable the integration service. Manually starting the service works
fine. So the mainline is still affected by the second issue.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-19 Thread Ionut Lenghel
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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-13 Thread Ionut Lenghel
I have tested both kernels provided, and both exhibit the bug. In both
cases the daemon does not stop after the integration services is being
disabled.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-13 Thread Ionut Lenghel
I have tested the above kernel. The daemon stops if the integration
service is being disabled, but does not automatically start after the
service is being enabled again (same behavior as 4.4.0-3).

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-12 Thread Ionut Lenghel
I have tested the above kernel build. The issue still occurs.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-11 Thread Ionut Lenghel
I have tested the above kernel build. The issue still occurs.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-07 Thread Ionut Lenghel
Tested the above kernel build. The issue still occurs.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-06 Thread Ionut Lenghel
Tested the above kernel build. The issue still occurs.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-06 Thread Ionut Lenghel
I have tested the kernel above. The daemon still remains running after
the integration service is being disabled.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-09-03 Thread Ionut Lenghel
I have tested the kernel above. The issue still occurs.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-08-29 Thread Ionut Lenghel
I have tested the kernel provided. The issue still occurs.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-08-28 Thread Ionut Lenghel
I have tested the kernel provided. The issue still occurs.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-08-25 Thread Ionut Lenghel
I have tested the kernel provided in the link above. The issue still
occurs.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-08-24 Thread Ionut Lenghel
I have tested the kernel provided in the link above. The daemons do not
stop when the integration services are disabled.

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-08-23 Thread Ionut Lenghel
I have checked back to 4.2.0-16. It seems that 4.4.0-2 is the last
kernel where the daemons remain running even if integration services are
being disabled. Starting with 4.4.0-3 the daemons stop if the
integration services are disabled, but do not automatically start if the
integrations services are being enabled again.

I have also checked the content of linux-cloud-tools-common package for
the above mentioned kernels, and it seems there is no difference between
the two packages (as shown by the md5sum file).

-- 
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:
  Triaged
Status in linux source package in Xenial:
  Triaged
Status in linux source package in Zesty:
  Triaged

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


[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services

2017-08-22 Thread Ionut Lenghel
The same happens on 4.4.0-20 kernel.

-- 
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:
  Triaged
Status in linux source package in Xenial:
  Triaged
Status in linux source package in Zesty:
  Triaged

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