Remote PC Directives

Remote PC configuration directives are used to define the configuration of remote PCs in a pod design.

  • A remote PC is bound to a virtual machine that is configured to act as a PC or server.

  • Each remote PC has an index number starting with 1 (not 0).

  • The index matches the remote PC number in the pod design (e.g., pc.1).

  • The system administrator may choose to not implement a remote PC (setting ABSENT).

pc.<i>.name

The configuration name used to refer to the remote PC in the pod design.

Note

The name is used for identification within the pod design and is not presented to the user in the lab environment.

Synopsis

pc.<i>.name=<label>

  • <i> is the remote PC index number (1, 2, etc.) starting at 1 (not 0)

  • <label> is a text string to identify the remote PC.

    • Use ASCII A-Z, a-z, 0-9, and _ (underscore) characters only.

    • Do not use spaces or enclose in quotes.

Examples

pc.1.name=client1
pc.2.name=server1

pc.<i>.net.vnic.<n>.portgroup.id

Binds a virtual NIC on the remote PC to a port group on a virtual switch.

Note

This directive is not used for remote PCs that interact with Hybrid Pods. See pc.<i>.net.vnic.<n>.vlan setting for those scenarios.

Synopsis

pc.<i>.net.vnic.<n>.portgroup.id=<id>

  • <i> is the remote PC index number (1, 2, etc.) starting at 1 (not 0).

  • <n> is the virtual NIC index number (1, 2, etc.) starting at 1 (not 0).

  • <id> is the port group ID of a defined port group.

Important

The port group ID must be defined in the pod design using the vswitch.<n>.portgroup.<p>.id directive.

Examples

# Define port groups on the virtual switch
vswitch.0.portgroup.0.id=LAN
vswitch.0.portgroup.1.id=WAN
vswitch.0.portgroup.2.id=DMZ

# Bind client 1 to the LAN port group
pc.1.name=client1
pc.1.net.vnic.1.portgroup.id=LAN

# Bind vrouter to all multiple port groups, one for each virtual NIC.
pc.2.net.vnic.1.portgroup.id=LAN
pc.2.net.vnic.2.portgroup.id=WAN
pc.2.net.vnic.3.portgroup.id=DMZ

# Bind client 2 to the LAN port group
pc.3.name=client2
pc.3.net.vnic.1.portgroup.id=LAN

pc.<i>.net.vnic.<n>.vlan

Bind a virtual NIC on the remote PC to a VLAN on the inside switch control switch.

Note

This directive is only used for remote PCs that interact with real equipment in Hybrid Pods. A network interface (NIC) can be bound either to a port group on a virtual switch or a relative VLAN on a control switch. When binding to a relative control switch VLAN, the virtual NIC is always bound to the relative VLAN specified by this directive. In other words, the relative VLAN on a virtual NIC is fixed and cannot not change per lab exercise. maps. Lab authors must account for this when using VLAN maps.

Synopsis

pc.<i>.net.vnic.<n>.vlan=<vlan_id>

  • <i> is the remote PC index number (1, 2, etc.) starting at 1 (not 0)

  • <n> is the virtual NIC index number (1, 2, etc.) starting at 1 (not 0)

  • <vlan_id> is the VLAN letter to bind the virtual NIC to, A-Z.

Important

Relative VLANs must be enabled using the pod.auto.net.control_switch.vlans directive.

Examples

# Enable this pod to communicate with real equipment using relative VLANs
# A and B.
pod.auto.net.control_switch.vlans=A,B

# Create port group dmz. This network cannot interact with real equipment.
vswitch.0.portgroup.0.id=dmz

# Bind PCA's first virtual NIC to VLAN A. Equipment whose control ports are
# mapped to VLAN A (using VLAN maps) will be able to communicate with PCA.
pc.1.name=pca
pc.1.net.vnic.1.vlan=A

# Bind PCB's first virtual NIC to VLAN B.
pc.2.name=pcb
pc.2.net.vnic.1.vlan=B

# Bind firewall's first virtual NIC to VLAN A and the second virtual NIC to VLAN B.
# The third virtual NIC is bound to the port group foo and cannot interact with real
# equipment.
pc.3.name=firewall
pc.3.net.vnic.1.vlan=A
pc.3.net.vnic.2.vlan=B
pc.3.net.vnic.3.portgroup.id=dmz

pc.<i>.net.vnic.<n>.mac_address

Determines how MAC addresses on virtual NICs are handled during cloning operations and when a virtual machine starts.

Added in 25.0.0

This directive was introduced in NETLAB+ version 25.0.0 and is ignored in previous versions.

Synopsis

pc.<i>.net.vnic.<n>.mac_address=<value>

  • <i> is the remote PC index number (1, 2, etc.) starting at 1 (not 0)

  • <n> is the virtual NIC index number (1, 2, etc.) starting at 1 (not 0)

  • <value> is one of the following:

Value

Meaning

keep

Preserve the MAC address when the virtual machine is cloned. Does not alter the MAC address when the virtual machine starts. This is the default behavior and most commonly used.

unique

Generate a new MAC address when the virtual machine is cloned. This MAC address is not altered when the virtual machine is started. This option is helpful when a virtual NIC is placed on a common network segment with other pods, and a duplicate MAC address would be problematic.

nn:nn:nn:nn:nn:nn

Use this specified MAC address when the virtual machine is cloned and when the virtual machine is started.

Tip

It recommended to use keep or specify a MAC address so that network interfaces are deterministically bound to the correct bus address. This helps to ensure that the same network is always bound to the same interface name (e.g. eth0, eth1, etc.). This is particularly important for Linux virtual machines where device initialization order can sometimes change (search udev rules). The excecption to this rule is then the network interface may be bound to a common network segment with other pods, and a duplicate MAC address would cause problems; in this case, use unique.

Important

This setting is implemented by NETLAB+. Extra care should be exercised when cloning, moving, or configuring virtual machines outside of NETLAB+.

Example 1

# A typical VM.
pc.1.name=client1
pc.1.net.vnic.1.mac_address=keep

Example 2

# Pin the MAC address to a specific value.
pc.1.name=client1
pc.1.net.vnic.1.mac_address=00:11:22:33:44:55

Example 3

# This is an internet gateway virtual machine.
# This interface is bound to an inside segment within one pod.
pc.1.name=gateway
pc.1.net.vnic.1.portgroup.id=inside
pc.1.net.vnic.1.mac_address=keep

# This interface is bound to a common segment with other pods.
pc.1.net.vnic.2.portgroup.id=internet
pc.1.net.vnic.2.mac_address=unique

pc.<i>.target_resolution.width

The target width of the remote PC’s display resolution in pixels.

Synopsis

pc.<i>.target_resolution.width=<width>

  • <i> is the remote PC index number (1, 2, etc.) starting at 1 (not 0)

  • <width> is the target width of the remote PC’s display resolution in pixels. Default is 1280.

Recomendations

  • This should be set to the width of the remote PC’s display resolution in pixels at the time of snapshot.

  • Some viewers will allow the user to resize the remote PC’s display, but the target resolution will be set to the value specified in the pod design.

  • NDG currently recommends a resolution of 1280 x 960 pixels for desktops, and a resolution of 800 x 600 for devices presenting a command line interface (shell, console, etc.)

Examples

pc.1.target_resolution.width=1280
pc.2.target_resolution.width=960

pc.<i>.target_resolution.height

The target height of the remote PC’s display resolution in pixels.

Synopsis

pc.<i>.target_resolution.height=<height>

  • <i> is the remote PC index number (1, 2, etc.) starting at 1 (not 0)

  • <height> is the target height of the remote PC’s display resolution in pixels. Default is 768.

Recommendations

  • This should be set to the height of the remote PC’s display resolution in pixels at the time of snapshot.

  • Some viewers will allow the user to resize the remote PC’s display, but the target resolution will be set to the value specified in the pod design.

  • NDG currently recommends a resolution of 1280 x 960 pixels for desktops, and a resolution of 800 x 600 for devices presenting a command line interface (shell, console, etc.)

Examples

pc.1.target_resolution.width=1280
pc.2.target_resolution.width=960

pc.<i>.boot.delay

Sometimes it is necessary to defer the booting of a virtual machine to allow other virtual machines or resources to become available first. NETLAB+ provides three advanced configuration settings that can control deferred booting.

These settings are enforced:

  • At the beginning of a lab reservation.

  • When a user switches lab exercises during a reservation, if the user chooses to reset virtual machines at that time.

The boot.delay directive delays the boot of a virtual machine by a specified number of seconds. The default is 0 seconds (no delay).

Added in 22.7.3

This directive was introduced in NETLAB+ version 22.7.3 and is ignored in previous versions.

Synopsis

pc.<i>.boot.delay=<seconds>

  • <i> is the remote PC index number (1, 2, etc.) starting at 1 (not 0)

  • <seconds> is the number of seconds to delay the boot of the virtual machine. 0 is the default (no fixed delay).

Note

The specified delay time will be accurate to within 5 seconds. Other settings may cause this value to be ignored or adjusted.

Example

# Delay the boot of the remote PC by 30 seconds.
pc.1.boot.delay=30

pc.<i>.boot.after_pc_index

This directive causes the remote PC with index pc.<i> to boot after the PC with index pc.<j> boots. Both pc.<i> and pc.<j> are the remote PC indices of the virtual machines, as shown in the Pod Designer. NETLAB+ considers a virtual machine to have booted when the guest tools process is running on the virtual machine:

  • For Proxmox, this is when the virtio driver is loaded.

  • For VMware, this is the VMware Tools driver is loaded.

Added in 22.7.3

This directive was introduced in NETLAB+ version 22.7.3 and is ignored in previous versions.

Synopsis

pc.<i>.boot.after_pc_index=<j>

  • <i> is the remote PC index number (1, 2, etc.) starting at 1 (not 0).

  • <j> is the remote PC index number of the virtual machine that must boot first.

Exceptions

  • This setting is ignored if pc.<i> is absent, or pc.<j> is not used by a lab exercise.

  • If pc.<i>.boot.delay is not specified, a minimum value of 120 seconds is set when pc.<i>.boot.after_pc_index=<j> is specified.

    • This ensures that pc.<i> will eventually boot, even if guest tools on pc.<j> is never detected.

    • This delay may be too long, so it is always best to set boot.delay to a reasonable value when using pc.<i>.boot.after_pc_index.

Example

# Boot the clients after the server boots.
pc.1.name=client1
pc.2.name=client2
pc.3.name=server
pc.1.boot.after_pc_index=3
pc.2.boot.after_pc_index=3

pc.<i>.boot.after_pc_extra

Used in conjunction with pc.<i>.boot.after_pc_index, this directive causes the remote PC with index pc.<i> to wait an extra amount of time (in seconds) to boot, after guest tools are detected on PC with index pc.<j>.

  • For Proxmox, this is when the virtio driver is loaded.

  • For VMware, this is the VMware Tools driver is loaded.

Added in 22.7.3

This directive was introduced in NETLAB+ version 22.7.3 and is ignored in previous versions.

Synopsis

pc.<i>.boot.after_pc_extra=<seconds>

  • <i> is the remote PC index number (1, 2, etc.) starting at 1 (not 0).

  • <seconds> is the number of additional seconds to wait after guesst tools are detected on the PC with index pc.<j>.

Exceptions

  • This setting is ignored for pc.<i> if pc.<j> is absent, or pc.<j> is not used by a lab exercise.

  • This setting is also ignored if the setting pc.<i>.boot.after_pc_index is omitted.

  • If pc.<i>.boot.delay is not specified, a minimum value of 120 seconds plus the pc.<i>.boot.after_pc_extra setting.

    • This ensures that pc.<i> will eventually boot, even if guest tools on pc.<j> are never detected.

    • This delay may be too long, so it is always best to set pc.<i>.boot.delay to a reasonable value when using pc.<i>.boot.after_pc_index.

Example 1

This example will cause the remote PC with index 2 to defer booting until one of the following conditions occurs (whichever comes first):

  • VMware Tools is running on the PC with index 5, AND 15 extra seconds have elapsed.

  • 60 seconds have elapsed since the pod reservation was started.

pc.2.name=client2
pc.5.name=server3
pc.2.boot.after_pc_index=5
pc.2.boot.after_pc_extra=15

Example 2

This example will cause the remote PC with index 2 to defer booting until one of the following conditions occurs (whichever comes first):

  • VMware Tools is running on the PC with index 5, AND 10 extra seconds have elapsed.

  • 120 seconds have elapsed since the pod reservation was started. This is the default setting for pc.2.boot.delay if not specified AND pc.2.boot.after_pc_index is set.

pc.2.boot.after_pc_index=5
pc.2.boot.after_pc_extra=10

pc.<i>.vmx_uuid_bios_clone

When enabled, NETLAB+ will preserve the BIOS UUID of the virtual machine when it is cloned by NETLAB+.

  • Each virtual machine is automatically assigned a universally unique identifier (UUID), which is stored in the SMBIOS system information descriptor. It can be accessed by standard SMBIOS scanning software (for example, SiSoftware Sandra or the IBM utility smbios2) and is used for system management in the same way you use the UUID of a physical computer.

  • Normally when a virtual machine is moved or copied, the UUID is regenerated to ensure that each virtual machine has a unique identifier.

  • This directive can be used in combination with pc.<i>.vmx_uuid_action=keep to control the UUID when a virtual machine is moved or copied outside of NETLAB+ each virtual machine has a unique identifier.

  • This directive is useful when you want to maintain the same BIOS UUID for a virtual machine when cloned to avoid triggering a license reactivation or other issues that may arise from a change in the BIOS UUID.

Note

You are responsible for ensuring that all software is properly licensed.

Synopsis

pc.<i>.vmx_uuid_bios_clone=<value>

  • <i> is the remote PC index number (1, 2, etc.) starting at 1 (not 0).

  • <value> is either 1 (enabled) or 0 (disabled).

Value

Meaning

1

Preserve the BIOS UUID of the virtual machine when it is cloned by NETLAB+.

0

Generate a new BIOS UUID of the virtual machine when it is cloned. (default)

Note

This option only applies to the cloning of virtual machines by NETLAB+, either through the user interface or NETLAB Python SDK. It does not apply to the cloning of virtual machines using the VCSA or by other means.

Tip

Practically, you would only use pc.<i>.vmx_uuid_bios_clone=1 in combination with pc.<i>.vmx_uuid_action=keep to preserve the BIOS UUID, otherwise it is best to omit both directives.

Example

pc.1.name=desktop1
# Preserve the BIOS UUID of the virtual machine when it is cloned by NETLAB+.
pc.1.vmx_uuid_bios_clone=1

# Preserve the BIOS UUID if the virtual machine is moved or copied outside of NETLAB+.
pc.1.vmx_uuid_action=keep

pc.<i>.vmx_uuid_action

This directive controls the BIOS UUID chosen when a virtual machine is moved or copied.

  • Each virtual machine is automatically assigned a universally unique identifier (UUID), which is stored in the SMBIOS system information descriptor. It can be accessed by standard SMBIOS scanning software (for example, SiSoftware Sandra or the IBM utility smbios2) and is used for system management in the same way you use the UUID of a physical computer.

  • Normally when a virtual machine is moved, or copied, the UUID is regenerated to ensure that each virtual machine has a unique identifier. However, in some cases, it may be desirable to keep the UUID the same. This directive controls the action taken when a virtual machine is moved or copied.

  • This directive is useful when you want to maintain the same UUID for a virtual machine when cloned to avoid triggering a license reactivation or other issues that may arise from a change in the UUID.

Note

You are responsible for ensuring that all software is properly licensed.

Synopsis

pc.<i>.vmx_uuid_action=<action>

  • <i> is the remote PC index number (1, 2, etc.) starting at 1 (not 0)

  • <action> is one of the following values:

Value

Meaning

keep

Keep the UUID the same when the virtual machine is moved or copied outside of NETLAB+.

create

Generate a new UUID when the virtual machine is moved or copied. This is the default behavior.

Exceptions

  • This option only applies to virtual machines that are moved or copied outside of NETLAB+.

  • This setting can be used in combination with pc.<i>.vmx_uuid_clone=1 to control the UUID when a virtual machine is cloned by NETLAB+.

  • For VMware virtual machines, this value corresponds to the uuid.action setting in the virtual machine’s .vmx file.

Examples

pc.1.name=desktop1
# Preserve the BIOS UUID of the virtual machine when it is cloned by NETLAB+.
pc.1.vmx_uuid_bios_clone=1

# Preserve the BIOS UUID if the virtual machine is moved or copied outside of NETLAB+.
pc.1.vmx_uuid_action=keep

pc.<i>.nested_vm_support

Enable and/or verify nested virtualization support for a virtual machine.

Proxmox

This setting sets the virtual machine’s CPU type to host as required for nested virtualization.

Warning

By setting the CPU type to host, the underlying host CPU features are passed through to the virtual machine. This may cause issues for live migration.

KVM may filter out some host CPU model features if they cannot be supported with virtualization. Live migration is unsafe when this mode is used as libvirt / QEMU cannot guarantee a stable CPU is exposed to the guest across hosts. This is the recommended CPU to use, provided live migration is not required.

VMware vSphere

This setting enables the hardware assisted virtualization (VHV) for the virtual machine.

Syntax

pc.<i>.nested_vm_support=<value>

  • <i> is the remote PC index number (1, 2, etc.) starting at 1 (not 0).

  • <value> is either 1 (enabled) or 0 (disabled).

Example

pc.1.name=esx1
pc.1.nested_vm_support=1