Handling “child” virtual machines: Early Steps: Logging in

(This is just about being able to log in. Once a successful login has been made, the rest of the instructions in this “Early Steps: Logging in” sub-section can be skipped. If a person is successfully logged in before following any of the instructions in this section, then this “Early Steps: Logging in” sub-section can be entirely skipped.)

Start the virtual machine

First, verify virtualization variable values.

echo VMDirBas=${VMDirBas} VMGenNam=${VMGenNam} VMLILNAM=${VMLILNAM}

Then, go ahead and start up the virtual machine (if it is not currently started.)

Viewing output from local display

If the system has a known IP address, then creating the VNC connection may be optional. (The alternative is to use a “remote access” protocol, such as SSH, to connect to a known IP address.) Still, this isn't a particularly bad thing to do. If the system doesn't have a known IP address, then this may be rather required, as a way to be able to start using the system.

Implementation Details
Qemu's VNC

Here are some highlights from use Qemu VNC.

telnet 72##

(Of course, that should be customized based on the actual TCP port, which may contain the VMNUM value.)

(qemu) change vnc localhost:20,password
(qemu) change vnc password

(Typically, the only part that needs to be changed/customized there is the desired VNC desktop number.)

Also, enable SSH port forwarding, and use the VNC client. If further details need to be reviewed again, check out use Qemu VNC again. Note that you'll need to use a different TCP port (which means using a different VNC desktop number) for every system that will be connected to simultaneously. To avoid conflicts (by accidentally trying to have two machines use the same TCP port), and to keep track (which can help avoid connecting to a different system than intended), a great idea is to use the VMNUM as a VNC desktop number.

Log in
How to log in

If you know the IP address of the system, you can try using a “remote access” protocol like SSH. (Using a default address might be an option. Otherwise, if automatic addressing hasn't been set up yet, then that might simply not be an option yet. However, this guide recommends not getting into the habit of just dismissing this step, because later on this process may be an option when performing a similar task on a newer system.)

If you want to use an IPv6 link-local address (which starts with “fe80:”), that is a feasible option. However, the SSH client must be on the same network link. (This typically means that the systems will be on the same subnet for IPv6 addresses that are not link-local). Also, the SSH client may need to know the name of the NIC to use on the machine that runs the SSH client software. So if the SSH server is on a system with an IPv6 address of 2001:db8::1, and the SSH client will be using a NIC named em1, then the SSH client needs to be told to connect to “ 2001:db8::1%em1 ”.

If using a “remote access” protocol (like SSH) isn't an option, then log in using the system's local display. (See the previous instructions for details about how to do that.) Then, if the system reports the IP address, you may be able to see the IP address before logging in. (If needed, pressing PgUp or Shift+PgUp or Ctrl-PgUp might help with scrollback.) In that case, using a “remote access” protocol may become a feasible option.

Log in. Presumably there is a user account that you have access to.


If you're having troubles handling networking after the machine is started, then the following may help.

You may wish to stop the virtual machine software entirely, and then destroy the TUN/TAP devices.

sudo ifconfig tun0

Then, restarting the Qemu software should re-create the TUN/TAP devices. Going through this process can help to make sure that Qemu is successfully creating the TUN/TAP devices, as expected. (If that isn't the case, such as if an incorrect TUN/TAP device is specified, then mucking around with other settings, like an IP address, could be futile. So perform this test rather early.)

  • Make sure that the TUN/TAP device has the LINK0 flag
  • Make sure that the TUN/TAP device has the expected IP address
    • (To clarify: the TUN/TAP device does not need an IP address if it is going to be bridged with another TUN/TAP device that is connected to another device that has an IP address. So, the “expected” IP address could be “none”. However, if you are trying to get the TUN/TAP device to respond to IP communications directly, then it would need an IP address to accomplish that goal.)

Also, if the “physical machine” (which is running the “virtual machine” software) should be running a DHCP dedicated to this NIC, then make sure that is running. The following may help:

sudoedit ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif0


echo ${0} starting NIC ${1}
export VMNIC=tun0
echo Actually using VMNIC=${VMNNIC}
sudo ifconfig ${VMNIC} prefixlen 24
sudo ifconfig ${VMNIC} link0
sudo ifconfig ${VMNIC} up
sudo ifconfig ${VMNIC} fd00::1 prefixlen 64
echo About to end DHCP server...
sudo pkill -l dhcpd -c /etc/dhcpd-${VMNIC}.conf
echo Done ending DHCP server...
sudo dhcpd -c /etc/dhcpd-${VMNIC}.conf
exit 0

Sometimes, Qemu has been known to nicely provide the NIC's name to the script. Other times, it seems that ${1} ends up being unset. It has even been seen to be set to “??” (a couple of question marks). So, this sample script is not relying on the parameter.

Of course, the correct network interface should be specified. Customize as appropriate.

Specific implementations of network address assignment

Then, if the virtual machine is already running, you can try the following to help test (less thoroughly, but more quickly) the results of this script.

sudo ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif0 tun0

See results:

sudo ifconfig tun0
ps -auxww | grep -i dhcpd | grep -v grep | grep -i tun0

the NIC should have flags including UP and LINK0. The status should be “status: active”.