OpenE2K
/
qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity

qemu-doc: Do not hard-code the name of the QEMU binary 

In our documentation, we use a mix of "$QEMU", "qemu-system-i386" and
"qemu-system-x86_64" when we give examples to the users how to run
QEMU. Some more consistency would be good here. Also some distributions
use different names for the QEMU binary (e.g. "qemu-kvm" in RHEL), so
providing more flexibility here would also be good. Thus let's define
some variables for the names of the QEMU command and use those in the
documentation instead: @value{qemu_system} for generic examples, and
@value{qemu_system_x86} for examples that only work with the x86
binaries.

Message-Id: <20190828093447.12441-1-thuth@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Reviewed-by: Miroslav Rezanina <mrezanin@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
This commit is contained in:
Thomas Huth 2019-07-30 17:08:26 +02:00
parent 4631332675
commit 664785acff
4 changed files with 149 additions and 142 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

72
docs/qemu-block-drivers.texi
View File

@ -2,6 +2,8 @@
QEMU block driver reference manual QEMU block driver reference manual
@c man end @c man end
@set qemu_system qemu-system-x86_64
@c man begin DESCRIPTION @c man begin DESCRIPTION
@node disk_images_formats @node disk_images_formats
@ -405,7 +407,7 @@ QEMU can automatically create a virtual FAT disk image from a
directory tree. In order to use it, just type: directory tree. In order to use it, just type:
@example @example
qemu-system-i386 linux.img -hdb fat:/my_directory @value{qemu_system} linux.img -hdb fat:/my_directory
@end example @end example
Then you access access to all the files in the @file{/my_directory} Then you access access to all the files in the @file{/my_directory}
@ -415,14 +417,14 @@ them via SAMBA or NFS. The default access is @emph{read-only}.
Floppies can be emulated with the @code{:floppy:} option: Floppies can be emulated with the @code{:floppy:} option:
@example @example
qemu-system-i386 linux.img -fda fat:floppy:/my_directory @value{qemu_system} linux.img -fda fat:floppy:/my_directory
@end example @end example
A read/write support is available for testing (beta stage) with the A read/write support is available for testing (beta stage) with the
@code{:rw:} option: @code{:rw:} option:
@example @example
qemu-system-i386 linux.img -fda fat:floppy:rw:/my_directory @value{qemu_system} linux.img -fda fat:floppy:rw:/my_directory
@end example @end example
What you should @emph{never} do: What you should @emph{never} do:
@ -440,14 +442,14 @@ QEMU can access directly to block device exported using the Network Block Device
protocol. protocol.
@example @example
qemu-system-i386 linux.img -hdb nbd://my_nbd_server.mydomain.org:1024/ @value{qemu_system} linux.img -hdb nbd://my_nbd_server.mydomain.org:1024/
@end example @end example
If the NBD server is located on the same host, you can use an unix socket instead If the NBD server is located on the same host, you can use an unix socket instead
of an inet socket: of an inet socket:
@example @example
qemu-system-i386 linux.img -hdb nbd+unix://?socket=/tmp/my_socket @value{qemu_system} linux.img -hdb nbd+unix://?socket=/tmp/my_socket
@end example @end example
In this case, the block device must be exported using qemu-nbd: In this case, the block device must be exported using qemu-nbd:
@ -464,23 +466,23 @@ qemu-nbd --socket=/tmp/my_socket --share=2 my_disk.qcow2
@noindent @noindent
and then you can use it with two guests: and then you can use it with two guests:
@example @example
qemu-system-i386 linux1.img -hdb nbd+unix://?socket=/tmp/my_socket @value{qemu_system} linux1.img -hdb nbd+unix://?socket=/tmp/my_socket
qemu-system-i386 linux2.img -hdb nbd+unix://?socket=/tmp/my_socket @value{qemu_system} linux2.img -hdb nbd+unix://?socket=/tmp/my_socket
@end example @end example
If the nbd-server uses named exports (supported since NBD 2.9.18, or with QEMU's If the nbd-server uses named exports (supported since NBD 2.9.18, or with QEMU's
own embedded NBD server), you must specify an export name in the URI: own embedded NBD server), you must specify an export name in the URI:
@example @example
qemu-system-i386 -cdrom nbd://localhost/debian-500-ppc-netinst @value{qemu_system} -cdrom nbd://localhost/debian-500-ppc-netinst
qemu-system-i386 -cdrom nbd://localhost/openSUSE-11.1-ppc-netinst @value{qemu_system} -cdrom nbd://localhost/openSUSE-11.1-ppc-netinst
@end example @end example
The URI syntax for NBD is supported since QEMU 1.3. An alternative syntax is The URI syntax for NBD is supported since QEMU 1.3. An alternative syntax is
also available. Here are some example of the older syntax: also available. Here are some example of the older syntax:
@example @example
qemu-system-i386 linux.img -hdb nbd:my_nbd_server.mydomain.org:1024 @value{qemu_system} linux.img -hdb nbd:my_nbd_server.mydomain.org:1024
qemu-system-i386 linux2.img -hdb nbd:unix:/tmp/my_socket @value{qemu_system} linux2.img -hdb nbd:unix:/tmp/my_socket
qemu-system-i386 -cdrom nbd:localhost:10809:exportname=debian-500-ppc-netinst @value{qemu_system} -cdrom nbd:localhost:10809:exportname=debian-500-ppc-netinst
@end example @end example
@node disk_images_sheepdog @node disk_images_sheepdog
@ -505,7 +507,7 @@ qemu-img convert @var{filename} sheepdog:///@var{image}
You can boot from the Sheepdog disk image with the command: You can boot from the Sheepdog disk image with the command:
@example @example
qemu-system-i386 sheepdog:///@var{image} @value{qemu_system} sheepdog:///@var{image}
@end example @end example
You can also create a snapshot of the Sheepdog image like qcow2. You can also create a snapshot of the Sheepdog image like qcow2.
@ -517,7 +519,7 @@ where @var{tag} is a tag name of the newly created snapshot.
To boot from the Sheepdog snapshot, specify the tag name of the To boot from the Sheepdog snapshot, specify the tag name of the
snapshot. snapshot.
@example @example
qemu-system-i386 sheepdog:///@var{image}#@var{tag} @value{qemu_system} sheepdog:///@var{image}#@var{tag}
@end example @end example
You can create a cloned image from the existing snapshot. You can create a cloned image from the existing snapshot.
@ -530,14 +532,14 @@ is its tag name.
You can use an unix socket instead of an inet socket: You can use an unix socket instead of an inet socket:
@example @example
qemu-system-i386 sheepdog+unix:///@var{image}?socket=@var{path} @value{qemu_system} sheepdog+unix:///@var{image}?socket=@var{path}
@end example @end example
If the Sheepdog daemon doesn't run on the local host, you need to If the Sheepdog daemon doesn't run on the local host, you need to
specify one of the Sheepdog servers to connect to. specify one of the Sheepdog servers to connect to.
@example @example
qemu-img create sheepdog://@var{hostname}:@var{port}/@var{image} @var{size} qemu-img create sheepdog://@var{hostname}:@var{port}/@var{image} @var{size}
qemu-system-i386 sheepdog://@var{hostname}:@var{port}/@var{image} @value{qemu_system} sheepdog://@var{hostname}:@var{port}/@var{image}
@end example @end example
@node disk_images_iscsi @node disk_images_iscsi
@ -627,7 +629,7 @@ cat >iscsi.conf <<EOF
header-digest = "CRC32C" header-digest = "CRC32C"
EOF EOF
qemu-system-i386 -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \ @value{qemu_system} -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
-readconfig iscsi.conf -readconfig iscsi.conf
@end example @end example
@ -646,7 +648,7 @@ tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 2 \
-b /IMAGES/cd.iso --device-type=cd -b /IMAGES/cd.iso --device-type=cd
tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL
qemu-system-i386 -iscsi initiator-name=iqn.qemu.test:my-initiator \ @value{qemu_system} -iscsi initiator-name=iqn.qemu.test:my-initiator \
-boot d -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \ -boot d -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
-cdrom iscsi://127.0.0.1/iqn.qemu.test/2 -cdrom iscsi://127.0.0.1/iqn.qemu.test/2
@end example @end example
@ -659,11 +661,11 @@ GlusterFS is a user space distributed file system.
You can boot from the GlusterFS disk image with the command: You can boot from the GlusterFS disk image with the command:
@example @example
URI: URI:
qemu-system-x86_64 -drive file=gluster[+@var{type}]://[@var{host}[:@var{port}]]/@var{volume}/@var{path} @value{qemu_system} -drive file=gluster[+@var{type}]://[@var{host}[:@var{port}]]/@var{volume}/@var{path}
[?socket=...][,file.debug=9][,file.logfile=...] [?socket=...][,file.debug=9][,file.logfile=...]
JSON: JSON:
qemu-system-x86_64 'json:@{"driver":"qcow2", @value{qemu_system} 'json:@{"driver":"qcow2",
"file":@{"driver":"gluster", "file":@{"driver":"gluster",
"volume":"testvol","path":"a.img","debug":9,"logfile":"...", "volume":"testvol","path":"a.img","debug":9,"logfile":"...",
"server":[@{"type":"tcp","host":"...","port":"..."@}, "server":[@{"type":"tcp","host":"...","port":"..."@},
@ -711,22 +713,22 @@ qemu-img create gluster://@var{host}/@var{volume}/@var{path} @var{size}
Examples Examples
@example @example
qemu-system-x86_64 -drive file=gluster://1.2.3.4/testvol/a.img @value{qemu_system} -drive file=gluster://1.2.3.4/testvol/a.img
qemu-system-x86_64 -drive file=gluster+tcp://1.2.3.4/testvol/a.img @value{qemu_system} -drive file=gluster+tcp://1.2.3.4/testvol/a.img
qemu-system-x86_64 -drive file=gluster+tcp://1.2.3.4:24007/testvol/dir/a.img @value{qemu_system} -drive file=gluster+tcp://1.2.3.4:24007/testvol/dir/a.img
qemu-system-x86_64 -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]/testvol/dir/a.img @value{qemu_system} -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]/testvol/dir/a.img
qemu-system-x86_64 -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]:24007/testvol/dir/a.img @value{qemu_system} -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]:24007/testvol/dir/a.img
qemu-system-x86_64 -drive file=gluster+tcp://server.domain.com:24007/testvol/dir/a.img @value{qemu_system} -drive file=gluster+tcp://server.domain.com:24007/testvol/dir/a.img
qemu-system-x86_64 -drive file=gluster+unix:///testvol/dir/a.img?socket=/tmp/glusterd.socket @value{qemu_system} -drive file=gluster+unix:///testvol/dir/a.img?socket=/tmp/glusterd.socket
qemu-system-x86_64 -drive file=gluster+rdma://1.2.3.4:24007/testvol/a.img @value{qemu_system} -drive file=gluster+rdma://1.2.3.4:24007/testvol/a.img
qemu-system-x86_64 -drive file=gluster://1.2.3.4/testvol/a.img,file.debug=9,file.logfile=/var/log/qemu-gluster.log @value{qemu_system} -drive file=gluster://1.2.3.4/testvol/a.img,file.debug=9,file.logfile=/var/log/qemu-gluster.log
qemu-system-x86_64 'json:@{"driver":"qcow2", @value{qemu_system} 'json:@{"driver":"qcow2",
"file":@{"driver":"gluster", "file":@{"driver":"gluster",
"volume":"testvol","path":"a.img", "volume":"testvol","path":"a.img",
"debug":9,"logfile":"/var/log/qemu-gluster.log", "debug":9,"logfile":"/var/log/qemu-gluster.log",
"server":[@{"type":"tcp","host":"1.2.3.4","port":24007@}, "server":[@{"type":"tcp","host":"1.2.3.4","port":24007@},
@{"type":"unix","socket":"/var/run/glusterd.socket"@}]@}@}' @{"type":"unix","socket":"/var/run/glusterd.socket"@}]@}@}'
qemu-system-x86_64 -drive driver=qcow2,file.driver=gluster,file.volume=testvol,file.path=/path/a.img, @value{qemu_system} -drive driver=qcow2,file.driver=gluster,file.volume=testvol,file.path=/path/a.img,
file.debug=9,file.logfile=/var/log/qemu-gluster.log, file.debug=9,file.logfile=/var/log/qemu-gluster.log,
file.server.0.type=tcp,file.server.0.host=1.2.3.4,file.server.0.port=24007, file.server.0.type=tcp,file.server.0.host=1.2.3.4,file.server.0.port=24007,
file.server.1.type=unix,file.server.1.socket=/var/run/glusterd.socket file.server.1.type=unix,file.server.1.socket=/var/run/glusterd.socket
@ -739,13 +741,13 @@ You can access disk images located on a remote ssh server
by using the ssh protocol: by using the ssh protocol:
@example @example
qemu-system-x86_64 -drive file=ssh://[@var{user}@@]@var{server}[:@var{port}]/@var{path}[?host_key_check=@var{host_key_check}] @value{qemu_system} -drive file=ssh://[@var{user}@@]@var{server}[:@var{port}]/@var{path}[?host_key_check=@var{host_key_check}]
@end example @end example
Alternative syntax using properties: Alternative syntax using properties:
@example @example
qemu-system-x86_64 -drive file.driver=ssh[,file.user=@var{user}],file.host=@var{server}[,file.port=@var{port}],file.path=@var{path}[,file.host_key_check=@var{host_key_check}] @value{qemu_system} -drive file.driver=ssh[,file.user=@var{user}],file.host=@var{server}[,file.port=@var{port}],file.path=@var{path}[,file.host_key_check=@var{host_key_check}]
@end example @end example
@var{ssh} is the protocol. @var{ssh} is the protocol.
@ -808,13 +810,13 @@ driver. For example:
# echo 0000:06:0d.0 > /sys/bus/pci/devices/0000:06:0d.0/driver/unbind # echo 0000:06:0d.0 > /sys/bus/pci/devices/0000:06:0d.0/driver/unbind
# echo 1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id # echo 1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id
# qemu-system-x86_64 -drive file=nvme://@var{host}:@var{bus}:@var{slot}.@var{func}/@var{namespace} # @value{qemu_system} -drive file=nvme://@var{host}:@var{bus}:@var{slot}.@var{func}/@var{namespace}
@end example @end example
Alternative syntax using properties: Alternative syntax using properties:
@example @example
qemu-system-x86_64 -drive file.driver=nvme,file.device=@var{host}:@var{bus}:@var{slot}.@var{func},file.namespace=@var{namespace} @value{qemu_system} -drive file.driver=nvme,file.device=@var{host}:@var{bus}:@var{slot}.@var{func},file.namespace=@var{namespace}
@end example @end example
@var{host}:@var{bus}:@var{slot}.@var{func} is the NVMe controller's PCI device @var{host}:@var{bus}:@var{slot}.@var{func} is the NVMe controller's PCI device

10
docs/qemu-cpu-models.texi
View File

@ -2,6 +2,8 @@
QEMU / KVM CPU model configuration QEMU / KVM CPU model configuration
@c man end @c man end
@set qemu_system_x86 qemu-system-x86_64
@c man begin DESCRIPTION @c man begin DESCRIPTION
@menu @menu
@ -578,25 +580,25 @@ CPU models / features in QEMU and libvirt
@item Host passthrough @item Host passthrough
@example @example
$ qemu-system-x86_64 -cpu host $ @value{qemu_system_x86} -cpu host
@end example @end example
With feature customization: With feature customization:
@example @example
$ qemu-system-x86_64 -cpu host,-vmx,... $ @value{qemu_system_x86} -cpu host,-vmx,...
@end example @end example
@item Named CPU models @item Named CPU models
@example @example
$ qemu-system-x86_64 -cpu Westmere $ @value{qemu_system_x86} -cpu Westmere
@end example @end example
With feature customization: With feature customization:
@example @example
$ qemu-system-x86_64 -cpu Westmere,+pcid,... $ @value{qemu_system_x86} -cpu Westmere,+pcid,...
@end example @end example
@end table @end table

81
qemu-doc.texi
View File

@ -11,6 +11,9 @@
@paragraphindent 0 @paragraphindent 0
@c %**end of header @c %**end of header
@set qemu_system qemu-system-x86_64
@set qemu_system_x86 qemu-system-x86_64
@ifinfo @ifinfo
@direntry @direntry
* QEMU: (qemu-doc). The QEMU Emulator User Documentation. * QEMU: (qemu-doc). The QEMU Emulator User Documentation.
@ -207,12 +210,12 @@ Note that, by default, GUS shares IRQ(7) with parallel ports and so
QEMU must be told to not have parallel ports to have working GUS. QEMU must be told to not have parallel ports to have working GUS.
@example @example
qemu-system-i386 dos.img -soundhw gus -parallel none @value{qemu_system_x86} dos.img -soundhw gus -parallel none
@end example @end example
Alternatively: Alternatively:
@example @example
qemu-system-i386 dos.img -device gus,irq=5 @value{qemu_system_x86} dos.img -device gus,irq=5
@end example @end example
Or some other unclaimed IRQ. Or some other unclaimed IRQ.
@ -225,10 +228,11 @@ CS4231A is the chip used in Windows Sound System and GUSMAX products
@section Quick Start @section Quick Start
@cindex quick start @cindex quick start
Download and uncompress the linux image (@file{linux.img}) and type: Download and uncompress a hard disk image with Linux installed (e.g.
@file{linux.img}) and type:
@example @example
qemu-system-i386 linux.img @value{qemu_system} linux.img
@end example @end example
Linux should boot and give you a prompt. Linux should boot and give you a prompt.
@ -238,7 +242,7 @@ Linux should boot and give you a prompt.
@example @example
@c man begin SYNOPSIS @c man begin SYNOPSIS
@command{qemu-system-i386} [@var{options}] [@var{disk_image}] @command{@value{qemu_system}} [@var{options}] [@var{disk_image}]
@c man end @c man end
@end example @end example
@ -278,21 +282,21 @@ is specified in seconds. The default is 0 which means no timeout. Libiscsi
Example (without authentication): Example (without authentication):
@example @example
qemu-system-i386 -iscsi initiator-name=iqn.2001-04.com.example:my-initiator \ @value{qemu_system} -iscsi initiator-name=iqn.2001-04.com.example:my-initiator \
-cdrom iscsi://192.0.2.1/iqn.2001-04.com.example/2 \ -cdrom iscsi://192.0.2.1/iqn.2001-04.com.example/2 \
-drive file=iscsi://192.0.2.1/iqn.2001-04.com.example/1 -drive file=iscsi://192.0.2.1/iqn.2001-04.com.example/1
@end example @end example
Example (CHAP username/password via URL): Example (CHAP username/password via URL):
@example @example
qemu-system-i386 -drive file=iscsi://user%password@@192.0.2.1/iqn.2001-04.com.example/1 @value{qemu_system} -drive file=iscsi://user%password@@192.0.2.1/iqn.2001-04.com.example/1
@end example @end example
Example (CHAP username/password via environment variables): Example (CHAP username/password via environment variables):
@example @example
LIBISCSI_CHAP_USERNAME="user" \ LIBISCSI_CHAP_USERNAME="user" \
LIBISCSI_CHAP_PASSWORD="password" \ LIBISCSI_CHAP_PASSWORD="password" \
qemu-system-i386 -drive file=iscsi://192.0.2.1/iqn.2001-04.com.example/1 @value{qemu_system} -drive file=iscsi://192.0.2.1/iqn.2001-04.com.example/1
@end example @end example
@item NBD @item NBD
@ -307,12 +311,12 @@ Syntax for specifying a NBD device using Unix Domain Sockets
Example for TCP Example for TCP
@example @example
qemu-system-i386 --drive file=nbd:192.0.2.1:30000 @value{qemu_system} --drive file=nbd:192.0.2.1:30000
@end example @end example
Example for Unix Domain Sockets Example for Unix Domain Sockets
@example @example
qemu-system-i386 --drive file=nbd:unix:/tmp/nbd-socket @value{qemu_system} --drive file=nbd:unix:/tmp/nbd-socket
@end example @end example
@item SSH @item SSH
@ -320,8 +324,8 @@ QEMU supports SSH (Secure Shell) access to remote disks.
Examples: Examples:
@example @example
qemu-system-i386 -drive file=ssh://user@@host/path/to/disk.img @value{qemu_system} -drive file=ssh://user@@host/path/to/disk.img
qemu-system-i386 -drive file.driver=ssh,file.user=user,file.host=host,file.port=22,file.path=/path/to/disk.img @value{qemu_system} -drive file.driver=ssh,file.user=user,file.host=host,file.port=22,file.path=/path/to/disk.img
@end example @end example
Currently authentication must be done using ssh-agent. Other Currently authentication must be done using ssh-agent. Other
@ -339,7 +343,7 @@ sheepdog[+tcp|+unix]://[host:port]/vdiname[?socket=path][#snapid|#tag]
Example Example
@example @example
qemu-system-i386 --drive file=sheepdog://192.0.2.1:30000/MyVirtualMachine @value{qemu_system} --drive file=sheepdog://192.0.2.1:30000/MyVirtualMachine
@end example @end example
See also @url{https://sheepdog.github.io/sheepdog/}. See also @url{https://sheepdog.github.io/sheepdog/}.
@ -365,17 +369,17 @@ JSON:
Example Example
@example @example
URI: URI:
qemu-system-x86_64 --drive file=gluster://192.0.2.1/testvol/a.img, @value{qemu_system} --drive file=gluster://192.0.2.1/testvol/a.img,
@ file.debug=9,file.logfile=/var/log/qemu-gluster.log @ file.debug=9,file.logfile=/var/log/qemu-gluster.log
JSON: JSON:
qemu-system-x86_64 'json:@{"driver":"qcow2", @value{qemu_system} 'json:@{"driver":"qcow2",
@ "file":@{"driver":"gluster", @ "file":@{"driver":"gluster",
@ "volume":"testvol","path":"a.img", @ "volume":"testvol","path":"a.img",
@ "debug":9,"logfile":"/var/log/qemu-gluster.log", @ "debug":9,"logfile":"/var/log/qemu-gluster.log",
@ "server":[@{"type":"tcp","host":"1.2.3.4","port":24007@}, @ "server":[@{"type":"tcp","host":"1.2.3.4","port":24007@},
@ @{"type":"unix","socket":"/var/run/glusterd.socket"@}]@}@}' @ @{"type":"unix","socket":"/var/run/glusterd.socket"@}]@}@}'
qemu-system-x86_64 -drive driver=qcow2,file.driver=gluster,file.volume=testvol,file.path=/path/a.img, @value{qemu_system} -drive driver=qcow2,file.driver=gluster,file.volume=testvol,file.path=/path/a.img,
@ file.debug=9,file.logfile=/var/log/qemu-gluster.log, @ file.debug=9,file.logfile=/var/log/qemu-gluster.log,
@ file.server.0.type=tcp,file.server.0.host=1.2.3.4,file.server.0.port=24007, @ file.server.0.type=tcp,file.server.0.host=1.2.3.4,file.server.0.port=24007,
@ file.server.1.type=unix,file.server.1.socket=/var/run/glusterd.socket @ file.server.1.type=unix,file.server.1.socket=/var/run/glusterd.socket
@ -440,9 +444,9 @@ of <protocol>.
Example: boot from a remote Fedora 20 live ISO image Example: boot from a remote Fedora 20 live ISO image
@example @example
qemu-system-x86_64 --drive media=cdrom,file=http://dl.fedoraproject.org/pub/fedora/linux/releases/20/Live/x86_64/Fedora-Live-Desktop-x86_64-20-1.iso,readonly @value{qemu_system_x86} --drive media=cdrom,file=http://dl.fedoraproject.org/pub/fedora/linux/releases/20/Live/x86_64/Fedora-Live-Desktop-x86_64-20-1.iso,readonly
qemu-system-x86_64 --drive media=cdrom,file.driver=http,file.url=http://dl.fedoraproject.org/pub/fedora/linux/releases/20/Live/x86_64/Fedora-Live-Desktop-x86_64-20-1.iso,readonly @value{qemu_system_x86} --drive media=cdrom,file.driver=http,file.url=http://dl.fedoraproject.org/pub/fedora/linux/releases/20/Live/x86_64/Fedora-Live-Desktop-x86_64-20-1.iso,readonly
@end example @end example
Example: boot from a remote Fedora 20 cloud image using a local overlay for Example: boot from a remote Fedora 20 cloud image using a local overlay for
@ -450,7 +454,7 @@ writes, copy-on-read, and a readahead of 64k
@example @example
qemu-img create -f qcow2 -o backing_file='json:@{"file.driver":"http",, "file.url":"https://dl.fedoraproject.org/pub/fedora/linux/releases/20/Images/x86_64/Fedora-x86_64-20-20131211.1-sda.qcow2",, "file.readahead":"64k"@}' /tmp/Fedora-x86_64-20-20131211.1-sda.qcow2 qemu-img create -f qcow2 -o backing_file='json:@{"file.driver":"http",, "file.url":"https://dl.fedoraproject.org/pub/fedora/linux/releases/20/Images/x86_64/Fedora-x86_64-20-20131211.1-sda.qcow2",, "file.readahead":"64k"@}' /tmp/Fedora-x86_64-20-20131211.1-sda.qcow2
qemu-system-x86_64 -drive file=/tmp/Fedora-x86_64-20-20131211.1-sda.qcow2,copy-on-read=on @value{qemu_system_x86} -drive file=/tmp/Fedora-x86_64-20-20131211.1-sda.qcow2,copy-on-read=on
@end example @end example
Example: boot from an image stored on a VMware vSphere server with a self-signed Example: boot from an image stored on a VMware vSphere server with a self-signed
@ -459,7 +463,7 @@ of 10 seconds.
@example @example
qemu-img create -f qcow2 -o backing_file='json:@{"file.driver":"https",, "file.url":"https://user:password@@vsphere.example.com/folder/test/test-flat.vmdk?dcPath=Datacenter&dsName=datastore1",, "file.sslverify":"off",, "file.readahead":"64k",, "file.timeout":10@}' /tmp/test.qcow2 qemu-img create -f qcow2 -o backing_file='json:@{"file.driver":"https",, "file.url":"https://user:password@@vsphere.example.com/folder/test/test-flat.vmdk?dcPath=Datacenter&dsName=datastore1",, "file.sslverify":"off",, "file.readahead":"64k",, "file.timeout":10@}' /tmp/test.qcow2
qemu-system-x86_64 -drive file=/tmp/test.qcow2 @value{qemu_system_x86} -drive file=/tmp/test.qcow2
@end example @end example
@end table @end table
@ -826,7 +830,7 @@ On Linux hosts, a shared memory device is available. The basic syntax
is: is:
@example @example
qemu-system-x86_64 -device ivshmem-plain,memdev=@var{hostmem} @value{qemu_system_x86} -device ivshmem-plain,memdev=@var{hostmem}
@end example @end example
where @var{hostmem} names a host memory backend. For a POSIX shared where @var{hostmem} names a host memory backend. For a POSIX shared
@ -847,7 +851,7 @@ memory server is:
ivshmem-server -p @var{pidfile} -S @var{path} -m @var{shm-name} -l @var{shm-size} -n @var{vectors} ivshmem-server -p @var{pidfile} -S @var{path} -m @var{shm-name} -l @var{shm-size} -n @var{vectors}
# Then start your qemu instances with matching arguments # Then start your qemu instances with matching arguments
qemu-system-x86_64 -device ivshmem-doorbell,vectors=@var{vectors},chardev=@var{id} @value{qemu_system_x86} -device ivshmem-doorbell,vectors=@var{vectors},chardev=@var{id}
-chardev socket,path=@var{path},id=@var{id} -chardev socket,path=@var{path},id=@var{id}
@end example @end example
@ -872,7 +876,7 @@ Instead of specifying the <shm size> using POSIX shm, you may specify
a memory backend that has hugepage support: a memory backend that has hugepage support:
@example @example
qemu-system-x86_64 -object memory-backend-file,size=1G,mem-path=/dev/hugepages/my-shmem-file,share,id=mb1 @value{qemu_system_x86} -object memory-backend-file,size=1G,mem-path=/dev/hugepages/my-shmem-file,share,id=mb1
-device ivshmem-plain,memdev=mb1 -device ivshmem-plain,memdev=mb1
@end example @end example
@ -888,7 +892,7 @@ kernel testing.
The syntax is: The syntax is:
@example @example
qemu-system-i386 -kernel arch/i386/boot/bzImage -hda root-2.4.20.img -append "root=/dev/hda" @value{qemu_system} -kernel bzImage -hda rootdisk.img -append "root=/dev/hda"
@end example @end example
Use @option{-kernel} to provide the Linux kernel image and Use @option{-kernel} to provide the Linux kernel image and
@ -903,7 +907,7 @@ If you do not need graphical output, you can disable it and redirect
the virtual serial port and the QEMU monitor to the console with the the virtual serial port and the QEMU monitor to the console with the
@option{-nographic} option. The typical command line is: @option{-nographic} option. The typical command line is:
@example @example
qemu-system-i386 -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \ @value{qemu_system} -kernel bzImage -hda rootdisk.img \
-append "root=/dev/hda console=ttyS0" -nographic -append "root=/dev/hda console=ttyS0" -nographic
@end example @end example
@ -969,7 +973,7 @@ Network adapter that supports CDC ethernet and RNDIS protocols. @var{id}
specifies a netdev defined with @code{-netdev @dots{},id=@var{id}}. specifies a netdev defined with @code{-netdev @dots{},id=@var{id}}.
For instance, user-mode networking can be used with For instance, user-mode networking can be used with
@example @example
qemu-system-i386 [...] -netdev user,id=net0 -device usb-net,netdev=net0 @value{qemu_system} [...] -netdev user,id=net0 -device usb-net,netdev=net0
@end example @end example
@item usb-ccid @item usb-ccid
Smartcard reader device Smartcard reader device
@ -988,7 +992,7 @@ no type is given, the HCI logic corresponds to @code{-bt hci,vlan=0}.
This USB device implements the USB Transport Layer of HCI. Example This USB device implements the USB Transport Layer of HCI. Example
usage: usage:
@example @example
@command{qemu-system-i386} [...@var{OPTIONS}...] @option{-usbdevice} bt:hci,vlan=3 @option{-bt} device:keyboard,vlan=3 @command{@value{qemu_system}} [...@var{OPTIONS}...] @option{-usbdevice} bt:hci,vlan=3 @option{-bt} device:keyboard,vlan=3
@end example @end example
@end table @end table
@ -1065,7 +1069,7 @@ For this setup it is recommended to restrict it to listen on a UNIX domain
socket only. For example socket only. For example
@example @example
qemu-system-i386 [...OPTIONS...] -vnc unix:/home/joebloggs/.qemu-myvm-vnc @value{qemu_system} [...OPTIONS...] -vnc unix:/home/joebloggs/.qemu-myvm-vnc
@end example @end example
This ensures that only users on local box with read/write access to that This ensures that only users on local box with read/write access to that
@ -1088,7 +1092,7 @@ is running the password is set with the monitor. Until the monitor is used to
set the password all clients will be rejected. set the password all clients will be rejected.
@example @example
qemu-system-i386 [...OPTIONS...] -vnc :1,password -monitor stdio @value{qemu_system} [...OPTIONS...] -vnc :1,password -monitor stdio
(qemu) change vnc password (qemu) change vnc password
Password: ******** Password: ********
(qemu) (qemu)
@ -1105,7 +1109,7 @@ support provides a secure session, but no authentication. This allows any
client to connect, and provides an encrypted session. client to connect, and provides an encrypted session.
@example @example
qemu-system-i386 [...OPTIONS...] \ @value{qemu_system} [...OPTIONS...] \
-object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=no \ -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=no \
-vnc :1,tls-creds=tls0 -monitor stdio -vnc :1,tls-creds=tls0 -monitor stdio
@end example @end example
@ -1127,7 +1131,7 @@ same syntax as previously, but with @code{verify-peer} set to @code{yes}
instead. instead.
@example @example
qemu-system-i386 [...OPTIONS...] \ @value{qemu_system} [...OPTIONS...] \
-object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \ -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \
-vnc :1,tls-creds=tls0 -monitor stdio -vnc :1,tls-creds=tls0 -monitor stdio
@end example @end example
@ -1140,7 +1144,7 @@ Finally, the previous method can be combined with VNC password authentication
to provide two layers of authentication for clients. to provide two layers of authentication for clients.
@example @example
qemu-system-i386 [...OPTIONS...] \ @value{qemu_system} [...OPTIONS...] \
-object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \ -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \
-vnc :1,tls-creds=tls0,password -monitor stdio -vnc :1,tls-creds=tls0,password -monitor stdio
(qemu) change vnc password (qemu) change vnc password
@ -1165,7 +1169,7 @@ used for authentication, but assuming use of one supporting SSF,
then QEMU can be launched with: then QEMU can be launched with:
@example @example
qemu-system-i386 [...OPTIONS...] -vnc :1,sasl -monitor stdio @value{qemu_system} [...OPTIONS...] -vnc :1,sasl -monitor stdio
@end example @end example
@node vnc_sec_certificate_sasl @node vnc_sec_certificate_sasl
@ -1179,7 +1183,7 @@ credentials. This can be enabled, by combining the 'sasl' option
with the aforementioned TLS + x509 options: with the aforementioned TLS + x509 options:
@example @example
qemu-system-i386 [...OPTIONS...] \ @value{qemu_system} [...OPTIONS...] \
-object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \ -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \
-vnc :1,tls-creds=tls0,sasl -monitor stdio -vnc :1,tls-creds=tls0,sasl -monitor stdio
@end example @end example
@ -1512,13 +1516,13 @@ To load server credentials with client certificate validation
enabled enabled
@example @example
$QEMU -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server @value{qemu_system} -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=server
@end example @end example
while to load client credentials use while to load client credentials use
@example @example
$QEMU -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=client @value{qemu_system} -object tls-creds-x509,id=tls0,dir=/etc/pki/qemu,endpoint=client
@end example @end example
Network services which support TLS will all have a @code{tls-creds} Network services which support TLS will all have a @code{tls-creds}
@ -1526,7 +1530,7 @@ parameter which expects the ID of the TLS credentials object. For
example with VNC: example with VNC:
@example @example
$QEMU -vnc 0.0.0.0:0,tls-creds=tls0 @value{qemu_system} -vnc 0.0.0.0:0,tls-creds=tls0
@end example @end example
@node tls_psk @node tls_psk
@ -1574,8 +1578,7 @@ QEMU has a primitive support to work with gdb, so that you can do
In order to use gdb, launch QEMU with the '-s' option. It will wait for a In order to use gdb, launch QEMU with the '-s' option. It will wait for a
gdb connection: gdb connection:
@example @example
qemu-system-i386 -s -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \ @value{qemu_system} -s -kernel bzImage -hda rootdisk.img -append "root=/dev/hda"
-append "root=/dev/hda"
Connected to host network interface: tun0 Connected to host network interface: tun0
Waiting gdb connection on port 1234 Waiting gdb connection on port 1234
@end example @end example

128
qemu-options.hx
View File

@ -254,10 +254,10 @@ This option defines a free-form string that can be used to describe @var{fd}.
You can open an image using pre-opened file descriptors from an fd set: You can open an image using pre-opened file descriptors from an fd set:
@example @example
qemu-system-i386 @value{qemu_system} \
-add-fd fd=3,set=2,opaque="rdwr:/path/to/file" -add-fd fd=3,set=2,opaque="rdwr:/path/to/file" \
-add-fd fd=4,set=2,opaque="rdonly:/path/to/file" -add-fd fd=4,set=2,opaque="rdonly:/path/to/file" \
-drive file=/dev/fdset/2,index=0,media=disk -drive file=/dev/fdset/2,index=0,media=disk
@end example @end example
ETEXI ETEXI
@ -283,7 +283,7 @@ STEXI
Set default value of @var{driver}'s property @var{prop} to @var{value}, e.g.: Set default value of @var{driver}'s property @var{prop} to @var{value}, e.g.:
@example @example
qemu-system-i386 -global ide-hd.physical_block_size=4096 disk-image.img @value{qemu_system_x86} -global ide-hd.physical_block_size=4096 disk-image.img
@end example @end example
In particular, you can use this to set driver properties for devices which are In particular, you can use this to set driver properties for devices which are
@ -337,11 +337,11 @@ bootindex options. The default is non-strict boot.
@example @example
# try to boot from network first, then from hard disk # try to boot from network first, then from hard disk
qemu-system-i386 -boot order=nc @value{qemu_system_x86} -boot order=nc
# boot from CD-ROM first, switch back to default order after reboot # boot from CD-ROM first, switch back to default order after reboot
qemu-system-i386 -boot once=d @value{qemu_system_x86} -boot once=d
# boot with a splash picture for 5 seconds. # boot with a splash picture for 5 seconds.
qemu-system-i386 -boot menu=on,splash=/root/boot.bmp,splash-time=5000 @value{qemu_system_x86} -boot menu=on,splash=/root/boot.bmp,splash-time=5000
@end example @end example
Note: The legacy format '-boot @var{drives}' is still supported but its Note: The legacy format '-boot @var{drives}' is still supported but its
@ -370,7 +370,7 @@ For example, the following command-line sets the guest startup RAM size to
memory the guest can reach to 4GB: memory the guest can reach to 4GB:
@example @example
qemu-system-x86_64 -m 1G,slots=3,maxmem=4G @value{qemu_system} -m 1G,slots=3,maxmem=4G
@end example @end example
If @var{slots} and @var{maxmem} are not specified, memory hotplug won't If @var{slots} and @var{maxmem} are not specified, memory hotplug won't
@ -666,15 +666,15 @@ STEXI
@item -soundhw @var{card1}[,@var{card2},...] or -soundhw all @item -soundhw @var{card1}[,@var{card2},...] or -soundhw all
@findex -soundhw @findex -soundhw
Enable audio and selected sound hardware. Use 'help' to print all Enable audio and selected sound hardware. Use 'help' to print all
available sound hardware. available sound hardware. For example:
@example @example
qemu-system-i386 -soundhw sb16,adlib disk.img @value{qemu_system_x86} -soundhw sb16,adlib disk.img
qemu-system-i386 -soundhw es1370 disk.img @value{qemu_system_x86} -soundhw es1370 disk.img
qemu-system-i386 -soundhw ac97 disk.img @value{qemu_system_x86} -soundhw ac97 disk.img
qemu-system-i386 -soundhw hda disk.img @value{qemu_system_x86} -soundhw hda disk.img
qemu-system-i386 -soundhw all disk.img @value{qemu_system_x86} -soundhw all disk.img
qemu-system-i386 -soundhw help @value{qemu_system_x86} -soundhw help
@end example @end example
Note that Linux's i810_audio OSS kernel (for AC97) module might Note that Linux's i810_audio OSS kernel (for AC97) module might
@ -1149,50 +1149,50 @@ is off.
Instead of @option{-cdrom} you can use: Instead of @option{-cdrom} you can use:
@example @example
qemu-system-i386 -drive file=file,index=2,media=cdrom @value{qemu_system} -drive file=file,index=2,media=cdrom
@end example @end example
Instead of @option{-hda}, @option{-hdb}, @option{-hdc}, @option{-hdd}, you can Instead of @option{-hda}, @option{-hdb}, @option{-hdc}, @option{-hdd}, you can
use: use:
@example @example
qemu-system-i386 -drive file=file,index=0,media=disk @value{qemu_system} -drive file=file,index=0,media=disk
qemu-system-i386 -drive file=file,index=1,media=disk @value{qemu_system} -drive file=file,index=1,media=disk
qemu-system-i386 -drive file=file,index=2,media=disk @value{qemu_system} -drive file=file,index=2,media=disk
qemu-system-i386 -drive file=file,index=3,media=disk @value{qemu_system} -drive file=file,index=3,media=disk
@end example @end example
You can open an image using pre-opened file descriptors from an fd set: You can open an image using pre-opened file descriptors from an fd set:
@example @example
qemu-system-i386 @value{qemu_system} \
-add-fd fd=3,set=2,opaque="rdwr:/path/to/file" -add-fd fd=3,set=2,opaque="rdwr:/path/to/file" \
-add-fd fd=4,set=2,opaque="rdonly:/path/to/file" -add-fd fd=4,set=2,opaque="rdonly:/path/to/file" \
-drive file=/dev/fdset/2,index=0,media=disk -drive file=/dev/fdset/2,index=0,media=disk
@end example @end example
You can connect a CDROM to the slave of ide0: You can connect a CDROM to the slave of ide0:
@example @example
qemu-system-i386 -drive file=file,if=ide,index=1,media=cdrom @value{qemu_system_x86} -drive file=file,if=ide,index=1,media=cdrom
@end example @end example
If you don't specify the "file=" argument, you define an empty drive: If you don't specify the "file=" argument, you define an empty drive:
@example @example
qemu-system-i386 -drive if=ide,index=1,media=cdrom @value{qemu_system_x86} -drive if=ide,index=1,media=cdrom
@end example @end example
Instead of @option{-fda}, @option{-fdb}, you can use: Instead of @option{-fda}, @option{-fdb}, you can use:
@example @example
qemu-system-i386 -drive file=file,index=0,if=floppy @value{qemu_system_x86} -drive file=file,index=0,if=floppy
qemu-system-i386 -drive file=file,index=1,if=floppy @value{qemu_system_x86} -drive file=file,index=1,if=floppy
@end example @end example
By default, @var{interface} is "ide" and @var{index} is automatically By default, @var{interface} is "ide" and @var{index} is automatically
incremented: incremented:
@example @example
qemu-system-i386 -drive file=a -drive file=b" @value{qemu_system_x86} -drive file=a -drive file=b"
@end example @end example
is interpreted like: is interpreted like:
@example @example
qemu-system-i386 -hda a -hdb b @value{qemu_system_x86} -hda a -hdb b
@end example @end example
ETEXI ETEXI
@ -2272,8 +2272,8 @@ The following two example do exactly the same, to show how @option{-nic} can
be used to shorten the command line length (note that the e1000 is the default be used to shorten the command line length (note that the e1000 is the default
on i386, so the @option{model=e1000} parameter could even be omitted here, too): on i386, so the @option{model=e1000} parameter could even be omitted here, too):
@example @example
qemu-system-i386 -netdev user,id=n1,ipv6=off -device e1000,netdev=n1,mac=52:54:98:76:54:32 @value{qemu_system} -netdev user,id=n1,ipv6=off -device e1000,netdev=n1,mac=52:54:98:76:54:32
qemu-system-i386 -nic user,ipv6=off,model=e1000,mac=52:54:98:76:54:32 @value{qemu_system} -nic user,ipv6=off,model=e1000,mac=52:54:98:76:54:32
@end example @end example
@item -nic none @item -nic none
@ -2344,7 +2344,7 @@ can not be resolved.
Example: Example:
@example @example
qemu-system-i386 -nic user,dnssearch=mgmt.example.org,dnssearch=example.org @value{qemu_system} -nic user,dnssearch=mgmt.example.org,dnssearch=example.org
@end example @end example
@item domainname=@var{domain} @item domainname=@var{domain}
@ -2368,7 +2368,7 @@ a guest from a local directory.
Example (using pxelinux): Example (using pxelinux):
@example @example
qemu-system-i386 -hda linux.img -boot n -device e1000,netdev=n1 \ @value{qemu_system} -hda linux.img -boot n -device e1000,netdev=n1 \
-netdev user,id=n1,tftp=/path/to/tftp/files,bootfile=/pxelinux.0 -netdev user,id=n1,tftp=/path/to/tftp/files,bootfile=/pxelinux.0
@end example @end example
@ -2402,7 +2402,7 @@ screen 0, use the following:
@example @example
# on the host # on the host
qemu-system-i386 -nic user,hostfwd=tcp:127.0.0.1:6001-:6000 @value{qemu_system} -nic user,hostfwd=tcp:127.0.0.1:6001-:6000
# this host xterm should open in the guest X11 server # this host xterm should open in the guest X11 server
xterm -display :1 xterm -display :1
@end example @end example
@ -2412,7 +2412,7 @@ the guest, use the following:
@example @example
# on the host # on the host
qemu-system-i386 -nic user,hostfwd=tcp::5555-:23 @value{qemu_system} -nic user,hostfwd=tcp::5555-:23
telnet localhost 5555 telnet localhost 5555
@end example @end example
@ -2431,7 +2431,7 @@ lifetime, like in the following example:
@example @example
# open 10.10.1.1:4321 on bootup, connect 10.0.2.100:1234 to it whenever # open 10.10.1.1:4321 on bootup, connect 10.0.2.100:1234 to it whenever
# the guest accesses it # the guest accesses it
qemu-system-i386 -nic user,guestfwd=tcp:10.0.2.100:1234-tcp:10.10.1.1:4321 @value{qemu_system} -nic user,guestfwd=tcp:10.0.2.100:1234-tcp:10.10.1.1:4321
@end example @end example
Or you can execute a command on every TCP connection established by the guest, Or you can execute a command on every TCP connection established by the guest,
@ -2440,7 +2440,7 @@ so that QEMU behaves similar to an inetd process for that virtual server:
@example @example
# call "netcat 10.10.1.1 4321" on every TCP connection to 10.0.2.100:1234 # call "netcat 10.10.1.1 4321" on every TCP connection to 10.0.2.100:1234
# and connect the TCP stream to its stdin/stdout # and connect the TCP stream to its stdin/stdout
qemu-system-i386 -nic 'user,id=n1,guestfwd=tcp:10.0.2.100:1234-cmd:netcat 10.10.1.1 4321' @value{qemu_system} -nic 'user,id=n1,guestfwd=tcp:10.0.2.100:1234-cmd:netcat 10.10.1.1 4321'
@end example @end example
@end table @end table
@ -2467,13 +2467,13 @@ Examples:
@example @example
#launch a QEMU instance with the default network script #launch a QEMU instance with the default network script
qemu-system-i386 linux.img -nic tap @value{qemu_system} linux.img -nic tap
@end example @end example
@example @example
#launch a QEMU instance with two NICs, each one connected #launch a QEMU instance with two NICs, each one connected
#to a TAP device #to a TAP device
qemu-system-i386 linux.img \ @value{qemu_system} linux.img \
-netdev tap,id=nd0,ifname=tap0 -device e1000,netdev=nd0 \ -netdev tap,id=nd0,ifname=tap0 -device e1000,netdev=nd0 \
-netdev tap,id=nd1,ifname=tap1 -device rtl8139,netdev=nd1 -netdev tap,id=nd1,ifname=tap1 -device rtl8139,netdev=nd1
@end example @end example
@ -2481,7 +2481,7 @@ qemu-system-i386 linux.img \
@example @example
#launch a QEMU instance with the default network helper to #launch a QEMU instance with the default network helper to
#connect a TAP device to bridge br0 #connect a TAP device to bridge br0
qemu-system-i386 linux.img -device virtio-net-pci,netdev=n1 \ @value{qemu_system} linux.img -device virtio-net-pci,netdev=n1 \
-netdev tap,id=n1,"helper=/path/to/qemu-bridge-helper" -netdev tap,id=n1,"helper=/path/to/qemu-bridge-helper"
@end example @end example
@ -2498,13 +2498,13 @@ Examples:
@example @example
#launch a QEMU instance with the default network helper to #launch a QEMU instance with the default network helper to
#connect a TAP device to bridge br0 #connect a TAP device to bridge br0
qemu-system-i386 linux.img -netdev bridge,id=n1 -device virtio-net,netdev=n1 @value{qemu_system} linux.img -netdev bridge,id=n1 -device virtio-net,netdev=n1
@end example @end example
@example @example
#launch a QEMU instance with the default network helper to #launch a QEMU instance with the default network helper to
#connect a TAP device to bridge qemubr0 #connect a TAP device to bridge qemubr0
qemu-system-i386 linux.img -netdev bridge,br=qemubr0,id=n1 -device virtio-net,netdev=n1 @value{qemu_system} linux.img -netdev bridge,br=qemubr0,id=n1 -device virtio-net,netdev=n1
@end example @end example
@item -netdev socket,id=@var{id}[,fd=@var{h}][,listen=[@var{host}]:@var{port}][,connect=@var{host}:@var{port}] @item -netdev socket,id=@var{id}[,fd=@var{h}][,listen=[@var{host}]:@var{port}][,connect=@var{host}:@var{port}]
@ -2519,11 +2519,11 @@ specifies an already opened TCP socket.
Example: Example:
@example @example
# launch a first QEMU instance # launch a first QEMU instance
qemu-system-i386 linux.img \ @value{qemu_system} linux.img \
-device e1000,netdev=n1,mac=52:54:00:12:34:56 \ -device e1000,netdev=n1,mac=52:54:00:12:34:56 \
-netdev socket,id=n1,listen=:1234 -netdev socket,id=n1,listen=:1234
# connect the network of this instance to the network of the first instance # connect the network of this instance to the network of the first instance
qemu-system-i386 linux.img \ @value{qemu_system} linux.img \
-device e1000,netdev=n2,mac=52:54:00:12:34:57 \ -device e1000,netdev=n2,mac=52:54:00:12:34:57 \
-netdev socket,id=n2,connect=127.0.0.1:1234 -netdev socket,id=n2,connect=127.0.0.1:1234
@end example @end example
@ -2548,15 +2548,15 @@ Use @option{fd=h} to specify an already opened UDP multicast socket.
Example: Example:
@example @example
# launch one QEMU instance # launch one QEMU instance
qemu-system-i386 linux.img \ @value{qemu_system} linux.img \
-device e1000,netdev=n1,mac=52:54:00:12:34:56 \ -device e1000,netdev=n1,mac=52:54:00:12:34:56 \
-netdev socket,id=n1,mcast=230.0.0.1:1234 -netdev socket,id=n1,mcast=230.0.0.1:1234
# launch another QEMU instance on same "bus" # launch another QEMU instance on same "bus"
qemu-system-i386 linux.img \ @value{qemu_system} linux.img \
-device e1000,netdev=n2,mac=52:54:00:12:34:57 \ -device e1000,netdev=n2,mac=52:54:00:12:34:57 \
-netdev socket,id=n2,mcast=230.0.0.1:1234 -netdev socket,id=n2,mcast=230.0.0.1:1234
# launch yet another QEMU instance on same "bus" # launch yet another QEMU instance on same "bus"
qemu-system-i386 linux.img \ @value{qemu_system} linux.img \
-device e1000,netdev=n3,mac=52:54:00:12:34:58 \ -device e1000,netdev=n3,mac=52:54:00:12:34:58 \
-netdev socket,id=n3,mcast=230.0.0.1:1234 -netdev socket,id=n3,mcast=230.0.0.1:1234
@end example @end example
@ -2564,7 +2564,7 @@ qemu-system-i386 linux.img \
Example (User Mode Linux compat.): Example (User Mode Linux compat.):
@example @example
# launch QEMU instance (note mcast address selected is UML's default) # launch QEMU instance (note mcast address selected is UML's default)
qemu-system-i386 linux.img \ @value{qemu_system} linux.img \
-device e1000,netdev=n1,mac=52:54:00:12:34:56 \ -device e1000,netdev=n1,mac=52:54:00:12:34:56 \
-netdev socket,id=n1,mcast=239.192.168.1:1102 -netdev socket,id=n1,mcast=239.192.168.1:1102
# launch UML # launch UML
@ -2573,7 +2573,7 @@ qemu-system-i386 linux.img \
Example (send packets from host's 1.2.3.4): Example (send packets from host's 1.2.3.4):
@example @example
qemu-system-i386 linux.img \ @value{qemu_system} linux.img \
-device e1000,netdev=n1,mac=52:54:00:12:34:56 \ -device e1000,netdev=n1,mac=52:54:00:12:34:56 \
-netdev socket,id=n1,mcast=239.192.168.1:1102,localaddr=1.2.3.4 -netdev socket,id=n1,mcast=239.192.168.1:1102,localaddr=1.2.3.4
@end example @end example
@ -2633,7 +2633,7 @@ brctl addif br-lan vmtunnel0
# on 4.3.2.1 # on 4.3.2.1
# launch QEMU instance - if your network has reorder or is very lossy add ,pincounter # launch QEMU instance - if your network has reorder or is very lossy add ,pincounter
qemu-system-i386 linux.img -device e1000,netdev=n1 \ @value{qemu_system} linux.img -device e1000,netdev=n1 \
-netdev l2tpv3,id=n1,src=4.2.3.1,dst=1.2.3.4,udp,srcport=16384,dstport=16384,rxsession=0xffffffff,txsession=0xffffffff,counter -netdev l2tpv3,id=n1,src=4.2.3.1,dst=1.2.3.4,udp,srcport=16384,dstport=16384,rxsession=0xffffffff,txsession=0xffffffff,counter
@end example @end example
@ -2650,7 +2650,7 @@ Example:
# launch vde switch # launch vde switch
vde_switch -F -sock /tmp/myswitch vde_switch -F -sock /tmp/myswitch
# launch QEMU instance # launch QEMU instance
qemu-system-i386 linux.img -nic vde,sock=/tmp/myswitch @value{qemu_system} linux.img -nic vde,sock=/tmp/myswitch
@end example @end example
@item -netdev vhost-user,chardev=@var{id}[,vhostforce=on|off][,queues=n] @item -netdev vhost-user,chardev=@var{id}[,vhostforce=on|off][,queues=n]
@ -3107,7 +3107,7 @@ and communicate. Requires the Linux @code{vhci} driver installed. Can
be used as following: be used as following:
@example @example
qemu-system-i386 [...OPTIONS...] -bt hci,vlan=5 -bt vhci,vlan=5 @value{qemu_system} [...OPTIONS...] -bt hci,vlan=5 -bt vhci,vlan=5
@end example @end example
@item -bt device:@var{dev}[,vlan=@var{n}] @item -bt device:@var{dev}[,vlan=@var{n}]
@ -3601,7 +3601,7 @@ connections will likely be TCP-based, but also UDP, pseudo TTY, or even
stdio are reasonable use case. The latter is allowing to start QEMU from stdio are reasonable use case. The latter is allowing to start QEMU from
within gdb and establish the connection via a pipe: within gdb and establish the connection via a pipe:
@example @example
(gdb) target remote | exec qemu-system-i386 -gdb stdio ... (gdb) target remote | exec @value{qemu_system} -gdb stdio ...
@end example @end example
ETEXI ETEXI
@ -4578,7 +4578,7 @@ which specify the queue number of cryptodev backend, the default of
@example @example
# qemu-system-x86_64 \ # @value{qemu_system} \
[...] \ [...] \
-object cryptodev-backend-builtin,id=cryptodev0 \ -object cryptodev-backend-builtin,id=cryptodev0 \
-device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \ -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \
@ -4598,7 +4598,7 @@ of cryptodev backend for multiqueue vhost-user, the default of @var{queues} is 1
@example @example
# qemu-system-x86_64 \ # @value{qemu_system} \
[...] \ [...] \
-chardev socket,id=chardev0,path=/path/to/socket \ -chardev socket,id=chardev0,path=/path/to/socket \
-object cryptodev-vhost-user,id=cryptodev0,chardev=chardev0 \ -object cryptodev-vhost-user,id=cryptodev0,chardev=chardev0 \
@ -4634,14 +4634,14 @@ The simplest (insecure) usage is to provide the secret inline
@example @example
# $QEMU -object secret,id=sec0,data=letmein,format=raw # @value{qemu_system} -object secret,id=sec0,data=letmein,format=raw
@end example @end example
The simplest secure usage is to provide the secret via a file The simplest secure usage is to provide the secret via a file
# printf "letmein" > mypasswd.txt # printf "letmein" > mypasswd.txt
# $QEMU -object secret,id=sec0,file=mypasswd.txt,format=raw # @value{qemu_system} -object secret,id=sec0,file=mypasswd.txt,format=raw
For greater security, AES-256-CBC should be used. To illustrate usage, For greater security, AES-256-CBC should be used. To illustrate usage,
consider the openssl command line tool which can encrypt the data. Note consider the openssl command line tool which can encrypt the data. Note
@ -4677,7 +4677,7 @@ and specify that to be used to decrypt the user password. Pass the
contents of @code{iv.b64} to the second secret contents of @code{iv.b64} to the second secret
@example @example
# $QEMU \ # @value{qemu_system} \
-object secret,id=secmaster0,format=base64,file=key.b64 \ -object secret,id=secmaster0,format=base64,file=key.b64 \
-object secret,id=sec0,keyid=secmaster0,format=base64,\ -object secret,id=sec0,keyid=secmaster0,format=base64,\
data=$SECRET,iv=$(<iv.b64) data=$SECRET,iv=$(<iv.b64)
@ -4720,7 +4720,7 @@ negotiate keys used for attestation. The file must be encoded in base64.
e.g to launch a SEV guest e.g to launch a SEV guest
@example @example
# $QEMU \ # @value{qemu_system_x86} \
...... ......
-object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=5 \ -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=5 \
-machine ...,memory-encryption=sev0 -machine ...,memory-encryption=sev0
@ -4742,7 +4742,7 @@ any commas in the distinguished name.
An example authorization object to validate a x509 distinguished name An example authorization object to validate a x509 distinguished name
would look like: would look like:
@example @example
# $QEMU \ # @value{qemu_system} \
... ...
-object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,O=Example Org,,L=London,,ST=London,,C=GB' \ -object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,O=Example Org,,L=London,,ST=London,,C=GB' \
... ...
@ -4791,7 +4791,7 @@ a TLS x509 distinguished name, or a SASL username.
An example authorization object to validate a SASL username An example authorization object to validate a SASL username
would look like: would look like:
@example @example
# $QEMU \ # @value{qemu_system} \
... ...
-object authz-simple,id=auth0,filename=/etc/qemu/vnc-sasl.acl,refresh=yes -object authz-simple,id=auth0,filename=/etc/qemu/vnc-sasl.acl,refresh=yes
... ...
@ -4809,7 +4809,7 @@ An example authorization object to validate a TLS x509 distinguished
name would look like: name would look like:
@example @example
# $QEMU \ # @value{qemu_system} \
... ...
-object authz-pam,id=auth0,service=qemu-vnc -object authz-pam,id=auth0,service=qemu-vnc
... ...