@@ -142,6 +142,38 @@ Otherwise, packets originating from the guest might be using old Link Layer
142
142
Address for up to arp cache timeout seconds. After said timeout period,
143
143
connectivity will work both ways even without an explicit flush.
144
144
145
+ ### Renaming host device names
146
+
147
+ In some environments where the jailer is not being used, restoring a snapshot
148
+ may be tricky because the tap device on the host will not be the same as the tap
149
+ device that the original VM was mapped to when it was snapshotted, as when the
150
+ tap device come from a pool of such devices.
151
+
152
+ In this case you can use the ` network_overrides ` parameter to snapshot restore
153
+ to specify which network device (based on the name inside the VM, such as
154
+ "eth0") maps to which host tap device (e.g. "vmtap01").
155
+
156
+ This may require reconfiguration of the networking inside the VM so that it is
157
+ still routable externally. The [ network setup documentation] ( ../network-setup.md )
158
+ in the "In The Guest" section describes what the typical setup is. If you are
159
+ not using network namespaces or the jailer, then the guest will have to be
160
+ made aware (via vsock or other channel) that it needs to reconfigure its
161
+ network to match the network configured on the tap device.
162
+
163
+ If the new TAP device, say ` vmtap3 ` has been configured to use a guest address
164
+ of ` 172.16.3.2 ` then after snapshot restore you would run something like:
165
+
166
+ ``` bash
167
+ # Clear out the previous addr and route
168
+ ip addr flush dev eth0
169
+ ip route flush dev eth0
170
+
171
+ # Configure the new address
172
+ ip addr add 172.16.3.2/30 dev eth0
173
+ ip route add defaul via 172.16.3.1/30 dev eth0
174
+ ```
175
+
176
+
145
177
# Ingress connectivity
146
178
147
179
The above setup only provides egress connectivity. If in addition we also want
0 commit comments