VIRT-XML(1)
π VIRT-XML π β that's virt-xml(1) bestie
β¨ NAME β¨
virt-xml β Edit libvirt XML using command line options. π
β¨ SYNOPSIS β¨
virt-xml DOMAIN XML-ACTION XML-OPTION [OUTPUT-OPTION] [MISC-OPTIONS] ...
β¨ DESCRIPTION β¨
okay so, virt-xml is a command line tool for editing libvirt XML using explicit command line options. and literally, if you wanna just jump right in, there's an EXAMPLES section at the end of this document. π«Ά
Every single virt-xml invocation requires 3 things: name of an existing domain to alter (or XML passed on stdin), an action to on the XML, and an XML change to make. the actions are one of:
--add-deviceβ Append a new device definition to the XML πΈ--remove-deviceβ Remove an existing device definition π--editβ Edit an existing XML block βοΈ--build-xmlβ Just build the requested XML block and print it. No domain or input are required here, but it's recommended to provide them, sovirt-xmlcan fill in optimal defaults. β¨
An XML change is one instance of any of the XML options provided by virt-xml, for example --disk or --boot.
virt-xml only allows one action and XML pair per invocation. If you need to make multiple edits, invoke the command multiple times. periodt. π
β¨ OPTIONS β¨
-c --connect URIβ Connect to a non-default hypervisor. Seevirt-install(1)for details πdomainβ domain is the name, UUID, or ID of the existing VM. This can be omitted if using--build-xml, or if XML is passed on stdin.
When a domain is specified, the default output action is --define, even if the VM is running. To update the running VM configuration, add the --update option (but not all options/devices support updating the running VM configuration). β οΈ
If XML is passed on stdin, the default output is --print-xml.
π₯ XML ACTIONS π₯
--edit [EDIT-OPTIONS]β Edit the specified XML block. EDIT-OPTIONS tellvirt-xmlwhich block to edit. The type of XML that we are editing is decided by XML option that is passed tovirt-xml. So if--diskis passed, EDIT-OPTIONS select which<disk>block to edit.
Certain XML options only ever map to a single XML block, like --cpu, --security, --boot, --clock, and a few others. In those cases, virt-xml will not complain if a corresponding XML block does not already exist, it will create it for you. π§
Most XML options support a special value 'clearxml=yes'. When combined with --edit, it will completely blank out the XML block being edited before applying the requested changes. This allows completely rebuilding an XML block. See EXAMPLES for some usage.
EDIT-OPTIONS examples:
--editβ--editwithout any options implies 'edit the first block'. So '--edit --disk DISK-OPTIONS' means 'edit the first<disk>'.
For the single XML block options mentioned above, plain '--edit' without any options is what you always want to use.
--edit #β Select the specified XML block number. So '--edit 2 --disk DISK-OPTS' means 'edit the second<disk>'. This option only really applies for device XML.--edit allβ Modify every XML block of the XML option type. So '--edit all --disk DISK-OPTS' means 'edit ever<disk>block'. This option only really applies for device XML.--edit DEVICE-OPTIONSβ Modify every XML block that matches the passed device options. The device options are in the same format as would be passed to the XML option.
So --edit path=/tmp/foo --disk DISK-OPTS means 'edit every <disk> with path /tmp/foo'. This option only really applies for device XML.
--add-deviceβ Append the specified XML options to the XML<devices>list. Example: '--add-device --disk DISK-OPTIONS' will create a new<disk>block and add it to the XML.
This option will error if specified with a non-device XML option (see --edit section for a partial list).
--remove-deviceβ Remove the specified device from the XML. The device to remove is chosen by the XML option, which takes arguments in the same format as--edit. Examples:--remove-device --disk 2β Remove the second disk device--remove-device --network allβ Remove all network devices--remove-device --sound pcspkβ Remove all sound devices withmodel='pcspk'
This option will error if specified with a non-device XML option (see --edit isection for a partial list).
--build-xmlβ Just build the specified XML, and print it to stdout. No input domain or input XML is required. Example: '--build-xml --disk DISK-OPTIONS' will just print the new<disk>device.
However if the generated XML is targeted for a specific domain, it's recommended to pass it to virt-xml, so the tool can set optimal defaults.
This option will error if specified with an XML option that does not map cleanly to a specific XML block, like --vcpus or --memory.
π¨οΈ OUTPUT OPTIONS π¨οΈ
These options decide what action to take after altering the XML. In the common case these do not need to be specified, as 'XML actions' will imply a default output action, described in detail above. These are only needed if you want to modify the default output.
--updateβ If the specified domain is running, attempt to alter the running VM configuration. If combined with--edit, this is an update operation. If combined with--add-device, this is a device hotplug. If combined with--remove-device, this is a device hotunplug.
keep in mind bestie, most XML properties and devices do not support live update operations, so don't expect it to succeed in all cases. π
By default this also implies --define.
--defineβ Define the requested XML change. This is typically the default if no output option is specified, but if a--printoption is specified,--defineis required to force the change.--no-defineβ Explicitly do not define the XML. For example if you only want to alter the runtime state of a VM, combine this with--update.--startβ Start the VM after performing the requested changes. If combined with--no-define, this will create transient VM boot with the requested changes.--print-diffβ Print the generated XML change in unified diff format. If only this output option is specified, all other output options are disabled and no persistent change is made.--print-xmlβ Print the generated XML in its entirety. If only this output option is specified, all other output options are disabled and no persistent change is made.--confirmβ Before defining or updating the domain, show the generated XML diff and interactively request confirmation.
π GUEST OS OPTIONS π
--osinfo,--os-variant OS_VARIANTβ Optimize the guest configuration for a specific operating system (ex. 'fedora29', 'rhel7', 'win10'). While not required, specifying this options is HIGHLY RECOMMENDED, as it can greatly increase performance by specifying virtio among other guest tweaks. π₯
If the guest has been installed using virt-manager version 2.0.0 or newer, providing this information should not be necessary, as the OS variant will have been stored in the guest configuration during installation and virt-xml will retrieve it from there automatically. π
Use the command virt-xml --osinfo list to get the list of the accepted OS variants. See osinfo-query os for even more output.
See virt-install(1) documentation for more details about --osinfo/--os-variant
π CONVERSION OPTIONS π
--convert-to-q35
Syntax: --convert-to-q35 [OPTIONS]
Convert an existing VM config from PC/i440FX to Q35 machine type. This largely consists of:
- Convert device topology from PCI to PCIe
- Convert any IDE storage to SATA
You may need to make config changes inside the VM to handle this as well. For example, Windows 10 may not find the boot device after IDE to SATA conversion. But booting into safe mode once may fix it. π©Ή
Sub options are:
num_pcie_root_ports=NUM
Control the number of default pcie-root-port controller devices we add to the VM by default.
--convert-to-vnc
Syntax: --convert-to-vnc [OPTIONS]
Convert an existing VM to exclusively use a single VNC graphics device.
It will attempt to remove all references to any non-VNC graphics config, like Spice. For example:
- qxl devices will be replaced
- all spicevmc and spiceport devices will be removed
- spice GL will be converted to egl-headless
Sub options are:
qemu-vdagent=on|off
Add a qemu-vdagent device if one is not already configured. This replaces some functionality of the spice vdagent. This defaults to off but that could change in the future. π¦
β¨ XML OPTIONS β¨
--disk--network--graphics--metadata--memory--vcpus--cpu--iothreads--seclabel--keywrap--cputune--numatune--memtune--blkiotune--memorybacking--features--clock--pm--events--resources--sysinfo--xml--qemu-commandline--launchSecurity--boot--idmap--controller--input--serial--parallel--channel--console--hostdev--filesystem--sound--audio--watchdog--video--smartcard--redirdev--memballoon--tpm--rng--panic--shmem--memdev
So these ones each poke at one single class of XML elements. If you want the full, no-crumbs-left version of the docs, that lives in virt-install(1) π
Ngl these map pretty straightforwardly onto the libvirt XML, which is documented right here: <https://libvirt.org/formatdomain.html>
Every option string follows this format, bestie:
--option opt=val,opt2=val2,...
like for real, e.g. --disk path=/tmp/foo,shareable=on. And plot twist π you can use properties as '--option opt=,' β so if you wanna clear a disk's cache setting you just go '--disk cache=,'
Wanna see every suboption an option takes? Ask it politely with --option=?. Example: --disk=? or --boot=? β¨
The --help output also lists a few general examples, and there's an EXAMPLES section further down with the common ones π«Ά
Okay so virt-xml specifically has some operations that don't really apply to virt-install. Examples, bestie:
--boot refresh-machine-type=yesβ refresh the XML<os><type machine=X></os>value up to the latest one that qemu provides. Say your VM has a machine type valuepc-q35-4.0β this resets it toq35, and it behaves the same way with other versioned machine types. Sometimes you literally need to do this to enable qemu bug fixes, or because qemu deprecated and removed old machine type values. It's giving maintenance era π
π MISCELLANEOUS OPTIONS π
-h,--helpβ show the help message and exit--versionβ show the program's version number and exit-q,--quietβ avoid verbose output-d,--debugβ print debugging information
π EXAMPLES π
See a list of all the suboptions that --disk and --network take:
# virt-xml --disk=? --network=?
Change the <description> of domain 'EXAMPLE':
# virt-xml EXAMPLE --edit --metadata description="my new description"
Enable the boot device menu for domain 'EXAMPLE': (yes the original comment has a stray #, we keep it, no cap π)
# Enable the boot device menu for domain 'EXAMPLE':
# virt-xml EXAMPLE --edit --boot menu=on
Clear the previous <cpu> definition of domain 'winxp', change it to 'host-model', but interactively confirm the diff before saving:
# virt-xml winxp --edit --cpu host-model,clearxml=yes --confirm
Change the second sound card to model=ich6 on 'fedora19', but only output the diff:
# virt-xml fedora19 --edit 2 --sound model=ich6 --print-diff
Update the every graphics device password to 'foo' of the running VM 'rhel6':
# virt-xml rhel6 --edit all --graphics password=foo --update
Remove the disk path from disk device hdc:
# virt-xml rhel6 --edit target=hdc --disk path=
Change all disk devices of type 'disk' to use cache=none, using XML from stdin, printing the new XML to stdout.
# cat <xmlfile> | virt-xml --edit device=disk --disk cache=none
Change disk 'hda' IO to native and use startup policy as 'optional'.
# virt-xml fedora20 --edit target=hda \
--disk io=native,startup_policy=optional
Change all host devices to use driver_name=vfio for VM 'fedora20' on the remote connection:
# virt-xml --connect qemu+ssh://remotehost/system \
fedora20 --edit all --hostdev driver_name=vfio
Hotplug host USB device 001.003 to running domain 'fedora19':
# virt-xml fedora19 --update --add-device --hostdev 001.003
Add a spicevmc channel to the domain 'winxp', that will be available after the next VM shutdown.
# virt-xml winxp --add-device --channel spicevmc
Create a 10G qcow2 disk image and attach it to 'fedora18' for the next VM startup:
# virt-xml fedora18 --add-device \
--disk /var/lib/libvirt/images/newimage.qcow2,format=qcow2,size=10
Same as above, but ensure the disk is attached to the most appropriate bus for the guest OS by providing information about it on the command line:
# virt-xml fedora18 --osinfo fedora18 --add-device \
--disk /var/lib/libvirt/images/newimage.qcow2,format=qcow2,size=10
Hotunplug the disk vdb from the running domain 'rhel7':
# virt-xml rhel7 --update --remove-device --disk target=vdb
Remove all graphics devices from the VM 'rhel7' after the next shutdown:
# virt-xml rhel7 --remove-device --graphics all
Generate XML for a virtio console device and print it to stdout:
# virt-xml --build-xml --console pty,target_type=virtio
Add qemu command line passthrough:
# virt-xml f25 --edit --confirm --qemu-commandline="-device FOO"
Use boot device 'network' for a single transient boot:
# virt-xml myvm --no-define --start --edit --boot network
β οΈ CAVEATS β οΈ
The virtualization hosts that libvirt supports may not permit all the changes that might seem possible. Some edits you make to a VM's definition may just get ignored, bestie, no warning, nothing π For instance, QEMU does not allow the removal of certain devices once they've been defined. That's just how it is, fr.
π BUGS π
Please see <https://virt-manager.org/bugs> β report it, they wanna know π
π COPYRIGHT π
Copyright (C) Red Hat, Inc, and various contributors. This is free software. You may redistribute copies of it under the terms of the GNU General Public License <https://www.gnu.org/licenses/gpl.html> . There is NO WARRANTY, to the extent permitted by law.
πΈ SEE ALSO πΈ
virt-install(1), the project website <https://virt-manager.org>
And that's a wrap, bestie π
This page is VIRT-XML(1), dated 2025-07-23 β go forth and edit your domains, you absolute main character π¦β¨
π¦ where this page comes from
- alpine 3.24: virt-manager-doc 5.1.0-r0 Β· GPL-2.0-or-later
- fedora 43: virt-install 5.1.0-2.fc43 Β· GPL-2.0-or-later
- fedora 43: virt-install 5.1.0-3.fc43 Β· GPL-2.0-or-later
- opensuse-leap 16.0: virt-install 5.0.0-160000.4.1 Β· GPL-2.0-or-later
- ubuntu resolute: virt-install 1:5.1.0-1 Β· GPL-2.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms