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.
33 Many arguments have sub options, specified like opt1=foo,opt2=bar, etc.
35 Try --option=? to see a complete list of sub options associated with
36 that argument, example: virt-install --disk=?
37 Most options are not required. Minimum requirements are --name,
39 --memory, guest storage (--disk or --filesystem), and an install
40 option.
41
43 --connect URI
44 Connect to a non-default hypervisor. If this isn't specified,
45 libvirt will try and choose the most suitable default.
46 Some valid options here are:
48 qemu:///system
50 For creating KVM and QEMU guests to be run by the system
51 libvirtd instance. This is the default mode that virt-manager
52 uses, and what most KVM users want.
53 qemu:///session
55 For creating KVM and QEMU guests for libvirtd running as the
56 regular user.
57 xen:///
59 For connecting to Xen.
60 lxc:///
62 For creating linux containers
63
65 General configuration parameters that apply to all types of guest
66 installs.
67 -n NAME
69 --name NAME
70 Name of the new guest virtual machine instance. This must be unique
71 amongst all guests known to the hypervisor on the connection,
72 including those not currently active. To re-define an existing
73 guest, use the virsh(1) tool to shut it down ('virsh shutdown') &
74 delete ('virsh undefine') it prior to running "virt-install".
75 --memory OPTIONS
77 Memory to allocate for the guest, in MiB. This deprecates the
78 -r/--ram option. Sub options are available, like 'maxmemory',
79 'hugepages', 'hotplugmemorymax' and 'hotplugmemoryslots'. The
80 memory parameter is mapped to <currentMemory> element, the
81 'maxmemory' sub-option is mapped to <memory> element and
82 'hotplugmemorymax' and 'hotplugmemoryslots' are mapped to
83 <maxMemory> element.
84 To configure memory modules which can be hotunplugged see --memdev
86 description.
87 Use --memory=? to see a list of all available sub options. Complete
89 details at
90 <https://libvirt.org/formatdomain.html#elementsMemoryAllocation>
91 --memorybacking OPTIONS
93 This option will influence how virtual memory pages are backed by
94 host pages.
95 Use --memorybacking=? to see a list of all available sub options.
97 Complete details at
98 <https://libvirt.org/formatdomain.html#elementsMemoryBacking>
99 --arch ARCH
101 Request a non-native CPU architecture for the guest virtual
102 machine. If omitted, the host CPU architecture will be used in the
103 guest.
104 --machine MACHINE
106 The machine type to emulate. This will typically not need to be
107 specified for Xen or KVM, but is useful for choosing machine types
108 of more exotic architectures.
109 --metadata OPT=VAL,[...]
111 Specify metadata values for the guest. Possible options include
112 name, uuid, title, and description. This option deprecates
113 -u/--uuid and --description.
114 Use --metadata=? to see a list of all available sub options.
116 Complete details at
117 <https://libvirt.org/formatdomain.html#elementsMetadata>
118 --events OPT=VAL,[...]
120 Specify events values for the guest. Possible options include
121 on_poweroff, on_reboot, and on_crash.
122 Use --events=? to see a list of all available sub options. Complete
124 details at <https://libvirt.org/formatdomain.html#elementsEvents>
125 --resource OPT=VAL,[...]
127 Specify resource partitioning for the guest.
128 Use --resource=? to see a list of all available sub options.
130 Complete details at
131 <https://libvirt.org/formatdomain.html#resPartition>
132 --sysinfo OPT=VAL,[...]
134 Configure sysinfo/SMBIOS values exposed to the guest OS. '--sysinfo
135 host' can be used to expose the host's SMBIOS info to the VM,
136 otherwise values can be manually specified.
137 Use --sysinfo=? to see a list of all available sub options.
139 Complete details at
140 <https://libvirt.org/formatdomain.html#elementsSysinfo>
141 --qemu-commandline ARGS
143 Pass options directly to the qemu emulator. Only works for the
144 libvirt qemu driver. The option can take a string of arguments, for
145 example:
146 --qemu-commandline="-display gtk,gl=on"
148 Environment variables are specified with 'env', for example:
150 --qemu-commandline=env=DISPLAY=:0.1
152 Complete details about the libvirt feature:
154 <https://libvirt.org/drvqemu.html#qemucommand>
155 --vcpus OPTIONS
157 Number of virtual cpus to configure for the guest. If 'maxvcpus' is
158 specified, the guest will be able to hotplug up to MAX vcpus while
159 the guest is running, but will startup with VCPUS.
160 CPU topology can additionally be specified with sockets, cores, and
162 threads. If values are omitted, the rest will be autofilled
163 preferring sockets over cores over threads.
164 'cpuset' sets which physical cpus the guest can use. "CPUSET" is a
166 comma separated list of numbers, which can also be specified in
167 ranges or cpus to exclude. Example:
168 0,2,3,5 : Use processors 0,2,3 and 5
170 1-5,^3,8 : Use processors 1,2,4,5 and 8
171 If the value 'auto' is passed, virt-install attempts to
173 automatically determine an optimal cpu pinning using NUMA data, if
174 available.
175 Use --vcpus=? to see a list of all available sub options. Complete
177 details at
178 <https://libvirt.org/formatdomain.html#elementsCPUAllocation>
179 --numatune OPTIONS
181 Tune NUMA policy for the domain process. Example invocations
182 --numatune 1,2,3,4-7
184 --numatune 1-3,5,mode=preferred
185 Specifies the numa nodes to allocate memory from. This has the same
187 syntax as "--vcpus cpuset=" option. mode can be one of
188 'interleave', 'preferred', or 'strict' (the default). See 'man 8
189 numactl' for information about each mode.
190 Use --numatune=? to see a list of all available sub options.
192 Complete details at
193 <https://libvirt.org/formatdomain.html#elementsNUMATuning>
194 --memtune OPTIONS
196 Tune memory policy for the domain process. Example invocations
197 --memtune 1000
199 --memtune hard_limit=100,soft_limit=60,swap_hard_limit=150,min_guarantee=80
200 Use --memtune=? to see a list of all available sub options.
202 Complete details at
203 <https://libvirt.org/formatdomain.html#elementsMemoryTuning>
204 --blkiotune OPTIONS
206 Tune blkio policy for the domain process. Example invocations
207 --blkiotune 100
209 --blkiotune weight=100,device_path=/dev/sdc,device_weight=200
210 Use --blkiotune=? to see a list of all available sub options.
212 Complete details at
213 <https://libvirt.org/formatdomain.html#elementsBlockTuning>
214 --cpu MODEL[,+feature][,-feature][,match=MATCH][,vendor=VENDOR],...
216 Configure the CPU model and CPU features exposed to the guest. The
217 only required value is MODEL, which is a valid CPU model as known
218 to libvirt.
219 Libvirt's feature policy values force, require, optional, disable,
221 or forbid, or with the shorthand '+feature' and '-feature', which
222 equal 'force=feature' and 'disable=feature' respectively.
223 If exact CPU model is specified virt-install will automatically
225 copy CPU features available on the host to mitigate recent CPU
226 speculative execution side channel and Microarchitectural Store
227 Buffer Data security vulnerabilities. This however will have some
228 impact on performance and will break migration to hosts without
229 security patches. In order to control this behavior there is a
230 secure parameter. Possible values are on and off, with on as the
231 default. It is highly recommended to leave this enabled and ensure
232 all virtualization hosts have fully up to date microcode, kernel &
233 virtualization software installed.
234 Some examples:
236 --cpu core2duo,+x2apic,disable=vmx
238 Expose the core2duo CPU model, force enable x2apic, but do not
239 expose vmx
240 --cpu host
242 Expose the host CPUs configuration to the guest. This enables
243 the guest to take advantage of many of the host CPUs features
244 (better performance), but may cause issues if migrating the
245 guest to a host without an identical CPU.
246 --cpu host-model-only
248 Expose the nearest host CPU model configuration to the guest.
249 It is the best CPU which can be used for a guest on any of the
250 hosts.
251 --cpu
253 cell0.memory=1234,cell0.cpus=0-3,cell1.memory=5678,cell1.cpus=4-7
254 Example of specifying two NUMA cells. This will generate XML
255 like:
256 <cpu>
258 <numa>
259 <cell cpus="0-3" memory="1234"/>
260 <cell cpus="4-7" memory="5678"/>
261 </numa>
262 </cpu>
263 --cpu host-passthrough,cache.mode=passthrough
265 Example of passing through the host cpu's cache information.
266 Use --cpu=? to see a list of all available sub options. Complete
268 details at <https://libvirt.org/formatdomain.html#elementsCPU>
269 --cputune OPTIONS
271 Tune CPU parameters for the guest.
272 Configure which of the host's physical CPUs the domain VCPU will be
274 pinned to. Example invocation
275 --cputune vpcupin0.vcpu=0,vpcupin0.cpuset=0-3,vpcupin1.vcpu=1,vpcupin1.cpuset=4-7
277 Use --cputune=? to see a list of all available sub options.
279 Complete details at
280 <https://libvirt.org/formatdomain.html#elementsCPUTuning>
281 --security type=TYPE[,label=LABEL][,relabel=yes|no]
283 Configure domain security driver settings. Type can be either
284 'static' or 'dynamic'. 'static' configuration requires a security
285 LABEL. Specifying LABEL without TYPE implies static configuration.
286 To have libvirt automatically apply your static label, you must
288 specify relabel=yes. Otherwise disk images must be manually labeled
289 by the admin, including images that virt-install is asked to
290 create.
291 Use --security=? to see a list of all available sub options.
293 Complete details at
294 <https://libvirt.org/formatdomain.html#seclabel>
295 --features FEAT=on|off,...
297 Set elements in the guests <features> XML on or off. Examples
298 include acpi, apic, eoi, privnet, and hyperv features. Some
299 examples:
300 --features eoi=on
302 Enable APIC PV EOI
303 --features hyperv_vapic=on,hyperv_spinlocks=off
305 Enable hypver VAPIC, but disable spinlocks
306 --features kvm_hidden=on
308 Allow the KVM hypervisor signature to be hidden from the guest
309 --features pvspinlock=on
311 Notify the guest that the host supports paravirtual spinlocks
312 for example by exposing the pvticketlocks mechanism.
313 --features gic_version=2
315 This is relevant only for ARM architectures. Possible values
316 are "host" or version number.
317 --features smm=on
319 This enables System Management Mode of hypervisor. Some UEFI
320 firmwares may require this feature to be present. (QEMU
321 supports SMM only with q35 machine type.)
322 Use --features=? to see a list of all available sub options.
324 Complete details at
325 <https://libvirt.org/formatdomain.html#elementsFeatures>
326 --clock offset=OFFSET,TIMER_OPT=VAL,...
328 Configure the guest's <clock> XML. Some supported options:
329 --clock offset=OFFSET
331 Set the clock offset, ex. 'utc' or 'localtime'
332 --clock TIMER_present=no
334 Disable a boolean timer. TIMER here might be hpet, kvmclock,
335 etc.
336 --clock TIMER_tickpolicy=VAL
338 Set a timer's tickpolicy value. TIMER here might be rtc, pit,
339 etc. VAL might be catchup, delay, etc. Refer to the libvirt
340 docs for all values.
341 Use --clock=? to see a list of all available sub options. Complete
343 details at <https://libvirt.org/formatdomain.html#elementsTime>
344 --pm OPTIONS
346 Configure guest power management features. Example suboptions
347 include suspend_to_mem=on|off and suspend_to_disk=on|off
348 Use --pm=? to see a list of all available sub options. Complete
350 details at
351 <https://libvirt.org/formatdomain.html#elementsPowerManagement>
352
354 -c OPTIONS
355 --cdrom OPTIONS
356 File or device used as a virtual CD-ROM device. It can be path to
357 an ISO image, or to a CDROM device. It can also be a URL from which
358 to fetch/access a minimal boot ISO image. The URLs take the same
359 format as described for the "--location" argument. If a cdrom has
360 been specified via the "--disk" option, and neither "--cdrom" nor
361 any other install option is specified, the "--disk" cdrom is used
362 as the install media.
363 -l LOCATION
365 --location OPTIONS
366 Distribution tree installation source. virt-install can recognize
367 certain distribution trees and fetches a bootable kernel/initrd
368 pair to launch the install.
369 With libvirt 0.9.4 or later, network URL installs work for remote
371 connections. virt-install will download kernel/initrd to the local
372 machine, and then upload the media to the remote host. This option
373 requires the URL to be accessible by both the local and remote
374 host.
375 --location allows things like --extra-args for kernel arguments,
377 and using --initrd-inject. If you want to use those options with
378 CDROM media, you have a few options:
379 * Run virt-install as root and do --location ISO
381 * Mount the ISO at a local directory, and do --location DIRECTORY
383 * Mount the ISO at a local directory, export that directory over
385 local http, and do --location https://localhost/DIRECTORY
386 The "LOCATION" can take one of the following forms:
388 https://host/path
390 An HTTP server location containing an installable distribution
391 image.
392 ftp://host/path
394 An FTP server location containing an installable distribution
395 image.
396 DIRECTORY
398 Path to a local directory containing an installable
399 distribution image. Note that the directory will not be
400 accessible by the guest after initial boot, so the OS installer
401 will need another way to access the rest of the install media.
402 ISO Mount the ISO and probe the directory. This requires running
404 virt-install as root, and has the same VM access caveat as
405 DIRECTORY.
406 Some distro specific url samples:
408 Fedora/Red Hat Based
410 https://download.fedoraproject.org/pub/fedora/linux/releases/25/Server/x86_64/os
411 Debian
413 https://ftp.us.debian.org/debian/dists/stable/main/installer-amd64/
414 Ubuntu
416 https://us.archive.ubuntu.com/ubuntu/dists/wily/main/installer-amd64/
417 Suse
419 https://download.opensuse.org/pub/opensuse/distribution/leap/42.3/repo/oss/
420 Mandriva
422 ftp://ftp.uwsg.indiana.edu/linux/mandrake/official/2009.0/i586/
423 Mageia
425 ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1
426 --pxe
428 Use the PXE boot protocol to load the initial ramdisk and kernel
429 for starting the guest installation process.
430 --import
432 Skip the OS installation process, and build a guest around an
433 existing disk image. The device used for booting is the first
434 device specified via "--disk" or "--filesystem".
435 --livecd
437 Specify that the installation media is a live CD and thus the guest
438 needs to be configured to boot off the CDROM device permanently. It
439 may be desirable to also use the "--disk none" flag in combination.
440 -x EXTRA
442 --extra-args OPTIONS
443 Additional kernel command line arguments to pass to the installer
444 when performing a guest install from "--location". One common usage
445 is specifying an anaconda kickstart file for automated installs,
446 such as --extra-args "ks=https://myserver/my.ks"
447 --initrd-inject PATH
449 Add PATH to the root of the initrd fetched with "--location". This
450 can be used to run an automated install without requiring a network
451 hosted kickstart file:
452 --initrd-inject=/path/to/my.ks --extra-args "ks=file:/my.ks"
454 --boot BOOTOPTS
456 Optionally specify the post-install VM boot configuration. This
457 option allows specifying a boot device order, permanently booting
458 off kernel/initrd with option kernel arguments, and enabling a BIOS
459 boot menu (requires libvirt 0.8.3 or later)
460 --boot can be specified in addition to other install options (such
462 as --location, --cdrom, etc.) or can be specified on its own. In
463 the latter case, behavior is similar to the --import install
464 option: there is no 'install' phase, the guest is just created and
465 launched as specified.
466 Some examples:
468 --boot cdrom,fd,hd,network,menu=on
470 Set the boot device priority as first cdrom, first floppy,
471 first harddisk, network PXE boot. Additionally enable BIOS boot
472 menu prompt.
473 --boot kernel=KERNEL,initrd=INITRD,kernel_args="console=/dev/ttyS0"
475 Have guest permanently boot off a local kernel/initrd pair,
476 with the specified kernel options.
477 --boot kernel=KERNEL,initrd=INITRD,dtb=DTB
479 Have guest permanently boot off a local kernel/initrd pair with
480 an external device tree binary. DTB can be required for some
481 non-x86 configurations like ARM or PPC
482 --boot loader=BIOSPATH
484 Use BIOSPATH as the virtual machine BIOS.
485 --boot menu=on,useserial=on
487 Enable the bios boot menu, and enable sending bios text output
488 over serial console.
489 --boot init=INITPATH
491 Path to a binary that the container guest will init. If a root
492 "--filesystem" has been specified, virt-install will default to
493 /sbin/init, otherwise will default to /bin/sh.
494 --boot uefi
496 Configure the VM to boot from UEFI. In order for virt-install
497 to know the correct UEFI parameters, libvirt needs to be
498 advertising known UEFI binaries via domcapabilities XML, so
499 this will likely only work if using properly configured distro
500 packages.
501 --boot
503 loader=/.../OVMF_CODE.fd,loader_ro=yes,loader_type=pflash,nvram_template=/.../OVMF_VARS.fd,loader_secure=no
504 Specify that the virtual machine use the custom OVMF binary as
505 boot firmware, mapped as a virtual flash chip. In addition,
506 request that libvirt instantiate the VM-specific UEFI varstore
507 from the custom "/.../OVMF_VARS.fd" varstore template. This is
508 the recommended UEFI setup, and should be used if --boot uefi
509 doesn't know about your UEFI binaries. If your UEFI firmware
510 supports Secure boot feature you can enable it via
511 loader_secure.
512 Use --boot=? to see a list of all available sub options. Complete
514 details at <https://libvirt.org/formatdomain.html#elementsOS>
515 --idmap OPTIONS
517 If the guest configuration declares a UID or GID mapping, the
518 'user' namespace will be enabled to apply these. A suitably
519 configured UID/GID mapping is a pre-requisite to make containers
520 secure, in the absence of sVirt confinement.
521 --idmap can be specified to enable user namespace for LXC
523 containers
524 Example:
526 --idmap
527 uid_start=0,uid_target=1000,uid_count=10,gid_start=0,gid_target=1000,gid_count=10
528 Use --idmap=? to see a list of all available sub options. Complete
530 details at
531 <https://libvirt.org/formatdomain.html#elementsOSContainer>
532
534 --os-variant OS_VARIANT
535 Optimize the guest configuration for a specific operating system
536 (ex. 'fedora29', 'rhel7', 'win10'). While not required, specifying
537 this options is HIGHLY RECOMMENDED, as it can greatly increase
538 performance by specifying virtio among other guest tweaks.
539 By default, virt-install will attempt to auto detect this value
541 from the install media (currently only supported for URL installs).
542 Autodetection can be disabled with the special value 'none'.
543 Autodetection can be forced with the special value 'auto'.
544 Use the command "osinfo-query os" to get the list of the accepted
546 OS variants.
547
549 --disk OPTIONS
550 Specifies media to use as storage for the guest, with various
551 options. The general format of a disk string is
552 --disk opt1=val1,opt2=val2,...
554 The simplest invocation to create a new 10G disk image and
556 associated disk device:
557 --disk size=10
559 virt-install will generate a path name, and place it in the default
561 image location for the hypervisor. To specify media, the command
562 can either be:
563 --disk /some/storage/path[,opt1=val1]...
565 or explicitly specify one of the following arguments:
567 path
569 A path to some storage media to use, existing or not. Existing
570 media can be a file or block device.
571 Specifying a non-existent path implies attempting to create the
573 new storage, and will require specifying a 'size' value. Even
574 for remote hosts, virt-install will try to use libvirt storage
575 APIs to automatically create the given path.
576 If the hypervisor supports it, path can also be a network URL,
578 like https://example.com/some-disk.img . For network paths,
579 they hypervisor will directly access the storage, nothing is
580 downloaded locally.
581 pool
583 An existing libvirt storage pool name to create new storage on.
584 Requires specifying a 'size' value.
585 vol An existing libvirt storage volume to use. This is specified as
587 'poolname/volname'.
588 Other available options:
590 device
592 Disk device type. Value can be 'cdrom', 'disk', 'lun' or
593 'floppy'. Default is 'disk'. If a 'cdrom' is specified, and no
594 install method is chosen, the cdrom is used as the install
595 media.
596 boot_order
598 Guest installation with multiple disks will need this parameter
599 to boot correctly after being installed. A boot_order parameter
600 will take values 1,2,3,... Devices with lower value has higher
601 priority.
602 bus Disk bus type. Value can be 'ide', 'sata', 'scsi', 'usb',
604 'virtio' or 'xen'. The default is hypervisor dependent since
605 not all hypervisors support all bus types.
606 removable
608 Sets the removable flag (/sys/block/$dev/removable on Linux).
609 Only used with QEMU and bus=usb. Value can be 'on' or 'off'.
610 readonly
612 Set drive as readonly (takes 'on' or 'off')
613 shareable
615 Set drive as shareable (takes 'on' or 'off')
616 size
618 size (in GiB) to use if creating new storage
619 sparse
621 whether to skip fully allocating newly created storage. Value
622 is 'yes' or 'no'. Default is 'yes' (do not fully allocate)
623 unless it isn't supported by the underlying storage type.
624 The initial time taken to fully-allocate the guest virtual disk
626 (sparse=no) will be usually balanced by faster install times
627 inside the guest. Thus use of this option is recommended to
628 ensure consistently high performance and to avoid I/O errors in
629 the guest should the host filesystem fill up.
630 backing_store
632 Path to a disk to use as the backing store for the newly
633 created image.
634 backing_format
636 Disk image format of backing_store
637 cache
639 The cache mode to be used. The host pagecache provides cache
640 memory. The cache value can be 'none', 'writethrough',
641 'directsync', 'unsafe' or 'writeback'. 'writethrough' provides
642 read caching. 'writeback' provides read and write caching.
643 'directsync' bypasses the host page cache. 'unsafe' may cache
644 all content and ignore flush requests from the guest.
645 discard
647 Whether discard (also known as "trim" or "unmap") requests are
648 ignored or passed to the filesystem. The value can be either
649 "unmap" (allow the discard request to be passed) or "ignore"
650 (ignore the discard request). Since 1.0.6 (QEMU and KVM only)
651 format
653 Disk image format. For file volumes, this can be 'raw',
654 'qcow2', 'vmdk', etc. See format types in
655 <https://libvirt.org/storage.html> for possible values. This is
656 often mapped to the driver_type value as well.
657 If not specified when creating file images, this will default
659 to 'qcow2'.
660 If creating storage, this will be the format of the new image.
662 If using an existing image, this overrides libvirt's format
663 auto-detection.
664 driver_name
666 Driver name the hypervisor should use when accessing the
667 specified storage. Typically does not need to be set by the
668 user.
669 driver_type
671 Driver format/type the hypervisor should use when accessing the
672 specified storage. Typically does not need to be set by the
673 user.
674 io Disk IO backend. Can be either "threads" or "native".
676 error_policy
678 How guest should react if a write error is encountered. Can be
679 one of "stop", "ignore", or "enospace"
680 serial
682 Serial number of the emulated disk device. This is used in
683 linux guests to set /dev/disk/by-id symlinks. An example serial
684 number might be: WD-WMAP9A966149
685 startup_policy
687 It defines what to do with the disk if the source file is not
688 accessible. See possible values in
689 <https://www.libvirt.org/formatdomain.html#elementsDisks>,
690 "startupPolicy" attribute of the <disk> element
691 snapshot_policy
693 Defines default behavior of the disk during disk snapshots.
694 See possible values in
695 <https://www.libvirt.org/formatdomain.html#elementsDisks>,
696 "snapshot" attribute of the <disk> element.
697 See the examples section for some uses. This option deprecates
699 -f/--file, -s/--file-size, --nonsparse, and --nodisks.
700 Use --disk=? to see a list of all available sub options. Complete
702 details at <https://libvirt.org/formatdomain.html#elementsDisks>
703 --filesystem
705 Specifies a directory on the host to export to the guest. The most
706 simple invocation is:
707 --filesystem /source/on/host,/target/point/in/guest
709 Which will work for recent QEMU and linux guest OS or LXC
711 containers. For QEMU, the target point is just a mounting hint in
712 sysfs, so will not be automatically mounted.
713 The following explicit options can be specified:
715 type
717 The type or the source directory. Valid values are 'mount' (the
718 default) or 'template' for OpenVZ templates.
719 mode
721 The access mode for the source directory from the guest OS.
722 Only used with QEMU and type=mount. Valid modes are
723 'passthrough' (the default), 'mapped', or 'squash'. See libvirt
724 domain XML documentation for more info.
725 source
727 The directory on the host to share.
728 target
730 The mount location to use in the guest.
731 Use --filesystem=? to see a list of all available sub options.
733 Complete details at
734 <https://libvirt.org/formatdomain.html#elementsFilesystems>
735
737 -w OPTIONS
738 --network OPTIONS
739 Connect the guest to the host network. The value for "NETWORK" can
740 take one of 4 formats:
741 bridge=BRIDGE
743 Connect to a bridge device in the host called "BRIDGE". Use
744 this option if the host has static networking config & the
745 guest requires full outbound and inbound connectivity to/from
746 the LAN. Also use this if live migration will be used with this
747 guest.
748 network=NAME
750 Connect to a virtual network in the host called "NAME". Virtual
751 networks can be listed, created, deleted using the "virsh"
752 command line tool. In an unmodified install of "libvirt" there
753 is usually a virtual network with a name of "default". Use a
754 virtual network if the host has dynamic networking (eg
755 NetworkManager), or using wireless. The guest will be NATed to
756 the LAN by whichever connection is active.
757 type=direct,source=IFACE[,source_mode=MODE]
759 Direct connect to host interface IFACE using macvtap.
760 user
762 Connect to the LAN using SLIRP. Only use this if running a QEMU
763 guest as an unprivileged user. This provides a very limited
764 form of NAT.
765 none
767 Tell virt-install not to add any default network interface.
768 If this option is omitted a single NIC will be created in the
770 guest. If there is a bridge device in the host with a physical
771 interface enslaved, that will be used for connectivity. Failing
772 that, the virtual network called "default" will be used. This
773 option can be specified multiple times to setup more than one NIC.
774 Other available options are:
776 model
778 Network device model as seen by the guest. Value can be any nic
779 model supported by the hypervisor, e.g.: 'e1000', 'rtl8139',
780 'virtio', ...
781 mac Fixed MAC address for the guest; If this parameter is omitted,
783 or the value "RANDOM" is specified a suitable address will be
784 randomly generated. For Xen virtual machines it is required
785 that the first 3 pairs in the MAC address be the sequence
786 '00:16:3e', while for QEMU or KVM virtual machines it must be
787 '52:54:00'.
788 filterref
790 Controlling firewall and network filtering in libvirt. Value
791 can be any nwfilter defined by the "virsh" 'nwfilter'
792 subcommands. Available filters can be listed by running 'virsh
793 nwfilter-list', e.g.: 'clean-traffic', 'no-mac-spoofing', ...
794 virtualport_type
796 The type of virtual port profile, one the following values
797 "802.Qbg"
799 The following additional parameters are accepted
800 virtualport_managerid
802 The VSI Manager ID identifies the database containing
803 the VSI type and instance definitions. This is an
804 integer value and the value 0 is reserved.
805 virtualport_typeid
807 The VSI Type ID identifies a VSI type characterizing
808 the network access. VSI types are typically managed by
809 network administrator. This is an integer value.
810 virtualport_typeidversion
812 The VSI Type Version allows multiple versions of a VSI
813 Type. This is an integer value.
814 virtualport_instanceid
816 The VSI Instance ID Identifier is generated when a VSI
817 instance (i.e. a virtual interface of a virtual
818 machine) is created. This is a globally unique
819 identifier.
820 "802.Qbh"
822 The following additional parameters are accepted
823 virtualport_profileid
825 The profile ID contains the name of the port profile
826 that is to be applied to this interface. This name is
827 resolved by the port profile database into the network
828 parameters from the port profile, and those network
829 parameters will be applied to this interface.
830 "openvswitch"
832 The following additional parameters are accepted
833 virtualport_profileid
835 The OpenVSwitch port profile for the interface
836 virtualport_interfaceid
838 A UUID to uniquely identify the interface. If omitted
839 one will be generated automatically
840 "midonet"
842 The following additional parameters are accepted
843 virtualport_interfaceid
845 A UUID identifying the port in the network to which the
846 interface will be bound
847 Use --network=? to see a list of all available sub options.
849 Complete details at
850 <https://libvirt.org/formatdomain.html#elementsNICS>
851 This option deprecates -m/--mac, -b/--bridge, and --nonetworks
853
855 If no graphics option is specified, "virt-install" will try to select
856 the appropriate graphics if the DISPLAY environment variable is set,
857 otherwise '--graphics none' is used.
858 --graphics TYPE,opt1=arg1,opt2=arg2,...
860 Specifies the graphical display configuration. This does not
861 configure any virtual hardware, just how the guest's graphical
862 display can be accessed. Typically the user does not need to
863 specify this option, virt-install will try and choose a useful
864 default, and launch a suitable connection.
865 General format of a graphical string is
867 --graphics TYPE,opt1=arg1,opt2=arg2,...
869 For example:
871 --graphics vnc,password=foobar
873 The supported options are:
875 type
877 The display type. This is one of:
878 vnc
880 Setup a virtual console in the guest and export it as a VNC
882 server in the host. Unless the "port" parameter is also
883 provided, the VNC server will run on the first free port number
884 at 5900 or above. The actual VNC display allocated can be
885 obtained using the "vncdisplay" command to "virsh" (or
886 virt-viewer(1) can be used which handles this detail for the
887 use).
888 spice
890 Export the guest's console using the Spice protocol. Spice
892 allows advanced features like audio and USB device streaming,
893 as well as improved graphical performance.
894 Using spice graphic type will work as if those arguments were
896 given:
897 --video qxl --channel spicevmc
899 none
901 No graphical console will be allocated for the guest. Guests
903 will likely need to have a text console configured on the first
904 serial port in the guest (this can be done via the --extra-args
905 option). The command 'virsh console NAME' can be used to
906 connect to the serial device.
907 port
909 Request a permanent, statically assigned port number for the
910 guest console. This is used by 'vnc' and 'spice'
911 tlsport
913 Specify the spice tlsport.
914 listen
916 Address to listen on for VNC/Spice connections. Default is
917 typically 127.0.0.1 (localhost only), but some hypervisors
918 allow changing this globally (for example, the qemu driver
919 default can be changed in /etc/libvirt/qemu.conf). Use 0.0.0.0
920 to allow access from other machines.
921 Use 'none' to specify that the display server should not listen
923 on any port. The display server can be accessed only locally
924 through libvirt unix socket (virt-viewer with --attach for
925 instance).
926 Use 'socket' to have the VM listen on a libvirt generated unix
928 socket path on the host filesystem.
929 This is used by 'vnc' and 'spice'
931 keymap
933 Request that the virtual console be configured to run with a
934 specific keyboard layout. If the special value 'local' is
935 specified, virt-install will attempt to configure to use the
936 same keymap as the local system. A value of 'none' specifically
937 defers to the hypervisor. Default behavior is hypervisor
938 specific, but typically is the same as 'local'. This is used by
939 'vnc' and 'spice'.
940 password
942 Request a console password, required at connection time.
943 Beware, this info may end up in virt-install log files, so
944 don't use an important password. This is used by 'vnc' and
945 'spice'
946 gl Whether to use OpenGl accelerated rendering. Value is 'yes' or
948 'no'. This is used by 'spice'.
949 rendernode
951 DRM render node path to use. This is used when 'gl' is enabled.
952 Use --graphics=? to see a list of all available sub options.
954 Complete details at
955 <https://libvirt.org/formatdomain.html#elementsGraphics>
956 This deprecates the following options: --vnc, --vncport,
958 --vnclisten, -k/--keymap, --sdl, --nographics
959 --noautoconsole
961 Don't automatically try to connect to the guest console. The
962 default behaviour is to launch virt-viewer(1) to display the
963 graphical console, or to run the "virsh" "console" command to
964 display the text console. Use of this parameter will disable this
965 behaviour.
966
968 Options to override the default virtualization type choices.
969 -v
971 --hvm
972 Request the use of full virtualization, if both para & full
973 virtualization are available on the host. This parameter may not be
974 available if connecting to a Xen hypervisor on a machine without
975 hardware virtualization support. This parameter is implied if
976 connecting to a QEMU based hypervisor.
977 -p
979 --paravirt
980 This guest should be a paravirtualized guest. If the host supports
981 both para & full virtualization, and neither this parameter nor the
982 "--hvm" are specified, this will be assumed.
983 --container
985 This guest should be a container type guest. This option is only
986 required if the hypervisor supports other guest types as well (so
987 for example this option is the default behavior for LXC and OpenVZ,
988 but is provided for completeness).
989 --virt-type
991 The hypervisor to install on. Example choices are kvm, qemu, or
992 xen. Available options are listed via 'virsh capabilities' in the
993 <domain> tags.
994 This deprecates the --accelerate option, which is now the default
996 behavior. To install a plain QEMU guest, use '--virt-type qemu'
997
999 All devices have a set of address.* options for configuring the
1000 particulars of the device's address on its parent controller or bus.
1001 See "https://libvirt.org/formatdomain.html#elementsAddress" for
1002 details.
1003 --controller OPTIONS
1005 Attach a controller device to the guest. TYPE is one of: ide, fdc,
1006 scsi, sata, virtio-serial, or usb.
1007 Controller also supports the special values usb2 and usb3 to
1009 specify which version of the USB controller should be used (version
1010 2 or 3).
1011 model
1013 Controller model. These may vary according to the hypervisor
1014 and its version. Most commonly used models are e.g. auto,
1015 virtio-scsi for the scsi controller, ehci or none for the usb
1016 controller. For full list and further details on
1017 controllers/models, see
1018 "https://libvirt.org/formatdomain.html#elementsControllers".
1019 address
1021 Shorthand for setting a manual PCI address from an lscpi style
1022 string. The preferred method for setting this is using the
1023 address.* parameters.
1024 index
1026 A decimal integer describing in which order the bus controller
1027 is encountered, and to reference the controller bus.
1028 master
1030 Applicable to USB companion controllers, to define the master
1031 bus startport.
1032 Examples:
1034 --controller usb,model=ich9-ehci1,address=0:0:4.0,index=0
1036 Adds a ICH9 EHCI1 USB controller on PCI address 0:0:4.0
1037 --controller usb,model=ich9-uhci2,address=0:0:4.7,index=0,master=2
1039 Adds a ICH9 UHCI2 USB companion controller for the previous
1040 master controller, ports start from port number 2.
1041 The parameter multifunction='on' will be added automatically to
1043 the proper device (if needed). This applies to all PCI
1044 devices.
1045 Use --controller=? to see a list of all available sub options.
1047 Complete details at
1048 <https://libvirt.org/formatdomain.html#elementsControllers>
1049 --input OPTIONS
1051 Attach an input device to the guest. Example input device types are
1052 mouse, tablet, or keyboard.
1053 Use --input=? to see a list of all available sub options. Complete
1055 details at <https://libvirt.org/formatdomain.html#elementsInput>
1056 --hostdev OPTIONS
1058 --host-device OPTIONS
1059 Attach a physical host device to the guest. Some example values for
1060 HOSTDEV:
1061 --hostdev pci_0000_00_1b_0
1063 A node device name via libvirt, as shown by 'virsh
1064 nodedev-list'
1065 --hostdev 001.003
1067 USB by bus, device (via lsusb).
1068 --hostdev 0x1234:0x5678
1070 USB by vendor, product (via lsusb).
1071 --hostdev 1f.01.02
1073 PCI device (via lspci).
1074 --hostdev wlan0,type=net
1076 Network device (in LXC container).
1077 --hostdev /dev/net/tun,type=misc
1079 Character device (in LXC container).
1080 --hostdev /dev/sdf,type=storage
1082 Block device (in LXC container).
1083 Use --hostdev=? to see a list of all available sub options.
1085 Complete details at
1086 <https://libvirt.org/formatdomain.html#elementsHostDev>
1087 --sound MODEL
1089 Attach a virtual audio device to the guest. MODEL specifies the
1090 emulated sound card model. Possible values are ich6, ich9, ac97,
1091 es1370, sb16, pcspk, or default. 'default' will try to pick the
1092 best model that the specified OS supports.
1093 This deprecates the old --soundhw option.
1095 Use --sound=? to see a list of all available sub options. Complete
1097 details at <https://libvirt.org/formatdomain.html#elementsSound>
1098 --watchdog MODEL[,action=ACTION]
1100 Attach a virtual hardware watchdog device to the guest. This
1101 requires a daemon and device driver in the guest. The watchdog
1102 fires a signal when the virtual machine appears to hung. ACTION
1103 specifies what libvirt will do when the watchdog fires. Values are
1104 reset
1106 Forcefully reset the guest (the default)
1107 poweroff
1109 Forcefully power off the guest
1110 pause
1112 Pause the guest
1113 none
1115 Do nothing
1116 shutdown
1118 Gracefully shutdown the guest (not recommended, since a hung
1119 guest probably won't respond to a graceful shutdown)
1120 MODEL is the emulated device model: either i6300esb (the default)
1122 or ib700. Some examples:
1123 Use the recommended settings:
1125 --watchdog default
1127 Use the i6300esb with the 'poweroff' action
1129 --watchdog i6300esb,action=poweroff
1131 Use --watchdog=? to see a list of all available sub options.
1133 Complete details at
1134 <https://libvirt.org/formatdomain.html#elementsWatchdog>
1135 --parallel OPTIONS
1137 --serial OPTIONS
1138 Specifies a serial device to attach to the guest, with various
1139 options. The general format of a serial string is
1140 --serial type,opt1=val1,opt2=val2,...
1142 --serial and --parallel devices share all the same options, unless
1144 otherwise noted. Some of the types of character device redirection
1145 are:
1146 --serial pty
1148 Pseudo TTY. The allocated pty will be listed in the running
1149 guests XML description.
1150 --serial dev,path=HOSTPATH
1152 Host device. For serial devices, this could be /dev/ttyS0. For
1153 parallel devices, this could be /dev/parport0.
1154 --serial file,path=FILENAME
1156 Write output to FILENAME.
1157 --serial pipe,path=PIPEPATH
1159 Named pipe (see pipe(7))
1160 --serial tcp,host=HOST:PORT,mode=MODE,protocol=PROTOCOL
1162 TCP net console. MODE is either 'bind' (wait for connections on
1163 HOST:PORT) or 'connect' (send output to HOST:PORT), default is
1164 'bind'. HOST defaults to '127.0.0.1', but PORT is required.
1165 PROTOCOL can be either 'raw' or 'telnet' (default 'raw'). If
1166 'telnet', the port acts like a telnet server or client. Some
1167 examples:
1168 Wait for connections on any address, port 4567:
1170 --serial tcp,host=0.0.0.0:4567
1172 Connect to localhost, port 1234:
1174 --serial tcp,host=:1234,mode=connect
1176 Wait for telnet connection on localhost, port 2222. The user
1178 could then connect interactively to this console via 'telnet
1179 localhost 2222':
1180 --serial tcp,host=:2222,mode=bind,protocol=telnet
1182 --serial udp,host=CONNECT_HOST:PORT,bind_host=BIND_HOST:BIND_PORT
1184 UDP net console. HOST:PORT is the destination to send output to
1185 (default HOST is '127.0.0.1', PORT is required).
1186 BIND_HOST:BIND_PORT is the optional local address to bind to
1187 (default BIND_HOST is 127.0.0.1, but is only set if BIND_PORT
1188 is specified). Some examples:
1189 Send output to default syslog port (may need to edit
1191 /etc/rsyslog.conf accordingly):
1192 --serial udp,host=:514
1194 Send output to remote host 192.168.10.20, port 4444 (this
1196 output can be read on the remote host using 'nc -u -l 4444'):
1197 --serial udp,host=192.168.10.20:4444
1199 --serial unix,path=UNIXPATH,mode=MODE
1201 Unix socket, see unix(7). MODE has similar behavior and
1202 defaults as --serial tcp,mode=MODE
1203 Use --serial=? or --parallel=? to see a list of all available sub
1205 options. Complete details at
1206 <https://libvirt.org/formatdomain.html#elementsCharSerial> and
1207 <https://libvirt.org/formatdomain.html#elementsCharParallel>
1208 --channel
1210 Specifies a communication channel device to connect the guest and
1211 host machine. This option uses the same options as --serial and
1212 --parallel for specifying the host/source end of the channel. Extra
1213 'target' options are used to specify how the guest machine sees the
1214 channel.
1215 Some of the types of character device redirection are:
1217 --channel SOURCE,target_type=guestfwd,target_address=HOST:PORT
1219 Communication channel using QEMU usermode networking stack. The
1220 guest can connect to the channel using the specified HOST:PORT
1221 combination.
1222 --channel SOURCE,target_type=virtio[,name=NAME]
1224 Communication channel using virtio serial (requires 2.6.34 or
1225 later host and guest). Each instance of a virtio --channel line
1226 is exposed in the guest as /dev/vport0p1, /dev/vport0p2, etc.
1227 NAME is optional metadata, and can be any string, such as
1228 org.linux-kvm.virtioport1. If specified, this will be exposed
1229 in the guest at /sys/class/virtio-ports/vport0p1/NAME
1230 --channel spicevmc,target_type=virtio[,name=NAME]
1232 Communication channel for QEMU spice agent, using virtio serial
1233 (requires 2.6.34 or later host and guest). NAME is optional
1234 metadata, and can be any string, such as the default
1235 com.redhat.spice.0 that specifies how the guest will see the
1236 channel.
1237 Use --channel=? to see a list of all available sub options.
1239 Complete details at
1240 <https://libvirt.org/formatdomain.html#elementsCharChannel>
1241 --console
1243 Connect a text console between the guest and host. Certain guest
1244 and hypervisor combinations can automatically set up a getty in the
1245 guest, so an out of the box text login can be provided
1246 (target_type=xen for xen paravirt guests, and possibly
1247 target_type=virtio in the future).
1248 Example:
1250 --console pty,target_type=virtio
1252 Connect a virtio console to the guest, redirected to a PTY on
1253 the host. For supported guests, this exposes /dev/hvc0 in the
1254 guest. See https://fedoraproject.org/wiki/Features/VirtioSerial
1255 for more info. virtio console requires libvirt 0.8.3 or later.
1256 Use --console=? to see a list of all available sub options.
1258 Complete details at
1259 <https://libvirt.org/formatdomain.html#elementsCharConsole>
1260 --video OPTIONS
1262 Specify what video device model will be attached to the guest.
1263 Valid values for VIDEO are hypervisor specific, but some options
1264 for recent kvm are cirrus, vga, qxl, virtio, or vmvga (vmware).
1265 Use --video=? to see a list of all available sub options. Complete
1267 details at <https://libvirt.org/formatdomain.html#elementsVideo>
1268 --smartcard MODE[,OPTIONS]
1270 Configure a virtual smartcard device.
1271 Mode is one of host, host-certificates, or passthrough. Additional
1273 options are:
1274 type
1276 Character device type to connect to on the host. This is only
1277 applicable for passthrough mode.
1278 An example invocation:
1280 --smartcard passthrough,type=spicevmc
1282 Use the smartcard channel of a SPICE graphics device to pass
1283 smartcard info to the guest
1284 Use --smartcard=? to see a list of all available sub options.
1286 Complete details at
1287 <https://libvirt.org/formatdomain.html#elementsSmartcard>
1288 --redirdev BUS[,OPTIONS]
1290 Add a redirected device.
1291 type
1293 The redirection type, currently supported is tcp or spicevmc.
1294 server
1296 The TCP server connection details, of the form 'server:port'.
1297 Examples of invocation:
1299 --redirdev usb,type=tcp,server=localhost:4000
1301 Add a USB redirected device provided by the TCP server on
1302 'localhost' port 4000.
1303 --redirdev usb,type=spicevmc
1305 Add a USB device redirected via a dedicated Spice channel.
1306 Use --redirdev=? to see a list of all available sub options.
1308 Complete details at
1309 <https://libvirt.org/formatdomain.html#elementsRedir>
1310 --memballoon MODEL
1312 Attach a virtual memory balloon device to the guest. If the
1313 memballoon device needs to be explicitly disabled, MODEL='none' is
1314 used.
1315 MODEL is the type of memballoon device provided. The value can be
1317 'virtio', 'xen' or 'none'. Some examples:
1318 Use the recommended settings:
1320 --memballoon virtio
1322 Do not use memballoon device:
1324 --memballoon none
1326 Use --memballoon=? to see a list of all available sub options.
1328 Complete details at
1329 <https://libvirt.org/formatdomain.html#elementsMemBalloon>
1330 --tpm TYPE[,OPTIONS]
1332 Configure a virtual TPM device.
1333 Type must be passthrough. Additional options are:
1335 model
1337 The device model to present to the guest operating system.
1338 Model must be tpm-tis.
1339 An example invocation:
1341 --tpm passthrough,model=tpm-tis
1343 Make the host's TPM accessible to a single guest.
1344 --tpm /dev/tpm
1346 Convenience option for passing through the hosts TPM.
1347 Use --tpm=? to see a list of all available sub options. Complete
1349 details at <https://libvirt.org/formatdomain.html#elementsTpm>
1350 --rng TYPE[,OPTIONS]
1352 Configure a virtual RNG device.
1353 Type can be random or egd.
1355 If the specified type is random then these values must be
1357 specified:
1358 backend_device
1360 The device to use as a source of entropy.
1361 Whereas, when the type is egd, these values must be provided:
1363 backend_host
1365 Specify the host of the Entropy Gathering Daemon to connect to.
1366 backend_service
1368 Specify the port of the Entropy Gathering Daemon to connect to.
1369 backend_type
1371 Specify the type of the connection: tcp or udp.
1372 backend_mode
1374 Specify the mode of the connection. It is either 'bind' (wait
1375 for connections on HOST:PORT) or 'connect' (send output to
1376 HOST:PORT).
1377 backend_connect_host
1379 Specify the remote host to connect to when the specified
1380 backend_type is udp and backend_mode is bind.
1381 backend_connect_service
1383 Specify the remote service to connect to when the specified
1384 backend_type is udp and backend_mode is bind.
1385 An example invocation:
1387 --rng
1389 egd,backend_host=localhost,backend_service=8000,backend_type=tcp
1390 Connect to localhost to the TCP port 8000 to get entropy data.
1391 --rng /dev/random
1393 Use the /dev/random device to get entropy data, this form
1394 implicitly uses the "random" model.
1395 Use --rng=? to see a list of all available sub options.
1397 Complete details at
1398 <https://libvirt.org/formatdomain.html#elementsRng>
1399 --panic MODEL[,OPTS]
1401 Attach a panic notifier device to the guest. For the recommended
1402 settings, use:
1403 --panic default
1405 Use --panic=? to see a list of all available sub options. Complete
1407 details at <https://libvirt.org/formatdomain.html#elementsPanic>
1408 --memdev OPTS
1410 Add a memory module to a guest which can be hotunplugged. To add a
1411 memdev you need to configure hotplugmemory and NUMA for a guest.
1412 Use --memdev=? to see a list of all available sub options. Complete
1414 details at <https://libvirt.org/formatdomain.html#elementsMemory>.
1415
1417 -h
1418 --help
1419 Show the help message and exit
1420 --version
1422 Show program's version number and exit
1423 --autostart
1425 Set the autostart flag for a domain. This causes the domain to be
1426 started on host boot up.
1427 --transient
1429 Use --import or --boot and --transient if you want a transient
1430 libvirt VM. These VMs exist only until the domain is shut down or
1431 the host server is restarted. Libvirt forgets the XML
1432 configuration of the VM after either of these events. Note that
1433 the VM's disks will not be deleted. See:
1434 <https://wiki.libvirt.org/page/VM_lifecycle#Transient_guest_domains_vs_Persistent_guest_domains>
1435 --destroy-on-exit
1437 When the VM console window is exited, destroy (force poweroff) the
1438 VM. If you combine this with --transient, this makes the virt-
1439 install command work similar to qemu, where the VM is shutdown when
1440 the console window is closed by the user.
1441 --print-xml [STEP]
1443 Print the generated XML of the guest, instead of defining it. By
1444 default this WILL do storage creation (can be disabled with
1445 --dry-run). This option implies --quiet.
1446 If the VM install has multiple phases, by default this will print
1448 all generated XML. If you want to print a particular step, use
1449 --print-xml 2 (for the second phase XML).
1450 --noreboot
1452 Prevent the domain from automatically rebooting after the install
1453 has completed.
1454 --wait WAIT
1456 Amount of time to wait (in minutes) for a VM to complete its
1457 install. Without this option, virt-install will wait for the
1458 console to close (not necessarily indicating the guest has
1459 shutdown), or in the case of --noautoconsole, simply kick off the
1460 install and exit. Any negative value will make virt-install wait
1461 indefinitely, a value of 0 triggers the same results as
1462 noautoconsole. If the time limit is exceeded, virt-install simply
1463 exits, leaving the virtual machine in its current state.
1464 --dry-run
1466 Proceed through the guest creation process, but do NOT create
1467 storage devices, change host device configuration, or actually
1468 teach libvirt about the guest. virt-install may still fetch
1469 install media, since this is required to properly detect the OS to
1470 install.
1471 --check
1473 Enable or disable some validation checks. Some examples are warning
1474 about using a disk that's already assigned to another VM (--check
1475 path_in_use=on|off), or warning about potentially running out of
1476 space during disk allocation (--check disk_size=on|off). Most
1477 checks are performed by default.
1478 -q
1480 --quiet
1481 Only print fatal error messages.
1482 -d
1484 --debug
1485 Print debugging information to the terminal when running the
1486 install process. The debugging information is also stored in
1487 "~/.cache/virt-manager/virt-install.log" even if this parameter is
1488 omitted.
1489
1491 Install a Fedora 20 KVM guest with virtio accelerated disk/network,
1492 creating a new 10GiB qcow2 file, installing from media in the hosts
1493 CDROM drive. This will use Spice graphics by default, and launch
1494 autolaunch a graphical client.
1495 # virt-install \
1497 --connect qemu:///system \
1498 --virt-type kvm \
1499 --name demo \
1500 --memory 500 \
1501 --disk size=10 \
1502 --cdrom /dev/cdrom \
1503 --os-variant fedora13
1504 Install a Fedora 9 plain QEMU guest, using LVM partition, virtual
1506 networking, booting from PXE, using VNC server/viewer, with virtio-scsi
1507 disk
1508 # virt-install \
1510 --connect qemu:///system \
1511 --name demo \
1512 --memory 500 \
1513 --disk path=/dev/HostVG/DemoVM,bus=scsi \
1514 --controller virtio-scsi \
1515 --network network=default \
1516 --virt-type qemu \
1517 --graphics vnc \
1518 --os-variant fedora9
1519 Run a Live CD image under Xen fullyvirt, in diskless environment
1521 # virt-install \
1523 --hvm \
1524 --name demo \
1525 --memory 500 \
1526 --disk none \
1527 --livecd \
1528 --graphics vnc \
1529 --cdrom /root/fedora7live.iso
1530 Run /usr/bin/httpd in a linux container guest (LXC). Resource usage is
1532 capped at 512 MiB of ram and 2 host cpus:
1533 # virt-install \
1535 --connect lxc:/// \
1536 --name httpd_guest \
1537 --memory 512 \
1538 --vcpus 2 \
1539 --init /usr/bin/httpd
1540 Start a linux container guest(LXC) with a private root filesystem,
1542 using /bin/sh as init. Container's root will be under host dir
1543 /home/LXC. The host dir "/home/test" will be mounted at "/mnt" dir
1544 inside container:
1545 # virt-install \
1547 --connect lxc:/// \
1548 --name container \
1549 --memory 128 \
1550 --filesystem /home/LXC,/ \
1551 --filesystem /home/test,/mnt \
1552 --init /bin/sh
1553 Install a paravirtualized Xen guest, 500 MiB of RAM, a 5 GiB of disk,
1555 and Fedora Core 6 from a web server, in text-only mode, with old style
1556 --file options:
1557 # virt-install \
1559 --paravirt \
1560 --name demo \
1561 --memory 500 \
1562 --disk /var/lib/xen/images/demo.img,size=6 \
1563 --graphics none \
1564 --location https://download.fedora.redhat.com/pub/fedora/linux/core/6/x86_64/os/
1565 Create a guest from an existing disk image 'mydisk.img' using defaults
1567 for the rest of the options.
1568 # virt-install \
1570 --name demo \
1571 --memory 512 \
1572 --disk /home/user/VMs/mydisk.img \
1573 --import
1574 Start serial QEMU ARM VM, which requires specifying a manual kernel.
1576 # virt-install \
1578 --name armtest \
1579 --memory 1024 \
1580 --arch armv7l --machine vexpress-a9 \
1581 --disk /home/user/VMs/myarmdisk.img \
1582 --boot kernel=/tmp/my-arm-kernel,initrd=/tmp/my-arm-initrd,dtb=/tmp/my-arm-dtb,kernel_args="console=ttyAMA0 rw root=/dev/mmcblk0p3" \
1583 --graphics none
1584
1586 Please see https://virt-manager.org/page/BugReporting
1587
1589 Copyright (C) Red Hat, Inc, and various contributors. This is free
1590 software. You may redistribute copies of it under the terms of the GNU
1591 General Public License "https://www.gnu.org/licenses/gpl.html". There
1592 is NO WARRANTY, to the extent permitted by law.
1593
1595 virsh(1), "virt-clone(1)", "virt-manager(1)", the project website
1596 "https://virt-manager.org"
15972.0.0 2019-07-01 VIRT-INSTALL(1)