@@ -142,6 +142,63 @@ Otherwise, packets originating from the guest might be using old Link Layer
142142Address for up to arp cache timeout seconds. After said timeout period,
143143connectivity will work both ways even without an explicit flush.
144144
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, for example
150+ when the tap device comes from a pool of such devices.
151+ 
152+ In this case you can use the ` network_overrides `  parameter of the snapshot
153+ restore API to specify which guest network device maps to which host tap device.
154+ 
155+ For example, if we have a network interface named ` eth0 `  in the snapshotted
156+ microVM, we can override it to point to the host device ` vmtap01 `  during
157+ snapshot resume, like this:
158+ 
159+ ``` bash 
160+ curl --unix-socket /tmp/firecracker.socket -i \
161+     -X PUT ' http://localhost/snapshot/load'   \
162+     -H  ' Accept: application/json'   \
163+     -H  ' Content-Type: application/json'   \
164+     -d ' {
165+             "snapshot_path": "./snapshot_file", 
166+             "mem_backend": { 
167+                 "backend_path": "./mem_file", 
168+                 "backend_type": "File" 
169+             }, 
170+             "network_overrides": [ 
171+                  { 
172+                      "iface_id": "eth0", 
173+                      "host_dev_name": "vmtap01" 
174+                  } 
175+             ] 
176+     }'  
177+ ``` 
178+ 
179+ This may require reconfiguration of the networking inside the VM so that it is
180+ still routable externally.
181+ [ network setup documentation] ( ../network-setup.md#in-the-guest )  describes what
182+ the typical setup is. If you are not using network namespaces or the jailer,
183+ then the guest will have to be made aware (via vsock or other channel) that it
184+ needs to reconfigure its network to match the network configured on the tap
185+ device.
186+ 
187+ If the new TAP device, say ` vmtap3 `  has been configured to use a guest address
188+ of ` 172.16.3.2 `  then after snapshot restore you would run something like:
189+ 
190+ ``` bash 
191+ #  In the guest
192+ 
193+ #  Clear out the previous addr and route
194+ ip addr flush dev eth0
195+ ip route flush dev eth0
196+ 
197+ #  Configure the new address
198+ ip addr add 172.16.3.2/30 dev eth0
199+ ip route add default via 172.16.3.1/30 dev eth0
200+ ``` 
201+ 
145202# Ingress connectivity  
146203
147204The above setup only provides egress connectivity. If in addition we also want
0 commit comments