[#mkvmcfg]:

Creating a configuration for a virtual machine

Recommendation: If this hasn't yet been done, grab a skeletal form of key system info. Copy this document into the main documentation file. Fill it out for the first system.

The following examples may show the process of creating a virtual machine without any (working) network interface cards. For the sake of simplifying each step of instructions (at least for at least some implementations), later instructions provide details about implementing network support to an already-created virtual machine.

Depending on what implementation (i.e. which virtual machine software, and which command line options) gets used, there may be a need for some port numbers, for something like a VNC session. If any sort of computer networking is going to be used for interacting with the system, then, in anticipation of the likely impending need, select a range of available ports. Some details of this (not strictly required) step may be found in a tutorial on making a virtual machine.

The actual step of creating the virtual machine involves a process that is specific to whichever software is being used to implement the virtual machines. Follow the steps from whichever of the following sections is most appropriate.

[#mkqmucfg]: Qemu Virtual Machine Configuration

This can be done by creating/editing text files. Another option may be to use graphical front-end software for Qemu. Chances are that such a front-end may just make text files anyway, so this guide to editing text files may show what is happening behind the scenes anyway.

Necessary file(s)

There are a few files with Qemu that may be related to a virtual machine. Other than the executable and the disk images, all of these files are all optional, in the sense that Qemu may simply be started from a command line. However, the command line may be lengthy enough that re-typing it later would be at least a bit undesirable if such an action is easy to not need to do. Therefore, it makes sense to run the Qemu machine from a script, especially if that script ends up handling things like networking. It also makes sense to have any machine-specific NIC scripts (that each help to configure a NIC on the machine) in one location, near the script that starts the virtual machine. Also, the optional PID file is good to use.

[#qemusysb]: Desired Qemu executable

Before running an executable, it will likely be worthwhile to determine the name of the best executable to use. Traditionally, the name of the executable has been qemu. However, some newer options may be more specific, and so presumably be better to use. From a command line, try typing qemu, but don't press the Enter key. Instead, press the tab key twice. With at least some shells, that will show the available commands inside the PATH which start with the letters qemu. If that doesn't work to show a list of available executables, try running “which qemu”. Then, if the which command shows that the executable is located at /usr/local/bin/qemu then run “ls -l /usr/local/bin/*qem* ”.

There will likely be multiple executables, including qemu and qemu-img. If there are others, see if any are more appropriate. The QEmu User Documentation: section for emulating targets other than the standard “PC” architecture mentions some of the executable names that start with qemu-system-. There may be others. For example, if the desired system to be emulated is a 64-bit x86 system, OpenBSD 4.9's Qemu 0.13.0p1 came with an qemu-system-x86_64 command (which did not seem to be mentioned in the online QEmu User Documentation, but was in a /usr/local/share/doc/qemu/qemu-* file). If there is an executable with a name resembling the desired target architecture, then that executable may be the most appropriate command to run. In that case, one option is to substitute qemu-system-x86_64 when this guide is generally recommending to run qemu. Another option may be to create a symbolic link. e.g.:

cd /usr/local/bin
# First, verify that the source file exists.
ls -l qemu*
# Then, make destination.
ln -s qemu-system-x86_64 qemu
ls -l qemu*
Choosing a machine to emulate

(This may need some review to verify how this works. Largely, not using -M has typically worked out okay.)

For a generic PC, use x86.

The above is simply a guideline. It would seem sensible to use x86_64 if the following is all true:

  • The hardware of the host environment is a 64-bit architecture
  • The operating system of the host computer is 64-bit. (This rather implies the last bullet point
  • The version of the virtual machine software being used supports x86_64

However, there may be little benefit in using x86_64 rather than the 32-bit x86 target. One of the key benefits of x86_64 is speed, although some speed may be lost by the virtualization cost. Also (and this may just be speculation), perhaps emulating a simpler machine might go faster. (Or, emulating a virtual machine that is more similar to the physical machine might be faster. So, which is faster? Perhaps the correct answer is actually implementation-dependent.) Other than speed, the other key benefit usually attributed to going with 64-bit hardware is better support more than 4GB of RAM. However, some versions of the virtual machine software may not support this anyway. (Specifically, there may be some applicable commentary in upcoming information, about the (lowercase) “ -m ” parameter that is used to specify the amount of available memory.) Check into that, before using a deisre for more memory as the basis of choosing x86_64.

qemu -M \? may show a list of architectures supported by the specific executable being used. (Note that backslash before the question mark is meant as an escape character, and may not be needed for some shells other than /bin/sh (and even with /bin/sh the backslash may not be needed depending on what exists in the current directory.)) In this case, this guide is going to proceed with using the default, so the guide might not show another “-M” parameter sequence being used.

Making a command file in Unix

(This subsection's text is largely just about running a text editor and specifying which customized filename is used for the name of the script that will run the virtual machine. Experienced users who are following this guide on their own may skip and/or customize these steps as appropriate.)

If the prior preparing for a vm cmd was followed in Unix, using the following command may work well:

$VISUAL $VMDir/bin/exc_base_system

(If that doesn't run a text editor, see the sections on preparing to make a virtual machine configuration and edit a text file, especially the section on editing a text file with common Unix environmental variables.)

In the above example, the customizable filename exc_base_system is meant to be named after the name of the virtual machine. Presumably the chances are high that the chosen name was something other than “base_system”, so feel free to customize the filename so that a more appropriate filename is used. The prefix of exc_ was meant to convey that this file is designed to executable (a.k.a. start) a process (which will run the virtual machine).

Details on customizing the content are below the following example content.

Sample Qemu script file

This was enhanced a bit from the simpler example that was provided below. This is meant for a machine running OpenBSD's version of ksh. Other platforms might not be able to tolerate the ulimit command or the style of commenting out lines.

Newer version

This is quite similar to the older version. The main reason for the upgrade was to add support for a new variable called VMGenNam.

This script file may be downloaded:

The following text is from an old version of the script. Functionality is very similar, so updating this was considered to be a low priority.

#!/bin/ksh

# The first line of this text file is parsed and may be impactful. All other
# lines starting with the hash mark, like this one, are unimpacting comments.

# Before customizations, this was a public Sample Qemu start script
# version 1.01 (from CyberPillar.com under mkvmcfg.htm#mkqmucfg )

echo Now entering exc_${VMLILNAM}

# The following is loaded in case it sets some initial env var values.
[ -f ~/.profile_orig ] && . ~/.profile_orig

# The following should be customized. (Modify the non-comment lines.)
#   VMLILNAME : a unique, and preferably short, name representing this system
export VMLILNAM=demomach

#  VMNUM : A two digit number (00 - 99) unique to this virtual machine, not
#          used by any other virtual machine run by this physical system.
export VMNUM=11

# VMDirBas : A place where this virtual machine (and perhaps may others) store
#          related files.  This does not need to be unique for this machine.
[ "X${VMDirBas}" = "X" ] || echo Using existing \${VMDirBas} of ${VMDirBas}

#          Only set if not pre-set.  (Allows easy override.)
[ "X${VMDirBas}" = "X" ] && export VMDirBas=/srv/bigspace/myvm

export VMGenNam=erlytest

# Default network option: By running this command first, there is typically
# no need to be trying to modify/customize this particular line.
export CLIOPTVMFIRSTNIC=" -net user,vlan=1 "

# If using the above (-net user) option, then only TCP/IPv4 and UDP/IPv4 work.
#  This means that ICMP/IPv4 (ping, often traceroute) will NOT work.

#  The below option will connect to a server, and is a fairly easy way to get
#  full network connectivity with other virtual machines connected to the same
#  server. However, it is only useful after setting up an initial server.
#  This line is only effective if no other value was set earlier.
#  If such a server IS available, then feel free to uncomment the line.
#  The value of 43000 must match the server (which defaults to 43000).

# unset CLIOPTVMFIRSTNIC
# if the previous line is uncommented then the following options will be used
# instead of using any of the earlier options
[ ${CLIOPTVMFIRSTNIC}"X" = "X" ] && \
    export CLIOPTVMFIRSTNIC=" -net socket,vlan=1,connect=127.0.0.1:43000 "

# The below option will start a server that provides ability to connect to
# other machines that use a socket-style connection.  Only one machine should
# offer connections on a single specific TCP port number.  In most
# cases, only a single computer virtual machine will use this style of network
# connection. That virtual machine will then enable easier configuraiton of
# other virtual machines.  This style of connection is really only good/useful
# for direct connections to other virtual machines.

# unset CLIOPTVMFIRSTNIC
# if the previous line is uncommented then the following options will be used
# instead of using any of the earlier options
[ ${CLIOPTVMFIRSTNIC}"X" = "X" ] && \
    export CLIOPTVMFIRSTNIC=" -net socket,vlan=1,listen=127.0.0.1:43000 "

# The below option will allow full-fledged communication with a physical
# machine that is using the proper TUN/TAP technology.  This provides the best
# results for communicating to a physical machine, but may also require the
# most setup effort.  In addition to enabling the following
# command line options, setup configuration on the physical machine will
# likely be required, including creating/adjusting the referenced script files.

# unset CLIOPTVMFIRSTNIC
# if the previous line is uncommented then the following options will be used
# instead of using any of the earlier options
[ ${CLIOPTVMFIRSTNIC}"X" = "X" ] && \
    export CLIOPTVMFIRSTNIC=" -net tap,vlan=4,ifname=tun0\
,script=${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/upif0\
,downscript=${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/nicscr/dnif0 "
# Note that the vlan here is set to 4.  When the command line specifies the NIC
# then that portion of the command line needs to match the value specified in
# the section describing the net infrastructure options that are related to
# the same NIC.  So, adjust the command line, if needed, to make these match.



# This ends a lot of the core critical customization. Customize the rest as
#  needed.  The most commonly customized options will probably be the location
#  of the disk images, which device gets booted, and the amount of memory.

# The following create floppy drives.  If unneeded, just leave commented out.
# export CLIOPTVMFLOPPY1=" -fda ${VMDirBas}/diskimgs/baseimgs/${VMLILNAM}/${VMLILNAM}f1.img "
# export CLIOPTVMFLOPPY2=" -fdb ${VMDirBas}/diskimgs/baseimgs/${VMLILNAM}/${VMLILNAM}f2.img "

export VMENV_TMPOLDDIR=$PWD

sudo mkdir -p /var/run/vmpids
sudo chmod ug+rw,a+t,o-w /var/run/vmpids

ulimit -d $( ulimit -dH )

cd ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstart

echo Attempting an unrestricted memory limit...
ulimit -d unlimited
echo Now starting to run Qemu...
( sudo ksh -c " ulimit -d $( ulimit -dH ) ; /usr/local/bin/qemu \
 -hda ${VMDirBas}/diskimgs/baseimgs/${VMGenNam}/${VMLILNAM}/${VMLILNAM}1.qc2 \
 -hdb ${VMDirBas}/diskimgs/baseimgs/${VMGenNam}/${VMLILNAM}/${VMLILNAM}2.qc2 \
 ${CLIOPTVMFLOPPY1} \
 ${CLIOPTVMFLOPPY2} \
 -cdrom /mypath/os_install.iso \
 -boot d \
 -m 272 \
 -localtime \
 -pidfile /var/run/vmpids/${VMGenNam}---${VMLILNAM}.pid \
 -name ${VMLILNAM} \
 -k en-us \
 -monitor telnet:127.0.0.1:72${VMNUM},server,nowait \
 -net nic,vlan=1,macaddr=52:54:00:12:${VMNUM}:01 \
 ${CLIOPTVMFIRSTNIC} \
 -vnc none \
 -usbdevice tablet \
 -soundhw sb16 \
 -vga cirrus \
 -S \
; echo Err/Res=$? ; " ) &


echo Attempt to start ${VMLILNAM} had a result code of : $?
echo If Qemu was not backgrounded then also see the Err/Res
echo value that was assigned above this text.
echo The ps results, using -auxww PIPE grep -i ${VMLILNAM}
ps -auxww | grep -i ${VMLILNAM} | tee -a ~/mygrep.res
echo End of ps results.
cd $VMENV_TMPOLDDIR
echo leaving exc_${VMLILNAM}

Skip past the “Older version” (recommendation for website users: press the “minimize” button) and check out the section called “Things to customize in the Qemu startup script”.

Older version

This is lacking some fairly small and not-very-significant updates. The older version is still available: older virtual machine configuration.

[#custrtqm]: Things to customize in the Qemu startup script

Things to customize:

  • Give the machine a unique name. (The topic of selecting a name is covered by: tutorial on setting up an installed operating system: system naming guidelines.
  • Set a unique machine number. It needs to be two digits so that it works well both as a hexedecimal portion of a MAC address and also as a portion of a TCP port number that is specified in decimal format. (This is discussed further in the section on: Virtual machine number.)
  • Handle networking. For an initial machine, some unideal results can be obtained without making any further changes. If another virtual machine is listening for socket connections, then uncomment the “# unset CLIOPTVMFIRSTNIC” line, for superior networking (which, for example, allows ICMP).
  • Also, follow the customization steps described later (namely setting an appropriate amount of memory, selecting the desired boot device, and making sure that all referenced file paths actually exist).
Simpler sample Qemu script file

An example of the contents of a Qemu script file may be:

export VMDir=/srv/bigspace/myvm
export VMENV_TMPOLDDIR=$PWD

sudo mkdir -p /var/run/vmpids
sudo chmod ug+rw,a+t,o-w /var/run/vmpids

ulimit -d $( ulimit -dH )

cd $VMDir/diskimgs/base/qcow2
sudo qemu \
 -hda $VMDir/diskimgs/base/qcow2/basesys.qc2 \
 -cdrom /mypath/os_install.iso \
 -boot d \
 -m 272 \
 -localtime \
 -pidfile /var/run/vmpids/basesystem \
 -name BaseSystem \
 -k en-us \
 -monitor telnet:127.0.0.1:7211,server,nowait \
 -vga std \
 -net nic,vlan=1,macaddr=52:54:00:12:11:01 \
 -net user,vlan=1 \
 -vnc none -usbdevice tablet \
 -S \
 &

cd $VMENV_TMPOLDDIR

Go ahead and copy the above literally into a script file, but be sure to review the contents before using the file. Customize the above example based on decisions made previously. (It may be highly likely that customizations are in order, perhaps even to get basic working functionality. Anticipate that this realistically may take several minutes, at least, to customize.) The following text provides some specific details to address most, or all, of the customizations needed.

Make sure variables are set right

With the new sample scripts, this is referring to VMDirBas and VMGenNam. The older sample scripts used a variable called VMDir. Make sure these are customized.

Do not allow this file to be executed if the file tries to use /srv/bigspace/myvm unless that directory actually exists. Again (the previous time being on section about creating a virtual machine), a reference is made to Peter N. M. Hansteen's “Pledge of the Network Admin”, visible on Peter N. M. Hansteen's PF Guide's Preface. The pledge doesn't say that pasting is bad, unless the pasting is being done “mindlessly”. So, be mindful, and customize this text file, as needed, before running it.

Handling memory limits

The above sample list of commands makes a reference to ksh's ulimit. That might not work when using a different shell, and a different shell may actually require a different command instead. For further details, read on to see the details about specifying memory size.

Overview: Command line differences

(This section about command line differences is an overview section, largely to provide extra information for those interested in learning a bit more. Instructions needed for functionality may be found in later sections.)

Versions of Qemu are known to have changed the way some command line parameters have been made: New command line parameters (such as -daemonize) have been added over time. (The separate executable qemu-img also changed the way to specify base files when creating a disk image.) New and updated information may be available from documentation such as qemu-doc.htm* which may be a file stored in a directory such as /usr/local/share/doc/qemu/ on a machine that has Qemu installed. (The exact path may vary based on the operating system's implementation of where certain types of files are placed for locally installed packages.) The version of documentation found on the hard drive is likely to be a version that matches the installed version of Qemu. In contrast, the online version of the main “QEMU Emulator User Documentation” file and the other online documentation from the Qemu project's main Wiki site is likely to document how the latest version of Qemu supports things, and may not match the version which is installed. (This is likely to be the case when installing from a package repository that frequently has an older version of Qemu. For example, OpenBSD completely skipped Qemu versions 0.10 and 0.11. (Side note: those two releases were nothing compared to how many releases of wine have been skipped by that operating system.)

  • For some older versions of Qemu, “ -std-vga ” was used instead of “ -vga std ” to achieve the same effect. The entire setting is optional and may be left off. (A reason to use this option is to increase the resolutions available in Windows XP, as noted by Qemu's Documentation on SVGA graphics support within Windows.) Using “-vga cirrus” may work better with newer versions of Qemu, particularly with certain operating systems (including Microsoft Windows 98 Seconed Edition).
  • In OpenBSD specifically, older versions of Qemu could not simply use an .iso image. Instead, something like a reference to /dev/cd0c instead was probably needed. (This would end up making root access desirable.) That has changed, making life easier in newer versions.
  • Some versions have supported “ -kernel-kqemu ” as a command line parameter. Then, some yet newer versions may have dropped support for this. So, if using the latest version of the Qemu software, do not plan to use this.
Using the desired executable

In the example line that says, sudo qemu, replacing the word qemu may be needed to achieve the desired goal, or it may result in creating a virtual machine that might perform nicer in some ways (e.g. if using x86_64 instead of 32-bit x86 platform). See desired Qemu executable which describes using another executable. The first part of that command may be better off being something like “ sudo qemu-system-x86_64 ”. (Also, keep the rest of the command line.)

Making sure the referenced files exist
Hard drive image
Make sure that a hard drive image exists at the specified location (located after the “-hda ” command line parameter). If not, perhaps the text file simply needs to be edited to properly point at the new file. Alternatively, perhaps what is needed is to make that location, section on creating disk images (or, see the section on making disk images for the virtual machine) if necessary, and then copy/move/rename/symlink the file as needed (using techniques from the section about handling files). Simply, do what is needed so that an appropriate file exists in the specified location.
Optical drive image
Does the specified ISO image exist? (If not, fix that. (If needed, see the section about making data images of an optical disc.) If no ISO image is being used, just leave off the part of the command line that says -cdrom cdfile. Also, be sure not to forget to change “ -boot d ” to “ -boot c ” if the desire is to use the first hard drive as a boot device.
Making sure that a referenced file does not exist
The value provided for the -pidfile should be unique for this machine. Therefore, to avoid conflicts with other virtual machines, be sure to customize the name of the PID file. Making the filename of the PID file match the name of the virtual machine seems sensible. While at it, go ahead and modify the system's -name parameter. It would be sensible if both the PID's filename and the -name parameter also match the name of the executable script file that is being customized/modified.
Networking parameters
  • [#vmachnum]: For deployments of less than 100 computers, it may make sense to have a unique one- or two-digit “machine number” assigned to this machine. (This may be discussed on the information about skeleton documentation for a system on the network.) Then using that number may help when making sure that MAC addresses and TCP ports are unique. As an illustration of this technique being used, the above example command line was made with a machine number of eleven. In this example command line, a TCP port number (following the -monitor command line parameter) uses the example machine number, which is eleven, as a visible part of the TCP port number. (At the time this example was made, IANA's list of TCP and UDP port numbers showed that port numbers 7202 through 7226 are unassigned. So the “72” portion of the port number just comes from an attempt to use an unassigned TCP port number.) Similarly, this chosen “machine number” of eleven is visible as part of the ninth and tenth digits of the MAC address. (The last two digits of the MAC address are used to identify each individual NIC in the system, in case the machine ends up using multiple NICs.)

    One option, to help quickly generate a unique number that will be used to decide other values, may be to use ][Cyber Pillar]['s system address usage guideline/map.

  • Ensure uniqueness.
    • Once a likely-unique TCP port number has been chosen for the “ -monitor ” command, that TCP port number is probably not already in use (since the port number is, according to the descriptive words at the start of this sentence, likely to be unique). However, prudence would demand checking that the port is, in fact, not in use.

      As an example, we'll review how to check if TCP port number 7211 is in use. To check this, run:

      Command in Unix
      netstat -na | grep -i 7211
      Command in Microsoft Windows

      (Note: This is not tested. Namely, this is not tested because of some challenges that may exist with using networking with Qemu in Microsoft Windows environments. However, this is a sample command that will likely work decently-ish...)

      netstat -na | find /i 7211

      If there is any output, that might mean that TCP port number 7211 is, in fact, currently being used (perhaps just by being listened to). Either explore this further to find out if the port really is in use, and rectify any potential conflict, or take the easy way out: decide to use a different port number.

    • Each MAC address should be unique on any network that it is a part of. (Further details to ensure that may be documented here at a later time.)
  • The portion (of the above, sample command line) related to “ -net nic...” will likely be sufficient without needing later modification, as long as the MAC address is sufficiently unique.
  • Qemu VLAN info

    The fact that a Qemu VLAN was specified may not be necessary for this very simple example.

    (This paragraph is simply informative, discusses why the command line complicated things by unnecessarily using Qemu VLANs.) If this virtual machine used a more complicated example involving multiple NICs, then having multiple Qemu VLANs may provide some benefits, including clarifying the command line parameters (because the VLANs will help show which command line parameters are related to which other command line parameters). So, by using a Qemu VLAN in this simple example, this simple example more closely resembles a good implementation of a more complicated, but clearly documented, networking configuration that involves multiple NICs.

    Some networking equipment may support 802.1Q VLANs. Do not expect such equipment to work with Qemu VLANs. Qemu VLANs are not compatible with 802.1q VLAN tagging. (For those who are unfamiliar with using VLANs, this warning is not a cause of worry. Simply, for those seeking simplicity and who do not have VLANs pre-deployed on a network, there is no need to worry about this. This paragraph is just provided as a warning to those who might think about implementing such complexity on a network.)

  • The portion of the command line related to “-net user...” is just meant as a quick example.
    • When the “-net user...” networking method is used, there are some limitations related to using that networking method. These limitations may cause some software to not work, while other software will work just fine.

      There are ways to address these limitations, mainly by using different networking configuration options. If this is a first virtual machine being started from a bootable CD, the general recommendation for most readers is to learn more about, and to deal with, such limitations later. (Doing this after testing the virtual machine may be sensible.) It makes sense to address such networking-specific complexity later, after verifying that much of the rest of the virtual machine looks like it may be working okay. The main problem with dealing with learning about the networking configuration options now is just that there's a bit of reading material, so taking the time to read that fully will delay the creation and testing of several other aspects of the virtual machine.

      However, for those people who are so curious about the networking options that they want to learn about them right now, even at the cost of making further immediate progress on the virtual machine, the topic is discussed in more detail in the networking with virtualization section, and more specifically in the subsection about when the host machine treats the virtual machine like a standard networking application. Ways of dealing with the limitations will be covered in the section about different Qemu networking options.

    • Using -net user is the default, so in theory a command line would not need to specify -net user. In this particular example, the -net user command line parameter is intentionally being specified in order to clearly specify a value that might not be the default. Specifically, the reason for specifying that parameter in this example is so that the Qemu VLAN can be specified, causing -net user portion to match the -net nic portion. (If no Qemu VLAN was specified, this would not be quite so necessary.)
  • Multiple NICs may be trickier. The best time to deal with such complexity may be later, as described by the section about the interaction between vm NICs and host machine (which provides some details and then references a guide to networking options in virtual machines.)
  • Some discussion has been made about what type of virtual NICs to use. At the time of this writing, this discussion is actually buried in the guide about Windows 98: see Qemu-specific directions: NIC model.
Choosing how much memory to use

Notes about the -m parameter: Don't try to use too much memory. Obviously this means not trying to use up more memory than what the host computer could provide. Here are some other limits to be aware of:

  • If trying to use up more memory than allowed by the shell's data size, the program may start running, but not be able to fully accomplish the task of running the virtual machine. (Instead, an error such as “Could not allocate dynamic translator buffer” may appear.) The details about these limits may vary based on what shell is being used: it also may affect standard users more than a user with active superuser permissions.

    ksh's ulimit

    For instance, running “ ulimit -a ” may show results such as:

    data(kbytes)         524288

    (There may also be other lines of output.)

    If this data size is not large enough, it might be able to be expanded on request, although perhaps just once. OpenBSD's man page for ksh says “The limits affect the shell and any processes created by the shell after a limit is imposed; limits may not be increased once they are set.” (That might or might not be true for other shells: investigating is likely a wiser choice than assuming there is no such limit.)

    If there is a specific known data size that is desired, specifying that amount my be sufficient. Otherwise, having some flexibility may be nice. Running a subshell (e.g. running $SHELL) may effectively allow changes without altering the parent shell.

    Some exploration has found that running ulimit -d unlimited seemed to set the data size to the hard limit, while using ulimit -d unlimited from a non-superuser, running this from ksh, would show “ksh: ulimit: exceeds allowable limit”. However, simply specifying the actual hard limit would work, even as a non-superuser. Specifying one kilobyte higher would not work.

    To determine the “hard” limit, run:

    ulimit -dH

    That will simply output a number. The number shown is the same number that would be shown on the “data(kbytes)” line that would be shown when running the more verbose command “ ulimit -aH ” which also shows some other values.

    Of all the lines of output from the “ ulimit -a ” command, the line starting with data(kbytes) is the only one that starts with the letter d. It might not be any coincidence that this number of kilobytes can be altered with the -d parameter. Use “ ulimit -d 1048576 ” for 1GB, or “ ulimit -d unlimited ”. That will take effect for that command line shell instance, until overridden.

    The ulimit command may be part of the shell, and so many be included in the documentation for a shell command. For instance, OpenBSD's “manual page” for ksh covers internal commands including the ulimit command.

    csh's limit

    To see current values, “ limit -h ” will show the “hard” values, and using just limit (with no parameters) will show some values. To see just some of the limits, commands line the following may be run:

    limit -h memoryuse
    limit -h memorylocked
    limit -h vmemoryuse
    limit memoryuse
    limit memorylocked
    limit vmemoryuse

    Note: The above examples are based on documentation. However, references to vmemoryuse may end up showing:

    limit: No such limit.

    (No further information is currently available here, regarding why a documented limit is apparently not existing. This was encountered in OpenBSD/amd64 4.9.)

    A limit may be raised, such as:

    limit -h memoryuse2016836k

    The optional suffix of k is impliable: the suffix of m is also supported.

    This limit command is internal to the shell, so documentation for this command shows up in the (OpenBSD) Manual Page for csh.

    There may be some limits that non-root users do not have permission to exceed. This might not be as big of an issue if qemu is being run as a superuser (perhaps because sudo is being used). (Some further research on this may be warranted. A discussion on Nabble indicates that this may be set by the user's class (see OpenBSD man page on the /etc/passwd file (modifiable with vipw) and OpenBSD man page on the /etc/login.conf file) and/or a /etc/security/limits.conf file. (The precise implementation may vary between operating systems.) Also, the same A discussion on Nabble indicated that there are some hard limits, like 1GB, that may not really be exceedable.

  • If running Qemu without using Kernel Virtual Machine (KVM), the following message may be shown: “ qemu: without kvm support at most 4095 MB RAM can be simulated
Other/special parameters
  • The Qemu program continues to support a command line option called “ -win2k-hack ”. If installing Win2K, use this. Qemu Documentation on -win2k-hack says, “Windows 2000 has a bug which gives a disk full problem during its installation. When installing it, use the ‘-win2k-hack’ QEMU option to enable a specific workaround. After Windows 2000 is installed,” this option which slows hard drive speed is no longer needed.
About the use of sudo

The example command line shown shows that qemu is run from sudo. The sudo is shown for convenience, but preferred security practice will be to run the process as a non-superuser if superuser access is not needed. Some following text shows some reasons why using superuser access may be needed. If it is determined that there is no need to be using superuser access, then remove the sudo portion of the command line, and run the virtual machine as an end user.

Here are a couple of reasons why the sudo command may be needed.

Networking
One reason that sudo is being used for the first virtual machine being created is that it is anticipated that a TUN/TAP device will start being used, eventually, when networking gets re-configured shortly (even before installing the operating system to the virtual machine).
Memory restrictions

The second reason is because a superuser might have fewer restrictions, especially regarding how much memory a single process can take up. For instance, when running ulimit, there may be some restrictions when using -d when running as a less privileged user.

Virtual machines may commonly use up quite a lot of memory compared to other applications, so having fewer restrictions may be nice. Being a superuser might not be the most restrictive method of dealing with these memory limitations, but if superuser access is going to be getting used anyway (because of the networking implementation), then there seems to be little reason to try to use other methods to deal with the memory limits.

How much of an issue this is may depend, in part, on how much memory the virtual machine will use. Such memory limits may be less likely to be an issue to run an 8MB virtual machine compared to running a virtual machine that uses a gigabyte or more of RAM. The actual precise limits may vary between different host environments.

If the plan isn't to very shortly change the networking implementation to use TUN/TAP, feel free to try working without using sudo.

Backgrounding
The ampersand at the end of the qemu command line allows a command shell to become instantly usable again. (This is discussed further in background tasks in Unix.)
Documentation

After spending time creating a script file, make sure the script file can be easily found again later. It is good to have system documentation note what command can be run to easily (and, preferably, non-interactively) start the virtual machine. That basically involves recording the name of the main script file that was just created.

That completes this guide's recommendations of things to change from the example Qemu command line. However, the safest recommendation that could be made would be to still read the entire script to make sure that everything makes sense and probably does not need any sort of further customization.

[#mkhpvcfg]: Hyper-V
Older guide

This guide may not fully walk through the entire process of configuring Hyper-V. However, here are some resources that may be helpful:

Networking details
See: Hyper-V Networking.
Automation

(The following information may be dated. See Hyper-V section: subsection on “Hyper-V Server Core” for details on how to interact with only “Server Core”. That section contains a lot of information about using a command line, which is likely to help with automation efforts.)

This guide may not currently provide a thorough walkthrough. However, the following may be helpful if there is a desire to explore this further:

WMI

(The following information may be dated. See Hyper-V section: subsection on “Hyper-V Server Core” for details on how to interact with only “Server Core”. That section contains a lot of information about using WMI, including references to MSDN documetnation and a bundled command line program that allows interaction with WMI.)

PowerShell

As it turns out, interacting with PowerShell seems to often be related to WMI. See: Hyper-V section: subsection on “Hyper-V Server Core” for details on how to interact with only “Server Core”. (Details that had been here, have now been moved to that newer guide.)

Specialized software
Possibly using other specialized software (such as Microsoft's System Center Virtual Machine Manager (SCVVM)).
Creating the virtual machine (partially)

This is simply the process of creating a new virtual machine so that the Hyper-V software can try to run the virtual machine. There are additional steps that may (and probably will) be required to make the virtual machine useful, including configuring the virtual hardware and adjusting what software gets executed (such as installing an operating system).

Using the graphical interface to create the virtual machine

Start up the Hyper-V Manager. (This may be done from an icon within Administrative Tools, or by accessing a similar MMC Snap-in using another method such as looking in Server Manager's Roles\Hyper-V section.

Choose the Hyper-V Server to work with. (In other words, in the left pane, select the option that is named after the computer that is going to be worked with.) (Pictures: [“Hyper-V Manager”: Hyper-V Server chosen in the left frame] and [“Hyper-V Manager”: Hyper-V Server chosen, middle pane scrolled])

In the right “Actions” pane, under the name of the Microsoft Hyper-V Server, choose the option which says “New” (which is the top option). Then choose “Virtual Machine...” [mkhypc5.png]

If the information screen is shown ([mkhypc7.png] ), just “Next >” past it.

[“New Virtual Machine Wizard”: “Specify Name and Location”]

Assign the virtual machine a decent name. If this is done as part of a class, it may make sense to name the virtual machine after the specific class period (e.g. CS189 10am). Also, if this is done as part of a class or lab that involve multiple people, it may make good sense to name the machine after the administrator who will be running this machine. It is believed that this machine may be visible system-wide, visible to other users (or at least other administrators), so coming up with a clear name may help to eliminate confusion and having somebody else accidentally tinker with the wrong machine.

[“New Virtual Machine Wizard”: custom virtual machine name made]

Proceed, by using the button labeled “Next >”.

[“New Virtual Machine Wizard”: “Assign Memory”]

The default amount of memory (512 MB) may be extremely insufficient for some modern day operating systems. For instance, if Windows Server 2008 is going to be installed, 512 MB is required but at least 2GB (which is 2048 MB) is what Microsoft recommends. ([“New Virtual Machine Wizard”: “Assign Memory” set to 2 GB]). Once the desired amount of memory is selected, naturally, press “Next >” to move on.

[“New Virtual Machine Wizard”: “Configure Networking”]

For the “Configure Networking”, it is safe to leave the “Connection” to “Not Connected”, and then configure the networking after the machine has been made. Unless a “Virtual Network” was created before creating this virtual machine, “Not Connected” might even be the only choice.

[“New Virtual Machine Wizard”: “Connect Virtual Hard Disk”]

When the machine asks about a virtual hard disk, it is safe to choose “Attach a virtual hard disk later”. This can easily be done later, and may even have some more flexibility if doing this later.

[“New Virtual Machine Wizard”: “Attach a virtual hard disk later”]

If a difference choice (making a virtual hard disk image) is utilized, there don't seem to be options to select what type of virtual hard disk to make. The created virtual hard disk ends up being a “Dynamically expanding” type. (This conclusion was made based on an 83,968 byte file being created when a 10GB drive was requested.)

After making any desired sections related to the virtual hard disk, naturally, press “Next >” to move on.

If no hard drive is attached, then the [“New Virtual Machine Wizard”: “Installation Options” (boot options) screen may simply be entirely skipped. If this screen does come up, this screen does not really need any configuring: using the “Install an operating system later” option is safe, as these types of options can be changed after the virtual machine is created.

[“Completing the New Virtual Machine Wizard”]

If a brand new hard drive was created, and if the plan is to boot off of a removable data storage image (such as an image of a CD), then choosing to “Start the virtual machine after it is created” is probably NOT going to be useful. Having the machine started will likely only hinder things, as the ability to configure the virtual hardware may be more limited while the virtual machine is actively running. So, in this most-common of cases, leaving the box *unchecked* is generally preferred. (However, if an existing virtual disk is being used, and if that image already has a runnable operating system on it, and if all of the other virtual hardware will not require any customizing, then checking that box might be a slight time saver.)

Press Alt-F to Finish.

[#hvvmcfg]: Viewing/Editing the settings of the virtual machine
Using the graphical interface to create the virtual machine
Right way of doing things

View the virtual machine's settings. To do this, in Hyper-V Manager, after selecting the Hyper-V Server in the left pane, locate the virtual machine (in the “Virtual Machines section) in the middle pane.

[“Hyper-V Manager” showing a single Virtual Machine]

Either:

Use the middle pane

Access the virtual machine's context/shortcut/“right-click” menu ([“Hyper-V Manager” shortcut menu for a selected Virtual Machine]) (by right-clicking on the name of the virtual machine in the middle pane), and choose “Settings...”

Use the “Actions” Pane on the right

Select the Virtual Machine in the middle frame and then, in the right frame, locate the “Settings...” option under the name of the virtual machine. (Although the screenshot ([“Hyper-V Manager”, “Settings...” selected (and, therefore, underlined) in the right pane]) doesn't show it, the icon will look like a hand when it is hovered over the option.)

Discussions about wrong ways

The desired screen a different screen than the “Hyper-V Server Settings...” listed in the right pane under the name of the Hyper-V Server. If the window that popped up says “Hyper-V Settings”, then this is NOT the same option. If the “Hyper-V Settings” window pops up but the goal was to edit the virtual machine's settings, press Escape from that screen and then choose the wrong option. This can also be checked with the status bar. If the right option is highlighted or hovered over, the stauts bar should say “Displays the virtual machine settings user interface.” If the status bar says “Launches the Hyper-V server settings user interface.”, then that is the wrong option.

(Also, the “Action” menu is unrelated to the “Actions” section of the window's right pane.)

The proper name of the window will be “Settings for ”, followed by the name of the virtual machine (as shown in this example picture of [Hyper-V: Settings for a specific virtual machine].)

(See the following section about “Further (hardware) setup of the virtual machine” for details on what to start doing in this screen.)

Further (hardware) setup of the virtual machine

There's quite a bit of material to cover for this step, so this is covered by a separate section: Hyper-V Virtual Machine hardware.

Next step

Generally, the next step is to install the operating system on the guest machine. This may often involve mounting a CD image (which may be the contents of a *.iso file, or may be the layout of an actual CD).

Mounting a CD

Before starting the virtual machine, “Connect...” to it. This should show a black window with some white text: “The virtual machine” ... “is not running”. Ignore its instructions about starting the virtual machine. On the Media menu, choose “DVD Drive”. If there is a physical CD in a drive, select the appropriate “Capture” option. Otherwise, select the desired ISO file.

Remember... if you made a ridiculously big “Dynamically expanding” drive, make sure not to partition the whole drive, or else (depending on what software partitions/formats the drive) you may needlessly end up with a ridiculously large VHD file.

Integration Services
Integration Services to support a Microsoft Windows guest operating system

KB 950050 cites “Integration Services” support for Win2K SP4, XP SP2 (and SP3 x86), Server 2003 SP2, Vista SP1, and 2008. These Integration Services have been known to help a network card be sufficiently detected and supported by the guest operating system. It also provides a different experience of using the mouse in the virtual machine: moving the mouse cursor from the virtual machine to the outer machine will not require using the “Release Key” (which is configurable in the “Hyper-V Server Settings...” screen). Also, (I think) Integration Services may effectively combine the clipboard of the guest's operating system with the clipboard of the operating system installation running the Hyper-V Server.

Linux Integration Services for Hyper-V

Check to see what the latest version is. Download information page for Linux Integration Services 3.4 for Hyper-V, Linux Integration Services 3.4 for Hyper-V “Read Me” file (PDF format)

Troubleshooting
Mouse captured

In the status bar, there may be a message like “To release your mouse press CTRL+ALT+LEFT ARROW”. Try following those directions. To configure which Release Key sequence is used, modify the Hyper-V settings. Even better, if the guest operating system supports such a thing, eliminate the need by installing Integration Services.

Networking
Perhaps see: Hyper-V Networking
Other emulation/“virtual machine” software

Specific details about more various solutions are not here at this time.

Graphical front ends

Often, then there is a command line program that supports lots of different command line options, some third parties may make a tool that uses a graphical interface.

Note that the quality of such software may vary. If an updated version of a command line program changes what command line parameters are supported, the third party front-end may not support those updated command line parameters until the author of the front-end realizes, and compensates for, the change. Sometimes the front-ends may not support all of the options of a command line. Using a graphical front-end may not be quite as easy to automate (including, as an example, having the program do something useful automatically when the computer is started up).

Such software might be designed for just one program (like Qemu), or might support multiple programs. It might be true that, in at least some cases, such a graphical front-end program might support one program less fully/thoroughly than the degree that the same front-end might support another program.

When choosing a GUI front-end, one feature that might be nice is if it supports multiple programs. If so, a transition to another program might be a bit easier if a familiar GUI front-end will then be usable.

[#guifeqem]: Graphical front ends for Qemu

For Qemu, some software that may serve this task may include: Qemu's Wiki: Hyperlinks related to the section for GUI Front Ends.