the guest OS recognizes it is running inside Qemu and cooperates with the
hypervisor.
-Qemu relies on the virtio virtualization standard, and is thus able to presente
+Qemu relies on the virtio virtualization standard, and is thus able to present
paravirtualized virtio devices, which includes a paravirtualized generic disk
controller, a paravirtualized network card, a paravirtualized serial port,
a paravirtualized SCSI controller, etc ...
it is usually a safe bet to set the number of *Total cores* to 2.
NOTE: It is perfectly safe to set the _overall_ number of total cores in all
-your VMs to be greater than the number of of cores you have on your server (ie.
+your VMs to be greater than the number of of cores you have on your server (i.e.
4 VMs with each 4 Total cores running in a 8 core machine is OK) In that case
the host system will balance the Qemu execution threads between your server
cores just like if you were running a standard multithreaded application.
When multiple VMs use the autoallocate facility, it is possible to set a
*Shares* coefficient which indicates the relative amount of the free host memory
-that each VM shoud take. Suppose for instance you have four VMs, three of them
+that each VM should take. Suppose for instance you have four VMs, three of them
running a HTTP server and the last one is a database server. To cache more
database blocks in the database server RAM, you would like to prioritize the
database VM when spare RAM is available. For this you assign a Shares property
of 3000 to the database VM, leaving the other VMs to the Shares default setting
-of 1000. The host server has 32GB of RAM, and is curring using 16GB, leaving 32
+of 1000. The host server has 32GB of RAM, and is currently using 16GB, leaving 32
* 80/100 - 16 = 9GB RAM to be allocated to the VMs. The database VM will get 9 *
3000 / (3000 + 1000 + 1000 + 1000) = 4.5 GB extra RAM and each HTTP server will
get 1/5 GB.
systems.
// see https://forum.proxmox.com/threads/solved-hyper-threading-vs-no-hyper-threading-fixed-vs-variable-memory.20265/
-When allocating RAMs to your VMs, a good rule of thumb is always to leave 1GB
+When allocating RAM to your VMs, a good rule of thumb is always to leave 1GB
of RAM available to the host.
{pve} will generate for each NIC a random *MAC address*, so that your VM is
addressable on Ethernet networks.
-The NIC you added to the VM can follow one of two differents models:
+The NIC you added to the VM can follow one of two different models:
* in the default *Bridged mode* each virtual NIC is backed on the host by a
_tap device_, ( a software loopback device simulating an Ethernet NIC ). This
tap device is added to a bridge, by default vmbr0 in {pve}. In this mode, VMs
have direct access to the Ethernet LAN on which the host is located.
* in the alternative *NAT mode*, each virtual NIC will only communicate with
-the Qemu user networking stack, where a builting router and DHCP server can
-provide network access. This built-in DHCP will serve adresses in the private
+the Qemu user networking stack, where a built-in router and DHCP server can
+provide network access. This built-in DHCP will serve addresses in the private
10.0.2.0/24 range. The NAT mode is much slower than the bridged mode, and
should only be used for testing.
If you are using the VirtIO driver, you can optionally activate the
*Multiqueue* option. This option allows the guest OS to process networking
packets using multiple virtual CPUs, providing an increase in the total number
-of packets transfered.
+of packets transferred.
//http://blog.vmsplice.net/2011/09/qemu-internals-vhost-architecture.html
When using the VirtIO driver with {pve}, each NIC network queue is passed to the
There are two different types of USB passthrough devices:
-* Host USB passtrough
+* Host USB passthrough
* SPICE USB passthrough
Host USB passthrough works by giving a VM a USB device of the host.
If a device is present in a VM configuration when the VM starts up,
but the device is not present in the host, the VM can boot without problems.
-As soon as the device/port ist available in the host, it gets passed through.
+As soon as the device/port is available in the host, it gets passed through.
WARNING: Using this kind of USB passthrough means that you cannot move
a VM online to another host, since the hardware is only available
There are, however, some scenarios in which a BIOS is not a good firmware
to boot from, e.g. if you want to do VGA passthrough. footnote:[Alex Williamson has a very good blog entry about this.
http://vfio.blogspot.co.at/2014/08/primary-graphics-assignment-without-vga.html]
-In such cases, you should rather use *OVMF*, which is an open-source UEFI implemenation. footnote:[See the OVMF Project http://www.tianocore.org/ovmf/]
+In such cases, you should rather use *OVMF*, which is an open-source UEFI implementation. footnote:[See the OVMF Project http://www.tianocore.org/ovmf/]
If you want to use OVMF, there are several things to consider:
the disk images. If you want to change the template, create a linked
clone and modify that.
-Importing Virtual Machines from foreign hypervisors
----------------------------------------------------
+Importing Virtual Machines and disk images
+------------------------------------------
A VM export from a foreign hypervisor takes usually the form of one or more disk
images, with a configuration file describing the settings of the VM (RAM,
drivers by yourself.
GNU/Linux and other free Unix can usually be imported without hassle. Note
-that we cannot guarantee a successful import/export of Windows WM in all
+that we cannot guarantee a successful import/export of Windows VMs in all
cases due to the problems above.
-Step-by-step example of a Windows disk image import
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Step-by-step example of a Windows OVF import
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Microsoft provides
-https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/[Virtual Machines exports]
- in different formats for browser testing. We are going to use one of these to
- demonstrate a VMDK import.
+https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/[Virtual Machines downloads]
+ to get started with Windows development.We are going to use one of these
+to demonstrate the OVF import feature.
-Download the export zip
-^^^^^^^^^^^^^^^^^^^^^^^
+Download the Virtual Machine zip
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-After getting informed about the user agreement, choose the _Microsoft Edge on
-Windows 10 Virtual Machine_ for the VMware platform, and download the zip.
+After getting informed about the user agreement, choose the _Windows 10
+Enterprise (Evaluation - Build)_ for the VMware platform, and download the zip.
Extract the disk image from the zip
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Using the unzip utility or any archiver of your choice, unpack the zip,
-and copy via ssh/scp the vmdk file to your {pve} host.
+Using the `unzip` utility or any archiver of your choice, unpack the zip,
+and copy via ssh/scp the ovf and vmdk files to your {pve} host.
-Create a new virtual machine and import the disk
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Import the Virtual Machine
+^^^^^^^^^^^^^^^^^^^^^^^^^^
-Create a virtual machine with 2 cores, 2GB RAM, and one NIC on the default
-+vmbr0+ bridge:
+This will create a new virtual machine, using cores, memory and
+VM name as read from the OVF manifest, and import the disks to the +local-lvm+
+ storage. You have to configure the network manually.
- qm create 999 -net0 e1000,bridge=vmbr0 -name Win10 -memory 2048 -bootdisk sata0
+ qm importovf 999 WinDev1709Eval.ovf local-lvm
-Import the disk image to the +local-lvm+ storage:
+The VM is ready to be started.
- qm importdisk 999 "MSEdge - Win10_preview.vmdk" local-lvm
+Adding an external disk image to a Virtual Machine
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The disk will be marked as *Unused* in the VM 999 configuration.
-After that you can go in the GUI, in the VM *Hardware*, *Edit* the unused disk
-and set the *Bus/Device* to *SATA/0*.
-The VM is ready to be started.
+You can also add an existing disk image to a VM, either coming from a
+foreign hypervisor, or one that you created yourself.
+
+Suppose you created a Debian/Ubuntu disk image with the 'vmdebootstrap' tool:
+
+ vmdebootstrap --verbose \
+ --size 10G --serial-console \
+ --grub --no-extlinux \
+ --package openssh-server \
+ --package avahi-daemon \
+ --package qemu-guest-agent \
+ --hostname vm600 --enable-dhcp \
+ --customize=./copy_pub_ssh.sh \
+ --sparse --image vm600.raw
+
+You can now create a new target VM for this image.
+
+ qm create 600 --net0 virtio,bridge=vmbr0 --name vm600 --serial0 socket \
+ --bootdisk scsi0 --scsihw virtio-scsi-pci --ostype l26
+Add the disk image as +unused0+ to the VM, using the storage +pvedir+:
+
+ qm importdisk 600 vm600.raw pvedir
+
+Finally attach the unused disk to the SCSI controller of the VM:
+
+ qm set 600 --scsi0 pvedir:600/vm-600-disk-1.raw
+
+The VM is ready to be started.
Managing Virtual Machines with `qm`
------------------------------------
projects / pve-docs.git / blobdiff