Difference between revisions of "VETH device"

From CRIU
Jump to navigation Jump to search
m (add to external cat)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
When you restore a net namespace with a VETH device end in it, CRIU will create the other end of the pair in the net namespace you launch CRIU from. By default its name will be the one generated by the veth kernel driver. Not to scan through all the net devices trying to find one, you can use the --external option (<code>opts.external</code> field in [[RPC]]) in the form <code>--external veth[NAME]:HOSTNAME{@BRIDGE}</code> (the <code>@BRIDGE</code> part is optional). When used a device named <code>''NAME''</code> in a newly restored namespace will be linked with the <code>''HOSTNAME''</code> one in the CRIU namespace and optionally the host-side device will be adder to the <code>''BRIDGE''</code> bridge device.
+
== Checkpoint ==
  
== Old days ==
+
VETH is an interconnected pair of devices in two different network namespace. With CRIU, you can checkpoint a network namespace with an VETH device in it (called "inner" device) doesn't require any special options for CRIU. Upon checkpoint, information about the inner VETH device is saved to [[images]], when this device dies (together with the containing namespace), and the other end (called "outer" device) dies instantly, too, for the lack of peer.
  
For now CRIU the same functionality was controlled with the <code>--veth-pair NAME=HOSTNAME[@BRIDGE]</code> option and <code>opts.veths</code> [[RPC]] field. Soon this option will be [[deprecation|deprecated]].
+
== Restore ==
 +
 
 +
When you restore a net namespace with a VETH device end in it, CRIU creates a VETH pair automatically. By default, the outer device name is autogenerated by the kernel, which is not convenient. Option <code>--external</code> (or [[RPC]] equivalent field <code>opts.external</code>) can be used to set that name explicitly.
 +
 
 +
The syntax is <code>--external veth[''inner_dev'']:''outer_dev''@''bridge''</code>, with the <code>@''bridge''</code> part being optional. Here ''inner_dev'' is an "inner" VETH device name, and ''outer_dev'' is the "outer" VETH device name. If <code>@''bridge''</code> is specified, the ''outer_dev'' device is added to that bridge.
 +
 
 +
== Obsoleted option ==
 +
 
 +
Option <code>--veth-pair ''inner_dev''=''outer_dev''[@''bridge'']</code> (or corresponding [[RPC]] field <code>opts.veths</code>) was used in old versions of CRIU for the same effect as <code>--external veth</code>. This option is now obsolete and will be [[deprecation|deprecated]] soon.
  
 
[[Category: HOWTO]]
 
[[Category: HOWTO]]
 
[[Category: API]]
 
[[Category: API]]
 
[[Category: Network]]
 
[[Category: Network]]
 +
[[Category: External]]

Latest revision as of 01:09, 2 November 2016

Checkpoint[edit]

VETH is an interconnected pair of devices in two different network namespace. With CRIU, you can checkpoint a network namespace with an VETH device in it (called "inner" device) doesn't require any special options for CRIU. Upon checkpoint, information about the inner VETH device is saved to images, when this device dies (together with the containing namespace), and the other end (called "outer" device) dies instantly, too, for the lack of peer.

Restore[edit]

When you restore a net namespace with a VETH device end in it, CRIU creates a VETH pair automatically. By default, the outer device name is autogenerated by the kernel, which is not convenient. Option --external (or RPC equivalent field opts.external) can be used to set that name explicitly.

The syntax is --external veth[inner_dev]:outer_dev@bridge, with the @bridge part being optional. Here inner_dev is an "inner" VETH device name, and outer_dev is the "outer" VETH device name. If @bridge is specified, the outer_dev device is added to that bridge.

Obsoleted option[edit]

Option --veth-pair inner_dev=outer_dev[@bridge] (or corresponding RPC field opts.veths) was used in old versions of CRIU for the same effect as --external veth. This option is now obsolete and will be deprecated soon.