ETEXI
SRST
-``-numa node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=initiator]``; \ ``-numa node[,memdev=id][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=initiator]``; \ ``-numa dist,src=source,dst=destination,val=distance``; \ ``-numa cpu,node-id=node[,socket-id=x][,core-id=y][,thread-id=z]``; \ ``-numa hmat-lb,initiator=node,target=node,hierarchy=hierarchy,data-type=tpye[,latency=lat][,bandwidth=bw]``; \ ``-numa hmat-cache,node-id=node,size=size,level=level[,associativity=str][,policy=str][,line=size]``
+``-numa node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=initiator]``
+ \
+``-numa node[,memdev=id][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=initiator]``
+ \
+``-numa dist,src=source,dst=destination,val=distance``
+ \
+``-numa cpu,node-id=node[,socket-id=x][,core-id=y][,thread-id=z]``
+ \
+``-numa hmat-lb,initiator=node,target=node,hierarchy=hierarchy,data-type=tpye[,latency=lat][,bandwidth=bw]``
+ \
+``-numa hmat-cache,node-id=node,size=size,level=level[,associativity=str][,policy=str][,line=size]``
Define a NUMA node and assign RAM and VCPUs to it. Set the NUMA
distance from a source node to a destination node. Set the ACPI
Heterogeneous Memory Attributes for the given nodes.
longhand syntax works even when @var{driver} contains a dot.
ETEXI
SRST
-``-global driver.prop=value``; \ ``-global driver=driver,property=property,value=value``
+``-global driver.prop=value``
+ \
+``-global driver=driver,property=property,value=value``
Set default value of driver's property prop to value, e.g.:
.. parsed-literal::
it. This only effects when boot priority is changed by bootindex
options. The default is non-strict boot.
- ::
+ .. parsed-literal::
# try to boot from network first, then from hard disk
|qemu_system_x86| -boot order=nc
Use @var{file} as floppy disk 0/1 image (@pxref{disk_images}).
ETEXI
SRST
-``-fda file``; \ ``-fdb file``
+``-fda file``
+ \
+``-fdb file``
Use file as floppy disk 0/1 image (see
:ref:`disk_005fimages`).
ERST
Use @var{file} as hard disk 0, 1, 2 or 3 image (@pxref{disk_images}).
ETEXI
SRST
-``-hda file``; \ ``-hdb file``; \ ``-hdc file``; \ ``-hdd file``
+``-hda file``
+ \
+``-hdb file``
+ \
+``-hdc file``
+ \
+``-hdd file``
Use file as hard disk 0, 1, 2 or 3 image (see
:ref:`disk_005fimages`).
ERST
the ``write-cache`` option of block guest devices (as in
``-device``). The modes correspond to the following settings:
- ::
-
- â\94\82 cache.writeback cache.direct cache.no-flush
- ─────────────┼─────────────────────────────────────────────────
- writeback │ on off off
- none │ on on off
- writethrough │ off off off
- directsync │ off on off
- unsafe │ on off on
+ ============= =============== ============ ==============
+ \ cache.writeback cache.direct cache.no-flush
+ ============= =============== ============ ==============
+ writeback on off off
+ none on on off
+ writethrough off off off
+ directsync off on off
+ unsafe on off on
+ ============= =============== ============ ==============
The default mode is ``cache=writeback``.
ETEXI
SRST
-``-fsdev local,id=id,path=path,security_model=security_model [,writeout=writeout][,readonly][,fmode=fmode][,dmode=dmode] [,throttling.option=value[,throttling.option=value[,...]]]``; \ ``-fsdev proxy,id=id,socket=socket[,writeout=writeout][,readonly]``; \ ``-fsdev proxy,id=id,sock_fd=sock_fd[,writeout=writeout][,readonly]``; \ ``-fsdev synth,id=id[,readonly]``
+``-fsdev local,id=id,path=path,security_model=security_model [,writeout=writeout][,readonly][,fmode=fmode][,dmode=dmode] [,throttling.option=value[,throttling.option=value[,...]]]``
+ \
+``-fsdev proxy,id=id,socket=socket[,writeout=writeout][,readonly]``
+ \
+``-fsdev proxy,id=id,sock_fd=sock_fd[,writeout=writeout][,readonly]``
+ \
+``-fsdev synth,id=id[,readonly]``
Define a new file system device. Valid options are:
``local``
@end table
ETEXI
SRST
-``-virtfs local,path=path,mount_tag=mount_tag ,security_model=security_model[,writeout=writeout][,readonly] [,fmode=fmode][,dmode=dmode][,multidevs=multidevs]``; \ ``-virtfs proxy,socket=socket,mount_tag=mount_tag [,writeout=writeout][,readonly]``; \ ``-virtfs proxy,sock_fd=sock_fd,mount_tag=mount_tag [,writeout=writeout][,readonly]``; \ ``-virtfs synth,mount_tag=mount_tag``
+``-virtfs local,path=path,mount_tag=mount_tag ,security_model=security_model[,writeout=writeout][,readonly] [,fmode=fmode][,dmode=dmode][,multidevs=multidevs]``
+ \
+``-virtfs proxy,socket=socket,mount_tag=mount_tag [,writeout=writeout][,readonly]``
+ \
+``-virtfs proxy,sock_fd=sock_fd,mount_tag=mount_tag [,writeout=writeout][,readonly]``
+ \
+``-virtfs synth,mount_tag=mount_tag``
Define a new filesystem device and expose it to the guest using a
virtio-9p-device. The general form of a Virtual File system
pass-through options are:
ETEXI
SRST
-``-g widthxheight[xdepth]``
+``-g`` *width*\ ``x``\ *height*\ ``[x``\ *depth*\ ``]``
Set the initial graphical resolution and depth (PPC, SPARC only).
For PPC the default is 800x600x32.
For example, to redirect host X11 connection from screen 1 to
guest screen 0, use the following:
- ::
+ .. parsed-literal::
# on the host
|qemu_system| -nic user,hostfwd=tcp:127.0.0.1:6001-:6000
To redirect telnet connections from host port 5555 to telnet
port on the guest, use the following:
- ::
+ .. parsed-literal::
# on the host
|qemu_system| -nic user,hostfwd=tcp::5555-:23
You can either use a chardev directly and have that one used
throughout QEMU's lifetime, like in the following example:
- ::
+ .. parsed-literal::
# open 10.10.1.1:4321 on bootup, connect 10.0.2.100:1234 to it whenever
# the guest accesses it
by the guest, so that QEMU behaves similar to an inetd process
for that virtual server:
- ::
+ .. parsed-literal::
# 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
Examples:
- ::
+ .. parsed-literal::
#launch a QEMU instance with the default network script
|qemu_system| linux.img -nic tap
- ::
+ .. parsed-literal::
#launch a QEMU instance with two NICs, each one connected
#to a TAP device
-netdev tap,id=nd0,ifname=tap0 -device e1000,netdev=nd0 \
-netdev tap,id=nd1,ifname=tap1 -device rtl8139,netdev=nd1
- ::
+ .. parsed-literal::
#launch a QEMU instance with the default network helper to
#connect a TAP device to bridge br0
Examples:
- ::
+ .. parsed-literal::
#launch a QEMU instance with the default network helper to
#connect a TAP device to bridge br0
|qemu_system| linux.img -netdev bridge,id=n1 -device virtio-net,netdev=n1
- ::
+ .. parsed-literal::
#launch a QEMU instance with the default network helper to
#connect a TAP device to bridge qemubr0
Example:
- ::
+ .. parsed-literal::
# launch a first QEMU instance
|qemu_system| linux.img \
Example:
- ::
+ .. parsed-literal::
# launch one QEMU instance
|qemu_system| linux.img \
Example (User Mode Linux compat.):
- ::
+ .. parsed-literal::
# launch QEMU instance (note mcast address selected is UML's default)
|qemu_system| linux.img \
For example, to attach a VM running on host 4.3.2.1 via L2TPv3 to
the bridge br-lan on the remote Linux host 1.2.3.4:
- ::
+ .. parsed-literal::
# Setup tunnel on linux host using raw ip as encapsulation
# on 1.2.3.4
Example:
- ::
+ .. parsed-literal::
# launch vde switch
vde_switch -F -sock /tmp/myswitch
``path`` specifies the path to the tty. ``path`` is required.
-``-chardev parallel,id=id,path=path``; \ ``-chardev parport,id=id,path=path``
+``-chardev parallel,id=id,path=path``
+ \
+``-chardev parport,id=id,path=path``
``parallel`` is only available on Linux, FreeBSD and DragonFlyBSD
hosts.
ETEXI
SRST
``-overcommit mem-lock=on|off``
+ \
``-overcommit cpu-pm=on|off``
Run qemu with hints about host resource overcommit. The default is
to assume that host overcommits all resources.
use case. The latter is allowing to start QEMU from within gdb and
establish the connection via a pipe:
- ::
+ .. parsed-literal::
(gdb) target remote | exec |qemu_system| -gdb stdio ...
ERST
the migrate_incoming to allow the migration to begin.
ETEXI
SRST
-``-incoming tcp:[host]:port[,to=maxport][,ipv4][,ipv6]``; \ ``-incoming rdma:host:port[,ipv4][,ipv6]``
+``-incoming tcp:[host]:port[,to=maxport][,ipv4][,ipv6]``
+ \
+``-incoming rdma:host:port[,ipv4][,ipv6]``
Prepare for incoming migration, listen on a given tcp port.
``-incoming unix:socketpath``
ETEXI
SRST
``-trace [[enable=]pattern][,events=file][,file=file]``
- Specify tracing options.
+ .. include:: ../qemu-option-trace.rst.inc
- ``[enable=]pattern``
- Immediately enable events matching pattern (either event name or
- a globbing pattern). This option is only available if QEMU has
- been compiled with the simple, log or ftrace tracing backend. To
- specify multiple events or patterns, specify the ``-trace``
- option multiple times.
-
- Use ``-trace help`` to print a list of names of trace points.
-
- ``events=file``
- Immediately enable events listed in file. The file must contain
- one event name (as listed in the ``trace-events-all`` file) per
- line; globbing patterns are accepted too. This option is only
- available if QEMU has been compiled with the simple, log or
- ftrace tracing backend.
-
- ``file=file``
- Log output traces to file. This option is only available if QEMU
- has been compiled with the simple tracing backend.
ERST
DEF("plugin", HAS_ARG, QEMU_OPTION_plugin,
"-plugin [file=]<file>[,arg=<string>]\n"
which specify the queue number of cryptodev backend, the default
of queues is 1.
- ::
+ .. parsed-literal::
# |qemu_system| \
[...] \
specify the queue number of cryptodev backend for multiqueue
vhost-user, the default of queues is 1.
- ::
+ .. parsed-literal::
# |qemu_system| \
[...] \
[...]
``-object secret,id=id,data=string,format=raw|base64[,keyid=secretid,iv=string]``
+ \
``-object secret,id=id,file=filename,format=raw|base64[,keyid=secretid,iv=string]``
Defines a secret to store a password, encryption key, or some
other sensitive data. The sensitive data can either be passed
The simplest (insecure) usage is to provide the secret inline
- ::
+ .. parsed-literal::
# |qemu_system| -object secret,id=sec0,data=letmein,format=raw
``key.b64`` and specify that to be used to decrypt the user
password. Pass the contents of ``iv.b64`` to the second secret
- ::
+ .. parsed-literal::
# |qemu_system| \
-object secret,id=secmaster0,format=base64,file=key.b64 \
e.g to launch a SEV guest
- ::
+ .. parsed-literal::
# |qemu_system_x86| \
......
An example authorization object to validate a x509 distinguished
name would look like:
- ::
+ .. parsed-literal::
# |qemu_system| \
...
An example authorization object to validate a SASL username
would look like:
- ::
+ .. parsed-literal::
# |qemu_system| \
...
An example authorization object to validate a TLS x509
distinguished name would look like:
- ::
+ .. parsed-literal::
# |qemu_system| \
...
projects / qemu.git / commitdiff