Python API¶

Connects to the minimega instance with UNIX socket at . If is set, the Python APIs will raise an Exception whenever minimega returns a response with an error. If is set, debugging information will be printed. The parameter allows you to "bind" the minimega object to a particular namespace (see help(minimega.minimega.namespace) for more info on namespaces).

Variants: args

Displays the CLI arguments minimega is using to run. If an argument was not set by CLI, the default value is displayed.

Variants: background ...

Execute a command under the credentials of the running user.

Commands run in the background and control returns immediately. Any output is logged at the "info" level.

Variants: background-error

Get the standard error of a background command.

    background-error <id>

Variants: background-output

Get the standard output of a background command.

    background-output <id>

Variants: background-status background-status

Get the status of a background command / commands.

To get the status of all background commands run

    background-status

To get the status of a specific command, run

    background-status [id]

Variants: bridge

When called with no arguments, display information about all managed bridges.

To add a trunk interface to a specific bridge, use 'bridge trunk'. For example, to add interface bar to bridge foo:

    bridge trunk foo bar

To create a vxlan or GRE tunnel to another bridge, use 'bridge tunnel'. For example, to create a vxlan tunnel to another bridge with IP 10.0.0.1:

    bridge tunnel vxlan mega_bridge 10.0.0.1

Note: bridge is not a namespace-aware command.

Variants: bridge config

When called with no arguments, display information about all managed bridges.

To add a trunk interface to a specific bridge, use 'bridge trunk'. For example, to add interface bar to bridge foo:

    bridge trunk foo bar

To create a vxlan or GRE tunnel to another bridge, use 'bridge tunnel'. For example, to create a vxlan tunnel to another bridge with IP 10.0.0.1:

    bridge tunnel vxlan mega_bridge 10.0.0.1

Note: bridge is not a namespace-aware command.

Variants: bridge destroy

When called with no arguments, display information about all managed bridges.

To add a trunk interface to a specific bridge, use 'bridge trunk'. For example, to add interface bar to bridge foo:

    bridge trunk foo bar

To create a vxlan or GRE tunnel to another bridge, use 'bridge tunnel'. For example, to create a vxlan tunnel to another bridge with IP 10.0.0.1:

    bridge tunnel vxlan mega_bridge 10.0.0.1

Note: bridge is not a namespace-aware command.

Variants: bridge notrunk

When called with no arguments, display information about all managed bridges.

To add a trunk interface to a specific bridge, use 'bridge trunk'. For example, to add interface bar to bridge foo:

    bridge trunk foo bar

To create a vxlan or GRE tunnel to another bridge, use 'bridge tunnel'. For example, to create a vxlan tunnel to another bridge with IP 10.0.0.1:

    bridge tunnel vxlan mega_bridge 10.0.0.1

Note: bridge is not a namespace-aware command.

Variants: bridge notunnel

When called with no arguments, display information about all managed bridges.

To add a trunk interface to a specific bridge, use 'bridge trunk'. For example, to add interface bar to bridge foo:

    bridge trunk foo bar

To create a vxlan or GRE tunnel to another bridge, use 'bridge tunnel'. For example, to create a vxlan tunnel to another bridge with IP 10.0.0.1:

    bridge tunnel vxlan mega_bridge 10.0.0.1

Note: bridge is not a namespace-aware command.

Variants: bridge trunk

When called with no arguments, display information about all managed bridges.

To add a trunk interface to a specific bridge, use 'bridge trunk'. For example, to add interface bar to bridge foo:

    bridge trunk foo bar

To create a vxlan or GRE tunnel to another bridge, use 'bridge tunnel'. For example, to create a vxlan tunnel to another bridge with IP 10.0.0.1:

    bridge tunnel vxlan mega_bridge 10.0.0.1

Note: bridge is not a namespace-aware command.

Variants: bridge tunnel bridge tunnel

When called with no arguments, display information about all managed bridges.

To add a trunk interface to a specific bridge, use 'bridge trunk'. For example, to add interface bar to bridge foo:

    bridge trunk foo bar

To create a vxlan or GRE tunnel to another bridge, use 'bridge tunnel'. For example, to create a vxlan tunnel to another bridge with IP 10.0.0.1:

    bridge tunnel vxlan mega_bridge 10.0.0.1

Note: bridge is not a namespace-aware command.

Variants: capture

show active captures

Variants: capture netflow bridge capture netflow bridge

Note: the capture API is not fully namespace-aware and should be used with caution. See notes below.

Capture experiment data including netflow and PCAP. Netflow capture obtains netflow data from any local openvswitch switch, and can write to file, another socket, or both. Netflow data can be written out in raw or ascii format, and file output can be compressed on the fly. Multiple netflow writers can be configured. There are several APIs to configure new netflow captures:

    capture netflow mode [raw,ascii]
    capture netflow gzip [true,false]
    capture netflow timeout [timeout]

PCAP capture can be from a bridge or VM interface. To set the snaplen or filter for new PCAP captures, use:

    capture pcap snaplen <size>
    capture pcap filter <bpf>

Examples:

    # Capture netflow for mega_bridge to foo.netflow
    capture netflow bridge mega_bridge foo.netflow

    # Capture all bridge foo traffic to foo.pcap
    capture pcap bridge foo foo.pcap

    # Capture the 0-th interface for VM foo to foo.pcap
    capture pcap vm foo 0 foo.pcap

When run without arguments, capture prints all running captures. To stop a capture, use the delete commands:

    capture netflow delete bridge <bridge>
    capture pcap delete bridge <bridge>
    capture pcap delete vm <name>
    capture pcap delete vm <name> <interface index>

To stop all captures of a particular kind, replace or with "all". If a VM has multiple interfaces and there are multiple captures running, calling "capture pcap delete vm " stops all the captures for that VM. To stop only the capture for a single interface, specify the interface index, e.g. "capture pcap delete vm 0" stops the capture for interface 0 without affecting captures on other interfaces of the same VM. To stop all captures of all types, use "clear capture".

Notes with namespaces: * Capturing traffic directly from the bridge (as PCAP or netflow) is not recommended if different namespaces share the same bridge. If this is the case, the captured traffic would contain data from across namespaces. * Due to the way Open vSwitch implements netflow, there can be only one netflow object per bridge. This means that the netflow timeout is shared across namespaces. Additionally, note that the API is also not bridge-specific.

Due to the above intricacies, the following commands only run on the local minimega instance:

    capture <netflow,> <bridge,> <bridge> <filename>
    capture <netflow,> <bridge,> <bridge> <tcp,udp> <hostname:port>
    capture <netflow,> <delete,> bridge <name>
    capture <netflow,> <timeout,> [timeout in seconds]
    capture <pcap,> bridge <bridge> <filename>
    capture <pcap,> <delete,> bridge <name>

Variants: capture netflow delete bridge

Note: the capture API is not fully namespace-aware and should be used with caution. See notes below.

Capture experiment data including netflow and PCAP. Netflow capture obtains netflow data from any local openvswitch switch, and can write to file, another socket, or both. Netflow data can be written out in raw or ascii format, and file output can be compressed on the fly. Multiple netflow writers can be configured. There are several APIs to configure new netflow captures:

    capture netflow mode [raw,ascii]
    capture netflow gzip [true,false]
    capture netflow timeout [timeout]

PCAP capture can be from a bridge or VM interface. To set the snaplen or filter for new PCAP captures, use:

    capture pcap snaplen <size>
    capture pcap filter <bpf>

Examples:

    # Capture netflow for mega_bridge to foo.netflow
    capture netflow bridge mega_bridge foo.netflow

    # Capture all bridge foo traffic to foo.pcap
    capture pcap bridge foo foo.pcap

    # Capture the 0-th interface for VM foo to foo.pcap
    capture pcap vm foo 0 foo.pcap

When run without arguments, capture prints all running captures. To stop a capture, use the delete commands:

    capture netflow delete bridge <bridge>
    capture pcap delete bridge <bridge>
    capture pcap delete vm <name>
    capture pcap delete vm <name> <interface index>

To stop all captures of a particular kind, replace or with "all". If a VM has multiple interfaces and there are multiple captures running, calling "capture pcap delete vm " stops all the captures for that VM. To stop only the capture for a single interface, specify the interface index, e.g. "capture pcap delete vm 0" stops the capture for interface 0 without affecting captures on other interfaces of the same VM. To stop all captures of all types, use "clear capture".

Notes with namespaces: * Capturing traffic directly from the bridge (as PCAP or netflow) is not recommended if different namespaces share the same bridge. If this is the case, the captured traffic would contain data from across namespaces. * Due to the way Open vSwitch implements netflow, there can be only one netflow object per bridge. This means that the netflow timeout is shared across namespaces. Additionally, note that the API is also not bridge-specific.

Due to the above intricacies, the following commands only run on the local minimega instance:

    capture <netflow,> <bridge,> <bridge> <filename>
    capture <netflow,> <bridge,> <bridge> <tcp,udp> <hostname:port>
    capture <netflow,> <delete,> bridge <name>
    capture <netflow,> <timeout,> [timeout in seconds]
    capture <pcap,> bridge <bridge> <filename>
    capture <pcap,> <delete,> bridge <name>

Variants: capture netflow gzip capture netflow gzip

configure captures

Variants: capture netflow mode capture netflow mode

configure captures

Variants: capture netflow timeout capture netflow timeout

Note: the capture API is not fully namespace-aware and should be used with caution. See notes below.

Capture experiment data including netflow and PCAP. Netflow capture obtains netflow data from any local openvswitch switch, and can write to file, another socket, or both. Netflow data can be written out in raw or ascii format, and file output can be compressed on the fly. Multiple netflow writers can be configured. There are several APIs to configure new netflow captures:

    capture netflow mode [raw,ascii]
    capture netflow gzip [true,false]
    capture netflow timeout [timeout]

PCAP capture can be from a bridge or VM interface. To set the snaplen or filter for new PCAP captures, use:

    capture pcap snaplen <size>
    capture pcap filter <bpf>

Examples:

    # Capture netflow for mega_bridge to foo.netflow
    capture netflow bridge mega_bridge foo.netflow

    # Capture all bridge foo traffic to foo.pcap
    capture pcap bridge foo foo.pcap

    # Capture the 0-th interface for VM foo to foo.pcap
    capture pcap vm foo 0 foo.pcap

When run without arguments, capture prints all running captures. To stop a capture, use the delete commands:

    capture netflow delete bridge <bridge>
    capture pcap delete bridge <bridge>
    capture pcap delete vm <name>
    capture pcap delete vm <name> <interface index>

To stop all captures of a particular kind, replace or with "all". If a VM has multiple interfaces and there are multiple captures running, calling "capture pcap delete vm " stops all the captures for that VM. To stop only the capture for a single interface, specify the interface index, e.g. "capture pcap delete vm 0" stops the capture for interface 0 without affecting captures on other interfaces of the same VM. To stop all captures of all types, use "clear capture".

Notes with namespaces: * Capturing traffic directly from the bridge (as PCAP or netflow) is not recommended if different namespaces share the same bridge. If this is the case, the captured traffic would contain data from across namespaces. * Due to the way Open vSwitch implements netflow, there can be only one netflow object per bridge. This means that the netflow timeout is shared across namespaces. Additionally, note that the API is also not bridge-specific.

Due to the above intricacies, the following commands only run on the local minimega instance:

    capture <netflow,> <bridge,> <bridge> <filename>
    capture <netflow,> <bridge,> <bridge> <tcp,udp> <hostname:port>
    capture <netflow,> <delete,> bridge <name>
    capture <netflow,> <timeout,> [timeout in seconds]
    capture <pcap,> bridge <bridge> <filename>
    capture <pcap,> <delete,> bridge <name>

Variants: capture pcap bridge

Note: the capture API is not fully namespace-aware and should be used with caution. See notes below.

Capture experiment data including netflow and PCAP. Netflow capture obtains netflow data from any local openvswitch switch, and can write to file, another socket, or both. Netflow data can be written out in raw or ascii format, and file output can be compressed on the fly. Multiple netflow writers can be configured. There are several APIs to configure new netflow captures:

    capture netflow mode [raw,ascii]
    capture netflow gzip [true,false]
    capture netflow timeout [timeout]

PCAP capture can be from a bridge or VM interface. To set the snaplen or filter for new PCAP captures, use:

    capture pcap snaplen <size>
    capture pcap filter <bpf>

Examples:

    # Capture netflow for mega_bridge to foo.netflow
    capture netflow bridge mega_bridge foo.netflow

    # Capture all bridge foo traffic to foo.pcap
    capture pcap bridge foo foo.pcap

    # Capture the 0-th interface for VM foo to foo.pcap
    capture pcap vm foo 0 foo.pcap

When run without arguments, capture prints all running captures. To stop a capture, use the delete commands:

    capture netflow delete bridge <bridge>
    capture pcap delete bridge <bridge>
    capture pcap delete vm <name>
    capture pcap delete vm <name> <interface index>

To stop all captures of a particular kind, replace or with "all". If a VM has multiple interfaces and there are multiple captures running, calling "capture pcap delete vm " stops all the captures for that VM. To stop only the capture for a single interface, specify the interface index, e.g. "capture pcap delete vm 0" stops the capture for interface 0 without affecting captures on other interfaces of the same VM. To stop all captures of all types, use "clear capture".

Notes with namespaces: * Capturing traffic directly from the bridge (as PCAP or netflow) is not recommended if different namespaces share the same bridge. If this is the case, the captured traffic would contain data from across namespaces. * Due to the way Open vSwitch implements netflow, there can be only one netflow object per bridge. This means that the netflow timeout is shared across namespaces. Additionally, note that the API is also not bridge-specific.

Due to the above intricacies, the following commands only run on the local minimega instance:

    capture <netflow,> <bridge,> <bridge> <filename>
    capture <netflow,> <bridge,> <bridge> <tcp,udp> <hostname:port>
    capture <netflow,> <delete,> bridge <name>
    capture <netflow,> <timeout,> [timeout in seconds]
    capture <pcap,> bridge <bridge> <filename>
    capture <pcap,> <delete,> bridge <name>

Variants: capture pcap delete bridge

Note: the capture API is not fully namespace-aware and should be used with caution. See notes below.

Capture experiment data including netflow and PCAP. Netflow capture obtains netflow data from any local openvswitch switch, and can write to file, another socket, or both. Netflow data can be written out in raw or ascii format, and file output can be compressed on the fly. Multiple netflow writers can be configured. There are several APIs to configure new netflow captures:

    capture netflow mode [raw,ascii]
    capture netflow gzip [true,false]
    capture netflow timeout [timeout]

PCAP capture can be from a bridge or VM interface. To set the snaplen or filter for new PCAP captures, use:

    capture pcap snaplen <size>
    capture pcap filter <bpf>

Examples:

    # Capture netflow for mega_bridge to foo.netflow
    capture netflow bridge mega_bridge foo.netflow

    # Capture all bridge foo traffic to foo.pcap
    capture pcap bridge foo foo.pcap

    # Capture the 0-th interface for VM foo to foo.pcap
    capture pcap vm foo 0 foo.pcap

When run without arguments, capture prints all running captures. To stop a capture, use the delete commands:

    capture netflow delete bridge <bridge>
    capture pcap delete bridge <bridge>
    capture pcap delete vm <name>
    capture pcap delete vm <name> <interface index>

To stop all captures of a particular kind, replace or with "all". If a VM has multiple interfaces and there are multiple captures running, calling "capture pcap delete vm " stops all the captures for that VM. To stop only the capture for a single interface, specify the interface index, e.g. "capture pcap delete vm 0" stops the capture for interface 0 without affecting captures on other interfaces of the same VM. To stop all captures of all types, use "clear capture".

Notes with namespaces: * Capturing traffic directly from the bridge (as PCAP or netflow) is not recommended if different namespaces share the same bridge. If this is the case, the captured traffic would contain data from across namespaces. * Due to the way Open vSwitch implements netflow, there can be only one netflow object per bridge. This means that the netflow timeout is shared across namespaces. Additionally, note that the API is also not bridge-specific.

Due to the above intricacies, the following commands only run on the local minimega instance:

    capture <netflow,> <bridge,> <bridge> <filename>
    capture <netflow,> <bridge,> <bridge> <tcp,udp> <hostname:port>
    capture <netflow,> <delete,> bridge <name>
    capture <netflow,> <timeout,> [timeout in seconds]
    capture <pcap,> bridge <bridge> <filename>
    capture <pcap,> <delete,> bridge <name>

Variants: capture pcap delete vm capture pcap delete vm

capture experiment data for a VM

Variants: capture pcap filter capture pcap filter

configure captures

Variants: capture pcap snaplen capture pcap snaplen

configure captures

Variants: capture pcap vm

capture experiment data for a VM

Variants: cc

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc background ...

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc background-once ...

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc clients

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc commands

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc delete command

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc delete response

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc exec ...

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc exec-once ...

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc exitcode

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc filter ... cc filter

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc listen

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc log level

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc mount cc mount cc mount

list mounted filesystems

Variants: cc prefix cc prefix

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc process kill

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc process killall

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc process list

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc recv ...

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc responses cc responses

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc rtunnel

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc send ...

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc test-conn wait cc test-conn wait

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc tunnel

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc tunnel close

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: cc tunnel list

Command and control for VMs running the miniccc client. Commands may include regular commands, backgrounded commands, and any number of sent and/or received files. Commands will be executed in command creation order. For example, to send a file 'foo' and display the contents on a remote VM:

    cc send foo
    cc exec cat foo

Files to be sent must be in the filepath directory, as set by the -filepath flag when launching minimega.

Executed commands can have their stdio tied to pipes used by the plumb and pipe APIs. To use named pipes, simply specify stdin, stdout, or stderr as a key=value pair. For example:

    cc exec stderr=foo cat server.log
    cc background stdin=foo stdout=bar /usr/bin/program

Executed commands can also be marked to be sent to miniccc clients only once. This will prevent the command from being sent again if the client restarts (for example, after a reboot).

    cc exec-once shutdown -r now

Responses are organized in a structure within /miniccc_responses, and include subdirectories for each client response named by the client's UUID. Responses can also be displayed on the command line with the 'responses' command.

Responses to executed commands (not backgrounded) will include the command's exit code, which can be displayed with the 'exitcode' command.

Filters may be set to limit which clients may execute a posted command. For example, to filter on VMs that are running windows and have a specific IP.

    cc filter os=windows ip=10.0.0.1

Users can also filter by VM tags. For example, to filter on VMs that have the tag with key foo and value bar set:

    cc filter tag=foo:bar

If users wish, they may drop the tag= prefix and key=value pairs will be treated as tags:

    cc filter foo=bar

Users can also filter by any column in "vm info" using a similar syntax:

    cc filter name=server
    cc filter vlan=DMZ

"vm info" columns take precedence over tags when both define the same key.

"cc mount" allows direct access to a guest's filesystem over the command and control connection. When given a VM uuid or name and a path, the VM's filesystem is mounted to the local machine at the provided path. "cc mount" without arguments displays the existing mounts. Users can use "clear cc mount" to unmount the filesystem of one or all VMs. This should be done before killing or stopping the VM ("clear namespace " will handle this automatically).

"cc tunnel" allows users to tunnel TCP connections to a local port through a VM to a remote port. The local port will be created on the minimega cluster host that the tunneling VM is running on. The remote port can be on the same VM or on a different VM the tunneling VM has network access to.

"cc test-conn" allows users to test network connectivity from a guest to the given IP or domain name and port. The wait timeout should be specified as a Go duration string (e.g. 5s, 1m). If "udp" is used, a "base64 udp packet" that will generate a valid response must be specified. Results of the test will be written to the command's STDOUT file, whether it passed or failed. An example test is as follows:

    cc test-conn tcp 10.0.0.68 443 wait 10s

If the above test passes, STDOUT for the command will contain the following:

    10.0.0.68:443 | pass

If it fails, STDOUT will instead contain the following:

    10.0.0.68:443 | fail

For more documentation, see the article "Command and Control API Tutorial".

Variants: check

minimega maintains a list of external packages that it depends on, such as qemu. Calling check will attempt to find each of these executables in the available path and check to make sure they meet the minimum version requirements. Returns errors for all missing executables and all minimum versions not met.

Variants: clear all

Runs all the "clear ..." handlers on the local instance -- as close to nuke as you can get without restarting minimega. Restarting minimega is preferable.

Variants: clear background-status

Clear background-status information

Variants: clear capture clear capture

Resets state for captures across the namespace. See "help capture" for more information.

Variants: clear cc

Resets state for the command and control infrastructure provided by minimega. See "help cc" for more information.

Variants: clear cc commands

Resets state for the command and control infrastructure provided by minimega. See "help cc" for more information.

Variants: clear cc filter

Resets state for the command and control infrastructure provided by minimega. See "help cc" for more information.

Variants: clear cc mount clear cc mount

unmount VM filesystem

Variants: clear cc prefix

Resets state for the command and control infrastructure provided by minimega. See "help cc" for more information.

Variants: clear cc responses

Resets state for the command and control infrastructure provided by minimega. See "help cc" for more information.

Variants: clear deploy flags

Reset the deploy flags to their default value, which is equal to the launch flags used when launching minimega.

Variants: clear history

Reset the command history. See "help history" for more information.

Variants: clear log

Resets state for logging. See "help log ..." for more information.

Variants: clear log file

Resets state for logging. See "help log ..." for more information.

Variants: clear log filter

Resets state for logging. See "help log ..." for more information.

Variants: clear log level

Resets state for logging. See "help log ..." for more information.

Variants: clear log mesh

Resets state for logging. See "help log ..." for more information.

Variants: clear log ring

Resets state for logging. See "help log ..." for more information.

Variants: clear log stderr

Resets state for logging. See "help log ..." for more information.

Variants: clear log syslog

Resets state for logging. See "help log ..." for more information.

Variants: clear optimize

Resets state for virtualization optimizations. See "help optimize" for more information.

Variants: clear optimize affinity clear optimize affinity

Resets state for virtualization optimizations. See "help optimize" for more information.

Variants: clear optimize hugepages

Resets state for virtualization optimizations. See "help optimize" for more information.

Variants: clear optimize ksm

Resets state for virtualization optimizations. See "help optimize" for more information.

Variants: clear pipe clear pipe

reset pipe state

Variants: clear pipe log

reset pipe state

Variants: clear pipe mode

reset pipe state

Variants: clear pipe via

reset pipe state

Variants: clear plumb ... clear plumb

reset plumber state

Variants: clear qos clear qos

Remove QoS constraints from a VM's interface. To clear QoS from all interfaces for a VM, use the wildcard:

    clear qos foo all

See "vm start" for a full description of allowable targets.

Variants: clear router clear router

Variants: clear router dhcp clear router dhcp

Variants: clear router dhcp dns

Variants: clear router dhcp range

Variants: clear router dhcp router

Variants: clear router dhcp static clear router dhcp static

Variants: clear router dns clear router dns

Variants: clear router fw

Variants: clear router gw

Variants: clear router interface clear router interface clear router interface clear router interface

Variants: clear router ra clear router ra

Variants: clear router rid

Variants: clear router route clear router route

Variants: clear router route bgp clear router route bgp

Variants: clear router route bgp rrclient

Variants: clear router route ospf clear router route ospf clear router route ospf

Variants: clear router route ospf export

Variants: clear router route static clear router route static

Variants: clear router upstream

Variants: clear tap

Reset state for taps. To delete individual taps, use "tap delete".

"clear tap mirror" can be used to delete one or all mirrors. Mirrors are identified by the destination for the mirror since a source can have multiple mirrors. "clear tap" also deletes all mirrors.

Only affects taps on the local node.

Variants: clear tap mirror clear tap mirror clear tap mirror

Reset state for taps. To delete individual taps, use "tap delete".

"clear tap mirror" can be used to delete one or all mirrors. Mirrors are identified by the destination for the mirror since a source can have multiple mirrors. "clear tap" also deletes all mirrors.

Only affects taps on the local node.

Variants: clear vlans clear vlans

Clear one or more aliases, freeing the VLANs for reuse. You should only clear allocated VLANs once you have killed all the VMs connected to them.

By default, "clear vlans" only clears aliases for the current namespace. If given "all" as the prefix, all state about managed VLANs is cleared across all namespaces, including blacklisted VLANS. You should only use this if you want a completely clean slate.

Variants: clear vm config

reset one or more configurations to default value

Variants: clear vm config android-adb

reset one or more configurations to default value

Variants: clear vm config android-avd

reset one or more configurations to default value

Variants: clear vm config android-avd-dir

reset one or more configurations to default value

Variants: clear vm config android-console-base-port

reset one or more configurations to default value

Variants: clear vm config android-emulator

reset one or more configurations to default value

Variants: clear vm config android-extra-args

reset one or more configurations to default value

Variants: clear vm config android-no-window

reset one or more configurations to default value

Variants: clear vm config android-sdk

reset one or more configurations to default value

Variants: clear vm config android-writable-system

reset one or more configurations to default value

Variants: clear vm config append

reset one or more configurations to default value

Variants: clear vm config backchannel

reset one or more configurations to default value

Variants: clear vm config baremetal

reset one or more configurations to default value

Variants: clear vm config baremetal-network-driver

reset one or more configurations to default value

Variants: clear vm config bidirectional-copy-paste

reset one or more configurations to default value

Variants: clear vm config bonds

reset one or more configurations to default value

Variants: clear vm config cdrom

reset one or more configurations to default value

Variants: clear vm config colocate

reset one or more configurations to default value

Variants: clear vm config cores

reset one or more configurations to default value

Variants: clear vm config coschedule

reset one or more configurations to default value

Variants: clear vm config cpu

reset one or more configurations to default value

Variants: clear vm config disks

reset one or more configurations to default value

Variants: clear vm config fifos

reset one or more configurations to default value

Variants: clear vm config filesystem

reset one or more configurations to default value

Variants: clear vm config hostname

reset one or more configurations to default value

Variants: clear vm config init

reset one or more configurations to default value

Variants: clear vm config initrd

reset one or more configurations to default value

Variants: clear vm config kernel

reset one or more configurations to default value

Variants: clear vm config machine

reset one or more configurations to default value

Variants: clear vm config memory

reset one or more configurations to default value

Variants: clear vm config migrate

reset one or more configurations to default value

Variants: clear vm config networks

reset one or more configurations to default value

Variants: clear vm config preinit

reset one or more configurations to default value

Variants: clear vm config qemu

reset one or more configurations to default value

Variants: clear vm config qemu-append

reset one or more configurations to default value

Variants: clear vm config qemu-override

reset one or more configurations to default value

Variants: clear vm config schedule

reset one or more configurations to default value

Variants: clear vm config serial-ports

reset one or more configurations to default value

Variants: clear vm config snapshot

reset one or more configurations to default value

Variants: clear vm config sockets

reset one or more configurations to default value

Variants: clear vm config state

reset one or more configurations to default value

Variants: clear vm config tag

Remove tags in the same manner as "clear vm tag".

Variants: clear vm config tags

reset one or more configurations to default value

Variants: clear vm config threads

reset one or more configurations to default value

Variants: clear vm config tpm-socket

reset one or more configurations to default value

Variants: clear vm config usb-use-xhci

reset one or more configurations to default value

Variants: clear vm config uuid

reset one or more configurations to default value

Variants: clear vm config vcpus

reset one or more configurations to default value

Variants: clear vm config vga

reset one or more configurations to default value

Variants: clear vm config virtio-ports

reset one or more configurations to default value

Variants: clear vm config volume

reset one or more configurations to default value

Variants: clear vm net bond clear vm net bond

remove net bonds from a VM

Variants: clear vm tag clear vm tag clear vm tag

Clears one, many, or all tags from a virtual machine.

Clear the tag "foo" from VM 0:

    clear vm tag 0 foo

Clear the tag "foo" from all VMs:

    clear vm tag all foo

Clear all tags from VM 0:

    clear vm tag 0

Clear all tags from all VMs:

    clear vm tag all

Variants: clear vnc

Resets the state for VNC recordings. See "help vnc" for more information.

Variants: debug

debug can help find and resolve issues with minimega. Without arguments, debug prints the go version, the number of goroutines, and the number of cgo calls.

With arguments, debug writes files that can be read using "go tool pprof":

• memory: sampling of all heap allocations
• cpu: starts CPU profiling (must be stopped before read)
• goroutine: stack traces of all current goroutines

Variants: debug cpu start

debug can help find and resolve issues with minimega. Without arguments, debug prints the go version, the number of goroutines, and the number of cgo calls.

With arguments, debug writes files that can be read using "go tool pprof":

• memory: sampling of all heap allocations
• cpu: starts CPU profiling (must be stopped before read)
• goroutine: stack traces of all current goroutines

Variants: debug cpu stop

debug can help find and resolve issues with minimega. Without arguments, debug prints the go version, the number of goroutines, and the number of cgo calls.

With arguments, debug writes files that can be read using "go tool pprof":

• memory: sampling of all heap allocations
• cpu: starts CPU profiling (must be stopped before read)
• goroutine: stack traces of all current goroutines

Variants: debug goroutine

debug can help find and resolve issues with minimega. Without arguments, debug prints the go version, the number of goroutines, and the number of cgo calls.

With arguments, debug writes files that can be read using "go tool pprof":

• memory: sampling of all heap allocations
• cpu: starts CPU profiling (must be stopped before read)
• goroutine: stack traces of all current goroutines

Variants: debug memory

debug can help find and resolve issues with minimega. Without arguments, debug prints the go version, the number of goroutines, and the number of cgo calls.

With arguments, debug writes files that can be read using "go tool pprof":

• memory: sampling of all heap allocations
• cpu: starts CPU profiling (must be stopped before read)
• goroutine: stack traces of all current goroutines

Variants: deploy flags ... deploy flags

deploy copies and runs minimega on remote nodes, facilitating the deployment of minimega to a cluster. By default, deploy will launch minimega with the same flags used when starting this minimega, and add the -nostdin flag so that the remote minimega can be backgrounded. For example, to launch minimega on nodes kn1 and kn2:

    deploy launch kn[1-2]

deploy uses scp/ssh to copy and run minimega. By default, minimega will attempt to login to remote nodes using the current user. This can be changed by providing a username. If using a different username, you can optionally specify the use of sudo when launching minimega (you typically need to run minimega as root).

In order to override the flags passed to remote minimega instances, provide flags with 'deploy flags'. For example:

    deploy flags -base=/opt/minimega -level=debug

To customize stdout and stderr, use 'deploy stdout' and 'deploy stderr':

    deploy stdout /var/log/minimega.out
    deploy stderr /var/log/minimega.err

By default, stdout and stderr are written to /dev/null.

Variants: deploy launch deploy launch deploy launch

deploy copies and runs minimega on remote nodes, facilitating the deployment of minimega to a cluster. By default, deploy will launch minimega with the same flags used when starting this minimega, and add the -nostdin flag so that the remote minimega can be backgrounded. For example, to launch minimega on nodes kn1 and kn2:

    deploy launch kn[1-2]

deploy uses scp/ssh to copy and run minimega. By default, minimega will attempt to login to remote nodes using the current user. This can be changed by providing a username. If using a different username, you can optionally specify the use of sudo when launching minimega (you typically need to run minimega as root).

In order to override the flags passed to remote minimega instances, provide flags with 'deploy flags'. For example:

    deploy flags -base=/opt/minimega -level=debug

To customize stdout and stderr, use 'deploy stdout' and 'deploy stderr':

    deploy stdout /var/log/minimega.out
    deploy stderr /var/log/minimega.err

By default, stdout and stderr are written to /dev/null.

Variants: deploy stderr deploy stderr

deploy copies and runs minimega on remote nodes, facilitating the deployment of minimega to a cluster. By default, deploy will launch minimega with the same flags used when starting this minimega, and add the -nostdin flag so that the remote minimega can be backgrounded. For example, to launch minimega on nodes kn1 and kn2:

    deploy launch kn[1-2]

deploy uses scp/ssh to copy and run minimega. By default, minimega will attempt to login to remote nodes using the current user. This can be changed by providing a username. If using a different username, you can optionally specify the use of sudo when launching minimega (you typically need to run minimega as root).

In order to override the flags passed to remote minimega instances, provide flags with 'deploy flags'. For example:

    deploy flags -base=/opt/minimega -level=debug

To customize stdout and stderr, use 'deploy stdout' and 'deploy stderr':

    deploy stdout /var/log/minimega.out
    deploy stderr /var/log/minimega.err

By default, stdout and stderr are written to /dev/null.

Variants: deploy stdout deploy stdout

deploy copies and runs minimega on remote nodes, facilitating the deployment of minimega to a cluster. By default, deploy will launch minimega with the same flags used when starting this minimega, and add the -nostdin flag so that the remote minimega can be backgrounded. For example, to launch minimega on nodes kn1 and kn2:

    deploy launch kn[1-2]

deploy uses scp/ssh to copy and run minimega. By default, minimega will attempt to login to remote nodes using the current user. This can be changed by providing a username. If using a different username, you can optionally specify the use of sudo when launching minimega (you typically need to run minimega as root).

In order to override the flags passed to remote minimega instances, provide flags with 'deploy flags'. For example:

    deploy flags -base=/opt/minimega -level=debug

To customize stdout and stderr, use 'deploy stdout' and 'deploy stderr':

    deploy stdout /var/log/minimega.out
    deploy stderr /var/log/minimega.err

By default, stdout and stderr are written to /dev/null.

Variants: disk commit

Commits the contents of 'image' to its backing file. 'image' is left unchanged, but may be deleted if not needed. Example of committing:

    disk commit myimage.qcow2

Variants: disk create

Creates a new qcow2 or raw disk of the specified size.

Example of creating a new disk:

    disk create qcow2 foo.qcow2 100G

The size argument is the size in bytes, or using optional suffixes "k" (kilobyte), "M" (megabyte), "G" (gigabyte), "T" (terabyte).

Variants: disk info disk info

Provides information about a disk such as format, virtual/actual size, and backing file. The 'recursive' flag can be set to print out full details for all backing images.

Variants: disk inject delete files ...

Injects files into a disk.

To inject files into an image:

    disk inject window7_miniccc.qc2 files "miniccc":"Program Files/miniccc"

Each argument after the image should be a source and destination pair, separated by a ':'. If the file paths contain spaces, use double quotes. Optionally, you may specify a partition (partition 1 will be used by default):

    disk inject window7_miniccc.qc2:2 files "miniccc":"Program Files/miniccc"

You may also specify that there is no partition on the disk, if your filesystem was directly written to the disk (this is highly unusual):

    disk inject partitionless_disk.qc2:none files /miniccc:/miniccc

You can optionally specify mount arguments to use with inject. Multiple options should be quoted. For example:

    disk inject foo.qcow2 options "-t fat -o offset=100" files foo:bar

To delete files or directories from an image, specify the delete keyword before listing the files or directories to delete from the image, separated by a comma. For example:

    disk inject window7_miniccc.qc2 delete files "Program Files/miniccc.exe"
    disk inject window7_miniccc.qc2 delete files "Users/Administrator/Documents/TestDir"
    disk inject window7_miniccc.qc2 delete files "foo.txt,Temp/bar.zip"

Variants: disk inject files ...

Injects files into a disk.

To inject files into an image:

    disk inject window7_miniccc.qc2 files "miniccc":"Program Files/miniccc"

Each argument after the image should be a source and destination pair, separated by a ':'. If the file paths contain spaces, use double quotes. Optionally, you may specify a partition (partition 1 will be used by default):

    disk inject window7_miniccc.qc2:2 files "miniccc":"Program Files/miniccc"

You may also specify that there is no partition on the disk, if your filesystem was directly written to the disk (this is highly unusual):

    disk inject partitionless_disk.qc2:none files /miniccc:/miniccc

You can optionally specify mount arguments to use with inject. Multiple options should be quoted. For example:

    disk inject foo.qcow2 options "-t fat -o offset=100" files foo:bar

To delete files or directories from an image, specify the delete keyword before listing the files or directories to delete from the image, separated by a comma. For example:

    disk inject window7_miniccc.qc2 delete files "Program Files/miniccc.exe"
    disk inject window7_miniccc.qc2 delete files "Users/Administrator/Documents/TestDir"
    disk inject window7_miniccc.qc2 delete files "foo.txt,Temp/bar.zip"

Variants: disk inject options delete files

Injects files into a disk.

To inject files into an image:

    disk inject window7_miniccc.qc2 files "miniccc":"Program Files/miniccc"

Each argument after the image should be a source and destination pair, separated by a ':'. If the file paths contain spaces, use double quotes. Optionally, you may specify a partition (partition 1 will be used by default):

    disk inject window7_miniccc.qc2:2 files "miniccc":"Program Files/miniccc"

You may also specify that there is no partition on the disk, if your filesystem was directly written to the disk (this is highly unusual):

    disk inject partitionless_disk.qc2:none files /miniccc:/miniccc

You can optionally specify mount arguments to use with inject. Multiple options should be quoted. For example:

    disk inject foo.qcow2 options "-t fat -o offset=100" files foo:bar

To delete files or directories from an image, specify the delete keyword before listing the files or directories to delete from the image, separated by a comma. For example:

    disk inject window7_miniccc.qc2 delete files "Program Files/miniccc.exe"
    disk inject window7_miniccc.qc2 delete files "Users/Administrator/Documents/TestDir"
    disk inject window7_miniccc.qc2 delete files "foo.txt,Temp/bar.zip"

Variants: disk inject options files

Injects files into a disk.

To inject files into an image:

    disk inject window7_miniccc.qc2 files "miniccc":"Program Files/miniccc"

Each argument after the image should be a source and destination pair, separated by a ':'. If the file paths contain spaces, use double quotes. Optionally, you may specify a partition (partition 1 will be used by default):

    disk inject window7_miniccc.qc2:2 files "miniccc":"Program Files/miniccc"

You may also specify that there is no partition on the disk, if your filesystem was directly written to the disk (this is highly unusual):

    disk inject partitionless_disk.qc2:none files /miniccc:/miniccc

You can optionally specify mount arguments to use with inject. Multiple options should be quoted. For example:

    disk inject foo.qcow2 options "-t fat -o offset=100" files foo:bar

To delete files or directories from an image, specify the delete keyword before listing the files or directories to delete from the image, separated by a comma. For example:

    disk inject window7_miniccc.qc2 delete files "Program Files/miniccc.exe"
    disk inject window7_miniccc.qc2 delete files "Users/Administrator/Documents/TestDir"
    disk inject window7_miniccc.qc2 delete files "foo.txt,Temp/bar.zip"

Variants: disk rebase disk rebase

Rebases the image 'image' onto a new backing file 'backing'. Using 'rebase' will write any differences between the original backing file and the new backing file to 'image'.

            disk rebase myimage.qcow2 base.qcow2

Alternatively, 'set-backing' can be used to change the backing file pointer without any changes to the images.

            disk set-backing myimage.qcow2 base.qcow2

The 'backing' argument can be omitted, causing all backing data to be written to 'image' making it independent.

            disk rebase myimage.qcow2

Users may use paths relative to the 'files' directory or absolute paths for inputs; however, the backing path will always be relative to the rebased image.

Variants: disk resize

Changes the size of a disk. IMPORTANT: Before shrinking an image, ensure changes have been made within the VM's OS to reduce the filesystem. Similarly, changes in the VM's OS will be required to grow the file system after increasing the disk size.

The size argument is the size in bytes, or using optional suffixes "k" (kilobyte), "M" (megabyte), "G" (gigabyte), "T" (terabyte).
It can be given as an absolute value or a relative +/- offset.

Examples:

    disk resize myimage.qcow2 50G
    disk resize myimage.qcow2 +512M

Variants: disk set-backing disk set-backing

Rebases the image 'image' onto a new backing file 'backing'. Using 'rebase' will write any differences between the original backing file and the new backing file to 'image'.

            disk rebase myimage.qcow2 base.qcow2

Alternatively, 'set-backing' can be used to change the backing file pointer without any changes to the images.

            disk set-backing myimage.qcow2 base.qcow2

The 'backing' argument can be omitted, causing all backing data to be written to 'image' making it independent.

            disk rebase myimage.qcow2

Users may use paths relative to the 'files' directory or absolute paths for inputs; however, the backing path will always be relative to the rebased image.

Variants: disk snapshot disk snapshot

Creates a new qcow2 image 'dst' backed by 'image'.

Example of taking a snapshot of a disk:

    disk snapshot windows7.qc2 window7_miniccc.qc2

If the destination name is omitted, a name will be randomly generated and the snapshot will be stored in the 'files' directory. Snapshots are always created in the 'files' directory.

Users may use paths relative to the 'files' directory or absolute paths for inputs; however, the backing path will always be relative to the new image.

Variants: dnsmasq

Start a dhcp/dns server on a specified IP with a specified range. For example, to start a DHCP server on IP 10.0.0.1 serving the range 10.0.0.2 - 10.0.254.254:

    dnsmasq start 10.0.0.1 10.0.0.2 10.0.254.254

To start only a from a config file:

    dnsmasq start /path/to/config

To list running dnsmasq servers, invoke dnsmasq with no arguments. To kill a running dnsmasq server, specify its ID from the list of running servers. For example, to kill dnsmasq server 2:

    dnsmasq kill 2

To kill all running dnsmasq servers, pass all as the ID:

    dnsmasq kill all

dnsmasq will provide DNS service from the host, as well as from /etc/hosts. You can specify an additional config file for dnsmasq by providing a file as an additional argument.

    dnsmasq start 10.0.0.1 10.0.0.2 10.0.254.254 /tmp/dnsmasq-extra.conf

NOTE: If specifying an additional config file, you must provide the full path to the file.

Variants: dnsmasq configure dns dnsmasq configure dns

Configuration options for running dnsmasq instances. Define a static IP allocation, specify a hostname->IP mapping for DNS, configure upstream DNS servers (useful when forwarding/NAT is enabled), or set DHCP options.

To list all existing static IP allocations on the first running dnsmasq server, do the following:

    dnsmasq configure 0 ip

To set up a static IP allocation for a VM with the MAC address 00:11:22:33:44:55:

    dnsmasq configure 0 ip 00:11:22:33:44:55 172.17.0.50

To see DNS entries:

    dnsmasq configure 0 dns

To add a DNS entry:

    dnsmasq configure 0 dns 172.17.0.50 example.com

To see upstream DNS servers:

    dnsmasq configure 0 upstream

To add an upstream DNS server:

    dnsmasq configure 0 upstream server 1.1.1.1

To see a list of all DHCP options:

    dnsmasq configure 0 options

To add a DHCP option:

    dnsmasq configure 0 options option:dns-server,172.17.0.254

Variants: dnsmasq configure dns upstream

Configuration options for running dnsmasq instances. Define a static IP allocation, specify a hostname->IP mapping for DNS, configure upstream DNS servers (useful when forwarding/NAT is enabled), or set DHCP options.

To list all existing static IP allocations on the first running dnsmasq server, do the following:

    dnsmasq configure 0 ip

To set up a static IP allocation for a VM with the MAC address 00:11:22:33:44:55:

    dnsmasq configure 0 ip 00:11:22:33:44:55 172.17.0.50

To see DNS entries:

    dnsmasq configure 0 dns

To add a DNS entry:

    dnsmasq configure 0 dns 172.17.0.50 example.com

To see upstream DNS servers:

    dnsmasq configure 0 upstream

To add an upstream DNS server:

    dnsmasq configure 0 upstream server 1.1.1.1

To see a list of all DHCP options:

    dnsmasq configure 0 options

To add a DHCP option:

    dnsmasq configure 0 options option:dns-server,172.17.0.254

Variants: dnsmasq configure dns upstream server

Configuration options for running dnsmasq instances. Define a static IP allocation, specify a hostname->IP mapping for DNS, configure upstream DNS servers (useful when forwarding/NAT is enabled), or set DHCP options.

To list all existing static IP allocations on the first running dnsmasq server, do the following:

    dnsmasq configure 0 ip

To set up a static IP allocation for a VM with the MAC address 00:11:22:33:44:55:

    dnsmasq configure 0 ip 00:11:22:33:44:55 172.17.0.50

To see DNS entries:

    dnsmasq configure 0 dns

To add a DNS entry:

    dnsmasq configure 0 dns 172.17.0.50 example.com

To see upstream DNS servers:

    dnsmasq configure 0 upstream

To add an upstream DNS server:

    dnsmasq configure 0 upstream server 1.1.1.1

To see a list of all DHCP options:

    dnsmasq configure 0 options

To add a DHCP option:

    dnsmasq configure 0 options option:dns-server,172.17.0.254

Variants: dnsmasq configure ip dnsmasq configure ip

Configuration options for running dnsmasq instances. Define a static IP allocation, specify a hostname->IP mapping for DNS, configure upstream DNS servers (useful when forwarding/NAT is enabled), or set DHCP options.

To list all existing static IP allocations on the first running dnsmasq server, do the following:

    dnsmasq configure 0 ip

To set up a static IP allocation for a VM with the MAC address 00:11:22:33:44:55:

    dnsmasq configure 0 ip 00:11:22:33:44:55 172.17.0.50

To see DNS entries:

    dnsmasq configure 0 dns

To add a DNS entry:

    dnsmasq configure 0 dns 172.17.0.50 example.com

To see upstream DNS servers:

    dnsmasq configure 0 upstream

To add an upstream DNS server:

    dnsmasq configure 0 upstream server 1.1.1.1

To see a list of all DHCP options:

    dnsmasq configure 0 options

To add a DHCP option:

    dnsmasq configure 0 options option:dns-server,172.17.0.254

Variants: dnsmasq configure options dnsmasq configure options

Configuration options for running dnsmasq instances. Define a static IP allocation, specify a hostname->IP mapping for DNS, configure upstream DNS servers (useful when forwarding/NAT is enabled), or set DHCP options.

To list all existing static IP allocations on the first running dnsmasq server, do the following:

    dnsmasq configure 0 ip

To set up a static IP allocation for a VM with the MAC address 00:11:22:33:44:55:

    dnsmasq configure 0 ip 00:11:22:33:44:55 172.17.0.50

To see DNS entries:

    dnsmasq configure 0 dns

To add a DNS entry:

    dnsmasq configure 0 dns 172.17.0.50 example.com

To see upstream DNS servers:

    dnsmasq configure 0 upstream

To add an upstream DNS server:

    dnsmasq configure 0 upstream server 1.1.1.1

To see a list of all DHCP options:

    dnsmasq configure 0 options

To add a DHCP option:

    dnsmasq configure 0 options option:dns-server,172.17.0.254

Variants: dnsmasq kill

Start a dhcp/dns server on a specified IP with a specified range. For example, to start a DHCP server on IP 10.0.0.1 serving the range 10.0.0.2 - 10.0.254.254:

    dnsmasq start 10.0.0.1 10.0.0.2 10.0.254.254

To start only a from a config file:

    dnsmasq start /path/to/config

To list running dnsmasq servers, invoke dnsmasq with no arguments. To kill a running dnsmasq server, specify its ID from the list of running servers. For example, to kill dnsmasq server 2:

    dnsmasq kill 2

To kill all running dnsmasq servers, pass all as the ID:

    dnsmasq kill all

dnsmasq will provide DNS service from the host, as well as from /etc/hosts. You can specify an additional config file for dnsmasq by providing a file as an additional argument.

    dnsmasq start 10.0.0.1 10.0.0.2 10.0.254.254 /tmp/dnsmasq-extra.conf

NOTE: If specifying an additional config file, you must provide the full path to the file.

Variants: dnsmasq start dnsmasq start dnsmasq start

Start a dhcp/dns server on a specified IP with a specified range. For example, to start a DHCP server on IP 10.0.0.1 serving the range 10.0.0.2 - 10.0.254.254:

    dnsmasq start 10.0.0.1 10.0.0.2 10.0.254.254

To start only a from a config file:

    dnsmasq start /path/to/config

To list running dnsmasq servers, invoke dnsmasq with no arguments. To kill a running dnsmasq server, specify its ID from the list of running servers. For example, to kill dnsmasq server 2:

    dnsmasq kill 2

To kill all running dnsmasq servers, pass all as the ID:

    dnsmasq kill all

dnsmasq will provide DNS service from the host, as well as from /etc/hosts. You can specify an additional config file for dnsmasq by providing a file as an additional argument.

    dnsmasq start 10.0.0.1 10.0.0.2 10.0.254.254 /tmp/dnsmasq-extra.conf

NOTE: If specifying an additional config file, you must provide the full path to the file.

Variants: echo ... echo

display input text after comment removal

Variants: file delete

file allows you to transfer and manage files served by minimega in the directory set by the -filepath flag (default is 'base'/files).

To list files currently being served, issue the list command with a directory relative to the served directory:

    file list /foo

Issuing "file list /" will list the contents of the served directory.

Files can be deleted with the delete command:

    file delete /foo

If a directory is given, the directory will be recursively deleted.

Files are transferred using the get command. When a get command is issued, the node will begin searching for a file matching the path and name within the mesh. If the file exists, it will be transferred to the requesting node. Which file is transferred over the mesh depends on the mode minimega is running in (see the "File transfer with minimega" article for details). When a file transfer begins, control will return to minimega while the transfer completes. If the -hashfiles flag is disabled (the default), and multiple files with the same name but different content exist across the mesh, the "file get" behavior for the file is undefined.

If a directory is specified, that directory will be recursively transferred to the node.

To see files that are currently being transferred, use the status command:

    file status

You can also supply globs (wildcards) with the * operator. For example:

    file get *.qcow2
    file delete *.qcow2

The stream command allows users to stream files through the Response. Each part of the file is returned as a separate response which can then be combined to form the original file. This command blocks until the stream is complete.

Variants: file get

file allows you to transfer and manage files served by minimega in the directory set by the -filepath flag (default is 'base'/files).

To list files currently being served, issue the list command with a directory relative to the served directory:

    file list /foo

Issuing "file list /" will list the contents of the served directory.

Files can be deleted with the delete command:

    file delete /foo

If a directory is given, the directory will be recursively deleted.

Files are transferred using the get command. When a get command is issued, the node will begin searching for a file matching the path and name within the mesh. If the file exists, it will be transferred to the requesting node. Which file is transferred over the mesh depends on the mode minimega is running in (see the "File transfer with minimega" article for details). When a file transfer begins, control will return to minimega while the transfer completes. If the -hashfiles flag is disabled (the default), and multiple files with the same name but different content exist across the mesh, the "file get" behavior for the file is undefined.

If a directory is specified, that directory will be recursively transferred to the node.

To see files that are currently being transferred, use the status command:

    file status

You can also supply globs (wildcards) with the * operator. For example:

    file get *.qcow2
    file delete *.qcow2

The stream command allows users to stream files through the Response. Each part of the file is returned as a separate response which can then be combined to form the original file. This command blocks until the stream is complete.

Variants: file list file list file list

file allows you to transfer and manage files served by minimega in the directory set by the -filepath flag (default is 'base'/files).

To list files currently being served, issue the list command with a directory relative to the served directory:

    file list /foo

Issuing "file list /" will list the contents of the served directory.

Files can be deleted with the delete command:

    file delete /foo

If a directory is given, the directory will be recursively deleted.

Files are transferred using the get command. When a get command is issued, the node will begin searching for a file matching the path and name within the mesh. If the file exists, it will be transferred to the requesting node. Which file is transferred over the mesh depends on the mode minimega is running in (see the "File transfer with minimega" article for details). When a file transfer begins, control will return to minimega while the transfer completes. If the -hashfiles flag is disabled (the default), and multiple files with the same name but different content exist across the mesh, the "file get" behavior for the file is undefined.

If a directory is specified, that directory will be recursively transferred to the node.

To see files that are currently being transferred, use the status command:

    file status

You can also supply globs (wildcards) with the * operator. For example:

    file get *.qcow2
    file delete *.qcow2

The stream command allows users to stream files through the Response. Each part of the file is returned as a separate response which can then be combined to form the original file. This command blocks until the stream is complete.

Variants: file status

file allows you to transfer and manage files served by minimega in the directory set by the -filepath flag (default is 'base'/files).

To list files currently being served, issue the list command with a directory relative to the served directory:

    file list /foo

Issuing "file list /" will list the contents of the served directory.

Files can be deleted with the delete command:

    file delete /foo

If a directory is given, the directory will be recursively deleted.

Files are transferred using the get command. When a get command is issued, the node will begin searching for a file matching the path and name within the mesh. If the file exists, it will be transferred to the requesting node. Which file is transferred over the mesh depends on the mode minimega is running in (see the "File transfer with minimega" article for details). When a file transfer begins, control will return to minimega while the transfer completes. If the -hashfiles flag is disabled (the default), and multiple files with the same name but different content exist across the mesh, the "file get" behavior for the file is undefined.

If a directory is specified, that directory will be recursively transferred to the node.

To see files that are currently being transferred, use the status command:

    file status

You can also supply globs (wildcards) with the * operator. For example:

    file get *.qcow2
    file delete *.qcow2

The stream command allows users to stream files through the Response. Each part of the file is returned as a separate response which can then be combined to form the original file. This command blocks until the stream is complete.

Variants: file stream

file allows you to transfer and manage files served by minimega in the directory set by the -filepath flag (default is 'base'/files).

To list files currently being served, issue the list command with a directory relative to the served directory:

    file list /foo

Issuing "file list /" will list the contents of the served directory.

Files can be deleted with the delete command:

    file delete /foo

If a directory is given, the directory will be recursively deleted.

Files are transferred using the get command. When a get command is issued, the node will begin searching for a file matching the path and name within the mesh. If the file exists, it will be transferred to the requesting node. Which file is transferred over the mesh depends on the mode minimega is running in (see the "File transfer with minimega" article for details). When a file transfer begins, control will return to minimega while the transfer completes. If the -hashfiles flag is disabled (the default), and multiple files with the same name but different content exist across the mesh, the "file get" behavior for the file is undefined.

If a directory is specified, that directory will be recursively transferred to the node.

To see files that are currently being transferred, use the status command:

    file status

You can also supply globs (wildcards) with the * operator. For example:

    file get *.qcow2
    file delete *.qcow2

The stream command allows users to stream files through the Response. Each part of the file is returned as a separate response which can then be combined to form the original file. This command blocks until the stream is complete.

Variants: history

history displays a list of all the commands that have been invoked since minimega started on this host, or since the last time the history was cleared. History includes only valid commands and comments. Invalid lines and blank lines are not recorded. There are some commands that interact differently with history, namely read. Instead of recording the "read" command in the history, minimega records all the valid commands executed from the read file in the history. This allows the full execution history to be listed using history.

Variants: host

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host androidvms

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host cpucommit

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host cpus

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host load

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host memcommit

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host memtotal

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host memused

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host name

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host netcommit

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host rx

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host tx

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host uptime

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host vmlimit

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: host vms

Report information about hosts in the current namespace:

• cpucommit : total cpu commit
• cpus : number of cpus
• load : system load average
• memcommit : total memory commit in MB
• memtotal : total memory in MB
• memused : memory used in MB
• name : name of the machine
• netcommit : total network interface commit
• rx : RX bandwidth stats (MB/s)
• tx : TX bandwidth stats (MB/s)
• uptime : uptime
• vms : number of VMs
• androidvms : number of active Android VMs counted against the per-host Android port limit
• vmlimit : limit based on coschedule values (-1 is no limit)

All VM-based stats are computed across namespaces.

Variants: log file log file

Log to a file. To disable file logging, call "clear log file".

Variants: log filter log filter

Control what data gets logged based on matching text. For example, to filter out all logging messages containing the word "foo":

    log filter foo

Variants: log level log level

Set the log level to one of [debug,info,warn,error,fatal]. Log levels inherit lower levels, so setting the level to error will also log fatal, and setting the mode to debug will log everything.

Variants: log mesh log mesh

Log to a mesh node. To disable mesh logging, call "clear log mesh".

Variants: log ring log ring

The log ring contains recent log messages, if it is enabled. By default the ring is not enabled. When enabling it, the user can specify a size. The larger the size, the more memory the logs will consume. The log ring can be cleared by re-enabling it with the same (or different) size.

To disable the log ring, call "clear log ring".

Variants: log stderr log stderr

enable or disable logging to stderr

Variants: log syslog local

Log to a syslog daemon on the provided network and address. For example, to log over UDP to a syslog server foo on port 514:

    log syslog udp foo:514

Variants: log syslog remote

    log syslog udp foo:514

Variants: mesh degree mesh degree

view or set the current degree for this mesh node

Variants: mesh dial

attempt to connect this node to another node

Variants: mesh dot

Output a graphviz formatted dot file representing the connected topology.

Variants: mesh hangup

disconnect from a client

Variants: mesh list mesh list

Without "all" or "peers", displays the mesh adjacency list. If "all" is specified, the hostnames of all nodes in the list are printed. If "peers" is specified, the hostnames of all peers are printed (the local node is not included).

Variants: mesh send (command)

Send a command to one or more connected clients. For example, to get the vm info from nodes kn1 and kn2:

    mesh send kn[1-2] vm info

You can use 'all' to send a command to all connected clients.

Variants: mesh status

display a short status report of the mesh

Variants: mesh timeout mesh timeout

View or set the timeout on sending mesh commands.

When a mesh command is issued, if a response isn't sent within mesh timeout seconds, the command will be dropped and any future response will be discarded. Note that this does not cancel the outstanding command - the node receiving the command may still complete - but rather this node will stop waiting on a response.

By default, the mesh timeout is 0 which disables timeouts.

Returns a new instance for use in a with statement:

    with mm.namespace("name") as mm:
            mm.vm_info(...)

Note that this wraps the existing minimega connection so multiple instances can be used concurrently but the commands themselves will be executed serially.

Variants: ns add-hosts

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns bridge ns bridge

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns del-bridge

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns del-hosts

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns flush

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns hosts

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns load

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns load cpucommit

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns load memcommit

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns load netcommit

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns queue

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns queueing ns queueing

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns run (command)

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns save ns save

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns schedule

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns schedule dry-run

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns schedule dump

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns schedule mv

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns schedule status

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: ns snapshot ns snapshot

Display or modify the active namespace.

• hosts : list hosts
• add-hosts : add comma-separated list of hosts to the namespace
• del-hosts : delete comma-separated list of hosts from the namespace
• load : display or change host load is computed for scheduler, based on:
• cpucommit : total CPU commit divided by number of CPUs (default)
• netcommit : total NIC
• memcommit : total memory commit divided by total memory
• queue : display VM queue
• flush : clear the VM queue
• queueing : toggle VMs queueing when launching (default false)
• schedule : run scheduler (same as "vm launch")
• dry-run : determine VM placement and print out VM -> host assignments
• dump : print out VM -> host assignments (after dry-run)
• mv : manually edit VM placement in schedule (after dry-run)
• status : display scheduling status
• bridge : create a bridge, defaults to GRE mesh between hosts
• del-bridge: destroy a bridge
• snapshot : DEPRECATED: Use 'ns save'
• save : Save all supported VMs in the namespace or print save progress
• run : run a command on all nodes in the namespace

Note: namespace save records Android VM configuration so Android VMs can be relaunched, but it does not capture Android Emulator runtime state, AVD data changes, guest IP addresses, guest policy routing, or guest firewall state.

Variants: nuke

After a crash, the VM state on the machine can be difficult to recover from. nuke attempts to kill all instances of QEMU, remove all taps and bridges, and removes the temporary minimega state on the harddisk.

Should be run with caution.

Variants: optimize

Enable or disable several virtualization optimizations, including Kernel Samepage Merging, CPU affinity for VMs, and the use of hugepages.

To enable/disable Kernel Samepage Merging (KSM):

    optimize ksm [true,false]

To enable hugepage support for future VM launches:

    optimize hugepages </path/to/hugepages_mount>

To disable hugepage support:

    clear optimize hugepages

To enable/disable CPU affinity support for VMs in the namespace:

    optimize affinity [true,false]

To set a CPU set filter for the affinity scheduler, for example (to use only CPUs 1, 2-20):

    optimize affinity filter [1,2-20]

If affinity is already enabled, will cause reassignment of affinity for all running VMs to match the new filter.

To clear a CPU set filter:

    clear optimize affinity filter

See note above about reassigning affinity.

To view current CPU affinity mappings (by PID):

    optimize affinity

To disable all optimizations, use "clear optimize".

Note: affinity and hugepages can be selectively enabled in particular namespaces. KSM affects VMs across all namespaces.

Variants: optimize affinity optimize affinity

Enable or disable several virtualization optimizations, including Kernel Samepage Merging, CPU affinity for VMs, and the use of hugepages.

To enable/disable Kernel Samepage Merging (KSM):

    optimize ksm [true,false]

To enable hugepage support for future VM launches:

    optimize hugepages </path/to/hugepages_mount>

To disable hugepage support:

    clear optimize hugepages

To enable/disable CPU affinity support for VMs in the namespace:

    optimize affinity [true,false]

To set a CPU set filter for the affinity scheduler, for example (to use only CPUs 1, 2-20):

    optimize affinity filter [1,2-20]

If affinity is already enabled, will cause reassignment of affinity for all running VMs to match the new filter.

To clear a CPU set filter:

    clear optimize affinity filter

See note above about reassigning affinity.

To view current CPU affinity mappings (by PID):

    optimize affinity

To disable all optimizations, use "clear optimize".

Note: affinity and hugepages can be selectively enabled in particular namespaces. KSM affects VMs across all namespaces.

Variants: optimize affinity filter

Enable or disable several virtualization optimizations, including Kernel Samepage Merging, CPU affinity for VMs, and the use of hugepages.

To enable/disable Kernel Samepage Merging (KSM):

    optimize ksm [true,false]

To enable hugepage support for future VM launches:

    optimize hugepages </path/to/hugepages_mount>

To disable hugepage support:

    clear optimize hugepages

To enable/disable CPU affinity support for VMs in the namespace:

    optimize affinity [true,false]

To set a CPU set filter for the affinity scheduler, for example (to use only CPUs 1, 2-20):

    optimize affinity filter [1,2-20]

If affinity is already enabled, will cause reassignment of affinity for all running VMs to match the new filter.

To clear a CPU set filter:

    clear optimize affinity filter

See note above about reassigning affinity.

To view current CPU affinity mappings (by PID):

    optimize affinity

To disable all optimizations, use "clear optimize".

Note: affinity and hugepages can be selectively enabled in particular namespaces. KSM affects VMs across all namespaces.

Variants: optimize hugepages optimize hugepages

Enable or disable several virtualization optimizations, including Kernel Samepage Merging, CPU affinity for VMs, and the use of hugepages.

To enable/disable Kernel Samepage Merging (KSM):

    optimize ksm [true,false]

To enable hugepage support for future VM launches:

    optimize hugepages </path/to/hugepages_mount>

To disable hugepage support:

    clear optimize hugepages

To enable/disable CPU affinity support for VMs in the namespace:

    optimize affinity [true,false]

To set a CPU set filter for the affinity scheduler, for example (to use only CPUs 1, 2-20):

    optimize affinity filter [1,2-20]

If affinity is already enabled, will cause reassignment of affinity for all running VMs to match the new filter.

To clear a CPU set filter:

    clear optimize affinity filter

See note above about reassigning affinity.

To view current CPU affinity mappings (by PID):

    optimize affinity

To disable all optimizations, use "clear optimize".

Note: affinity and hugepages can be selectively enabled in particular namespaces. KSM affects VMs across all namespaces.

Variants: optimize ksm optimize ksm

Enable or disable several virtualization optimizations, including Kernel Samepage Merging, CPU affinity for VMs, and the use of hugepages.

To enable/disable Kernel Samepage Merging (KSM):

    optimize ksm [true,false]

To enable hugepage support for future VM launches:

    optimize hugepages </path/to/hugepages_mount>

To disable hugepage support:

    clear optimize hugepages

To enable/disable CPU affinity support for VMs in the namespace:

    optimize affinity [true,false]

To set a CPU set filter for the affinity scheduler, for example (to use only CPUs 1, 2-20):

    optimize affinity filter [1,2-20]

If affinity is already enabled, will cause reassignment of affinity for all running VMs to match the new filter.

To clear a CPU set filter:

    clear optimize affinity filter

See note above about reassigning affinity.

To view current CPU affinity mappings (by PID):

    optimize affinity

To disable all optimizations, use "clear optimize".

Note: affinity and hugepages can be selectively enabled in particular namespaces. KSM affects VMs across all namespaces.

Variants: pipe pipe

Interact with named pipes. To write to a pipe, simply invoke the pipe API with the pipe name and value:

    pipe foo Hello pipes!

Pipes have several message delivery modes. Based on the mode, messages written to a pipe will be delivered to one or more readers. Mode "all" copies messages to all readers, "round-robin" chooses a single reader, in-order, and "random" selects a random reader.

Pipes can also have "vias", programs through which all written data is passed before being sent to readers. Unlike pipelines, vias are run for every reader. This allows for mutating data on a per-reader basis with a single write. For example, to send a unique floating-point value on a normal distribution with a written mean to all readers:

    pipe foo via normal -stddev 5.0
    pipe foo 1.5

Pipes in other namespaces can be referenced with the syntax //.

Variants: pipe log

Interact with named pipes. To write to a pipe, simply invoke the pipe API with the pipe name and value:

    pipe foo Hello pipes!

Pipes have several message delivery modes. Based on the mode, messages written to a pipe will be delivered to one or more readers. Mode "all" copies messages to all readers, "round-robin" chooses a single reader, in-order, and "random" selects a random reader.

Pipes can also have "vias", programs through which all written data is passed before being sent to readers. Unlike pipelines, vias are run for every reader. This allows for mutating data on a per-reader basis with a single write. For example, to send a unique floating-point value on a normal distribution with a written mean to all readers:

    pipe foo via normal -stddev 5.0
    pipe foo 1.5

Pipes in other namespaces can be referenced with the syntax //.

Variants: pipe mode

Interact with named pipes. To write to a pipe, simply invoke the pipe API with the pipe name and value:

    pipe foo Hello pipes!

Pipes have several message delivery modes. Based on the mode, messages written to a pipe will be delivered to one or more readers. Mode "all" copies messages to all readers, "round-robin" chooses a single reader, in-order, and "random" selects a random reader.

Pipes can also have "vias", programs through which all written data is passed before being sent to readers. Unlike pipelines, vias are run for every reader. This allows for mutating data on a per-reader basis with a single write. For example, to send a unique floating-point value on a normal distribution with a written mean to all readers:

    pipe foo via normal -stddev 5.0
    pipe foo 1.5

Pipes in other namespaces can be referenced with the syntax //.

Variants: pipe via ...

Variants: plumb ... plumb

Create pipelines composed of named pipes and external programs. Pipelines pass data on standard I/O, with messages split on newlines. Pipelines are constructed similar to that of UNIX pipelines. For example, to pipeline named pipe "foo" through "sed" and into another pipe "bar":

    plumb foo "sed -u s/foo/moo/" bar

When specifying pipelines, strings that are not found in $PATH are considered named pipes.

Pipelines can be composed into larger, nonlinear pipelines. For example, to create a simple tree rooted at A with leaves B and C, simply specify multiple pipelines:

    plumb a b
    plumb a c

Variants: qos add delay

Add quality-of-service (qos) constraints on mega interfaces to emulate real networks. Currently only applies qos constraints on the egress side / transmit direction. Qos constraints can be stacked with multiple calls to , and must be specified explicitly. Any existing constraints will be overwritten by additional calls to . VM can be specified with the same target syntax as the "vm start" api.

Note that qos is namespace aware, and any qos commands will be matched to target vms within the currently active namespace.

qos constraints include:

• loss : packets will be randomly dropped with a specified probability
• delay : delay packets for specified unit of time (ms, ns, etc)
• rate : impose a maximum bandwidth on an interface in kbit, mbit, or gbit

Note: due to limitations of the underlying tool, "tc", you can only add rate or loss/delay to a VM. Enabling loss or delay will disable rate and vice versa.

Note: qos applies only to traffic received by the VM (which is "egress" traffic on the mega_tap interface on the host) -- traffic sent by the VM ("ingress" on the mega_tap interface on the host) is not policed to the desired rate.

Examples:

    Randomly drop packets on the 0th interface for vms foo0, 1, and 2 with
    probability 25%

    qos add foo[0-2] 0 loss 25

    Add a 100ms delay to every packet on the 0th interface for vm foo and bar

    qos add foo,bar 0 delay 100ms

    Rate limit the 0th interface on all vms in the active namespace to 1mbit/s

    qos add all 0 rate 1 mbit

To clear active qos settings, use:

    clear qos <vm> <interface|all>

Example:

    clear qos foo all

Variants: qos add loss

Add quality-of-service (qos) constraints on mega interfaces to emulate real networks. Currently only applies qos constraints on the egress side / transmit direction. Qos constraints can be stacked with multiple calls to , and must be specified explicitly. Any existing constraints will be overwritten by additional calls to . VM can be specified with the same target syntax as the "vm start" api.

Note that qos is namespace aware, and any qos commands will be matched to target vms within the currently active namespace.

qos constraints include:

• loss : packets will be randomly dropped with a specified probability
• delay : delay packets for specified unit of time (ms, ns, etc)
• rate : impose a maximum bandwidth on an interface in kbit, mbit, or gbit

Note: due to limitations of the underlying tool, "tc", you can only add rate or loss/delay to a VM. Enabling loss or delay will disable rate and vice versa.

Note: qos applies only to traffic received by the VM (which is "egress" traffic on the mega_tap interface on the host) -- traffic sent by the VM ("ingress" on the mega_tap interface on the host) is not policed to the desired rate.

Examples:

    Randomly drop packets on the 0th interface for vms foo0, 1, and 2 with
    probability 25%

    qos add foo[0-2] 0 loss 25

    Add a 100ms delay to every packet on the 0th interface for vm foo and bar

    qos add foo,bar 0 delay 100ms

    Rate limit the 0th interface on all vms in the active namespace to 1mbit/s

    qos add all 0 rate 1 mbit

To clear active qos settings, use:

    clear qos <vm> <interface|all>

Example:

    clear qos foo all

Variants: qos add rate

Add quality-of-service (qos) constraints on mega interfaces to emulate real networks. Currently only applies qos constraints on the egress side / transmit direction. Qos constraints can be stacked with multiple calls to , and must be specified explicitly. Any existing constraints will be overwritten by additional calls to . VM can be specified with the same target syntax as the "vm start" api.

Note that qos is namespace aware, and any qos commands will be matched to target vms within the currently active namespace.

qos constraints include:

• loss : packets will be randomly dropped with a specified probability
• delay : delay packets for specified unit of time (ms, ns, etc)
• rate : impose a maximum bandwidth on an interface in kbit, mbit, or gbit

Note: due to limitations of the underlying tool, "tc", you can only add rate or loss/delay to a VM. Enabling loss or delay will disable rate and vice versa.

Note: qos applies only to traffic received by the VM (which is "egress" traffic on the mega_tap interface on the host) -- traffic sent by the VM ("ingress" on the mega_tap interface on the host) is not policed to the desired rate.

Examples:

    Randomly drop packets on the 0th interface for vms foo0, 1, and 2 with
    probability 25%

    qos add foo[0-2] 0 loss 25

    Add a 100ms delay to every packet on the 0th interface for vm foo and bar

    qos add foo,bar 0 delay 100ms

    Rate limit the 0th interface on all vms in the active namespace to 1mbit/s

    qos add all 0 rate 1 mbit

To clear active qos settings, use:

    clear qos <vm> <interface|all>

Example:

    clear qos foo all

Variants: quit quit

Quit minimega. An optional integer argument X allows deferring the quit call for X seconds. This is useful for telling a mesh of minimega nodes to quit.

quit will not return a response to the cli, control socket, or meshage, it will simply exit. meshage connected nodes catch this and will remove the quit node from the mesh. External tools interfacing minimega must check for EOF on stdout or the control socket as an indication that minimega has quit.

Variants: read read

Read a command file and execute it. This has the same behavior as if you typed the file in manually. read stops if it reads an invalid command. read does not stop if a command returns an error. Nested reads are not permitted.

To prevent issues with another script changing the namespace and commands being run in a different namespace than originally intended, read records the active namespace when it starts and prepends that namespace to all commands that it reads from the file. If it reads a command that would change the active namespace, read updates its state so that the new namespace is prepended instead.

If the optional argument check is specified then read doesn't execute any of the commands in the file. Instead, it checks that all the commands are syntactically valid. This can identify mistyped commands in scripts before you read them. It cannot check for semantic errors (e.g. killing a non-existent VM). The check stops at the first invalid command.

Variants: router

Configure running minirouter VMs running minirouter and miniccc.

Routers are configured by specifying or updating a configuration, and then applying that configuration with a commit command. For example, to configure a router on a running VM named 'foo' to serve DHCP on 10.0.0.0/24 with a range of IPs:

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

router takes a number of subcommands:

• 'log': Change the log level of the minirouter tool on the VM.

• 'interface': Set IPv4 or IPv6 addresses, or configure an interface to assign using DHCP. The interface field is an integer index of the interface defined with 'vm config net'. You could also specify if that interface will be a loopback interface For example, to configure the second interface of the router with a static IP and a loopback with a different IP:

  vm config net 100 200
  # ...
  router foo interface 1 10.0.0.1/24
  router foo interface 2 11.0.0.1/32 lo
  

• 'dhcp': Configure one or more DHCP servers on the router. The API allows you to set several options including static IP assignments and the default route and DNS server. For example, to serve a range of IPs, with 2 static IPs explicitly called out on router with IP 10.0.0.1:

  router vm foo dhcp 10.0.0.0 range 10.0.0.2 10.0.0.254
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:55 10.0.0.10
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:56 10.0.0.11
  

• 'dns': Set DNS records for IPv4 or IPv6 hosts.

• 'upstream': Set upstream server for DNS.

• 'gw': Set default gateway which will be used if there is no matching route.

• 'ra': Enable neighbor discovery protocol router advertisements for a given subnet.

• 'route': Set static, OSPF, or BGP routes. Static routes include a subnet, next-hop, and optionally a name for this router. For example to specify a static route(s):

  router foo route static 0.0.0.0/0 10.0.0.1 default-route
  

OSPF routes include an area and a network index corresponding to the interface described in 'vm config net'. You can also specify what networks to advertise using the export command.

For example, to enable OSPF on area 0 for both interfaces of a router:

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

For example, to advertise specific networks, advertise a static route or use a static route as a filter:

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

To configure BGP must specify the process name for the specific bgp context, local ip address and AS, Neighbor ip address and AS, and what networks need to be advertised

For example, local router is in AS 100 with an ip 10.0.0.1 and bgp peer is in AS 200 with an ip of 20.0.0.1 and you want to advertise network 10.0.0.0/24:

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

You can set up route reflection for BGP by using the rrclient command for that process. By using the command it indicates that the peer is a bgp client:

    router foo bgp bar rrclient

• 'rid': Sets the 32 bit router ID for the router. Typically this ID is unique across the organization's network and is used for various routing protocols ie OSPF

  router foo rid 1.1.1.1
  

• 'fw': specify flows to accept/drop/reject via iptables. For example, to globally globally drop all forwarded packets and accept HTTP traffic from any IP address to host 192.168.0.5 on the interface at index 0 (which is on the 192.168.0.0/24 network):

  router foo fw default drop
  router foo fw accept out 0 192.168.0.5:80 tcp
  

Note that we use 'out' here since we're applying the rule to the interface that's on the same network as the destination. The source and destination does not have to include a port.

New iptables chains can also be created, providing a method for grouping rules together instead of adding rules at the global level. Chains are then applied to one or more interfaces using the interface index. For example, one could put the previous rule into a chain named "allow-http" and apply it to the interface at index 0 via the following:

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0

Variants: router commit

Configure running minirouter VMs running minirouter and miniccc.

Routers are configured by specifying or updating a configuration, and then applying that configuration with a commit command. For example, to configure a router on a running VM named 'foo' to serve DHCP on 10.0.0.0/24 with a range of IPs:

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

router takes a number of subcommands:

• 'log': Change the log level of the minirouter tool on the VM.

• 'interface': Set IPv4 or IPv6 addresses, or configure an interface to assign using DHCP. The interface field is an integer index of the interface defined with 'vm config net'. You could also specify if that interface will be a loopback interface For example, to configure the second interface of the router with a static IP and a loopback with a different IP:

  vm config net 100 200
  # ...
  router foo interface 1 10.0.0.1/24
  router foo interface 2 11.0.0.1/32 lo
  

• 'dhcp': Configure one or more DHCP servers on the router. The API allows you to set several options including static IP assignments and the default route and DNS server. For example, to serve a range of IPs, with 2 static IPs explicitly called out on router with IP 10.0.0.1:

  router vm foo dhcp 10.0.0.0 range 10.0.0.2 10.0.0.254
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:55 10.0.0.10
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:56 10.0.0.11
  

• 'dns': Set DNS records for IPv4 or IPv6 hosts.

• 'upstream': Set upstream server for DNS.

• 'gw': Set default gateway which will be used if there is no matching route.

• 'ra': Enable neighbor discovery protocol router advertisements for a given subnet.

• 'route': Set static, OSPF, or BGP routes. Static routes include a subnet, next-hop, and optionally a name for this router. For example to specify a static route(s):

  router foo route static 0.0.0.0/0 10.0.0.1 default-route
  

OSPF routes include an area and a network index corresponding to the interface described in 'vm config net'. You can also specify what networks to advertise using the export command.

For example, to enable OSPF on area 0 for both interfaces of a router:

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

For example, to advertise specific networks, advertise a static route or use a static route as a filter:

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

To configure BGP must specify the process name for the specific bgp context, local ip address and AS, Neighbor ip address and AS, and what networks need to be advertised

For example, local router is in AS 100 with an ip 10.0.0.1 and bgp peer is in AS 200 with an ip of 20.0.0.1 and you want to advertise network 10.0.0.0/24:

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

You can set up route reflection for BGP by using the rrclient command for that process. By using the command it indicates that the peer is a bgp client:

    router foo bgp bar rrclient

• 'rid': Sets the 32 bit router ID for the router. Typically this ID is unique across the organization's network and is used for various routing protocols ie OSPF

  router foo rid 1.1.1.1
  

• 'fw': specify flows to accept/drop/reject via iptables. For example, to globally globally drop all forwarded packets and accept HTTP traffic from any IP address to host 192.168.0.5 on the interface at index 0 (which is on the 192.168.0.0/24 network):

  router foo fw default drop
  router foo fw accept out 0 192.168.0.5:80 tcp
  

Note that we use 'out' here since we're applying the rule to the interface that's on the same network as the destination. The source and destination does not have to include a port.

New iptables chains can also be created, providing a method for grouping rules together instead of adding rules at the global level. Chains are then applied to one or more interfaces using the interface index. For example, one could put the previous rule into a chain named "allow-http" and apply it to the interface at index 0 via the following:

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0

Variants: router dhcp dns

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

    router foo bgp bar rrclient

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0

Variants: router dhcp range

Configure running minirouter VMs running minirouter and miniccc.

Routers are configured by specifying or updating a configuration, and then applying that configuration with a commit command. For example, to configure a router on a running VM named 'foo' to serve DHCP on 10.0.0.0/24 with a range of IPs:

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

router takes a number of subcommands:

• 'log': Change the log level of the minirouter tool on the VM.

• 'interface': Set IPv4 or IPv6 addresses, or configure an interface to assign using DHCP. The interface field is an integer index of the interface defined with 'vm config net'. You could also specify if that interface will be a loopback interface For example, to configure the second interface of the router with a static IP and a loopback with a different IP:

  vm config net 100 200
  # ...
  router foo interface 1 10.0.0.1/24
  router foo interface 2 11.0.0.1/32 lo
  

• 'dhcp': Configure one or more DHCP servers on the router. The API allows you to set several options including static IP assignments and the default route and DNS server. For example, to serve a range of IPs, with 2 static IPs explicitly called out on router with IP 10.0.0.1:

  router vm foo dhcp 10.0.0.0 range 10.0.0.2 10.0.0.254
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:55 10.0.0.10
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:56 10.0.0.11
  

• 'dns': Set DNS records for IPv4 or IPv6 hosts.

• 'upstream': Set upstream server for DNS.

• 'gw': Set default gateway which will be used if there is no matching route.

• 'ra': Enable neighbor discovery protocol router advertisements for a given subnet.

• 'route': Set static, OSPF, or BGP routes. Static routes include a subnet, next-hop, and optionally a name for this router. For example to specify a static route(s):

  router foo route static 0.0.0.0/0 10.0.0.1 default-route
  

OSPF routes include an area and a network index corresponding to the interface described in 'vm config net'. You can also specify what networks to advertise using the export command.

For example, to enable OSPF on area 0 for both interfaces of a router:

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

For example, to advertise specific networks, advertise a static route or use a static route as a filter:

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

To configure BGP must specify the process name for the specific bgp context, local ip address and AS, Neighbor ip address and AS, and what networks need to be advertised

For example, local router is in AS 100 with an ip 10.0.0.1 and bgp peer is in AS 200 with an ip of 20.0.0.1 and you want to advertise network 10.0.0.0/24:

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

You can set up route reflection for BGP by using the rrclient command for that process. By using the command it indicates that the peer is a bgp client:

    router foo bgp bar rrclient

• 'rid': Sets the 32 bit router ID for the router. Typically this ID is unique across the organization's network and is used for various routing protocols ie OSPF

  router foo rid 1.1.1.1
  

• 'fw': specify flows to accept/drop/reject via iptables. For example, to globally globally drop all forwarded packets and accept HTTP traffic from any IP address to host 192.168.0.5 on the interface at index 0 (which is on the 192.168.0.0/24 network):

  router foo fw default drop
  router foo fw accept out 0 192.168.0.5:80 tcp
  

Note that we use 'out' here since we're applying the rule to the interface that's on the same network as the destination. The source and destination does not have to include a port.

New iptables chains can also be created, providing a method for grouping rules together instead of adding rules at the global level. Chains are then applied to one or more interfaces using the interface index. For example, one could put the previous rule into a chain named "allow-http" and apply it to the interface at index 0 via the following:

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0

Variants: router dhcp router

Configure running minirouter VMs running minirouter and miniccc.

Routers are configured by specifying or updating a configuration, and then applying that configuration with a commit command. For example, to configure a router on a running VM named 'foo' to serve DHCP on 10.0.0.0/24 with a range of IPs:

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

router takes a number of subcommands:

• 'log': Change the log level of the minirouter tool on the VM.

• 'interface': Set IPv4 or IPv6 addresses, or configure an interface to assign using DHCP. The interface field is an integer index of the interface defined with 'vm config net'. You could also specify if that interface will be a loopback interface For example, to configure the second interface of the router with a static IP and a loopback with a different IP:

  vm config net 100 200
  # ...
  router foo interface 1 10.0.0.1/24
  router foo interface 2 11.0.0.1/32 lo
  

• 'dhcp': Configure one or more DHCP servers on the router. The API allows you to set several options including static IP assignments and the default route and DNS server. For example, to serve a range of IPs, with 2 static IPs explicitly called out on router with IP 10.0.0.1:

  router vm foo dhcp 10.0.0.0 range 10.0.0.2 10.0.0.254
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:55 10.0.0.10
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:56 10.0.0.11
  

• 'dns': Set DNS records for IPv4 or IPv6 hosts.

• 'upstream': Set upstream server for DNS.

• 'gw': Set default gateway which will be used if there is no matching route.

• 'ra': Enable neighbor discovery protocol router advertisements for a given subnet.

• 'route': Set static, OSPF, or BGP routes. Static routes include a subnet, next-hop, and optionally a name for this router. For example to specify a static route(s):

  router foo route static 0.0.0.0/0 10.0.0.1 default-route
  

OSPF routes include an area and a network index corresponding to the interface described in 'vm config net'. You can also specify what networks to advertise using the export command.

For example, to enable OSPF on area 0 for both interfaces of a router:

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

For example, to advertise specific networks, advertise a static route or use a static route as a filter:

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

To configure BGP must specify the process name for the specific bgp context, local ip address and AS, Neighbor ip address and AS, and what networks need to be advertised

For example, local router is in AS 100 with an ip 10.0.0.1 and bgp peer is in AS 200 with an ip of 20.0.0.1 and you want to advertise network 10.0.0.0/24:

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

You can set up route reflection for BGP by using the rrclient command for that process. By using the command it indicates that the peer is a bgp client:

    router foo bgp bar rrclient

• 'rid': Sets the 32 bit router ID for the router. Typically this ID is unique across the organization's network and is used for various routing protocols ie OSPF

  router foo rid 1.1.1.1
  

• 'fw': specify flows to accept/drop/reject via iptables. For example, to globally globally drop all forwarded packets and accept HTTP traffic from any IP address to host 192.168.0.5 on the interface at index 0 (which is on the 192.168.0.0/24 network):

  router foo fw default drop
  router foo fw accept out 0 192.168.0.5:80 tcp
  

Note that we use 'out' here since we're applying the rule to the interface that's on the same network as the destination. The source and destination does not have to include a port.

New iptables chains can also be created, providing a method for grouping rules together instead of adding rules at the global level. Chains are then applied to one or more interfaces using the interface index. For example, one could put the previous rule into a chain named "allow-http" and apply it to the interface at index 0 via the following:

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0

Variants: router dhcp static

Configure running minirouter VMs running minirouter and miniccc.

Routers are configured by specifying or updating a configuration, and then applying that configuration with a commit command. For example, to configure a router on a running VM named 'foo' to serve DHCP on 10.0.0.0/24 with a range of IPs:

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

router takes a number of subcommands:

• 'log': Change the log level of the minirouter tool on the VM.

• 'interface': Set IPv4 or IPv6 addresses, or configure an interface to assign using DHCP. The interface field is an integer index of the interface defined with 'vm config net'. You could also specify if that interface will be a loopback interface For example, to configure the second interface of the router with a static IP and a loopback with a different IP:

  vm config net 100 200
  # ...
  router foo interface 1 10.0.0.1/24
  router foo interface 2 11.0.0.1/32 lo
  

• 'dhcp': Configure one or more DHCP servers on the router. The API allows you to set several options including static IP assignments and the default route and DNS server. For example, to serve a range of IPs, with 2 static IPs explicitly called out on router with IP 10.0.0.1:

  router vm foo dhcp 10.0.0.0 range 10.0.0.2 10.0.0.254
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:55 10.0.0.10
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:56 10.0.0.11
  

• 'dns': Set DNS records for IPv4 or IPv6 hosts.

• 'upstream': Set upstream server for DNS.

• 'gw': Set default gateway which will be used if there is no matching route.

• 'ra': Enable neighbor discovery protocol router advertisements for a given subnet.

• 'route': Set static, OSPF, or BGP routes. Static routes include a subnet, next-hop, and optionally a name for this router. For example to specify a static route(s):

  router foo route static 0.0.0.0/0 10.0.0.1 default-route
  

OSPF routes include an area and a network index corresponding to the interface described in 'vm config net'. You can also specify what networks to advertise using the export command.

For example, to enable OSPF on area 0 for both interfaces of a router:

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

For example, to advertise specific networks, advertise a static route or use a static route as a filter:

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

To configure BGP must specify the process name for the specific bgp context, local ip address and AS, Neighbor ip address and AS, and what networks need to be advertised

For example, local router is in AS 100 with an ip 10.0.0.1 and bgp peer is in AS 200 with an ip of 20.0.0.1 and you want to advertise network 10.0.0.0/24:

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

You can set up route reflection for BGP by using the rrclient command for that process. By using the command it indicates that the peer is a bgp client:

    router foo bgp bar rrclient

• 'rid': Sets the 32 bit router ID for the router. Typically this ID is unique across the organization's network and is used for various routing protocols ie OSPF

  router foo rid 1.1.1.1
  

• 'fw': specify flows to accept/drop/reject via iptables. For example, to globally globally drop all forwarded packets and accept HTTP traffic from any IP address to host 192.168.0.5 on the interface at index 0 (which is on the 192.168.0.0/24 network):

  router foo fw default drop
  router foo fw accept out 0 192.168.0.5:80 tcp
  

Note that we use 'out' here since we're applying the rule to the interface that's on the same network as the destination. The source and destination does not have to include a port.

New iptables chains can also be created, providing a method for grouping rules together instead of adding rules at the global level. Chains are then applied to one or more interfaces using the interface index. For example, one could put the previous rule into a chain named "allow-http" and apply it to the interface at index 0 via the following:

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0

Variants: router dns

Configure running minirouter VMs running minirouter and miniccc.

Routers are configured by specifying or updating a configuration, and then applying that configuration with a commit command. For example, to configure a router on a running VM named 'foo' to serve DHCP on 10.0.0.0/24 with a range of IPs:

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

router takes a number of subcommands:

• 'log': Change the log level of the minirouter tool on the VM.

• 'interface': Set IPv4 or IPv6 addresses, or configure an interface to assign using DHCP. The interface field is an integer index of the interface defined with 'vm config net'. You could also specify if that interface will be a loopback interface For example, to configure the second interface of the router with a static IP and a loopback with a different IP:

  vm config net 100 200
  # ...
  router foo interface 1 10.0.0.1/24
  router foo interface 2 11.0.0.1/32 lo
  

• 'dhcp': Configure one or more DHCP servers on the router. The API allows you to set several options including static IP assignments and the default route and DNS server. For example, to serve a range of IPs, with 2 static IPs explicitly called out on router with IP 10.0.0.1:

  router vm foo dhcp 10.0.0.0 range 10.0.0.2 10.0.0.254
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:55 10.0.0.10
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:56 10.0.0.11
  

• 'dns': Set DNS records for IPv4 or IPv6 hosts.

• 'upstream': Set upstream server for DNS.

• 'gw': Set default gateway which will be used if there is no matching route.

• 'ra': Enable neighbor discovery protocol router advertisements for a given subnet.

• 'route': Set static, OSPF, or BGP routes. Static routes include a subnet, next-hop, and optionally a name for this router. For example to specify a static route(s):

  router foo route static 0.0.0.0/0 10.0.0.1 default-route
  

OSPF routes include an area and a network index corresponding to the interface described in 'vm config net'. You can also specify what networks to advertise using the export command.

For example, to enable OSPF on area 0 for both interfaces of a router:

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

For example, to advertise specific networks, advertise a static route or use a static route as a filter:

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

To configure BGP must specify the process name for the specific bgp context, local ip address and AS, Neighbor ip address and AS, and what networks need to be advertised

For example, local router is in AS 100 with an ip 10.0.0.1 and bgp peer is in AS 200 with an ip of 20.0.0.1 and you want to advertise network 10.0.0.0/24:

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

You can set up route reflection for BGP by using the rrclient command for that process. By using the command it indicates that the peer is a bgp client:

    router foo bgp bar rrclient

• 'rid': Sets the 32 bit router ID for the router. Typically this ID is unique across the organization's network and is used for various routing protocols ie OSPF

  router foo rid 1.1.1.1
  

• 'fw': specify flows to accept/drop/reject via iptables. For example, to globally globally drop all forwarded packets and accept HTTP traffic from any IP address to host 192.168.0.5 on the interface at index 0 (which is on the 192.168.0.0/24 network):

  router foo fw default drop
  router foo fw accept out 0 192.168.0.5:80 tcp
  

Note that we use 'out' here since we're applying the rule to the interface that's on the same network as the destination. The source and destination does not have to include a port.

New iptables chains can also be created, providing a method for grouping rules together instead of adding rules at the global level. Chains are then applied to one or more interfaces using the interface index. For example, one could put the previous rule into a chain named "allow-http" and apply it to the interface at index 0 via the following:

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0

Variants: router fw router fw

Configure running minirouter VMs running minirouter and miniccc.

Routers are configured by specifying or updating a configuration, and then applying that configuration with a commit command. For example, to configure a router on a running VM named 'foo' to serve DHCP on 10.0.0.0/24 with a range of IPs:

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

router takes a number of subcommands:

• 'log': Change the log level of the minirouter tool on the VM.

• 'interface': Set IPv4 or IPv6 addresses, or configure an interface to assign using DHCP. The interface field is an integer index of the interface defined with 'vm config net'. You could also specify if that interface will be a loopback interface For example, to configure the second interface of the router with a static IP and a loopback with a different IP:

  vm config net 100 200
  # ...
  router foo interface 1 10.0.0.1/24
  router foo interface 2 11.0.0.1/32 lo
  

• 'dhcp': Configure one or more DHCP servers on the router. The API allows you to set several options including static IP assignments and the default route and DNS server. For example, to serve a range of IPs, with 2 static IPs explicitly called out on router with IP 10.0.0.1:

  router vm foo dhcp 10.0.0.0 range 10.0.0.2 10.0.0.254
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:55 10.0.0.10
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:56 10.0.0.11
  

• 'dns': Set DNS records for IPv4 or IPv6 hosts.

• 'upstream': Set upstream server for DNS.

• 'gw': Set default gateway which will be used if there is no matching route.

• 'ra': Enable neighbor discovery protocol router advertisements for a given subnet.

• 'route': Set static, OSPF, or BGP routes. Static routes include a subnet, next-hop, and optionally a name for this router. For example to specify a static route(s):

  router foo route static 0.0.0.0/0 10.0.0.1 default-route
  

OSPF routes include an area and a network index corresponding to the interface described in 'vm config net'. You can also specify what networks to advertise using the export command.

For example, to enable OSPF on area 0 for both interfaces of a router:

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

For example, to advertise specific networks, advertise a static route or use a static route as a filter:

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

To configure BGP must specify the process name for the specific bgp context, local ip address and AS, Neighbor ip address and AS, and what networks need to be advertised

For example, local router is in AS 100 with an ip 10.0.0.1 and bgp peer is in AS 200 with an ip of 20.0.0.1 and you want to advertise network 10.0.0.0/24:

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

You can set up route reflection for BGP by using the rrclient command for that process. By using the command it indicates that the peer is a bgp client:

    router foo bgp bar rrclient

• 'rid': Sets the 32 bit router ID for the router. Typically this ID is unique across the organization's network and is used for various routing protocols ie OSPF

  router foo rid 1.1.1.1
  

• 'fw': specify flows to accept/drop/reject via iptables. For example, to globally globally drop all forwarded packets and accept HTTP traffic from any IP address to host 192.168.0.5 on the interface at index 0 (which is on the 192.168.0.0/24 network):

  router foo fw default drop
  router foo fw accept out 0 192.168.0.5:80 tcp
  

Note that we use 'out' here since we're applying the rule to the interface that's on the same network as the destination. The source and destination does not have to include a port.

New iptables chains can also be created, providing a method for grouping rules together instead of adding rules at the global level. Chains are then applied to one or more interfaces using the interface index. For example, one could put the previous rule into a chain named "allow-http" and apply it to the interface at index 0 via the following:

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0

Variants: router fw chain action router fw chain action

Configure running minirouter VMs running minirouter and miniccc.

Routers are configured by specifying or updating a configuration, and then applying that configuration with a commit command. For example, to configure a router on a running VM named 'foo' to serve DHCP on 10.0.0.0/24 with a range of IPs:

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

router takes a number of subcommands:

• 'log': Change the log level of the minirouter tool on the VM.

• 'interface': Set IPv4 or IPv6 addresses, or configure an interface to assign using DHCP. The interface field is an integer index of the interface defined with 'vm config net'. You could also specify if that interface will be a loopback interface For example, to configure the second interface of the router with a static IP and a loopback with a different IP:

  vm config net 100 200
  # ...
  router foo interface 1 10.0.0.1/24
  router foo interface 2 11.0.0.1/32 lo
  

• 'dhcp': Configure one or more DHCP servers on the router. The API allows you to set several options including static IP assignments and the default route and DNS server. For example, to serve a range of IPs, with 2 static IPs explicitly called out on router with IP 10.0.0.1:

  router vm foo dhcp 10.0.0.0 range 10.0.0.2 10.0.0.254
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:55 10.0.0.10
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:56 10.0.0.11
  

• 'dns': Set DNS records for IPv4 or IPv6 hosts.

• 'upstream': Set upstream server for DNS.

• 'gw': Set default gateway which will be used if there is no matching route.

• 'ra': Enable neighbor discovery protocol router advertisements for a given subnet.

• 'route': Set static, OSPF, or BGP routes. Static routes include a subnet, next-hop, and optionally a name for this router. For example to specify a static route(s):

  router foo route static 0.0.0.0/0 10.0.0.1 default-route
  

OSPF routes include an area and a network index corresponding to the interface described in 'vm config net'. You can also specify what networks to advertise using the export command.

For example, to enable OSPF on area 0 for both interfaces of a router:

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

For example, to advertise specific networks, advertise a static route or use a static route as a filter:

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

To configure BGP must specify the process name for the specific bgp context, local ip address and AS, Neighbor ip address and AS, and what networks need to be advertised

For example, local router is in AS 100 with an ip 10.0.0.1 and bgp peer is in AS 200 with an ip of 20.0.0.1 and you want to advertise network 10.0.0.0/24:

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

You can set up route reflection for BGP by using the rrclient command for that process. By using the command it indicates that the peer is a bgp client:

    router foo bgp bar rrclient

• 'rid': Sets the 32 bit router ID for the router. Typically this ID is unique across the organization's network and is used for various routing protocols ie OSPF

  router foo rid 1.1.1.1
  

• 'fw': specify flows to accept/drop/reject via iptables. For example, to globally globally drop all forwarded packets and accept HTTP traffic from any IP address to host 192.168.0.5 on the interface at index 0 (which is on the 192.168.0.0/24 network):

  router foo fw default drop
  router foo fw accept out 0 192.168.0.5:80 tcp
  

Note that we use 'out' here since we're applying the rule to the interface that's on the same network as the destination. The source and destination does not have to include a port.

New iptables chains can also be created, providing a method for grouping rules together instead of adding rules at the global level. Chains are then applied to one or more interfaces using the interface index. For example, one could put the previous rule into a chain named "allow-http" and apply it to the interface at index 0 via the following:

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0

Variants: router fw chain apply

Configure running minirouter VMs running minirouter and miniccc.

Routers are configured by specifying or updating a configuration, and then applying that configuration with a commit command. For example, to configure a router on a running VM named 'foo' to serve DHCP on 10.0.0.0/24 with a range of IPs:

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

router takes a number of subcommands:

• 'log': Change the log level of the minirouter tool on the VM.

• 'interface': Set IPv4 or IPv6 addresses, or configure an interface to assign using DHCP. The interface field is an integer index of the interface defined with 'vm config net'. You could also specify if that interface will be a loopback interface For example, to configure the second interface of the router with a static IP and a loopback with a different IP:

  vm config net 100 200
  # ...
  router foo interface 1 10.0.0.1/24
  router foo interface 2 11.0.0.1/32 lo
  

• 'dhcp': Configure one or more DHCP servers on the router. The API allows you to set several options including static IP assignments and the default route and DNS server. For example, to serve a range of IPs, with 2 static IPs explicitly called out on router with IP 10.0.0.1:

  router vm foo dhcp 10.0.0.0 range 10.0.0.2 10.0.0.254
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:55 10.0.0.10
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:56 10.0.0.11
  

• 'dns': Set DNS records for IPv4 or IPv6 hosts.

• 'upstream': Set upstream server for DNS.

• 'gw': Set default gateway which will be used if there is no matching route.

• 'ra': Enable neighbor discovery protocol router advertisements for a given subnet.

• 'route': Set static, OSPF, or BGP routes. Static routes include a subnet, next-hop, and optionally a name for this router. For example to specify a static route(s):

  router foo route static 0.0.0.0/0 10.0.0.1 default-route
  

OSPF routes include an area and a network index corresponding to the interface described in 'vm config net'. You can also specify what networks to advertise using the export command.

For example, to enable OSPF on area 0 for both interfaces of a router:

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

For example, to advertise specific networks, advertise a static route or use a static route as a filter:

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

To configure BGP must specify the process name for the specific bgp context, local ip address and AS, Neighbor ip address and AS, and what networks need to be advertised

For example, local router is in AS 100 with an ip 10.0.0.1 and bgp peer is in AS 200 with an ip of 20.0.0.1 and you want to advertise network 10.0.0.0/24:

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

You can set up route reflection for BGP by using the rrclient command for that process. By using the command it indicates that the peer is a bgp client:

    router foo bgp bar rrclient

• 'rid': Sets the 32 bit router ID for the router. Typically this ID is unique across the organization's network and is used for various routing protocols ie OSPF

  router foo rid 1.1.1.1
  

• 'fw': specify flows to accept/drop/reject via iptables. For example, to globally globally drop all forwarded packets and accept HTTP traffic from any IP address to host 192.168.0.5 on the interface at index 0 (which is on the 192.168.0.0/24 network):

  router foo fw default drop
  router foo fw accept out 0 192.168.0.5:80 tcp
  

Note that we use 'out' here since we're applying the rule to the interface that's on the same network as the destination. The source and destination does not have to include a port.

New iptables chains can also be created, providing a method for grouping rules together instead of adding rules at the global level. Chains are then applied to one or more interfaces using the interface index. For example, one could put the previous rule into a chain named "allow-http" and apply it to the interface at index 0 via the following:

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0

Variants: router fw chain default action

Configure running minirouter VMs running minirouter and miniccc.

Routers are configured by specifying or updating a configuration, and then applying that configuration with a commit command. For example, to configure a router on a running VM named 'foo' to serve DHCP on 10.0.0.0/24 with a range of IPs:

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

router takes a number of subcommands:

• 'log': Change the log level of the minirouter tool on the VM.

• 'interface': Set IPv4 or IPv6 addresses, or configure an interface to assign using DHCP. The interface field is an integer index of the interface defined with 'vm config net'. You could also specify if that interface will be a loopback interface For example, to configure the second interface of the router with a static IP and a loopback with a different IP:

  vm config net 100 200
  # ...
  router foo interface 1 10.0.0.1/24
  router foo interface 2 11.0.0.1/32 lo
  

• 'dhcp': Configure one or more DHCP servers on the router. The API allows you to set several options including static IP assignments and the default route and DNS server. For example, to serve a range of IPs, with 2 static IPs explicitly called out on router with IP 10.0.0.1:

  router vm foo dhcp 10.0.0.0 range 10.0.0.2 10.0.0.254
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:55 10.0.0.10
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:56 10.0.0.11
  

• 'dns': Set DNS records for IPv4 or IPv6 hosts.

• 'upstream': Set upstream server for DNS.

• 'gw': Set default gateway which will be used if there is no matching route.

• 'ra': Enable neighbor discovery protocol router advertisements for a given subnet.

• 'route': Set static, OSPF, or BGP routes. Static routes include a subnet, next-hop, and optionally a name for this router. For example to specify a static route(s):

  router foo route static 0.0.0.0/0 10.0.0.1 default-route
  

OSPF routes include an area and a network index corresponding to the interface described in 'vm config net'. You can also specify what networks to advertise using the export command.

For example, to enable OSPF on area 0 for both interfaces of a router:

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

For example, to advertise specific networks, advertise a static route or use a static route as a filter:

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

To configure BGP must specify the process name for the specific bgp context, local ip address and AS, Neighbor ip address and AS, and what networks need to be advertised

For example, local router is in AS 100 with an ip 10.0.0.1 and bgp peer is in AS 200 with an ip of 20.0.0.1 and you want to advertise network 10.0.0.0/24:

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

You can set up route reflection for BGP by using the rrclient command for that process. By using the command it indicates that the peer is a bgp client:

    router foo bgp bar rrclient

• 'rid': Sets the 32 bit router ID for the router. Typically this ID is unique across the organization's network and is used for various routing protocols ie OSPF

  router foo rid 1.1.1.1
  

• 'fw': specify flows to accept/drop/reject via iptables. For example, to globally globally drop all forwarded packets and accept HTTP traffic from any IP address to host 192.168.0.5 on the interface at index 0 (which is on the 192.168.0.0/24 network):

  router foo fw default drop
  router foo fw accept out 0 192.168.0.5:80 tcp
  

Note that we use 'out' here since we're applying the rule to the interface that's on the same network as the destination. The source and destination does not have to include a port.

New iptables chains can also be created, providing a method for grouping rules together instead of adding rules at the global level. Chains are then applied to one or more interfaces using the interface index. For example, one could put the previous rule into a chain named "allow-http" and apply it to the interface at index 0 via the following:

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0

Variants: router fw default

Configure running minirouter VMs running minirouter and miniccc.

Routers are configured by specifying or updating a configuration, and then applying that configuration with a commit command. For example, to configure a router on a running VM named 'foo' to serve DHCP on 10.0.0.0/24 with a range of IPs:

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

router takes a number of subcommands:

• 'log': Change the log level of the minirouter tool on the VM.

• 'interface': Set IPv4 or IPv6 addresses, or configure an interface to assign using DHCP. The interface field is an integer index of the interface defined with 'vm config net'. You could also specify if that interface will be a loopback interface For example, to configure the second interface of the router with a static IP and a loopback with a different IP:

  vm config net 100 200
  # ...
  router foo interface 1 10.0.0.1/24
  router foo interface 2 11.0.0.1/32 lo
  

• 'dhcp': Configure one or more DHCP servers on the router. The API allows you to set several options including static IP assignments and the default route and DNS server. For example, to serve a range of IPs, with 2 static IPs explicitly called out on router with IP 10.0.0.1:

  router vm foo dhcp 10.0.0.0 range 10.0.0.2 10.0.0.254
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:55 10.0.0.10
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:56 10.0.0.11
  

• 'dns': Set DNS records for IPv4 or IPv6 hosts.

• 'upstream': Set upstream server for DNS.

• 'gw': Set default gateway which will be used if there is no matching route.

• 'ra': Enable neighbor discovery protocol router advertisements for a given subnet.

• 'route': Set static, OSPF, or BGP routes. Static routes include a subnet, next-hop, and optionally a name for this router. For example to specify a static route(s):

  router foo route static 0.0.0.0/0 10.0.0.1 default-route
  

OSPF routes include an area and a network index corresponding to the interface described in 'vm config net'. You can also specify what networks to advertise using the export command.

For example, to enable OSPF on area 0 for both interfaces of a router:

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

For example, to advertise specific networks, advertise a static route or use a static route as a filter:

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

To configure BGP must specify the process name for the specific bgp context, local ip address and AS, Neighbor ip address and AS, and what networks need to be advertised

For example, local router is in AS 100 with an ip 10.0.0.1 and bgp peer is in AS 200 with an ip of 20.0.0.1 and you want to advertise network 10.0.0.0/24:

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

You can set up route reflection for BGP by using the rrclient command for that process. By using the command it indicates that the peer is a bgp client:

    router foo bgp bar rrclient

• 'rid': Sets the 32 bit router ID for the router. Typically this ID is unique across the organization's network and is used for various routing protocols ie OSPF

  router foo rid 1.1.1.1
  

• 'fw': specify flows to accept/drop/reject via iptables. For example, to globally globally drop all forwarded packets and accept HTTP traffic from any IP address to host 192.168.0.5 on the interface at index 0 (which is on the 192.168.0.0/24 network):

  router foo fw default drop
  router foo fw accept out 0 192.168.0.5:80 tcp
  

Note that we use 'out' here since we're applying the rule to the interface that's on the same network as the destination. The source and destination does not have to include a port.

New iptables chains can also be created, providing a method for grouping rules together instead of adding rules at the global level. Chains are then applied to one or more interfaces using the interface index. For example, one could put the previous rule into a chain named "allow-http" and apply it to the interface at index 0 via the following:

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0

Variants: router gw

Configure running minirouter VMs running minirouter and miniccc.

Routers are configured by specifying or updating a configuration, and then applying that configuration with a commit command. For example, to configure a router on a running VM named 'foo' to serve DHCP on 10.0.0.0/24 with a range of IPs:

    router foo dhcp 10.0.0.0 range 10.0.0.100 10.0.0.200
    router foo commit

router takes a number of subcommands:

• 'log': Change the log level of the minirouter tool on the VM.

• 'interface': Set IPv4 or IPv6 addresses, or configure an interface to assign using DHCP. The interface field is an integer index of the interface defined with 'vm config net'. You could also specify if that interface will be a loopback interface For example, to configure the second interface of the router with a static IP and a loopback with a different IP:

  vm config net 100 200
  # ...
  router foo interface 1 10.0.0.1/24
  router foo interface 2 11.0.0.1/32 lo
  

• 'dhcp': Configure one or more DHCP servers on the router. The API allows you to set several options including static IP assignments and the default route and DNS server. For example, to serve a range of IPs, with 2 static IPs explicitly called out on router with IP 10.0.0.1:

  router vm foo dhcp 10.0.0.0 range 10.0.0.2 10.0.0.254
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:55 10.0.0.10
  router vm foo dhcp 10.0.0.0 static 00:11:22:33:44:56 10.0.0.11
  

• 'dns': Set DNS records for IPv4 or IPv6 hosts.

• 'upstream': Set upstream server for DNS.

• 'gw': Set default gateway which will be used if there is no matching route.

• 'ra': Enable neighbor discovery protocol router advertisements for a given subnet.

• 'route': Set static, OSPF, or BGP routes. Static routes include a subnet, next-hop, and optionally a name for this router. For example to specify a static route(s):

  router foo route static 0.0.0.0/0 10.0.0.1 default-route
  

OSPF routes include an area and a network index corresponding to the interface described in 'vm config net'. You can also specify what networks to advertise using the export command.

For example, to enable OSPF on area 0 for both interfaces of a router:

    vm config net 100 200
    # ...
    router foo route ospf 0 0
    router foo route ospf 0 1

For example, to advertise specific networks, advertise a static route or use a static route as a filter:

    router foo route static 11.0.0.0/24 0 bar-route
    router foo route static 12.0.0.0/24 0 bar-route
    router foo route ospf 0 export 10.0.0.0/24
    router foo route ospf 0 export default-route
    router foo route ospf 0 export bar-route

To configure BGP must specify the process name for the specific bgp context, local ip address and AS, Neighbor ip address and AS, and what networks need to be advertised

For example, local router is in AS 100 with an ip 10.0.0.1 and bgp peer is in AS 200 with an ip of 20.0.0.1 and you want to advertise network 10.0.0.0/24:

    router foo route static 10.0.0.0/24 0 foo_out
    router foo bgp bar local 10.0.0.1 100
    router foo bgp bar neighbor 20.0.0.1 200
    router foo bgp bar export filter foo_out

You can set up route reflection for BGP by using the rrclient command for that process. By using the command it indicates that the peer is a bgp client:

    router foo bgp bar rrclient

• 'rid': Sets the 32 bit router ID for the router. Typically this ID is unique across the organization's network and is used for various routing protocols ie OSPF

  router foo rid 1.1.1.1
  

• 'fw': specify flows to accept/drop/reject via iptables. For example, to globally globally drop all forwarded packets and accept HTTP traffic from any IP address to host 192.168.0.5 on the interface at index 0 (which is on the 192.168.0.0/24 network):

  router foo fw default drop
  router foo fw accept out 0 192.168.0.5:80 tcp
  

Note that we use 'out' here since we're applying the rule to the interface that's on the same network as the destination. The source and destination does not have to include a port.

New iptables chains can also be created, providing a method for grouping rules together instead of adding rules at the global level. Chains are then applied to one or more interfaces using the interface index. For example, one could put the previous rule into a chain named "allow-http" and apply it to the interface at index 0 via the following:

    router foo fw chain allow-http default action drop
    router foo fw chain allow-http action accept 192.168.0.5:80 tcp
    router foo fw chain allow-http apply out 0