ショートバージョン：Hyper-V VMでubuntu 18.04.02をusbipクライアントとして実行し、ubuntu 18.04をRaspberry Piからusbサーバーとして実行します。 Hyper-V VM は Docker コンテナで Home Assistant (例: hass.io) を実行します。 Hyper-V仮想マシンが再起動されると、rPiのusbipサービスが再起動されるまで、usbipサービスがrPiのサーバー側に再接続できないことがあります。
これは、Hyper-V VMが（-権限のある）ドッカーコンテナ内で再起動した場合にのみ発生するようです。 Ubuntuシェルから再起動すると機能します。
両方のクライアントはlinux-tools-generic（以前のスタンドアロンパッケージではありません）のusbipを使用し、バージョン2として識別されます。私は2つを1つのサービスとしてパッケージ化しました。サーバー側はタイプフォークで実行され、クライアント側はワンタイムで実行されます。どちらも新しく起動すると正常に動作します。
以下は、接続できない（デバッグが有効になっている）クライアント（Hyper-V）の再起動のログです。長さについてお詫び申し上げます。かなりカットしましたが、残りの内容が関連性があるかどうかはわかりません。
すべてが正常な場合はクライアントから送信され、接続されているリモートポートを表示できます。
root@ha:~# usbip port
Imported USB devices
====================
Port 00: <Port in Use> at Full Speed(12Mbps)
Cygnal Integrated Products, Inc. : unknown product (10c4:8a2a)
1-1 -> usbip://192.168.132.100:3240/1-1.2
-> remote bus/dev 001/004
Hyper-V（usbipクライアント）側でdockerを再起動すると、シャットダウン時のログは次のようになります。
May 2 13:07:04 ha NetworkManager[1181]: <info> [1556802424.0981] device changed (path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0004:00/VMBUS:00/f8091f75-727b-47ed-85fd-ce642aa4be61/net/eth0, iface: eth0)
May 2 13:07:04 ha ModemManager[964]: <info> (tty/ttyUSB1): released by modem /sys/devices/platform/vhci_hcd.0/usb1/1-1
May 2 13:07:04 ha ModemManager[964]: <warn> [plugin manager] task 0,ttyUSB1: error when checking support with plugin 'Iridium': 'Operation was cancelled'
May 2 13:07:04 ha ModemManager[964]: <warn> [plugin manager] task 0,ttyUSB1: failed: Operation was cancelled
May 2 13:07:04 ha NetworkManager[1181]: <info> [1556802424.1522] device changed (path: /sys/devices/virtual/net/docker0, iface: docker0)
これは、サーバー（rPi usbipサーバー）側の同じ終了メッセージです。 rPiが終了しないことに注意してください。これはHyper-Vシャットダウンへの応答にすぎません（またはより正確にはこれが日常的でシャットダウンしているようです）。 Hyper-Vの終了に応答するハートビートでない限り、実際の応答はありませんが、とにかく定期的に表示されます。
May 2 13:06:56 ubuntu kernel: [41155.172199] usbip-host 1-1.2: endpoint 0 is stalled
May 2 13:06:56 ubuntu kernel: [41155.176078] usbip-host 1-1.2: endpoint 0 is stalled
May 2 13:07:03 ubuntu usbipd: usbipd: debug: usbipd.c:573:[do_standalone_mode] heartbeat timeout on ppoll()
Hyper-Vは再起動後にこの状態に戻ります。
May 2 13:11:27 ha kernel: [ 2.810394] systemd[1]: Set hostname to <ha>.
May 2 13:11:27 ha kernel: [ 2.977418] systemd[1]: /lib/systemd/system/usbip.service:9: Ignoring unknown escape sequences: "/usr/lib/linux-tools/$(uname -r)/usbip detach --port=$(/usr/lib/linux-tools/$(uname -r)/usbip port | grep '<Port in Use>' | sed -E 's/^Port ([0-9][0-9]).*/\1/')"
注：上記の行は、サービス定義のExecStopセクションから得られたものです。サービスが開始される前に起動時にどのように実行されるかはわかりませんが、何もしないようです。 （現在では）探して分離するポートがないため、このエラーが発生するようです。
May 2 13:11:28 ha sh[1380]: usbip: error: recv op_common
May 2 13:11:28 ha sh[1380]: usbip: error: query
May 2 13:11:28 ha systemd[1]: Starting Docker Application Container Engine...
May 2 13:11:28 ha systemd[1]: usbip.service: Main process exited, code=exited, status=1/FAILURE
May 2 13:11:28 ha systemd[1]: usbip.service: Failed with result 'exit-code'.
May 2 13:11:28 ha systemd[1]: Failed to start usbip client.
May 2 13:11:28 ha systemd[1]: Started Permit User Sessions.
このエラーはサービスを開始せず、手動で起動しません（以下同じエラー）。この時点で、クライアントはリモートデバイスを表示できますが、接続できません（このマニュアルの例を参照）。
root@ha:~# usbip list -r zwave
Exportable USB devices
======================
- zwave
1-1.2: Cygnal Integrated Products, Inc. : unknown product (10c4:8a2a)
: /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2
: (Defined at Interface level) (00/00/00)
: 0 - Vendor Specific Class / unknown subclass / unknown protocol (ff/00/00)
: 1 - Vendor Specific Class / unknown subclass / unknown protocol (ff/00/00)
root@ha:~# usbip port
Imported USB devices
====================
root@ha:~# usbip attach -r zwave -b 1-1.2
usbip: error: recv op_common
usbip: error: query
ただし、サーバー（rPi）から接続しようとすると、上記のコマンドに対する応答は次のようになります。クライアントは最初にバスIDを取得するためにリストを実行してから追加を実行するため、リストがリンクされて追加が失敗することがわかります。
May 2 13:11:28 ubuntu usbipd: usbipd: debug: usbipd.c:568:[do_standalone_mode] read event on fd[0]=4
May 2 13:11:28 ubuntu usbipd: usbipd: info: connection from 192.168.132.254:34686
May 2 13:11:28 ubuntu usbipd: usbipd: info: received request: 0x8005(6)
May 2 13:11:28 ubuntu usbipd: usbipd: info: exportable devices: 1
May 2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:91:[dump_usb_device] path = /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2
May 2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:92:[dump_usb_device] busid = 1-1.2
May 2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:98:[dump_usb_device] Device(C/SC/P) = (Defined at Interface level) (00/00/00)
May 2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:100:[dump_usb_device] bcdDevice = 100
May 2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:105:[dump_usb_device] Vendor/Product = unknown vendor : unknown product (10c4:8a2a)
May 2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:107:[dump_usb_device] bNumConfigurations = 1
May 2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:108:[dump_usb_device] bNumInterfaces = 2
May 2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:111:[dump_usb_device] speed = Full Speed(12Mbps)
May 2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:113:[dump_usb_device] busnum = 1
May 2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:114:[dump_usb_device] devnum = 4
May 2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:84:[dump_usb_interface] Interface(C/SC/P) = unknown class / unknown subclass / unknown protocol (ff/00/00)
May 2 13:11:28 ubuntu usbipd: libusbip: debug: usbip_common.c:84:[dump_usb_interface] Interface(C/SC/P) = unknown class / unknown subclass / unknown protocol (ff/00/00)
May 2 13:11:28 ubuntu usbipd: usbipd: info: request 0x8005(6): complete
May 2 13:11:28 ubuntu usbipd: usbipd: debug: usbipd.c:568:[do_standalone_mode] read event on fd[0]=4
May 2 13:11:28 ubuntu usbipd: usbipd: info: connection from 192.168.132.254:34688
May 2 13:11:28 ubuntu usbipd: usbipd: info: received request: 0x8003(6)
May 2 13:11:28 ubuntu usbipd: usbipd: info: found requested device: 1-1.2
May 2 13:11:28 ubuntu usbipd: usbip: debug: usbip_host_common.c:233:[usbip_export_device] device not available: 1-1.2
May 2 13:11:28 ubuntu usbipd: usbip: debug: usbip_host_common.c:239:[usbip_export_device] status SDEV_ST_USED
May 2 13:11:28 ubuntu usbipd: usbipd: debug: usbipd.c:152:[recv_request_import] import request busid 1-1.2: failed
May 2 13:11:28 ubuntu usbipd: usbipd: info: request 0x8003(6): failed
上記の奇妙なことは、デバイスがあると言われているようですが、使用できません。
その後、時には（推論によると、Ubuntuを再起動するdockerではなく、Ubuntuシェルがいつ再起動するかわからない）、それはうまく動作します。
rPi サービスは引き続き実行されるため、サービスが失敗するのではなく、接続の失敗が自動的に再開されません。まず、rPiサーバーを手動で再起動してから、HyperV VMクライアントを再起動して正常に動作させます。サービス定義でクライアントを自動的に再起動できますが、問題を解決するにはrPi usbipサービスを再起動する必要があるため、役に立ちません。
はい、短い答えは常にドッカーコンテナではなくUbuntuで再起動することを覚えておくことです。
しかし...もっと強力な答えがありますか？サーバー側のクリーンアップが正しく実行されないようにするいくつかの構成または設定の問題がありますか？
理論的には、サーバーをリモートで再起動し、準備が整うのを待つクライアント再起動スクリプトを書くことができるようですが、これは非常に脆弱です。
どんな洞察力がありますか？
PS。反対のシナリオも問題であることに注意してください。 rPiでusbipサービスを再起動すると、クライアント（Hyper-V VM）はサービスがまだ接続されていると思いますが、機能しないため再起動する必要があります。 rPiサーバーを再起動する必要はほとんどなく、ホームアシスタントソフトウェアを開発しており、頻繁に再起動するため、これは大きな問題ではありません。しかし、基本的な問題は似ています。一方の端を再起動すると、もう一方の端が損傷する可能性があります。