Skip to content

Commit a0e3945

Browse files
andrewlabchalios
authored andcommitted
Adding documentation and changelog
Documenting the ability to rename network interfaces on snapshot restore. Signed-off-by: Andrew Laucius <[email protected]> Signed-off-by: Babis Chalios <[email protected]>
1 parent b4290d4 commit a0e3945

File tree

2 files changed

+61
-0
lines changed

2 files changed

+61
-0
lines changed

CHANGELOG.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,8 @@ and this project adheres to
1212

1313
- [#5065](https://github.com/firecracker-microvm/firecracker/pull/5065) Added
1414
support for Intel AMX (Advanced Matrix Extensions).
15+
- [#4731](https://github.com/firecracker-microvm/firecracker/pull/4731): Added
16+
support for modifying the host TAP device name during snapshot restore.
1517

1618
### Changed
1719

docs/snapshotting/network-for-clones.md

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -142,6 +142,65 @@ Otherwise, packets originating from the guest might be using old Link Layer
142142
Address for up to arp cache timeout seconds. After said timeout period,
143143
connectivity 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, 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 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+
"enable_diff_snapshots": true,
171+
"resume_vm": false,
172+
"network_overrides": [
173+
{
174+
iface_id: "eth0",
175+
host_dev_name": "vmtap01"
176+
}
177+
]
178+
}'
179+
```
180+
181+
This may require reconfiguration of the networking inside the VM so that it is
182+
still routable externally. The
183+
[network setup documentation](../network-setup.md) in the "In The Guest" section
184+
describes what the typical setup is. If you are not using network namespaces or
185+
the jailer, then the guest will have to be made aware (via vsock or other
186+
channel) that it needs to reconfigure its network to match the network
187+
configured on the tap device.
188+
189+
If the new TAP device, say `vmtap3` has been configured to use a guest address
190+
of `172.16.3.2` then after snapshot restore you would run something like:
191+
192+
```bash
193+
# In the guest
194+
195+
# Clear out the previous addr and route
196+
ip addr flush dev eth0
197+
ip route flush dev eth0
198+
199+
# Configure the new address
200+
ip addr add 172.16.3.2/30 dev eth0
201+
ip route add defaul via 172.16.3.1/30 dev eth0
202+
```
203+
145204
# Ingress connectivity
146205

147206
The above setup only provides egress connectivity. If in addition we also want

0 commit comments

Comments
 (0)