已恢復的 VM 快照上的 DHCP 租約過期會干擾活動的 gRPC 連接？
我正在使用 gRPC 在 Java（在主機上執行）和 Python（在我的來賓 VM 上執行）之間進行通信。我的軟體在啟動時使用 libvirt 設置了一些虛擬機。我使用這樣的 DHCP 範圍指定我的網路：
<network> ... <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.128' end='192.168.122.254'/> <host mac="00:16:3e:77:e2:ed" ip="192.168.122.128"/> <host mac="00:16:3e:3e:a9:1a" ip="192.168.122.129"/> ... </dhcp> </ip> ... </network>一旦一切都設置好並且我的虛擬機正在執行，我會為每個虛擬機創建一個快照。現在軟體的工作流程是這樣的：打開gRPC介面到上面指定IP的guest VM的mac地址，設置正確的時間（現在時間，由於snapshot和不能上網而不同），做一些工作，然後恢復快照並重複。
在 VM 上的 Python 程式碼中，我每 5 秒向主機發送一條 ping 消息（類似於心跳）。大多數情況下，這工作得很好，我在 Java 程式碼中收到主機上的消息。但是，有時我會在 3 分鐘內不再在主機上收到消息（之後我會拋出自定義超時異常）。Python 程式碼中沒有錯誤或無限循環，Java 端也沒有收到異常。所以問題一定出在其他地方。
在檢查這種奇怪行為的原因時，我遇到了 DHCP 租用時間。我的虛擬機從通過 libvirt 配置的 DHCP 範圍獲取它們的 IP（見上文）。DHCP 租約設置為在 1 小時後到期。有趣的是，心跳消息的這種超時經常發生（如果發生，並非總是如此）大約 1 小時後，我製作了我從中恢復的初始快照。我的問題是否與虛擬機突然處於不再具有初始 IP 的狀態的 DHCP 租約更新程序有關？例如，我打開到 192.168.122.128 的 gRPC 連接，獲取心跳消息，突然由於 DHCP 租約到期，IP 被更改，gRPC 無法傳遞任何進一步的消息？如果這可能是問題，我該怎麼做呢？
我還執行了一個自定義測試，在其中打開與 VM 的 gRPC 連接，然後手動更改 VM 上的 IP 地址，然後將其更改回其原始 IP。然後我觀察到完全相同的行為：3 分鐘後出現超時異常，因為在手動更改後不再收到心跳消息。所以我有一種強烈的感覺，VM 上的 IP 以某種方式發生了變化，這可能與到期的 DHCP 租約有關，這會干擾 gRPC 連接。
這可能是問題所在，還是完全不同的東西導致 gRPC 連接出現問題？我能做些什麼來解決這個問題？任何幫助或進一步闡述表示讚賞。
我很確定 gRPC 卡住的大多數情況都可以追溯到 DHCP 租用時間續訂。我還懷疑，一般來說，當 DHCP 伺服器在任何時間點都無法訪問時，gRPC 連接就會卡住（我通過手動設置系統時間並
ipconfig /renew從命令行呼叫對此進行了測試。然後我首先得到了 DHCP 超時但是之後它工作了。但結果 gRPC 被卡住了，即使我再次獲得了相同的 IP）。由於我仍然不完全了解 DHCP 租約續訂的行為以及有關查詢 DHCP 伺服器及其超時的一般情況，因此我決定不再擺弄它。我決定為我的 VM 快照使用靜態 IP（禁用 DHCP）。如果有人遇到同樣的問題，您可能想嘗試一下。希望能幫助到你。