1VIRT-INSTALL(1) Virtual Machine Manager VIRT-INSTALL(1)
2
6 virt-install - provision new virtual machines
7
9 virt-install [OPTION]...
10
12 virt-install is a command line tool for creating new KVM, Xen, or Linux
13 container guests using the "libvirt" hypervisor management library.
14 See the EXAMPLES section at the end of this document to quickly get
15 started.
16 virt-install tool supports graphical installations using (for example)
18 VNC or SPICE, as well as text mode installs over serial console. The
19 guest can be configured to use one or more virtual disks, network
20 interfaces, audio devices, physical USB or PCI devices, among others.
21 The installation media can be local ISO or CDROM media, or a distro
23 install tree hosted remotely over HTTP, FTP, or in a local directory.
24 In the install tree case "virt-install" will fetch the minimal files
25 necessary to kick off the installation process, allowing the guest to
26 fetch the rest of the OS distribution as needed. PXE booting, and
27 importing an existing disk image (thus skipping the install phase) are
28 also supported.
29 Given suitable command line arguments, "virt-install" is capable of
31 running completely unattended, with the guest 'kickstarting' itself
32 too. This allows for easy automation of guest installs. This can be
33 done manually, or more simply with the --unattended option.
34 Many arguments have sub options, specified like opt1=foo,opt2=bar, etc.
36 Try --option=? to see a complete list of sub options associated with
37 that argument, example: virt-install --disk=?
38 Most options are not required. If a suitable --os-variant value is
40 specified or detected, all defaults will be filled in and reported in
41 the terminal output. If an --os-variant is not specified. minimum
42 required options, --memory, guest storage (--disk or --filesystem), and
43 an install method choice.
44
46 --connect URI
47 Connect to a non-default hypervisor. If this isn't specified,
48 libvirt will try and choose the most suitable default.
49 Some valid options here are:
51 qemu:///system
53 For creating KVM and QEMU guests to be run by the system
54 libvirtd instance. This is the default mode that virt-manager
55 uses, and what most KVM users want.
56 qemu:///session
58 For creating KVM and QEMU guests for libvirtd running as the
59 regular user.
60 xen:///
62 For connecting to Xen.
63 lxc:///
65 For creating linux containers
66
68 General configuration parameters that apply to all types of guest
69 installs.
70 -n NAME
72 --name NAME
73 Name of the new guest virtual machine instance. This must be unique
74 amongst all guests known to the hypervisor on the connection,
75 including those not currently active. To re-define an existing
76 guest, use the virsh(1) tool to shut it down ('virsh shutdown') &
77 delete ('virsh undefine') it prior to running "virt-install".
78 --memory OPTIONS
80 Memory to allocate for the guest, in MiB. This deprecates the
81 -r/--ram option. Sub options are available, like 'memory',
82 'currentMemory', 'maxMemory' and 'maxMemory.slots', which all map
83 to the identically named XML values.
84 Back compat values 'memory' maps to the <currentMemory> element,
86 and maxmemory maps to the <memory> element.
87 To configure memory modules which can be hotunplugged see --memdev
89 description.
90 Use --memory=? to see a list of all available sub options. Complete
92 details at
93 <https://libvirt.org/formatdomain.html#elementsMemoryAllocation>
94 --memorybacking OPTIONS
96 This option will influence how virtual memory pages are backed by
97 host pages.
98 Use --memorybacking=? to see a list of all available sub options.
100 Complete details at
101 <https://libvirt.org/formatdomain.html#elementsMemoryBacking>
102 --arch ARCH
104 Request a non-native CPU architecture for the guest virtual
105 machine. If omitted, the host CPU architecture will be used in the
106 guest.
107 --machine MACHINE
109 The machine type to emulate. This will typically not need to be
110 specified for Xen or KVM, but is useful for choosing machine types
111 of more exotic architectures.
112 --metadata OPT=VAL,[...]
114 Specify metadata values for the guest. Possible options include
115 name, uuid, title, and description. This option deprecates
116 -u/--uuid and --description.
117 Use --metadata=? to see a list of all available sub options.
119 Complete details at
120 <https://libvirt.org/formatdomain.html#elementsMetadata>
121 --events OPT=VAL,[...]
123 Specify events values for the guest. Possible options include
124 on_poweroff, on_reboot, and on_crash.
125 Use --events=? to see a list of all available sub options. Complete
127 details at <https://libvirt.org/formatdomain.html#elementsEvents>
128 --resource OPT=VAL,[...]
130 Specify resource partitioning for the guest.
131 Use --resource=? to see a list of all available sub options.
133 Complete details at
134 <https://libvirt.org/formatdomain.html#resPartition>
135 --sysinfo OPT=VAL,[...]
137 Configure sysinfo/SMBIOS values exposed to the VM OS.
138 Some examples:
140 --sysinfo host
142 Special type that exposes the host's SMBIOS info into the VM.
143 --sysinfo emulate
145 Sepcial type where hypervisor will generate SMBIOS info into
146 the VM.
147 --sysinfo bios.vendor=custom or --sysinfo smbios,bios.vendor=custom
149 The default type is smbios and allows users to specify SMBIOS
150 info manually.
151 Use --sysinfo=? to see a list of all available sub options.
153 Complete details at
155 <https://libvirt.org/formatdomain.html#elementsSysinfo> and
156 <https://libvirt.org/formatdomain.html#elementsOSBIOS> for smbios
157 XML element.
158 --qemu-commandline ARGS
160 Pass options directly to the qemu emulator. Only works for the
161 libvirt qemu driver. The option can take a string of arguments, for
162 example:
163 --qemu-commandline="-display gtk,gl=on"
165 Environment variables are specified with 'env', for example:
167 --qemu-commandline=env=DISPLAY=:0.1
169 Complete details about the libvirt feature:
171 <https://libvirt.org/drvqemu.html#qemucommand>
172 --vcpus OPTIONS
174 Number of virtual cpus to configure for the guest. If 'maxvcpus' is
175 specified, the guest will be able to hotplug up to MAX vcpus while
176 the guest is running, but will startup with VCPUS.
177 CPU topology can additionally be specified with sockets, cores, and
179 threads. If values are omitted, the rest will be autofilled
180 preferring sockets over cores over threads.
181 'cpuset' sets which physical cpus the guest can use. "CPUSET" is a
183 comma separated list of numbers, which can also be specified in
184 ranges or cpus to exclude. Example:
185 0,2,3,5 : Use processors 0,2,3 and 5
187 1-5,^3,8 : Use processors 1,2,4,5 and 8
188 If the value 'auto' is passed, virt-install attempts to
190 automatically determine an optimal cpu pinning using NUMA data, if
191 available.
192 Use --vcpus=? to see a list of all available sub options. Complete
194 details at
195 <https://libvirt.org/formatdomain.html#elementsCPUAllocation>
196 --numatune OPTIONS
198 Tune NUMA policy for the domain process. Example invocations
199 --numatune 1,2,3,4-7
201 --numatune 1-3,5,memory.mode=preferred
202 Specifies the numa nodes to allocate memory from. This has the same
204 syntax as "--vcpus cpuset=" option. mode can be one of
205 'interleave', 'preferred', or 'strict' (the default). See 'man 8
206 numactl' for information about each mode.
207 Use --numatune=? to see a list of all available sub options.
209 Complete details at
210 <https://libvirt.org/formatdomain.html#elementsNUMATuning>
211 --memtune OPTIONS
213 Tune memory policy for the domain process. Example invocations
214 --memtune 1000
216 --memtune hard_limit=100,soft_limit=60,swap_hard_limit=150,min_guarantee=80
217 Use --memtune=? to see a list of all available sub options.
219 Complete details at
220 <https://libvirt.org/formatdomain.html#elementsMemoryTuning>
221 --blkiotune OPTIONS
223 Tune blkio policy for the domain process. Example invocations
224 --blkiotune 100
226 --blkiotune weight=100,device.path=/dev/sdc,device.weight=200
227 Use --blkiotune=? to see a list of all available sub options.
229 Complete details at
230 <https://libvirt.org/formatdomain.html#elementsBlockTuning>
231 --cpu MODEL[,+feature][,-feature][,match=MATCH][,vendor=VENDOR],...
233 Configure the CPU model and CPU features exposed to the guest. The
234 only required value is MODEL, which is a valid CPU model as known
235 to libvirt.
236 Libvirt's feature policy values force, require, optional, disable,
238 or forbid, or with the shorthand '+feature' and '-feature', which
239 equal 'force=feature' and 'disable=feature' respectively.
240 If exact CPU model is specified virt-install will automatically
242 copy CPU features available on the host to mitigate recent CPU
243 speculative execution side channel and Microarchitectural Store
244 Buffer Data security vulnerabilities. This however will have some
245 impact on performance and will break migration to hosts without
246 security patches. In order to control this behavior there is a
247 secure parameter. Possible values are on and off, with on as the
248 default. It is highly recommended to leave this enabled and ensure
249 all virtualization hosts have fully up to date microcode, kernel &
250 virtualization software installed.
251 Some examples:
253 --cpu core2duo,+x2apic,disable=vmx
255 Expose the core2duo CPU model, force enable x2apic, but do not
256 expose vmx
257 --cpu host
259 Expose the host CPUs configuration to the guest. This enables
260 the guest to take advantage of many of the host CPUs features
261 (better performance), but may cause issues if migrating the
262 guest to a host without an identical CPU.
263 --cpu host-model-only
265 Expose the nearest host CPU model configuration to the guest.
266 It is the best CPU which can be used for a guest on any of the
267 hosts.
268 --cpu
270 numa.cell0.memory=1234,numa.cell0.cpus=0-3,numa.cell1.memory=5678,numa.cell1.cpus=4-7
271 Example of specifying two NUMA cells. This will generate XML
272 like:
273 <cpu>
275 <numa>
276 <cell cpus="0-3" memory="1234"/>
277 <cell cpus="4-7" memory="5678"/>
278 </numa>
279 </cpu>
280 --cpu host-passthrough,cache.mode=passthrough
282 Example of passing through the host cpu's cache information.
283 Use --cpu=? to see a list of all available sub options. Complete
285 details at <https://libvirt.org/formatdomain.html#elementsCPU>
286 --cputune OPTIONS
288 Tune CPU parameters for the guest.
289 Configure which of the host's physical CPUs the domain VCPU will be
291 pinned to. Example invocation
292 --cputune vcpupin0.vcpu=0,vcpupin0.cpuset=0-3,vcpupin1.vcpu=1,vcpupin1.cpuset=4-7
294 Use --cputune=? to see a list of all available sub options.
296 Complete details at
297 <https://libvirt.org/formatdomain.html#elementsCPUTuning>
298 --security/--seclabel type=TYPE[,label=LABEL][,relabel=yes|no],...
300 Configure domain seclabel domain settings. Type can be either
301 'static' or 'dynamic'. 'static' configuration requires a security
302 LABEL. Specifying LABEL without TYPE implies static configuration.
303 Use --security=? to see a list of all available sub options.
305 Complete details at
306 <https://libvirt.org/formatdomain.html#seclabel>
307 --iothreads OPTIONS
309 Specify domain <iothreads> and/or <iothreadids> XML. For example,
310 to configure <iothreads>4</iothreads>, do:
311 --iothreads 4
313 Use --iothreads=? to see a list of all available sub options.
315 Complete details at
316 <https://libvirt.org/formatdomain.html#elementsIOThreadsAllocation>
317 --features FEAT=on|off,...
319 Set elements in the guests <features> XML on or off. Examples
320 include acpi, apic, eoi, privnet, and hyperv features. Some
321 examples:
322 --features apic.eoi=on
324 Enable APIC PV EOI
325 --features hyperv.vapic.state=on,hyperv.spinlocks.state=off
327 Enable hypver VAPIC, but disable spinlocks
328 --features kvm.hidden.state==on
330 Allow the KVM hypervisor signature to be hidden from the guest
331 --features pvspinlock=on
333 Notify the guest that the host supports paravirtual spinlocks
334 for example by exposing the pvticketlocks mechanism.
335 --features gic.version=2
337 This is relevant only for ARM architectures. Possible values
338 are "host" or version number.
339 --features smm.state=on
341 This enables System Management Mode of hypervisor. Some UEFI
342 firmwares may require this feature to be present. (QEMU
343 supports SMM only with q35 machine type.)
344 Use --features=? to see a list of all available sub options.
346 Complete details at
347 <https://libvirt.org/formatdomain.html#elementsFeatures>
348 --clock offset=OFFSET,TIMER_OPT=VAL,...
350 Configure the guest's <clock> XML. Some supported options:
351 --clock offset=OFFSET
353 Set the clock offset, ex. 'utc' or 'localtime'
354 --clock TIMER_present=no
356 Disable a boolean timer. TIMER here might be hpet, kvmclock,
357 etc.
358 --clock TIMER_tickpolicy=VAL
360 Set a timer's tickpolicy value. TIMER here might be rtc, pit,
361 etc. VAL might be catchup, delay, etc. Refer to the libvirt
362 docs for all values.
363 Use --clock=? to see a list of all available sub options. Complete
365 details at <https://libvirt.org/formatdomain.html#elementsTime>
366 --pm OPTIONS
368 Configure guest power management features. Example:
369 --pm suspend_to_memi.enabled=on,suspend_to_disk.enabled=off
371 Use --pm=? to see a list of all available sub options. Complete
373 details at
374 <https://libvirt.org/formatdomain.html#elementsPowerManagement>
375 --launch-security TYPE[,OPTS]
377 Enable launch security for the guest, e.g. AMD SEV.
378 Use --launch-security=? to see a list of all available sub options.
380 Complete details at
381 <https://libvirt.org/formatdomain.html#launchSecurity>. Example
382 invocations:
383 # This will use a default policy 0x03
384 # No dhCert provided, so no data can be exchanged with the SEV
385 firmware
386 --launchSecurity sev
387 # Explicit policy 0x01 - disables debugging, allows guest key sharing
389 --launchSecurity sev,policy=0x01
390 # Provide the session blob obtained from the SEV firmware
392 # Provide dhCert to open a secure communication channel with SEV firmware
393 --launchSecurity sev,session=BASE64SESSIONSTRING,dhCert=BASE64DHCERTSTRING
394 SEV has further implications on usage of virtio devices, so refer
396 to EXAMPLES section to see a full invocation of virt-install with
397 --launchSecurity.
398
400 -c, --cdrom PATH
401 ISO file or CDROM device to use for VM install media. After
402 install, the the virtual CDROM device will remain attached to the
403 VM, but with the ISO or host path media ejected.
404 -l, --location OPTIONS
406 Distribution tree installation source. virt-install can recognize
407 certain distribution trees and fetches a bootable kernel/initrd
408 pair to launch the install.
409 --location allows things like --extra-args for kernel arguments,
411 and using --initrd-inject. If you want to use those options with
412 CDROM media, you can pass the ISO to --location as well which works
413 for some, but not all, CDROM media.
414 The "LOCATION" can take one of the following forms:
416 https://host/path
418 An HTTP server location containing an installable distribution
419 image.
420 ftp://host/path
422 An FTP server location containing an installable distribution
423 image.
424 ISO Probe the ISO and extract files using 'isoinfo'
426 DIRECTORY
428 Path to a local directory containing an installable
429 distribution image. Note that the directory will not be
430 accessible by the guest after initial boot, so the OS installer
431 will need another way to access the rest of the install media.
432 Some distro specific url samples:
434 Fedora/Red Hat Based
436 https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/x86_64/os
437 Debian
439 https://ftp.us.debian.org/debian/dists/stable/main/installer-amd64/
440 Ubuntu
442 https://us.archive.ubuntu.com/ubuntu/dists/wily/main/installer-amd64/
443 Suse
445 https://download.opensuse.org/pub/opensuse/distribution/leap/42.3/repo/oss/
446 Additionally, --location can take 'kernel' and 'initrd' sub
448 options. These paths relative to the specified location URL/ISO
449 that allow selecting specific files for kernel/initrd within the
450 install tree. This can be useful if virt-install/ libosinfo doesn't
451 know where to find the kernel in the specified --location.
452 For example, if you have an ISO that libosinfo doesn't know about
454 called my-unknown.iso, with a kernel at 'kernel/fookernel' and
455 initrd at 'kernel/fooinitrd', you can make this work with:
456 --location my-unknown.iso,kernel=kernel/fookernel,initrd=kernel/fooinitrd
458 --pxe
460 Install from PXE. This just tells the VM to boot off the network
461 for the first boot.
462 --import
464 Skip the OS installation process, and build a guest around an
465 existing disk image. The device used for booting is the first
466 device specified via "--disk" or "--filesystem".
467 -x, --extra-args KERNELARGS
469 Additional kernel command line arguments to pass to the installer
470 when performing a guest install from "--location". One common usage
471 is specifying an anaconda kickstart file for automated installs,
472 such as --extra-args "ks=https://myserver/my.ks"
473 --initrd-inject PATH
475 Add PATH to the root of the initrd fetched with "--location". This
476 can be used to run an automated install without requiring a network
477 hosted kickstart file:
478 --initrd-inject=/path/to/my.ks --extra-args "ks=file:/my.ks"
480 --install
482 This is a larger entry point for various types of install
483 operations. The command has multiple subarguments, similar to
484 --disk and friends. This option is strictly for VM install
485 operations, essentially configuring the first boot.
486 The simplest usage to ex: install fedora29 is:
488 --install fedora29
490 And virt-install will fetch a --location URL from libosinfo, and
492 populate defaults from there.
493 Available suboptions:
495 os= This is os install option described above. The explicit way to
497 specify that would be --install os=fedora29. os= is the default
498 option if none is specified
499 kernel=, initrd=
501 Specify a kernel and initrd pair to use as install media. They
502 are copied into a temporary location before booting the VM, so
503 they can be combined with --initrd-inject and your source media
504 will not be altered. Media will be uploaded to a remote
505 connection if required.
506 Example case using local filesystem paths:
508 --install kernel=/path/to/kernel,initrd=/path/to/initrd
509 Example using network paths. Kernel/initrd will be downloaded
511 locally first, then passed to the VM as local filesystem paths
512 --install
513 kernel=https://127.0.0.1/tree/kernel,initrd=https://127.0.0.1/tree/initrd
514 Note, these are just for install time booting. If you want to
516 set the kernel used for permanent VM booting, use the --boot
517 option.
518 kernel_args=, kernel_args_overwrite=yes|no
520 Specify install time kernel arguments (libvirt <cmdline> XML).
521 These can be combine with ex: kernel/initrd options, or
522 --location media. By default, kernel_args is just like
523 --extra-args, and will _append_ to the arguments that virt-
524 install will try to set by default for most --location
525 installs. If you want to override the virt-install default,
526 additionally specify kernel_args_overwrite=yes
527 bootdev=
529 Specify the install bootdev (hd, cdrom, floppy, network) to
530 boot off of for the install phase. This maps to libvirt
531 <os><boot dev=X> XML.
532 If you want to install off a cdrom or network, it's probably
534 simpler and more backwards compatible to just use --cdrom or
535 --pxe, but this options gives fine grained control over the
536 install process if needed.
537 no_install=yes|no
539 Tell virt-install that there isn't actually any install
540 happening, and you just want to create the VM. --import is just
541 an alias for this, as is specifying --boot without any other
542 install options. The deprecated --live option is the same as
543 '--cdrom $ISO --install no_install=yes'
544 --unattended [OPTIONS]
546 Perform an unattended install using libosinfo's install script
547 support. This is essentially a database of auto install scripts
548 for various distros: Red Hat kickstarts, Debian installer
549 scripting, Windows unattended installs, and potentially others. The
550 simplest invocation is to combine it with --install like:
551 --install fedora29 --unattended
553 A Windows install will look like
555 --cdrom /path/to/my/windows.iso --unattended
557 Sub options are:
559 profile=
561 Choose which libosinfo unattended profile to use. Most distros
562 have a 'desktop' and a 'jeos' profile. virt-install will
563 default to 'desktop' if this is unspecified.
564 admin-password-file=
566 A file used to set the VM OS admin/root password from. This
567 option can be used either as
568 "admin-password-file=/path/to/password-file" or as
569 "admin-password-file=/dev/fd/n", being n the file descriptor of
570 the password-file. Note that only the first line of the file
571 will be considered, including any whitespace characters and
572 excluding new-line.
573 user-password-file=
575 A file used to set the VM user password. This option can be
576 used either as "user-password-file=/path/to/password-file" or
577 as "user-password-file=/dev/fd/n", being n the file descriptor
578 of the password-file. The username is your current host
579 username. Note that only the first line of the file will be
580 considered, including any whitespace characters and excluding
581 new-line.
582 product-key=
584 Set a Windows product key
585 --boot BOOTOPTS
587 Optionally specify the post-install VM boot configuration. This
588 option allows specifying a boot device order, permanently booting
589 off kernel/initrd with option kernel arguments, and enabling a BIOS
590 boot menu (requires libvirt 0.8.3 or later)
591 --boot can be specified in addition to other install options (such
593 as --location, --cdrom, etc.) or can be specified on its own. In
594 the latter case, behavior is similar to the --import install
595 option: there is no 'install' phase, the guest is just created and
596 launched as specified.
597 Some examples:
599 --boot cdrom,fd,hd,network
601 Set the boot device priority as first cdrom, first floppy,
602 first harddisk, network PXE boot.
603 --boot kernel=KERNEL,initrd=INITRD,kernel_args="console=/dev/ttyS0"
605 Have guest permanently boot off a local kernel/initrd pair,
606 with the specified kernel options.
607 --boot kernel=KERNEL,initrd=INITRD,dtb=DTB
609 Have guest permanently boot off a local kernel/initrd pair with
610 an external device tree binary. DTB can be required for some
611 non-x86 configurations like ARM or PPC
612 --boot loader=BIOSPATH
614 Use BIOSPATH as the virtual machine BIOS.
615 --boot bootmenu.enable=on,bios.useserial=on
617 Enable the bios boot menu, and enable sending bios text output
618 over serial console.
619 --boot init=INITPATH
621 Path to a binary that the container guest will init. If a root
622 "--filesystem" has been specified, virt-install will default to
623 /sbin/init, otherwise will default to /bin/sh.
624 --boot uefi
626 Configure the VM to boot from UEFI. In order for virt-install
627 to know the correct UEFI parameters, libvirt needs to be
628 advertising known UEFI binaries via domcapabilities XML, so
629 this will likely only work if using properly configured distro
630 packages.
631 --boot
633 loader=/.../OVMF_CODE.fd,loader.readonly=yes,loader.type=pflash,nvram.template=/.../OVMF_VARS.fd,loader_secure=no
634 Specify that the virtual machine use the custom OVMF binary as
635 boot firmware, mapped as a virtual flash chip. In addition,
636 request that libvirt instantiate the VM-specific UEFI varstore
637 from the custom "/.../OVMF_VARS.fd" varstore template. This is
638 the recommended UEFI setup, and should be used if --boot uefi
639 doesn't know about your UEFI binaries. If your UEFI firmware
640 supports Secure boot feature you can enable it via
641 loader_secure.
642 Use --boot=? to see a list of all available sub options. Complete
644 details at <https://libvirt.org/formatdomain.html#elementsOS>
645 --idmap OPTIONS
647 If the guest configuration declares a UID or GID mapping, the
648 'user' namespace will be enabled to apply these. A suitably
649 configured UID/GID mapping is a pre-requisite to make containers
650 secure, in the absence of sVirt confinement.
651 --idmap can be specified to enable user namespace for LXC
653 containers. Example:
654 --idmap uid.start=0,uid.target=1000,uid.count=10,gid.start=0,gid.target=1000,gid.count=10
656 Use --idmap=? to see a list of all available sub options. Complete
658 details at
659 <https://libvirt.org/formatdomain.html#elementsOSContainer>
660
662 --os-variant OS_VARIANT
663 Optimize the guest configuration for a specific operating system
664 (ex. 'fedora29', 'rhel7', 'win10'). While not required, specifying
665 this options is HIGHLY RECOMMENDED, as it can greatly increase
666 performance by specifying virtio among other guest tweaks.
667 By default, virt-install will attempt to auto detect this value
669 from the install media (currently only supported for URL installs).
670 Autodetection can be disabled with the special value 'none'.
671 Autodetection can be forced with the special value 'auto'.
672 Use the command "osinfo-query os" to get the list of the accepted
674 OS variants.
675
677 --disk OPTIONS
678 Specifies media to use as storage for the guest, with various
679 options. The general format of a disk string is
680 --disk opt1=val1,opt2=val2,...
682 The simplest invocation to create a new 10G disk image and
684 associated disk device:
685 --disk size=10
687 virt-install will generate a path name, and place it in the default
689 image location for the hypervisor. To specify media, the command
690 can either be:
691 --disk /some/storage/path[,opt1=val1]...
693 or explicitly specify one of the following arguments:
695 path
697 A path to some storage media to use, existing or not. Existing
698 media can be a file or block device.
699 Specifying a non-existent path implies attempting to create the
701 new storage, and will require specifying a 'size' value. Even
702 for remote hosts, virt-install will try to use libvirt storage
703 APIs to automatically create the given path.
704 If the hypervisor supports it, path can also be a network URL,
706 like https://example.com/some-disk.img . For network paths,
707 they hypervisor will directly access the storage, nothing is
708 downloaded locally.
709 pool
711 An existing libvirt storage pool name to create new storage on.
712 Requires specifying a 'size' value.
713 vol An existing libvirt storage volume to use. This is specified as
715 'poolname/volname'.
716 Options that apply to storage creation:
718 size
720 size (in GiB) to use if creating new storage
721 sparse
723 whether to skip fully allocating newly created storage. Value
724 is 'yes' or 'no'. Default is 'yes' (do not fully allocate)
725 unless it isn't supported by the underlying storage type.
726 The initial time taken to fully-allocate the guest virtual disk
728 (sparse=no) will be usually balanced by faster install times
729 inside the guest. Thus use of this option is recommended to
730 ensure consistently high performance and to avoid I/O errors in
731 the guest should the host filesystem fill up.
732 format
734 Disk image format. For file volumes, this can be 'raw',
735 'qcow2', 'vmdk', etc. See format types in
736 <https://libvirt.org/storage.html> for possible values. This is
737 often mapped to the driver_type value as well.
738 If not specified when creating file images, this will default
740 to 'qcow2'.
741 If creating storage, this will be the format of the new image.
743 If using an existing image, this overrides libvirt's format
744 auto-detection.
745 backing_store
747 Path to a disk to use as the backing store for the newly
748 created image.
749 backing_format
751 Disk image format of backing_store
752 Some example device configuration suboptions:
754 device
756 Disk device type. Example values are be 'cdrom', 'disk', 'lun'
757 or 'floppy'. The default is 'disk'.
758 boot.order
760 Guest installation with multiple disks will need this parameter
761 to boot correctly after being installed. A boot.order parameter
762 will take values 1,2,3,... Devices with lower value has higher
763 priority. This option applies to other bootable device types
764 as well.
765 target.bus or bus
767 Disk bus type. Example values are be 'ide', 'sata', 'scsi',
768 'usb', 'virtio' or 'xen'. The default is hypervisor dependent
769 since not all hypervisors support all bus types.
770 readonly
772 Set drive as readonly (takes 'on' or 'off')
773 shareable
775 Set drive as shareable (takes 'on' or 'off')
776 cache
778 The cache mode to be used. The host pagecache provides cache
779 memory. The cache value can be 'none', 'writethrough',
780 'directsync', 'unsafe' or 'writeback'. 'writethrough' provides
781 read caching. 'writeback' provides read and write caching.
782 'directsync' bypasses the host page cache. 'unsafe' may cache
783 all content and ignore flush requests from the guest.
784 driver.discard
786 Whether discard (also known as "trim" or "unmap") requests are
787 ignored or passed to the filesystem. The value can be either
788 "unmap" (allow the discard request to be passed) or "ignore"
789 (ignore the discard request). Since 1.0.6 (QEMU and KVM only)
790 driver.name
792 Driver name the hypervisor should use when accessing the
793 specified storage. Typically does not need to be set by the
794 user.
795 driver.type
797 Driver format/type the hypervisor should use when accessing the
798 specified storage. Typically does not need to be set by the
799 user.
800 driver.io
802 Disk IO backend. Can be either "threads" or "native".
803 driver.error_policy
805 How guest should react if a write error is encountered. Can be
806 one of "stop", "ignore", or "enospace"
807 serial
809 Serial number of the emulated disk device. This is used in
810 linux guests to set /dev/disk/by-id symlinks. An example serial
811 number might be: WD-WMAP9A966149
812 source.startupPolicy
814 It defines what to do with the disk if the source file is not
815 accessible. See possible values in
816 <https://www.libvirt.org/formatdomain.html#elementsDisks>,
817 "startupPolicy" attribute of the <disk> element
818 snapshot
820 Defines default behavior of the disk during disk snapshots.
821 See possible values in
822 <https://www.libvirt.org/formatdomain.html#elementsDisks>,
823 "snapshot" attribute of the <disk> element.
824 See the examples section for some uses. This option deprecates
826 -f/--file, -s/--file-size, --nonsparse, and --nodisks.
827 Use --disk=? to see a list of all available sub options. Complete
829 details at <https://libvirt.org/formatdomain.html#elementsDisks>
830 --filesystem
832 Specifies a directory on the host to export to the guest. The most
833 simple invocation is:
834 --filesystem /source/on/host,/target/point/in/guest
836 Which will work for recent QEMU and linux guest OS or LXC
838 containers. For QEMU, the target point is just a mounting hint in
839 sysfs, so will not be automatically mounted.
840 Some example suboptions:
842 type
844 The type or the source directory. Valid values are 'mount' (the
845 default) or 'template' for OpenVZ templates.
846 accessmode or mode
848 The access mode for the source directory from the guest OS.
849 Only used with QEMU and type=mount. Valid modes are
850 'passthrough' (the default), 'mapped', or 'squash'. See libvirt
851 domain XML documentation for more info.
852 source
854 The directory on the host to share.
855 target
857 The mount location to use in the guest.
858 Use --filesystem=? to see a list of all available sub options.
860 Complete details at
861 <https://libvirt.org/formatdomain.html#elementsFilesystems>
862
864 -w OPTIONS
865 --network OPTIONS
866 Connect the guest to the host network. The value for "NETWORK" can
867 take one of 4 formats:
868 bridge=BRIDGE
870 Connect to a bridge device in the host called "BRIDGE". Use
871 this option if the host has static networking config & the
872 guest requires full outbound and inbound connectivity to/from
873 the LAN. Also use this if live migration will be used with this
874 guest.
875 network=NAME
877 Connect to a virtual network in the host called "NAME". Virtual
878 networks can be listed, created, deleted using the "virsh"
879 command line tool. In an unmodified install of "libvirt" there
880 is usually a virtual network with a name of "default". Use a
881 virtual network if the host has dynamic networking (eg
882 NetworkManager), or using wireless. The guest will be NATed to
883 the LAN by whichever connection is active.
884 type=direct,source=IFACE[,source.mode=MODE]
886 Direct connect to host interface IFACE using macvtap.
887 user
889 Connect to the LAN using SLIRP. Only use this if running a QEMU
890 guest as an unprivileged user. This provides a very limited
891 form of NAT.
892 none
894 Tell virt-install not to add any default network interface.
895 If this option is omitted a single NIC will be created in the
897 guest. If there is a bridge device in the host with a physical
898 interface enslaved, that will be used for connectivity. Failing
899 that, the virtual network called "default" will be used. This
900 option can be specified multiple times to setup more than one NIC.
901 Some example suboptions:
903 model.type or model
905 Network device model as seen by the guest. Value can be any nic
906 model supported by the hypervisor, e.g.: 'e1000', 'rtl8139',
907 'virtio', ...
908 mac.address or mac
910 Fixed MAC address for the guest; If this parameter is omitted,
911 or the value "RANDOM" is specified a suitable address will be
912 randomly generated. For Xen virtual machines it is required
913 that the first 3 pairs in the MAC address be the sequence
914 '00:16:3e', while for QEMU or KVM virtual machines it must be
915 '52:54:00'.
916 filterref.filter
918 Controlling firewall and network filtering in libvirt. Value
919 can be any nwfilter defined by the "virsh" 'nwfilter'
920 subcommands. Available filters can be listed by running 'virsh
921 nwfilter-list', e.g.: 'clean-traffic', 'no-mac-spoofing', ...
922 virtualport.* options
924 Configure the device virtual port profile. This is used for
925 802.Qbg, 802.Qbh, midonet, and openvswitch config. Check for
926 'virtualport' references in the libvirt documentation:
927 "https://libvirt.org/formatdomain.html#elementsNICS"
928 Use --network=? to see a list of all available sub options.
930 Complete details at
931 <https://libvirt.org/formatdomain.html#elementsNICS>
932 This option deprecates -m/--mac, -b/--bridge, and --nonetworks
934
936 If no graphics option is specified, "virt-install" will try to select
937 the appropriate graphics if the DISPLAY environment variable is set,
938 otherwise '--graphics none' is used.
939 --graphics TYPE,opt1=arg1,opt2=arg2,...
941 Specifies the graphical display configuration. This does not
942 configure any virtual hardware, just how the guest's graphical
943 display can be accessed. Typically the user does not need to
944 specify this option, virt-install will try and choose a useful
945 default, and launch a suitable connection.
946 General format of a graphical string is
948 --graphics TYPE,opt1=arg1,opt2=arg2,...
950 For example:
952 --graphics vnc,password=foobar
954 Some supported options are:
956 type
958 The display type. This is one of:
959 vnc
961 Setup a virtual console in the guest and export it as a VNC
963 server in the host. Unless the "port" parameter is also
964 provided, the VNC server will run on the first free port number
965 at 5900 or above. The actual VNC display allocated can be
966 obtained using the "vncdisplay" command to "virsh" (or
967 virt-viewer(1) can be used which handles this detail for the
968 use).
969 spice
971 Export the guest's console using the Spice protocol. Spice
973 allows advanced features like audio and USB device streaming,
974 as well as improved graphical performance.
975 Using spice graphic type will work as if those arguments were
977 given:
978 --video qxl --channel spicevmc
980 none
982 No graphical console will be allocated for the guest. Guests
984 will likely need to have a text console configured on the first
985 serial port in the guest (this can be done via the --extra-args
986 option). The command 'virsh console NAME' can be used to
987 connect to the serial device.
988 port
990 Request a permanent, statically assigned port number for the
991 guest console. This is used by 'vnc' and 'spice'
992 tlsPort
994 Specify the spice tlsport.
995 listen
997 Address to listen on for VNC/Spice connections. Default is
998 typically 127.0.0.1 (localhost only), but some hypervisors
999 allow changing this globally (for example, the qemu driver
1000 default can be changed in /etc/libvirt/qemu.conf). Use 0.0.0.0
1001 to allow access from other machines.
1002 Use 'none' to specify that the display server should not listen
1004 on any port. The display server can be accessed only locally
1005 through libvirt unix socket (virt-viewer with --attach for
1006 instance).
1007 Use 'socket' to have the VM listen on a libvirt generated unix
1009 socket path on the host filesystem.
1010 This is used by 'vnc' and 'spice'
1012 password
1014 Request a console password, required at connection time.
1015 Beware, this info may end up in virt-install log files, so
1016 don't use an important password. This is used by 'vnc' and
1017 'spice'
1018 gl.enable
1020 Whether to use OpenGL accelerated rendering. Value is 'yes' or
1021 'no'. This is used by 'spice'.
1022 gl.rendernode
1024 DRM render node path to use. This is used when 'gl' is enabled.
1025 Use --graphics=? to see a list of all available sub options.
1027 Complete details at
1028 <https://libvirt.org/formatdomain.html#elementsGraphics>
1029 This deprecates the following options: --vnc, --vncport,
1031 --vnclisten, -k/--keymap, --sdl, --nographics
1032 --noautoconsole
1034 Don't automatically try to connect to the guest console. The
1035 default behaviour is to launch virt-viewer(1) to display the
1036 graphical console, or to run the "virsh" "console" command to
1037 display the text console. Use of this parameter will disable this
1038 behaviour.
1039 Note, virt-install exits quickly when this option is specified. If
1041 your command requested a multistep install, like --cdrom or
1042 --location, after the install phase is complete the VM will be
1043 shutoff, regardless of whether a reboot was requested in the VM. If
1044 you want the VM to be rebooted, virt-install must remain running.
1045 You can use '--wait' to keep virt-install alive even if
1046 --noautoconsole is specified.
1047
1049 Options to override the default virtualization type choices.
1050 -v
1052 --hvm
1053 Request the use of full virtualization, if both para & full
1054 virtualization are available on the host. This parameter may not be
1055 available if connecting to a Xen hypervisor on a machine without
1056 hardware virtualization support. This parameter is implied if
1057 connecting to a QEMU based hypervisor.
1058 -p
1060 --paravirt
1061 This guest should be a paravirtualized guest. If the host supports
1062 both para & full virtualization, and neither this parameter nor the
1063 "--hvm" are specified, this will be assumed.
1064 --container
1066 This guest should be a container type guest. This option is only
1067 required if the hypervisor supports other guest types as well (so
1068 for example this option is the default behavior for LXC and OpenVZ,
1069 but is provided for completeness).
1070 --virt-type
1072 The hypervisor to install on. Example choices are kvm, qemu, or
1073 xen. Available options are listed via 'virsh capabilities' in the
1074 <domain> tags.
1075 This deprecates the --accelerate option, which is now the default
1077 behavior. To install a plain QEMU guest, use '--virt-type qemu'
1078
1080 All devices have a set of address.* options for configuring the
1081 particulars of the device's address on its parent controller or bus.
1082 See "https://libvirt.org/formatdomain.html#elementsAddress" for
1083 details.
1084 --controller OPTIONS
1086 Attach a controller device to the guest. TYPE is one of: ide, fdc,
1087 scsi, sata, virtio-serial, or usb.
1088 Controller also supports the special values usb2 and usb3 to
1090 specify which version of the USB controller should be used (version
1091 2 or 3).
1092 Some example suboptions:
1094 model
1096 Controller model. These may vary according to the hypervisor
1097 and its version. Most commonly used models are e.g. auto,
1098 virtio-scsi for the scsi controller, ehci or none for the usb
1099 controller. For full list and further details on
1100 controllers/models, see
1101 "https://libvirt.org/formatdomain.html#elementsControllers".
1102 address
1104 Shorthand for setting a manual PCI address from an lscpi style
1105 string. The preferred method for setting this is using the
1106 address.* parameters.
1107 index
1109 A decimal integer describing in which order the bus controller
1110 is encountered, and to reference the controller bus.
1111 Use --controller=? to see a list of all available sub options.
1113 Complete details at
1114 <https://libvirt.org/formatdomain.html#elementsControllers>
1115 --input OPTIONS
1117 Attach an input device to the guest. Example input device types are
1118 mouse, tablet, or keyboard.
1119 Use --input=? to see a list of all available sub options. Complete
1121 details at <https://libvirt.org/formatdomain.html#elementsInput>
1122 --hostdev OPTIONS
1124 --host-device OPTIONS
1125 Attach a physical host device to the guest. Some example values for
1126 HOSTDEV:
1127 --hostdev pci_0000_00_1b_0
1129 A node device name via libvirt, as shown by 'virsh
1130 nodedev-list'
1131 --hostdev 001.003
1133 USB by bus, device (via lsusb).
1134 --hostdev 0x1234:0x5678
1136 USB by vendor, product (via lsusb).
1137 --hostdev 1f.01.02
1139 PCI device (via lspci).
1140 --hostdev wlan0,type=net
1142 Network device (in LXC container).
1143 --hostdev /dev/net/tun,type=misc
1145 Character device (in LXC container).
1146 --hostdev /dev/sdf,type=storage
1148 Block device (in LXC container).
1149 Use --hostdev=? to see a list of all available sub options.
1151 Complete details at
1152 <https://libvirt.org/formatdomain.html#elementsHostDev>
1153 --sound MODEL
1155 Attach a virtual audio device to the guest. MODEL specifies the
1156 emulated sound card model. Possible values are ich6, ich9, ac97,
1157 es1370, sb16, pcspk, or default. 'default' will try to pick the
1158 best model that the specified OS supports.
1159 This deprecates the old --soundhw option.
1161 Use --sound=? to see a list of all available sub options. Complete
1163 details at <https://libvirt.org/formatdomain.html#elementsSound>
1164 --watchdog MODEL[,action=ACTION]
1166 Attach a virtual hardware watchdog device to the guest. This
1167 requires a daemon and device driver in the guest. The watchdog
1168 fires a signal when the virtual machine appears to hung. ACTION
1169 specifies what libvirt will do when the watchdog fires. Values are
1170 reset
1172 Forcefully reset the guest (the default)
1173 poweroff
1175 Forcefully power off the guest
1176 pause
1178 Pause the guest
1179 none
1181 Do nothing
1182 shutdown
1184 Gracefully shutdown the guest (not recommended, since a hung
1185 guest probably won't respond to a graceful shutdown)
1186 MODEL is the emulated device model: either i6300esb (the default)
1188 or ib700. Some examples:
1189 Use the recommended settings:
1191 --watchdog default
1193 Use the i6300esb with the 'poweroff' action
1195 --watchdog i6300esb,action=poweroff
1197 Use --watchdog=? to see a list of all available sub options.
1199 Complete details at
1200 <https://libvirt.org/formatdomain.html#elementsWatchdog>
1201 --parallel OPTIONS
1203 --serial OPTIONS
1204 Specifies a serial device to attach to the guest, with various
1205 options. The general format of a serial string is
1206 --serial type,opt1=val1,opt2=val2,...
1208 --serial and --parallel devices share all the same options, unless
1210 otherwise noted. Some of the types of character device redirection
1211 are:
1212 --serial pty
1214 Pseudo TTY. The allocated pty will be listed in the running
1215 guests XML description.
1216 --serial dev,path=HOSTPATH
1218 Host device. For serial devices, this could be /dev/ttyS0. For
1219 parallel devices, this could be /dev/parport0.
1220 --serial file,path=FILENAME
1222 Write output to FILENAME.
1223 --serial tcp,host=HOST:PORT,source.mode=MODE,protocol.type=PROTOCOL
1225 TCP net console. MODE is either 'bind' (wait for connections on
1226 HOST:PORT) or 'connect' (send output to HOST:PORT), default is
1227 'bind'. HOST defaults to '127.0.0.1', but PORT is required.
1228 PROTOCOL can be either 'raw' or 'telnet' (default 'raw'). If
1229 'telnet', the port acts like a telnet server or client. Some
1230 examples:
1231 Wait for connections on any address, port 4567:
1233 --serial tcp,host=0.0.0.0:4567
1235 Connect to localhost, port 1234:
1237 --serial tcp,host=:1234,source.mode=connect
1239 Wait for telnet connection on localhost, port 2222. The user
1241 could then connect interactively to this console via 'telnet
1242 localhost 2222':
1243 --serial tcp,host=:2222,source.mode=bind,source.protocol=telnet
1245 --serial udp,host=CONNECT_HOST:PORT,bind_host=BIND_HOST:BIND_PORT
1247 UDP net console. HOST:PORT is the destination to send output to
1248 (default HOST is '127.0.0.1', PORT is required).
1249 BIND_HOST:BIND_PORT is the optional local address to bind to
1250 (default BIND_HOST is 127.0.0.1, but is only set if BIND_PORT
1251 is specified). Some examples:
1252 Send output to default syslog port (may need to edit
1254 /etc/rsyslog.conf accordingly):
1255 --serial udp,host=:514
1257 Send output to remote host 192.168.10.20, port 4444 (this
1259 output can be read on the remote host using 'nc -u -l 4444'):
1260 --serial udp,host=192.168.10.20:4444
1262 --serial unix,path=UNIXPATH,mode=MODE
1264 Unix socket, see unix(7). MODE has similar behavior and
1265 defaults as --serial tcp,mode=MODE
1266 Use --serial=? or --parallel=? to see a list of all available sub
1268 options. Complete details at
1269 <https://libvirt.org/formatdomain.html#elementsCharSerial> and
1270 <https://libvirt.org/formatdomain.html#elementsCharParallel>
1271 --channel
1273 Specifies a communication channel device to connect the guest and
1274 host machine. This option uses the same options as --serial and
1275 --parallel for specifying the host/source end of the channel. Extra
1276 'target' options are used to specify how the guest machine sees the
1277 channel.
1278 Some of the types of character device redirection are:
1280 --channel SOURCE,target.type=guestfwd,target.address=HOST:PORT
1282 Communication channel using QEMU usermode networking stack. The
1283 guest can connect to the channel using the specified HOST:PORT
1284 combination.
1285 --channel SOURCE,target.type=virtio[,target.name=NAME]
1287 Communication channel using virtio serial (requires 2.6.34 or
1288 later host and guest). Each instance of a virtio --channel line
1289 is exposed in the guest as /dev/vport0p1, /dev/vport0p2, etc.
1290 NAME is optional metadata, and can be any string, such as
1291 org.linux-kvm.virtioport1. If specified, this will be exposed
1292 in the guest at /sys/class/virtio-ports/vport0p1/NAME
1293 --channel spicevmc,target.type=virtio[,target.name=NAME]
1295 Communication channel for QEMU spice agent, using virtio serial
1296 (requires 2.6.34 or later host and guest). NAME is optional
1297 metadata, and can be any string, such as the default
1298 com.redhat.spice.0 that specifies how the guest will see the
1299 channel.
1300 Use --channel=? to see a list of all available sub options.
1302 Complete details at
1303 <https://libvirt.org/formatdomain.html#elementsCharChannel>
1304 --console
1306 Connect a text console between the guest and host. Certain guest
1307 and hypervisor combinations can automatically set up a getty in the
1308 guest, so an out of the box text login can be provided
1309 (target_type=xen for xen paravirt guests, and possibly
1310 target_type=virtio in the future).
1311 Example:
1313 --console pty,target.type=virtio
1315 Connect a virtio console to the guest, redirected to a PTY on
1316 the host. For supported guests, this exposes /dev/hvc0 in the
1317 guest. See https://fedoraproject.org/wiki/Features/VirtioSerial
1318 for more info. virtio console requires libvirt 0.8.3 or later.
1319 Use --console=? to see a list of all available sub options.
1321 Complete details at
1322 <https://libvirt.org/formatdomain.html#elementsCharConsole>
1323 --video OPTIONS
1325 Specify what video device model will be attached to the guest.
1326 Valid values for VIDEO are hypervisor specific, but some options
1327 for recent kvm are cirrus, vga, qxl, virtio, or vmvga (vmware).
1328 Use --video=? to see a list of all available sub options. Complete
1330 details at <https://libvirt.org/formatdomain.html#elementsVideo>
1331 --smartcard MODE[,OPTIONS]
1333 Configure a virtual smartcard device.
1334 Mode is one of host, host-certificates, or passthrough. Additional
1336 options are:
1337 type
1339 Character device type to connect to on the host. This is only
1340 applicable for passthrough mode.
1341 An example invocation:
1343 --smartcard passthrough,type=spicevmc
1345 Use the smartcard channel of a SPICE graphics device to pass
1346 smartcard info to the guest
1347 Use --smartcard=? to see a list of all available sub options.
1349 Complete details at
1350 <https://libvirt.org/formatdomain.html#elementsSmartcard>
1351 --redirdev BUS[,OPTIONS]
1353 Add a redirected device.
1354 type
1356 The redirection type, currently supported is tcp or spicevmc.
1357 server
1359 The TCP server connection details, of the form 'server:port'.
1360 Examples of invocation:
1362 --redirdev usb,type=tcp,server=localhost:4000
1364 Add a USB redirected device provided by the TCP server on
1365 'localhost' port 4000.
1366 --redirdev usb,type=spicevmc
1368 Add a USB device redirected via a dedicated Spice channel.
1369 Use --redirdev=? to see a list of all available sub options.
1371 Complete details at
1372 <https://libvirt.org/formatdomain.html#elementsRedir>
1373 --memballoon MODEL
1375 Attach a virtual memory balloon device to the guest. If the
1376 memballoon device needs to be explicitly disabled, MODEL='none' is
1377 used.
1378 MODEL is the type of memballoon device provided. The value can be
1380 'virtio', 'xen' or 'none'. Some examples:
1381 Use the recommended settings:
1383 --memballoon virtio
1385 Do not use memballoon device:
1387 --memballoon none
1389 Use --memballoon=? to see a list of all available sub options.
1391 Complete details at
1392 <https://libvirt.org/formatdomain.html#elementsMemBalloon>
1393 --tpm TYPE[,OPTIONS]
1395 Configure a virtual TPM device.
1396 Type must be passthrough. Additional options are:
1398 model
1400 The device model to present to the guest operating system.
1401 Model must be tpm-tis.
1402 An example invocation:
1404 --tpm passthrough,model=tpm-tis
1406 Make the host's TPM accessible to a single guest.
1407 --tpm /dev/tpm
1409 Convenience option for passing through the hosts TPM.
1410 Use --tpm=? to see a list of all available sub options. Complete
1412 details at <https://libvirt.org/formatdomain.html#elementsTpm>
1413 --rng TYPE[,OPTIONS]
1415 Configure a virtual RNG device.
1416 Type can be random or egd.
1418 If the specified type is random then these values must be
1420 specified:
1421 backend
1423 The device to use as a source of entropy.
1424 Whereas, when the type is egd, these values must be provided:
1426 backend.source.host
1428 Specify the host of the Entropy Gathering Daemon to connect to.
1429 backend.source.service
1431 Specify the port of the Entropy Gathering Daemon to connect to.
1432 backend.type
1434 Specify the type of the connection: tcp or udp.
1435 backend.source.mode
1437 Specify the mode of the connection. It is either 'bind' (wait
1438 for connections on HOST:PORT) or 'connect' (send output to
1439 HOST:PORT).
1440 backend.connect_host
1442 Specify the remote host to connect to when the specified
1443 backend_type is udp and backend_mode is bind.
1444 backend.connect_service
1446 Specify the remote service to connect to when the specified
1447 backend_type is udp and backend_mode is bind.
1448 An example invocation:
1450 --rng
1452 egd,backend.source.host=localhost,backend.source.service=8000,backend.type=tcp
1453 Connect to localhost to the TCP port 8000 to get entropy data.
1454 --rng /dev/random
1456 Use the /dev/random device to get entropy data, this form
1457 implicitly uses the "random" model.
1458 Use --rng=? to see a list of all available sub options.
1460 Complete details at
1461 <https://libvirt.org/formatdomain.html#elementsRng>
1462 --panic MODEL[,OPTS]
1464 Attach a panic notifier device to the guest. For the recommended
1465 settings, use:
1466 --panic default
1468 Use --panic=? to see a list of all available sub options. Complete
1470 details at <https://libvirt.org/formatdomain.html#elementsPanic>
1471 --memdev OPTS
1473 Add a memory module to a guest which can be hotunplugged. To add a
1474 memdev you need to configure hotplugmemory and NUMA for a guest.
1475 Use --memdev=? to see a list of all available sub options. Complete
1477 details at <https://libvirt.org/formatdomain.html#elementsMemory>.
1478 --vsock OPTS
1480 Configure a vsock host/guest interface. A typical configuration
1481 would be
1482 --vsock cid.auto=yes
1484 Use --vsock=? to see a list of all available sub options. Complete
1486 details at <https://libvirt.org/formatdomain.html#vsock>.
1487
1489 -h
1490 --help
1491 Show the help message and exit
1492 --version
1494 Show program's version number and exit
1495 --autostart
1497 Set the autostart flag for a domain. This causes the domain to be
1498 started on host boot up.
1499 --transient
1501 Use --import or --boot and --transient if you want a transient
1502 libvirt VM. These VMs exist only until the domain is shut down or
1503 the host server is restarted. Libvirt forgets the XML
1504 configuration of the VM after either of these events. Note that
1505 the VM's disks will not be deleted. See:
1506 <https://wiki.libvirt.org/page/VM_lifecycle#Transient_guest_domains_vs_Persistent_guest_domains>
1507 --destroy-on-exit
1509 When the VM console window is exited, destroy (force poweroff) the
1510 VM. If you combine this with --transient, this makes the virt-
1511 install command work similar to qemu, where the VM is shutdown when
1512 the console window is closed by the user.
1513 --print-xml [STEP]
1515 Print the generated XML of the guest, instead of defining it. By
1516 default this WILL do storage creation (can be disabled with
1517 --dry-run). This option implies --quiet.
1518 If the VM install has multiple phases, by default this will print
1520 all generated XML. If you want to print a particular step, use
1521 --print-xml 2 (for the second phase XML).
1522 --noreboot
1524 Prevent the domain from automatically rebooting after the install
1525 has completed.
1526 --wait WAIT
1528 Configure how virt-install will wait for the install to complete.
1529 Without this option, virt-install will wait for the console to
1530 close (not necessarily indicating the guest has shutdown), or in
1531 the case of --noautoconsole, simply kick off the install and exit.
1532 Bare '--wait' or any negative value will make virt-install wait
1534 indefinitely. Any positive number is the number of minutes virt-
1535 install will wait. If the time limit is exceeded, virt-install
1536 simply exits, leaving the virtual machine in its current state.
1537 --dry-run
1539 Proceed through the guest creation process, but do NOT create
1540 storage devices, change host device configuration, or actually
1541 teach libvirt about the guest. virt-install may still fetch
1542 install media, since this is required to properly detect the OS to
1543 install.
1544 --check
1546 Enable or disable some validation checks. Some examples are warning
1547 about using a disk that's already assigned to another VM (--check
1548 path_in_use=on|off), or warning about potentially running out of
1549 space during disk allocation (--check disk_size=on|off). Most
1550 checks are performed by default.
1551 -q
1553 --quiet
1554 Only print fatal error messages.
1555 -d
1557 --debug
1558 Print debugging information to the terminal when running the
1559 install process. The debugging information is also stored in
1560 "~/.cache/virt-manager/virt-install.log" even if this parameter is
1561 omitted.
1562
1564 The simplest invocation to interactively install a Fedora 29 KVM VM
1565 with recommended defaults. virt-viewer(1) will be launched to
1566 graphically interact with the VM install
1567 # sudo virt-install --install fedora29
1569 Similar, but use libosinfo's unattended install support, which will
1571 perform the fedora29 install automatically without user intervention:
1572 # sudo virt-install --install fedora29 --unattended
1574 Install a Windows 10 VM, using 40GiB storage in the default location
1576 and 4096MiB of ram, and ensure we are connecting to the system libvirtd
1577 instance:
1578 # virt-install \
1580 --connect qemu:///system \
1581 --name my-win10-vm \
1582 --memory 4096 \
1583 --disk size=40 \
1584 --os-variant win10 \
1585 --cdrom /path/to/my/win10.iso
1586 Install a CentOS 7 KVM from a URL, with recommended device defaults and
1588 default required storag,e but specifically request VNC graphics instead
1589 of the default SPICE, and request 8 virtual CPUs and 8192 MiB of
1590 memory:
1591 # virt-install \
1593 --connect qemu:///system \
1594 --memory 8192 \
1595 --vcpus 8 \
1596 --graphics vnc \
1597 --os-variant centos7.0 \
1598 --location http://mirror.centos.org/centos-7/7/os/x86_64/
1599 Create a VM around an existing debian9 disk image:
1601 # virt-install \
1603 --import \
1604 --memory 512 \
1605 --disk /home/user/VMs/my-debian9.img \
1606 --os-variant debian9
1607 Start serial QEMU ARM VM, which requires specifying a manual kernel.
1609 # virt-install \
1611 --name armtest \
1612 --memory 1024 \
1613 --arch armv7l --machine vexpress-a9 \
1614 --disk /home/user/VMs/myarmdisk.img \
1615 --boot kernel=/tmp/my-arm-kernel,initrd=/tmp/my-arm-initrd,dtb=/tmp/my-arm-dtb,kernel_args="console=ttyAMA0 rw root=/dev/mmcblk0p3" \
1616 --graphics none
1617 Start an SEV launch security VM with 4GB RAM, 4GB+256MiB of hard_limit,
1619 with a couple of virtio devices:
1620 Note: The IOMMU flag needs to be turned on with driver.iommu for virtio
1622 devices. Usage of --memtune is currently required because of SEV
1623 limitations, refer to libvirt docs for a detailed explanation.
1624 # virt-install \
1626 --name foo \
1627 --memory 4096 \
1628 --boot uefi \
1629 --machine q35 \
1630 --memtune hard_limit=4563402 \
1631 --disk size=15,target.bus=scsi \
1632 --import \
1633 --controller type=scsi,model=virtio-scsi,driver.iommu=on \
1634 --controller type=virtio-serial,driver.iommu=on \
1635 --network network=default,model=virtio,driver.iommu=on \
1636 --rng driver,iommu=on \
1637 --memballoon driver.iommu=on \
1638 --launchSecurity sev
1639
1641 Please see <https://virt-manager.org/bugs>
1642
1644 Copyright (C) Red Hat, Inc, and various contributors. This is free
1645 software. You may redistribute copies of it under the terms of the GNU
1646 General Public License "https://www.gnu.org/licenses/gpl.html". There
1647 is NO WARRANTY, to the extent permitted by law.
1648
1650 virsh(1), "virt-clone(1)", "virt-manager(1)", the project website
1651 "https://virt-manager.org"
16522.2.1 2020-01-31 VIRT-INSTALL(1)