Skip to content

Commit 97838cb

Browse files
committed
Adding documentation and changelog
Documenting the ability to rename network interfaces on snapshot restore. Signed-off-by: Andrew Laucius <[email protected]>
1 parent c667e03 commit 97838cb

File tree

2 files changed

+37
-0
lines changed

2 files changed

+37
-0
lines changed

CHANGELOG.md

+5
Original file line numberDiff line numberDiff line change
@@ -102,15 +102,20 @@ and this project adheres to
102102
Support for VMGenID via DeviceTree bindings exists only on mainline 6.10 Linux
103103
onwards. Users of Firecracker will need to backport the relevant patches on
104104
top of their 6.1 kernels to make use of the feature.
105+
105106
- [#4732](https://github.com/firecracker-microvm/firecracker/pull/4732),
106107
[#4733](https://github.com/firecracker-microvm/firecracker/pull/4733),
107108
[#4741](https://github.com/firecracker-microvm/firecracker/pull/4741),
108109
[#4746](https://github.com/firecracker-microvm/firecracker/pull/4746): Added
109110
official support for 6.1 microVM guest kernels.
111+
110112
- [#4743](https://github.com/firecracker-microvm/firecracker/pull/4743): Added
111113
support for `-h` help flag to the Jailer. The Jailer will now print the help
112114
message with either `--help` or `-h`.
113115

116+
- [#4731](https://github.com/firecracker-microvm/firecracker/pull/4731): Added
117+
support for modifying the host TAP device name during snapshot restore.
118+
114119
### Changed
115120

116121
### Deprecated

docs/snapshotting/network-for-clones.md

+32
Original file line numberDiff line numberDiff line change
@@ -142,6 +142,38 @@ 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 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
158+
[network setup documentation](../network-setup.md) in the "In The Guest" section
159+
describes what the typical setup is. If you are not using network namespaces or
160+
the jailer, then the guest will have to be made aware (via vsock or other
161+
channel) that it needs to reconfigure its network to match the network
162+
configured on the tap device.
163+
164+
If the new TAP device, say `vmtap3` has been configured to use a guest address
165+
of `172.16.3.2` then after snapshot restore you would run something like:
166+
167+
```bash
168+
# Clear out the previous addr and route
169+
ip addr flush dev eth0
170+
ip route flush dev eth0
171+
172+
# Configure the new address
173+
ip addr add 172.16.3.2/30 dev eth0
174+
ip route add defaul via 172.16.3.1/30 dev eth0
175+
```
176+
145177
# Ingress connectivity
146178

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

0 commit comments

Comments
 (0)