Xen virt-install cdrom

If omitted, the host CPU architecture will be used in the guest. The machine type to emulate. This will typically not need to be specified for Xen or KVM, but is useful for choosing machine types of more exotic architectures.

Specify metadata values for the guest. Possible options include name, uuid, title, and description. Specify events values for the guest. The default behavior if no explicit suboption is set. See below for how value is interpreted. Pass options directly to the qemu emulator. Only works for the libvirt qemu driver. The option can take a string of arguments, for example:. Number of virtual cpus to configure for the guest.

CPU topology can additionally be specified with sockets, cores, and threads. If values are omitted, the rest will be autofilled preferring sockets over cores over threads. CPUSET is a comma separated list of numbers, which can also be specified in ranges or cpus to exclude.

If the value 'auto' is passed, virt-install attempts to automatically determine an optimal cpu pinning using NUMA data, if available.

Specifies the numa nodes to allocate memory from. See 'man 8 numactl' for information about each mode. This however will have some impact on performance and will break migration to hosts without security patches. In order to control this behavior there is a secure parameter. Possible values are on and off , with on as the default. Expose the host CPUs configuration to the guest. This enables the guest to take advantage of many of the host CPUs features better performance , but may cause issues if migrating the guest to a host without an identical CPU.

Example invocation. Configure domain seclabel domain settings. Type can be either 'static' or 'dynamic'. Examples include acpi, apic, eoi, privnet, and hyperv features. Some examples:. Notify the guest that the host supports paravirtual spinlocks for example by exposing the pvticketlocks mechanism. This enables System Management Mode of hypervisor.

Some UEFI firmwares may require this feature to be present. Set a timer's tickpolicy value. TIMER here might be rtc, pit, etc. VAL might be catchup, delay, etc. Refer to the libvirt docs for all values. SEV has further implications on usage of virtio devices, so refer to Examples section to see a full invocation of virt-install with --launchSecurity.

Distribution tree installation source. Path to a local directory containing an installable distribution image. Note that the directory will not be accessible by the guest after initial boot, so the OS installer will need another way to access the rest of the install media.

Additionally, --location can take 'kernel' and 'initrd' sub options. For example, if you have an ISO that libosinfo doesn't know about called my-unknown. Skip the OS installation process, and build a guest around an existing disk image. The device used for booting is the first device specified via --disk or --filesystem. Additional kernel command line arguments to pass to the installer when performing a guest install from --location.

Add PATH to the root of the initrd fetched with --location. This is a larger entry point for various types of install operations. The command has multiple subarguments, similar to --disk and friends.

This option is strictly for VM install operations, essentially configuring the first boot. This is os install option described above. Specify a kernel and initrd pair to use as install media.

They are copied into a temporary location before booting the VM, so they can be combined with --initrd-inject and your source media will not be altered. Media will be uploaded to a remote connection if required. Example using network paths. Note, these are just for install time booting.

If you want to set the kernel used for permanent VM booting, use the --boot option. Specify the install bootdev hd, cdrom, floppy, network to boot off of for the install phase. If you want to install off a cdrom or network, it's probably simpler and more backwards compatible to just use --cdrom or --pxe , but this options gives fine grained control over the install process if needed. Tell virt-install that there isn't actually any install happening, and you just want to create the VM.

Reinstall an existing VM. Only install related options are processed, all other VM configuration options like --name, --disk, etc. Perform an unattended install using libosinfo's install script support. This is essentially a database of auto install scripts for various distros: Red Hat kickstarts, Debian installer scripting, Windows unattended installs, and potentially others.

The simplest invocation is to combine it with --install like:. Choose which libosinfo unattended profile to use. Most distros have a 'desktop' and a 'jeos' profile. Note that only the first line of the file will be considered, including any whitespace characters and excluding new-line.

The user login name to be used in th VM. Note that when running virt-install as "root", this option must be specified. A file used to set the VM user password. The username is either the user-login specified or your current host username. Pass cloud-init metadata to the VM. The device is only attached for the first boot.

This option is particularly useful for distro cloud images, which have locked login accounts by default; --cloud-init provides the means to initialize those login accounts, like setting a root password. See those suboptions for explanation of how they work.

Generate a new root password for the VM. When used, virt-install will print the generated password to the console, and pause for 10 seconds to give the user a chance to notice it and copy it. Disable cloud-init in the VM for subsequent boots.

Without this, cloud-init may reset auth on each boot. A file used to set the VM root password from. Specify a cloud-init meta-data file to add directly to the iso. All other meta-data configuration options on the --cloud-init command line are ignored.

Specify a cloud-init user-data file to add directly to the iso. All other user-data configuration options on the --cloud-init command line are ignored. Specify a public key to inject into the guest, providing ssh access to the unprivileged account. Optionally specify the post-install VM boot configuration. In the latter case, behavior is similar to the --import install option: there is no 'install' phase, the guest is just created and launched as specified.

Path to a binary that the container guest will init. In order for virt-install to know the correct UEFI parameters, libvirt needs to be advertising known UEFI binaries via domcapabilities XML, so this will likely only work if using properly configured distro packages.

Specify that the virtual machine use the custom OVMF binary as boot firmware, mapped as a virtual flash chip. Optimize the guest configuration for a specific operating system ex. Whether virt-install should attempt OS detection from the specified install media. This tells virt-install to attempt detection from install media, but explicitly fail if that does not succeed. This will ensure your virt-install invocations don't fallback to a poorly performing config.

If any manual --os-variant value is specified, the default is all settings off or unset. Specifies media to use as storage for the guest, with various options. The general format of a disk string is. To specify media, the command can either be:. If values are omitted, the rest will be autofilled preferring sockets over cores over threads. See 'man 8 numactl' for information about each mode.

This enables the guest to take advantage of many of the host CPUs features better performance , but may cause issues if migrating the guest to a host without an identical CPU. It is the best CPU which can be used for a guest on any of the hosts. Example invocation --cputune vpcupin0. Type can be either 'static' or 'dynamic'. Otherwise disk images must be manually labeled by the admin, including images that virt-install is asked to create. Examples include acpi, apic, eoi, privnet, and hyperv features.

Possible values are "host" or version number. Some UEFI firmwares may require this feature to be present. TIMER here might be hpet, kvmclock, etc. TIMER here might be rtc, pit, etc. VAL might be catchup, delay, etc. Refer to the libvirt docs for all values. The URLs take the same format as described for the "--location" argument. If a cdrom has been specified via the "--disk" option, and neither "--cdrom" nor any other install option is specified, the "--disk" cdrom is used as the install media.

With libvirt 0. This option requires the URL to be accessible by both the local and remote host. This requires running virt-install as root. Note that the directory will not be accessible by the guest after initial boot, so the OS installer will need another way to access the rest of the install media. The device used for booting is the first device specified via "--disk" or "--filesystem". It may be desirable to also use the "--disk none" flag in combination.

By default, virt-install will attempt to auto detect this value from the install media currently only supported for URL installs.

Autodetection can be disabled with the special value 'none'. Autodetection can be forced with the special value 'auto'. Use the command "osinfo-query os" to get the list of the accepted OS variants. In the latter case, behavior is similar to the --import install option: there is no 'install' phase, the guest is just created and launched as specified. Additionally enable BIOS boot menu prompt. In order for virt-install to know the correct UEFI parameters, libvirt needs to be advertising known UEFI binaries via domcapabilities XML, so this will likely only work if using properly configured distro packages.

Existing media can be a file or block device. Specifying a non-existent path implies attempting to create the new storage, and will require specifying a 'size' value. Even for remote hosts, virt-install will try to use libvirt storage APIs to automatically create the given path. For network paths, they hypervisor will directly access the storage, nothing is downloaded locally.

Requires specifying a 'size' value. Other available options: device Disk device type. Value can be 'cdrom', 'disk', 'lun' or 'floppy'. Default is 'disk'. If a 'cdrom' is specified, and no install method is chosen, the cdrom is used as the install media.

Devices with lower value has higher priority. Value can be 'ide', 'sata', 'scsi', 'usb', 'virtio' or 'xen'. The default is hypervisor dependent since not all hypervisors support all bus types. Value can be 'on' or 'off'. Value is 'yes' or 'no'. Default is 'yes' do not fully allocate unless it isn't supported by the underlying storage type. The host pagecache provides cache memory.

The cache value can be 'none', 'writethrough', 'directsync', 'unsafe' or 'writeback'. The value can be either "unmap" allow the discard request to be passed or "ignore" ignore the discard request.

Since 1. For file volumes, this can be 'raw', 'qcow2', 'vmdk', etc. If not specified when creating file images, this will default to 'qcow2'. If creating storage, this will be the format of the new image. If using an existing image, this overrides libvirt's format auto-detection.

Typically does not need to be set by the user. Can be either "threads" or "native". Can be one of "stop", "ignore", or "enospace" serial Serial number of the emulated disk device. See the examples section for some uses. For QEMU, the target point is just a mounting hint in sysfs, so will not be automatically mounted. This option is deprecated in favor of "--disk". Size of the file to create for the guest virtual disk. This is deprecated in favor of "--disk". Connect the guest to the host network.

Also use this if live migration will be used with this guest. Virtual networks can be listed, created, deleted using the "virsh" command line tool. In an unmodified install of "libvirt" there is usually a virtual network with a name of "default". Use a virtual network if the host has dynamic networking eg NetworkManager , or using wireless. Only use this if running a QEMU guest as an unprivileged user.

This provides a very limited form of NAT. If this option is omitted a single NIC will be created in the guest. If there is a bridge device in the host with a physical interface enslaved, that will be used for connectivity.

Failing that, the virtual network called "default" will be used. This option can be specified multiple times to setup more than one NIC. Bridge device to connect the guest NIC to. This parameter is deprecated in favour of the "--network" parameter. Setup a virtual console in the guest and export it as a VNC server in the host.

Unless the "--vncport" parameter is also provided, the VNC server will run on the first free port number at or above. The actual VNC display allocated can be obtained using the "vncdisplay" command to "virsh" or virt-viewer 1 can be used which handles this detail for the use. Request a permanent, statically assigned port number for the guest VNC console. Use of this option is discouraged as other guests may automatically choose to run on this port causing a clash. Setup a virtual console in the guest and display an SDL window in the host to render the output.

If the SDL window is closed the guest may be unconditionally terminated. No graphical console will be allocated for the guest. Xen PV will set this up automatically. The default behaviour is to launch a VNC client to display the graphical console, or to run the "virsh" "console" command to display the text console.

Use of this parameter will disable this behaviour. Print debugging information to the terminal when running the install process. Amount of time to wait in minutes for a VM to complete its install. Without this option, virt-install will wait for the console to close not neccessarily indicating the guest has shutdown , or in the case of --noautoconsole, simply kick off the install and exit.

Any negative value will make virt-install wait indefinitely, a value of 0 triggers the same results as noautoconsole.