Common Steps To Make A “Child” “Virtual Machine” Config
This is a guide for creating a virtual machine as a “child” from an existing virtual machine that is called the “parent”. Disk images, presumably related to the “parent”, are used (on an ongoing basis) by the child. Furthermore, the “parent” may be useful for having things like script files that can be copied, but those details are simply copied once. After being copied, there is no ongoing relationship/connection/requirement that needs the original system to be operational in order for the child image to operate, except for the disk images (that were already just mentioned).
- Set some key variables
- Actually, work with documentation first
If you have a template for new computer systems, copy that so that the network documentation has a section about this latest computer. Then, the recommended way to set these variables is to follow these steps:
- Follow this guide's section about what variables need to be set
As each new variable name is introduced, update the documentation
- The documentation can contain the precise commands needed to set the variables
- Then, to actually set the variables, just use “copy and paste”, copying from the documentation and pasting into a terminal window.
- Setting parent
The first thing you'll need (to know, and have this information handy) is the name of the parent system. (Specifically, the value that is used for the
variable for that system.) If you aren't sure what system you want to use as a “parent”, then fix that problem right now. That information needs to start being readily available, so perform any research that is needed, and make any decisions that are required to have that information handy.
Store that name (which is the name of the parent system) in the
Actually, if you have just been working with that parent, and haven't updated the
VMLILNAMvariable yet, then the following might work. (For safety, to help prevent accidental overwriting, this example only works if
VMParNamis currently blank.)
Otherwise, just set
Just, somehow, get this set to the right value.
- Naming the child
It is time to Christen the child. (In other words, provide the name for the child.)
Specifically, what this refers to The
VMLILNAMvariable should be updated, although the
VMGenNamvariables can probably remain the same.
- Creating the disk images
Follow instructions at:
Hopefully, documentation was already started so that the environment variables may be set. In truth, if you can remember the desired name of the system, there's often little difficulty in putting off the documentation until approximately now.
Soon, a VMNUM will need to be chosen. If you don't remember what VMNUMs have been used already, then documentation may need to be checked. Since documentation is being accessed, this is a perfect time to get some documentation up to date.
Copy documentation from an example/template system, and update some key fields. Especially update:
VMLILNAM(so that the documentation of this system starts to look unique, different than the template that was copied),
VMNUMis about to be used).
Also, since the
VMNUMis now readily available, update the following documentation which is related to the
- The IPv6 link-local address
- The names of every TUN/TAP device
- The “Remote Access” section's details about how to use the IPv6 link-local address
- The “Remote Access” section's details about the default IPv6 address: specifically the comment about which TUN/TAP device is related. (This isn't really necessary if such details just get deleted out of the documentation anyway. But if they are unnecessarily kept, then the details may as well be correct.)
It is also good to figure out what the IPv6 (non-“link-local”) and IPv4 addresses will be, and update them now too.
- Update details for “ipv6rt” for each NIC
- Update details for “ipv4rt” for each NIC
- Update details in the “Remote Access” section
- Placing a new script file
Get a copy of the script file
You can either copy an existing script file, or re-download it.
- Copying an existing script file might go faster. However, because people may have customized an existing script file, and perhaps some customization might not be something that the new machine should use, this guide follows the process of using the original script file. The thought was that starting from scratch, and going through the whole standard process, is probably safer. Therefore, people who rely on this guide are recommended to use the original script file.
- To get a copy from the source again, see: getting Qemu script file.
- You can either copy an existing script file, or re-download it.
After making sure that you have the script file, the new script file should go in a sensible location, such as a directory that is related to the new machine. This is done when following all of the steps from the section on putting Qemu script file.
- Place a copy of the script file where the “virtual machine” script file will be expected. This can be done by following the steps described by: putting Qemu script file, which installs a copy of the script file that this guide uses as a basic template.
Instead of using the original script file, there are some other options that may exist. One such option is to use a different template that has been saved. Another possible option could be using a copy of the “startup script” of another virtual machine. This guide doesn't go through the steps of performing these alternatives. People who are copying an existing script file should just make sure that variables are set (verify virtualization variable values), and then continue to be careful to perform the process correctly.
- Get a copy of the script file
- Initial Updates to the script's commands
In this first “Common Qemu Script Updates” section, you can ignore the comment about networking... that will be covered after this first section.
- Typical script file updates
- Perform the steps described by: Common Qemu Script Updates