Creating a virtual machine
- [#inidcmvm]: Initial items to decide when creating a virtual machine
- An example
Following is an example of what the above documentation might look like if files are being stored on a Unix system (or a remote network site where paths look like a Unix system). The parts that say “
at” (after IPv4 addresses) are paths (locations of directories/folders). Although the example shows the paths in Unix-style, some operating systems may have paths using a different style (such as starting with a drive letter, followed by a colon and then a backslash).
(The following sections may provide some more information about what details are expected in the above format, including hints about how to make any necessary determinations.)
Create a name which is likely to be unique for the network.
Sometimes, machines are named after their intended purpose, or by their physical location, or who the machine will be primarily used by. (In a computer used by an organization, naming the machine after a role, instead of a person's name, may often provide flexibility to transfer that machine to another staff member. That may be more common, except in cases where the machine is owned by the staff member and, therefore, is less likely to be transfered to a different staff member.)
It is common practice to take a topic of interest, and to name machines after the names of people or locations that are related to that topic. Examples may include names of cities, nations, or foods. Naming machines after some form of entertainment has been popular (although companies often stake claims in such names, so that may or may not be a good idea). For example, the items in a video game (e.g.: candle, whistle, potion, wand, raft, ladder, book, ring, key, bracelet) could be used. In addition to such nouns, adjectives (whether appropriate or humurous) may serve well as names. The nice thing about a theme is that subsequent devices on the same network can often have a name from the same theme, or a similar style of theme.
Note that in some organized environment, there may be a pre-established method of name machines. For instance, in a classroom environment, the first virtual machine created by a student named Megan might be called
meganvm1. In a larger complex, machines might be named after departments, or the location where the machine may be found. When adding a machine to a pre-existing environment, consider whether this may be the case.
The operating system won't ask for the system name until further along in the process, after the bootable media is started. Until then, a name change may be as easy as modifying documentation and the names of any folders storing related files. After the computer knows the name, the name change might not be quite as easy, primarily because software on the computer and on other devices on the network may start to remember the old name.
- Locations of files
Although some of these details might not need to be determined up front, and can be decided as needed, having the details determined ahead of time may allow a later actions to be performed more quickly because there won't need to be the interruption to consider where to place this sort of data.
Determine where the virtual drives will
reside. (This is mainly referring to the
hard drive images that will be used by the virtual machine.) Mention the
system and then where the data is.
”. Another example, this time using Unix-style:
Also determine where private key files for this
sytem are going to be stored. (e.g. “
)” and in Unix: “
Also determine where other network documentation will
)” and in Unix: “
Know how boot media will be accessed. For
example, if the plan is to install an operating system from an image of a
bootable CD, know where that CD image is at, or where it is going to be stored.
” and in Unix: “
If needed (which generally should not be the case except in unusual circumstances), mention how (what protocol is used) to refer to the data. However, in most cases, simply using one of a small number of pre-established (commonly used) standards may be sufficient.
- Determine where the virtual drives will reside. (This is mainly referring to the hard drive images that will be used by the virtual machine.) Mention the system and then where the data is. (e.g. “
- [#hostsoft]: Determine what operating systems and/or virtual machine software will be used
There may be various considerations for choosing an Operating System that will be run on the virtual machine. Those who want to follow a guide may wish to use the operating system that is heavily covered by that guide (if such an operating system is easily available).
There are various virtual machine software solutions to choose from (including the operating system that runs the virtual machine software). One possible criteria to consider may be whether the desired software supports the desired disk image, although compatibility with a specific disk image generally does not need to be a consideration since converting disk images is often an option. Other considerations may include fullness of emulation and other compatibility factors, speed, and other features such as an easy and fast way to move a virtual machine from virtual machine software running on one computer to virtual machine software on another computer.
- [#vmdrvsiz]: Determine how big of hard drive space to use
If the virtual hard drive is meant to be a copy of an existing drive, whether that is done by copying a physical hard drive or by creating a child/snapshot image of a “parent/base image”/“backing file”, then this question may be rather answered already. (The child drive image may use the same amount of space as the “parent/base image”/“backing file”.)
For virtual machines, there may be more flexabilty than when existing physical hard drives are going to be used. One decision to make is whether to use an image with a dynamic size: Doing so may provide additional overhead but keep images fairly small. If using a dynamically sized drive, the hard drive can be made enormous and there may be no real costs to doing that as long as the virtual machine limits its activity to working within the borders of a reasonably sized hard drive partition. The only real impact of making the drive large will be offering easier future flexibility. For instance, years later a virtual machine could be moved to a new physical machine (which is probably using newer technology and so may have a substantially larger data storage device), and there may be a need to place more data on the virtual machine. For instance, if a virtual machine needs a bit more than 10 GB, then a 2,047 GB dynamically expanding drive can be made. By having a very large hard drive image, a partition can be created and that partition can be quite large, if desired.
The one thing to be very careful about is to make sure that the disk layout will be effectively restricting disk activity to a reasonably small partition. So, be careful when selecting the size of a partition. Many operating systems may have a default to use all available space when making a partition. That could easily lead to the virtual machine making an unnecessarily large hard drive image. The computer running the virtual machine software may uselessly reduce the amount of free disk space so much that the computer may be unable to operate properly (including even completing the task of writing the disk image). This disaster can generally be entirely prevented by carefully and tightly controlling the size of the partitions.
- Software's requirements for size
When deciding how large of a hard drive to use, keep in mind requirements of the software being used. For instance, although Windows XP Pro installations (with Service Pack 2 or 3) may commonly use up around 10 GB, additional third party software could substantially increase the amount of required disk space. Software may include the software that users typically interact with, like a word processor, as well as additional software, like anti-virus protection.
- Operating system requirements for disk space
The Operating Systems page has information about some various operating systems. Commonly, that section has some information about the operating systems may have a section describing some details about how much space is used. For example, available information about specific operating systems includes: OpenBSD sizes. (This documentation will often refer to vendor documentation about official recommendations, although additional details about practical usage may be included as well.) As another possibile source of information, vendor documentation often provides system recommendations (sometimes called “system requirements”) that may include details (perhaps even just a hint) about a recommended amount of disk space to have available. Eventually that section should have system requirements available. In the meantime, for convenience, here is some information on the system requirements:
- OpenBSD: See OpenBSD size
- Microsoft Windows: Some notes were here, but have been moved to a more appropriate location: Microsoft Windows disk space
MS-DOS: Although MS-DOS may be able to access hard
drives larger than 2GB, each FAT16 partition is limited to 2GB in this
operating system. (A FAT16 drive may be made to be up to 4GB in size with
some operating system/versions, but such a drive is not supported by
MS-DOS.) As the largest
number of drives supported (at least typically) is 24, there is no need for a
drive much larger than about 48GB in size. (Perhaps a bit more for overhead
such as the MBR.) If this OS wants to support an optical disc (CD-ROM) drive
or use the
command, the additional drives may reduce the amount of hard drive permissions that can be fully supported. (
may report additional drives, but other software like the command shell's prompt may not support the drives at all.)
- More hints on disk space requirements
In case the needed information hasn't yet been located, here are some generalizations or other approaches:
Additional software may require more space. The range is huge: older software was frequently under a megabyte. Nowadays, even software that is considered to be “small” may often be multiple megabytes. Some software may be gigabytes.
If convenient, consider checking a machine that is known to successfully use the software (including the operating system, and other software) that will be getting used. If that machine being checked is using a version of the software that predates the version that is going to be installed (meaning that the already-installed version is an older version), consider that space usage may have increased by some amount, perhaps by about 50% every few years (as a very rough, and possibly extremely inaccurate estimate), as new versions get released.
It is possible that many more decisions may be made about the system. However, once these basic things are decided, it may make some good sense to start installing an operating system, as that may take a while. (Then the time it takes to consider and determine some additional decisions may overlap with some of the time of waiting for a process such as booting up an operating system.) Therefore, putting off the making of some other decisions may be a worthwhile course of action to take.
For those interested in filling out a more complete set of documentation, one may wish to document some additional details like what IP address the machine will use. An example skeletal form of key system info.
If a main collection of documentation for a network/computer has not yet been established, create one. Copy the documentation about this system into the main documentation file.
- [#vmhstenv]: Prepare the host environment
After deciding which operating system and virtual machine software to use (as discussed in the section about initial items to decide when creating a virtual machine), make sure to obtain and software and install the software so that the host machine is ready to go. Doing this can be done by accomplishing the following general steps:
- Install the operating system. (TOOGAM's tutorial for installing an operating system may contain generalized information about multiple operating systems. More specific details may be in the sections about specific operating systems.)
- Follow up by following the guide to setting up an installed operating system. This should help secure the newly installed operating system, and get some useful features (especially remote access) operational.
Once it has been determined which software is going to be used, enable the CPU's virtualization feature in the BIOS if all of the following three things are true: if the CPU offers such functionality, and if the BIOS has an option to enable such functionality, and if the software would benefit from such functionality. In many cases, all of those conditions are true and so this is worth doing, although it requires rebooting the computer so perform that as soon as there seems to be an ample opportunity.
Delaying this step substantially may or may not be an option, depending at least in part on requirements of the virtual machine software.
Obtain and install the “virtual machine
- Earlier instructions (“deciding which operating system and virtual machine software to use) had details about deciding what virtual machine software should be used. So, it is assumed that the decision has been made by this point of time.
- Obtaining the “virtual machine software”, which is the software that will operating the “virtual machine”, is a logical step to perform before trying to create the data files (such as disk images) that the software will be using. (This applies to conversion as well as new images: obtaining the desired virtual machine software first may be worthwhile to do before spending time trying to convert any pre-existing images.) One reason for this is because the virtual machine software, which uses virtual machine data files (in order to create and run the virtual machine), often provides a solution capable of being able to create the desired disk images. The virtual machine software may be directly capable of such functionality, or it may flexibly be bundled with a modular program that provides such functionality.
- The precise method of obtaining the software may vary based on what software is going to be used. The software installation guide has instructions about installing software, and in some cases (like if using the Debian operating system), those instructions might be useful in obtaining the software.
- Install the “virtual machine software”. Information about obtaining and/or installing the “virtual machine software” may be gathered by reviewing the generalized software installation guide.
- If it is expected that the virtual machine will be interfacing with some physical hardware, such as a virtual network interface card or a virtual sound card, then the host environment may need hardware that provides such functionality in order for the emulated hardware to be both useful and nicely perceivable.
- Providing the virtual machine access to data
- [#dskimgfl]: Disk image files
Note: This section is about creating image files of data storage devices, such as hard drives. This includes creating new image files (which are rather blank), creating child/snapshot images, and converting existing images. For similar information about creating images used with other formats, such as optical discs (or archaic floppy disks), see the section about disk images.
- [#mkvmmkim]: Creating disk images for a virtual machine:
- Choosing a file format for a hard drive image
Making a choice of hard drive formats may involve some considerations that are covered in more detail in the section about images of “primary storage” devices: section about choosing a file format for a hard drive image.
Further information about what formats are available at at: images of “primary storage” devices: disk image file formats.
- Determine how big the file will be
- As an example, when virtual machines are being used, the section about Creating virtual machines: section about determining how big of hard drive space to use.
- [#locvmimg]: Determine location where the file will be stored
After deciding which format(s) to use, if that format is documented in one of the following sections, follow the appropriate steps from that following section. Hopefully this won't require changing details like how big the hard drive image will be.
If this hard drive image is being used for a virtual machine, then hopefully the location should be documented from the process of deciding initial items to decide when creating a virtual machine. If such a location has been pre-decided and pre-documented, then that location is likely the good, recommended location. Otherwise, go ahead and make the selection, and then document the decision.
Before settling on a specific location, and actually putting a hard drive image at that location, verify that there is a suitable amount of free disk space. (Of course, other standard considerations, like suitable data security being implemented, should also be in good shape before putting confidential data anywhere.) If everything looks good about a location, then that location is likely suitable.
- [#cnvdskim]: Converting disk images
- See: images of “primary storage” devices: converting between disk image file formats. (There might also be information in the section about images of “primary storage” devices: disk image file formats.)
- Other changes to disk images
- Disk format features
- Disk image features.
- Modifying contents of a disk image
- Modifying contents of a disk image
- Operating system change: Supporting virtualized hardware
If an operating system installation is getting moved from one computer to another computer (whether or not the new computer is virtual), hardware drivers will need to be able to support the new hardware. To the degree that a computer uses fairly generic hardware drivers, the issue may go more smoothly. To the degree that the operating system is using highly optimized, or in other ways customized, drivers that are designed for the old computer, there may be some problems with trying to get the operating system to run on the new computer.
One possible way to deal with this may be to try switching drivers to more generic drivers.
- Using a new HAL
Review this section
On Microsoft Windows, the operating system uses a “hardware abstraction layer” between the drivers and the rest of the operating system. Changing the HAL may be a more centralized change that will then involve needing less changes to other drivers. This might be an approach that may be used by some software distributed by Microsoft (either Sysinternals's Disk2vhd, or perhaps it is Hyper-V's Integration Services?) and/or Acronis.
http://blogs.msdn.com/b/virtual_pc_guy/archive/2004/12/16/316643.aspx refers to: http://support.microsoft.com/default.aspx?scid=kb;en-us;309283 (which refers to MS KB 299340) http://blogs.msdn.com/b/virtual_pc_guy/archive/2004/12/16/316643.aspx recommends expanding HALACPI.DLL and then overwriting HAL.DLL with it. This may be difficult to do from a running operating system, and that is likely why this Virtual PC Guy's Blog entry is suggesting to do this from the recovery console. He says, “Note - this method is not officially supported by Microsoft - but I have found it to be very handy :-)” Ah, yes, but surely a wise standard precaution would be to back up the HAL.DLL file (simply by making a convenient copy called HALDLL.BAK) before replacing the file. http://www.softwareknowhow.info/blogs/tabid/63/entryid/136/migrating-from-physical-to-virtual-with-hyper-v-and-disk2vhd.aspx suggests placing the file in Windows, and using a new BOOT.INI entry. That may actually be a nicer approach (as it isn't replacing a file, and the old entry could be rather easily revereted).
http://www.softwareknowhow.info/blogs/tabid/63/entryid/136/migrating-from-physical-to-virtual-with-hyper-v-and-disk2vhd.aspx noted (perhaps about system speed?): “Removing software made obsolete by the migration, things like the SoundMAX and NVIDIA drivers seemed to help quite a bit.”
- Providing access to a host's data (via directly accessing its drives/folders)
- Accessing folders
Before using the
fat:option (or the
fat:floppy:option/sub-option) described by Qemu documention section 3.6.7: section on using Virtual FAT disk images, see the sections about what to never do.
- Direct access to host hardware devices
- via network
- (This isn't likely much different at all than network file sharing. Perhaps special considerations about booting, e.g. via TFTP?)
- [#prpvmcmd]: Preparing for, and creating, a command which will run the virtual machine
Some of the preparation mentioned in this step may be completely unnecessary, but at least some of these steps may also (eventually) be nice and useful.
One recommended step is to make the directory which will be storing the data related to the virtual machine.
As another example of preparing things even a bit further, the Qemu program may use multiple files that are executable. In addition to the virtual machine program's binary executable file, the relevant executable files that regularly get used may commonly include multiple script files for a single virtual machine. The first of these scripts may start the Qemu software, while an additional script file may be used to initialize customized settings for each virtual “network interface card” (“NIC”). In such a case, it may be useful to have all of the executable script files placed in a single directory.
Having a text editor which can be effectively used is yet one more example.
- Preparing to make a command file, in Unix
Before blindly running the above command(s) (in violation of the final sentence of Peter N. M. Hansteen's “Pledge of the Network Admin”, visible on Peter N. M. Hansteen's PF Guide's Preface), be sure to customize the directory in the command line that sets
VMDir. (Of course, this method of setting an operating system environmental variable may be shell-dependent.) The specified directory should match the documentation made for this machine. (If the documentation does not point to a desirable location, update the documentation as needed.)
Then, run the following:
Note that the above made a directory called
/var/run/Depending on the implementation of the operating system, it may be somewhat common/standard for the entire
/var/run/directory to be erased when the system is started. The fact that the subdirectory's contents will be erased is of no consequence: the files that may have been in the directory before a reboot are not likely to matter after a reboot. However, realize that the continued existance of the subdirectory itself (particularly after the system may be rebooted) should be ensured, not assumed. (That may be addressed in the upcoming documentation about creating a configuration for a virtual machine, so it does not necessarily need to be addressed immediately. Addressing it before the host machine reboots, though, will be a good thing.)
Be prepared to edit a text file. (However, before starting the text editor, be familiar with the editor so that the software can easily be exited.) There may be no need to edit a text editor right at this moment (until proceeding to the next step), but do be prepared to know how to edit a text file. This includes having a desired text editor installed. When the time is right to start editing a text file, the following may work:
If that doesn't work, then
$VISUALis not standardly set to a full-screen editor. One may try “
” instead of using “
” If neither of those environment variables are set, that is a common but not good thing which should ideally be fixed. Details about fixing the problem may be found in the section about editing a text file: section about common Unix variables.
- Preparing a command in Windows
This guide does not have much
details here about preparing to run a virtual machine
in Microsoft Windows.: If this is
automatable from the command line, this might involve making a directory and
using a text
editor to make a file ending with the
.bat“extension” at the end of the filename.
- Creating a configuration for a virtual machine
With some software (e.g. Microsoft Hyper-V), this would seem like a surprising step to do before even creating the virtual machine. However, the virtual machine itself may really be nothing more than a small set of configuration files, plus the hard drive images. So, creating these configuration files is not a different step than creating the virtual machine. (In other words: this step *is* the step for creating the virtual machine.)
- [#vminetcf]: Interaction between virtual machine's NICs and host machine
The instructions provided so far, to create a virtual machine, may have provided little details about setting up networking. The simple reason for this is that networking configuration for a virtual machine can be fairly complex. The results may vary based on some implementation specifics. For some virtual machines, the default may be full networking that seems to work well, while other virtual machines may have networking disabled by default. Some virtual machines may support some sort of partial networking, such as supporting TCP/IPv4 and UDP/IPv4 packets but not supporting other types of packets (like ICMP/IPv4 or anything involving IPv6) to remote machines. (That, for example, has been seen with Qemu when using the approach of having the host machine treat the virtual machine like a standard application that uses networking.) An implementation with those specific limits might allow some types of communications (like what is needed for web browsing, including DNS and HTTP(S)), while
may not work.
A general recommendation is to delay modifying this, at least initially. Many virtual machines will likely boot off of local media, such as a hard drive disk image, or a bootable optical disc image. Many such systems will not automatically start writing to critical areas of the hard drive, nor perform any other substantial part of the installation process, until after some user interaction occurs. For such machines, the complexity related to networking can easily be delayed until after some other things are successfully tested.
Getting networking fully working may involve adding support in the host operating system. Simply making sure that the virtual machine runs well, that the expected disks are accessible, and that there is a working ability to interact with the virtual machine, may be substantial tasks that can easily be separated from the complexity of getting networking to function. Keeping those tasks separate may help to simplify troubleshooting, as well as providing a sensible break point (if sensible/applicable/desired). Some of those tasks may help with configuring and/or testing the virtual machine's portion of networking. Testing fewer things at once may help to simplify troubleshooting if there are any problems. Therefore, the general recommendation for many machines is to delay working on network configuration for a virtual machine until after some of the other basics have been tested. (Then, once some of the basics have been verified to work, configuring the networking may be worthwhile to do before substantially proceeding through an interactive process that sets up an operating system.)
In some cases, getting the operating system fully functional may be a task that uses networking. In those cases, there may be less sense in the idea of delaying the enabling of functional networking.
In summary, if easily doable, this guide's recommendation is to worry about that later.
- [#vmprpfnl]: Final preparations
Make sure everything is right.
Make sure the disk images have been created. (If that
hasn't been done yet, see
creating disk images.) e.g. for a qcow2 image, the
following is an example of what may work well:
The file that is specified by the Qemu command line is not where it needs to be, make adjustments: copy or move the file as appropriate, and change any ownership and permission settings that are needed. Alternatively, if there isn't a pre-existing file to be used, make a disk image for use with Qemu.
Make sure that file attributes (file ownerships and/or permissions) are set so that the disk images are readable and writable by whatever user is going to run the virtual machine. (This may be especially likely to be a problem with an image of an optical disc created in Unix (using directions at: making data images of an optical disc), if superuser privileges were used for reading directly from a block device.) If a file is owned by the superuser, and is not correctly accessible (readable for optical disc images; readable and writable for a hard drive image), then change those file attributes (running software as a superuser as necessary).
If any bootable media hasn't yet been obtained, it is about to be needed. (Following the use of that bootable media, there will be the need for any other media needed to the operating system.)
If a PID file is going to be used, make sure it can be used. (This isn't a problem if using the example script file, as the example script file takes care of this. Otherwise, this needs to be taken care of.) If the virtual machine software is asked to make a PID file, but then can't, then the virtual machine software will quit rather immediately.
Then, make sure that any created directory allows usage by the user that will be running the software. File attributes of ownerships and/or permissions may get in the way of this, so consider running:
If the process of starting the virtual machine will involve using a configuration/script file that is used to configure a hardware device (e.g. Qemu can run a custom script file after creating a NIC, so that the NIC is configured), then make sure that there is a file with the correct permissions. (Even if permissions are not expected to be a problem, simply verifying that any needed script file does exist may be needed. Details about determining with the permissions are, and changing them, are available in the section about handling file attributes like file ownerships and permissions. Generally the desired permissions are that the file is both readable and executable.)
This is only required if the virtual machine software is being instructed to use a script to configure a hardware device. If that doesn't apply, then no action is needed.
e.g. for Qemu, if “
script” is being used, and if a configuration script is needed for that NIC, make sure that the specified file exists. (Using
-net nic” should imply a corresponding
-netof another type, which may or may not be using a script file. This may typically/always be unneeded for using “
-net user”. It is also possible, although perhaps unpreferable, for a
-net tap” to not require a configuration file.)
If a required NIC-configuring script file doesn't exist yet, either change virtual machine software's command line so that the NIC-configuring script isn't referenced or, generally more preferable, just make the needed file. (Even if the full NIC configuration doesn't exist, having a simple file pre-existing may simplify things later. Later, when necessary commands are put into the network configuration scripts, it may be more convenient to not also need to be changing the virtual machine software's command line.)
At least with some virtual machine software, including Qemu, the following is true: if the virtual machine software is configured to use these sort of scripts, then these script files absolutely must be able to be successfully ran. Although these scripts may be optional, in the sense that the virtual machine software doesn't have to be configured to use these scripts, these script files are not optional if the virtual machine software tries to use them. (Changing the virtual machine's configuration, so that the virtual machine software will not try to use those files, may be one option. Otherwise, the file may be required.) If the virtual machine software cannot successfully execute the specified file, the virtual machine software will quit.
At this point, the virtual machine may be nearly ready to work well. Actually, the virtual machine's networking may not communicate with any other software or devices on the host machine, and that will probably need to be fixed sometime later, as specified by the section about Interaction between virtual machine's NICs and host machine.
- Make sure the disk images have been created. (If that hasn't been done yet, see creating disk images.) e.g. for a qcow2 image, the following is an example of what may work well:
- [#startvm]: Starting the virtual machine
The method of starting the virtual machine should be in the documentation that has been made for the virtual machine. (That was added to the documentation when the configuration for the virtual machine was created/saved, right?) So, simply follow those documented instructions. If the method to start the virtual machine hasn't yet been documented, here are some pointers, but be sure to document the desired process and then follow the instructions that get placed into the custom documentation for the specific virtual machine.
Naturally, the precise method will vary based on the implementation of the virtual machine. Rather than repeat instructions mentioned elsewhere, this guide will simply expect that the steps from creating a configuration for a virtual machine have been followed.
If there was a script file created to run the virtual machine, go ahead and run that file (using the following guidelines if they help at all).
- Running a script file in Unix
See: batch/script files for details, including some troubleshooting information, about running a script file. Use that to run a script file.
e.g., perhaps run:
(This may likely show a PID assigned to the script that gets run. However, if the script simply runs Qemu in the background and then exits, the PID of the script won't be useful for very long because the script will exit.)
If there seem to be troubles that aren't covered by the generalized section about Unix script files (batch/script files), consider the following troubleshooting information.
If that didn't seem to execute the command, there may be multiple reasons. One is that the filename may have been customized. Another may be that
$VMDirmight not be currently set. If either of these are the problem, just be more careful to correctly specify the actual location fo the file (after the period and the space which start on the command line).
Another possibility is that the script file did run the virtual machine software, but then the virtual machine software had an error (such as being unable to run a different script file). An example of this is if Qemu tries to run a script file to configure a network card, but then perhaps that script file doesn't exist. The error might look like an error that happened when the outer script file ran. To help narrow down if this might be the case, try running an “
” command in the outermost script file before that file runs the virtual machine software.
- GUI front-ends
Generally, locate the machine and start it. Specific details are not available here at this time. (Consult the documentation that comes with any GUI front end that is being used.) Some more details about these front-ends are mentioned in the section about creating a configuration for a virtual machine.
- [#vmaftrun]: After attempting to run the virtual machine
- [#ckisvmrn] Checking results: See if the virtual machine is running
Now, the virtual machine may be running! However, it also might not visibly doing much. There may be some desire to interact with the virtual machine, seeing its video output.
First, before spending further time interacting with the virtual machine, note any errors that showed up in the standard output of the terminal that ran the virtual machine. (It is recommended to note these before those visible errors scrolled off.) This isn't to say that all such errors should be addressed, but note what the errors are so that (eventually) they can be taken care of. (It might, or might not, be a sensible/practical/useful idea to run with Qemu's output being piped to the
command, although that likely won't be as useful for any previous execution.)
Second, before trying to correct those errors, let's determine whether the virtual machine is (still) running. If the virtual machine is visible on the screen and is actively running code from the hard drive, the answer to that question may be obvious. In other cases, it may be less obvious.
Here are some brief examples of what could be preventing the virtual machine from running at all. All of these examples are from the same virtual machine software, Qemu. An error of “
” (referencing the filename that was specified by a parameter such as the
: could not open disk image
-hdaparameter) is likely a critical error that would cause the virtual machine to stop completely. Another error message, “
” (due to the PID file's location being a non-existant directory, or a location that cannot be written to for some other reason), is actually another error that can cause Qemu to refuse to run. However, “
Could not acquire pid file
” (by a version of Qemu that was made to be able to at least attempt using the kqemu acceleration layer) is simply an error message that is not likely to prevent the virtual machine software from continuing to run, so the virtual machine may still be running despite this error message.
Could not open '
' - QEMU acceleration layer not activated: Operation not supported by device
Those results, from some specific virtual machine software, are very different than what the expected results of similar issues on a physical machine. A physical system may attempt to boot with an unplugged or otherwise missing hard drive, but would not fully attempt to boot if the CPU was removed from the socket. One might reasonably intuitively expect that similarly, a missing acceleration layer, likely related to how the CPU gets implemented, would affect things less than a missing hard drive image. That is not the case for Qemu, even if this reality differs (in a non-obvious, non-intuitive way) from how physical hardware may act. With the virtual machine software, a problem with the hard drive is more impactful than the ability for an emulated CPU to work as expected.
So, just seeing an error message may not clearly indicate whether the virtual machine is running or not. The precise method of verifying if the machine is running may vary depending on what virtual machine software is running. Techniques may involve verifying that expected PID files exist, verifying that an expected process is running, and/or using a management front end which may report on the status of the machine. (When using a graphical interface, that last option might be as simple as looking at the screen.)
- Checking by using a PID file
This technique may not work for all software, but may be the cleanest technique that is easily automatable (for software that this process does work on). As an example, this does work with Qemu, but only if a PID file was specified on the command line.
(This is basically a specific example showing a way to verify that the virtual machine software is running. More generalized information about performing this task may be in the section about seeing what is running.) (The exact parameters sent to the
command may be specific to some versions of
. Wikipedia's article on “ps (Unix)”: section about ps Options says “Note that, for maximum compatibility when using this syntax, there is no” hyphen before the BSD options: the procps version may even complain as noted by its FAQ. However, since options vary, if the below BSD-style syntax does not work, try putting a hyphen before the first set of command line paraemters to
(to use the ps syntax attributed to System V and ps syntax attributed to Unix98) or try using
-efinstead of other options.)
Adjust the filename above if needed. This would be the same filename that is specified by the virtual machine software.
- Checking if Qemu is running (without using a PID file)
If the virtual machine is not using a PID file, then change the grep command line to search for instances of the virtual machine software. For example, if the virtual machine software's executable is called
, change the part after the pipe in the earlier example
command line. As an example, run the following:
(If that isn't specific enough because there are too many virtual machines running, pipe into another grep command that specifies the hard drive image being used.)
If the virtual is running, and if it should be stopped (because of an error shown on the screen), the best aproach may be to close the software cleanly or, if that is infeasible or known to be unnecessary, to terminate the process. It will generally be preferable to do this before the virtual machine starts running additional software (if the virtual machine is likely to do that).
- Relieve stress in the future
Note: If the virtual machine is working after having been successfully started from a command line, and if there is not any other documentation of the exact command line that was used, save the command line that was used. Actually, this guide's instructions will specify that such a thing should already be documented, quite possibly by having the command line be stored in a script file. However, it's also well known that such practices aren't always followed, especially when not part of organized (formal) training. If the working command line still hasn't been saved to a text file of some sort, be sure to save it. It will be desirable to be able to either run the command line directly from a script file, or if that isn't easily possible, at least to be able to copy the command line from a text file to a clipboard, and then to be able to paste those clipboard contents directly into a text file.
- Reasons why this is likely a good idea to do now
- “Now” (meaning at this point in the process) is probably a relatively convenient time to do such a thing.
- If this doesn't happen now, it is often too easy to start interacting with the virtual machine and lose quick and easy access to the working command line, possibly simply because other commands were performed re-using the command line shell. Especially if the command line shell is later exited (possibly, as an example, by rebooting the host machine), the command line history may not be so easy to access in the future. Since the command is likely easily accessible at this point of the overall process, it is generally very worthwhile (even in a short term) to at least save that command to a file, even when generally documenting things extremely sparsely.
- Saving the command to a file, if that isn't already done, will likely save time either by running the same virtual machine later, or to provide an approximate command line that may be used by another virtual machine (which may be similar to the virtual machine just made). This time savings is likely regardless of whether the next machine is uses a stand-alone hard drive image similar to the machine just made, or whether the next machine is a “child/snapshot” image based on the machine just made.
A simple way to save the command line simply, which may be the easiest way if some other copy and paste mechanism isn't easily available, is to follow the steps to copy command line history to a batch/script file.
- [#vmoutdsp]: Interacting with the virtual machine's output/display
So far, the screen may not be visible. If that is the case, this may take longer than what one might initially think/hope for. Prepare to do a bit of reading in the section about interacting with the virtual machine's output/display.
- [#vmnetcfg]: Networking with virtualization
- See: Networking with virtualization.
- [#rematovm]: Remotely accessing the environment in the virtual machine
The two basic ways are:
- First, ensure that the virtual machine's host provides a usable display of the virtual machine, even if just locally. Then get remote access working to the host machine which is running the virtual machines. Use the interface on the host machine to control the virtual machines similar to any other program running on the host machine. This method really doesn't require any changes to the configuration of the virtual machine's installed software (including its operating system), or even any network capabilities of the virtual machine.
Often a nicer method once available: First Get the virtual machine's networking working. Then use a remote access method to remote directly into the virtual machine. This is most often not supported during an operating system's installation, and so proceeding with this method may be something to delay until after installing the operting system.
In addition to making sure that there is some remote access software running on the virtual machine, this method requires that traffic is effectively being routed to the machine. For many remote access methods, this ends up meaning that a known IP address and port being listened to need to be known. (However, this may not be as much of an issue with remote access methods where the machine being controlled does not require an incoming connection, such as using a VNC program with reverse/“listening” mode, or remote access methods involving different routing for initiating contact to the client.)
As for knowing the IP address that the guest machine uses, configuring the IP address is something typically done by configuring the software running on the virtual machine, although if that software is set up to use automatically configured addressing then this may be achievable by modifying how automatically configured addressing operates. For example, DHCP configuration may be modified. Note that some virtual machine software solutions may implement a DHCP server, at least when some methods of networking are being implemented, and so configuring a working DHCP server may be an option that can be performed by configuring the virtual machine software.
Some virtual machine software implementations may implement networking in a way that effectively firewalls incoming connections away from the machine. These networking methods may be the simplest to set up, but they do complicate the incoming connections used for many of the remote access methods.
To work around this, either use a different networking option which does not cause that firewalling effect, or punch a hole in the firewall using some sort of options. Details about those options may vary based on not only which virtual machine software is being used, but whether or not the options are available (or needed) may vary based on exactly which networking mode is being used by the virtual machine software. Further details for some solutions may be (this text will say “are” instead of “may be” after multiple solutions are definitely availble in the specified section) available in the section of implementation-specific details of networking support by virtual machine software.
- More recommended follow up
After starting the virtual machine, one may wish to begin to really start using the virtual machine. Here are some things to consider doing, though, before making a bunch of changes to the virtual machine.
- Compressing disk image(s)
- see: images of “primary storage” devices: section about compressing disk images.
- Double-checking the documentation is complete
- Before using the just-created image as a parent image that child images are based off of, it makes sense to make sure that all the details about this parent image are documented. After all, if multiple child images are made from this parent image, that will only increase complexity; the recommended task of documenting the child images may be even more difficulty when there is not yet sufficient documentation about the parent image they are based on. Especially note the location of the file, so that it may be found when creating child images (now or down the road), as well as information how to log in. (If the parent image is to be the basis of a new child image months from now, it will be good to have the credentials of the parent image documented so that those credentials can be effectively used, easily, to help create the new child image.)
- Creating snapshot/child images
- Incomplete/unverified section: May have some info in the section about creating images?
- Other steps?
- Are there any other steps? (Likely not: if there were other steps then they would be considered part of follow-up, and so would go in the previous section)
- Using the virtual machine
- First, have all previous steps been taken, including creating the virtual machine, enabling remote access, and creating child images as desired?
- Other virtualization details
- [#astvrthw]: Hardware-assisted virtualization
Some microprocessors may have support for specific instructions that are often related to virtual machines. Supporting virtualization software may be able to use these instructions to provide speed, often in order to implement security features (which may go slower, or even be not implemented, when the software is used on microprocessors that are not providing this feature). Note that some systems may have such CPU features disabled in the BIOS setup, and so if virtualization is going to be used then it is likely worthwhile to verify whether such features are supported by the processor and whether they are enabled.
Microsoft calls the speed-benefiting technology “hardware-assisted virtualization (“HAV”). (For example, this was a system requirement for Microsoft Windows Virtual PC before MS KB 977206 offered a change to that requirement, although it may still be a requirement for other virtualization software by Microsoft.) Specifically there are two variations: AMC and Intel. AMD's implementation is called “AMD-V” (“AMD virtualization”) and has previously been named “AMD Secure Virtual Machine” (“AMD SVM”) and before that was code-named “Pacifica”. Intel has the “Intel VT-x”, the “Intel Virtualization Technology” (for x86), which was previously codenamed “Vanderpool”. Wikipedia's article on x86 virtualization: section on processors providing hardware assist provides further details.
In addition to AMD-V and Intel VT-x, some hardware features that may help virtual machines is hardware-based “data execution prevention” (“DEP”) bits: specifically this refers to AMD'x “no execute” (“NX”) bit and Intel's equivilent “execute disable” (“XD”) bit.
Other features that may help:
In addition to CPUs, other technologies that may assist are also listed on Wikipedia's article on x86 virtualization.
- Next steps
Once networking is available, remotely accessing the environment in the virtual machine can be quite convenient. It may also eliminate the need to keep using the virtual machine's output display, which can be nice if the virtual machine's output display is less than ideal. However, getting remote access to work might require taking other steps before setting up such remote access, such as installing an operating system and performing other steps to perform after installing an operating system (like performing tasks to help with network security) before.