cryptospore / rpms / qemu-kvm

Forked from rpms/qemu-kvm 2 years ago
Clone
Blob Blame History Raw
From 1c2dac56d5e710faebe25b7aa9cac594ec0f9d4b Mon Sep 17 00:00:00 2001
From: Miroslav Rezanina <mrezanin@redhat.com>
Date: Fri, 14 Nov 2014 08:51:50 +0100
Subject: Use qemu-kvm in documentation instead of qemu-system-i386

Patchwork-id: 62380
O-Subject: [RHEV-7.1 qemu-kvm-rhev PATCHv4] Use qemu-kvm in documentation instead of qemu-system-i386
Bugzilla: 1140620
RH-Acked-by: Laszlo Ersek <lersek@redhat.com>
RH-Acked-by: Markus Armbruster <armbru@redhat.com>
RH-Acked-by: Stefan Hajnoczi <stefanha@redhat.com>

From: Miroslav Rezanina <mrezanin@redhat.com>

We change the name and location of qemu-kvm binaries. Update documentation
to reflect this change.

Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
(cherry picked from commit acd13dd2a1ddce4de705587bc90a07939e7b3d7f)

Rebase Notes (2.9.0):
- fixed chunks missed on 2.8 rebase

(cherry picked from commit c4a72f98eb8bbc3237e23725413dea0e23d7b88a)
---
 qemu-doc.texi   | 110 ++++++++++++++++++++---------------------
 qemu-options.hx | 148 ++++++++++++++++++++++++++++----------------------------
 2 files changed, 129 insertions(+), 129 deletions(-)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index 794ab4a..8a3d7d4 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -199,12 +199,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.
 
 @example
-qemu-system-i386 dos.img -soundhw gus -parallel none
+qemu-kvm dos.img -soundhw gus -parallel none
 @end example
 
 Alternatively:
 @example
-qemu-system-i386 dos.img -device gus,irq=5
+qemu-kvm dos.img -device gus,irq=5
 @end example
 
 Or some other unclaimed IRQ.
@@ -220,7 +220,7 @@ CS4231A is the chip used in Windows Sound System and GUSMAX products
 Download and uncompress the linux image (@file{linux.img}) and type:
 
 @example
-qemu-system-i386 linux.img
+qemu-kvm linux.img
 @end example
 
 Linux should boot and give you a prompt.
@@ -230,7 +230,7 @@ Linux should boot and give you a prompt.
 
 @example
 @c man begin SYNOPSIS
-@command{qemu-system-i386} [@var{options}] [@var{disk_image}]
+@command{qemu-kvm} [@var{options}] [@var{disk_image}]
 @c man end
 @end example
 
@@ -789,7 +789,7 @@ QEMU can automatically create a virtual FAT disk image from a
 directory tree. In order to use it, just type:
 
 @example
-qemu-system-i386 linux.img -hdb fat:/my_directory
+qemu-kvm linux.img -hdb fat:/my_directory
 @end example
 
 Then you access access to all the files in the @file{/my_directory}
@@ -799,14 +799,14 @@ them via SAMBA or NFS. The default access is @emph{read-only}.
 Floppies can be emulated with the @code{:floppy:} option:
 
 @example
-qemu-system-i386 linux.img -fda fat:floppy:/my_directory
+qemu-kvm linux.img -fda fat:floppy:/my_directory
 @end example
 
 A read/write support is available for testing (beta stage) with the
 @code{:rw:} option:
 
 @example
-qemu-system-i386 linux.img -fda fat:floppy:rw:/my_directory
+qemu-kvm linux.img -fda fat:floppy:rw:/my_directory
 @end example
 
 What you should @emph{never} do:
@@ -824,14 +824,14 @@ QEMU can access directly to block device exported using the Network Block Device
 protocol.
 
 @example
-qemu-system-i386 linux.img -hdb nbd://my_nbd_server.mydomain.org:1024/
+qemu-kvm linux.img -hdb nbd://my_nbd_server.mydomain.org:1024/
 @end example
 
 If the NBD server is located on the same host, you can use an unix socket instead
 of an inet socket:
 
 @example
-qemu-system-i386 linux.img -hdb nbd+unix://?socket=/tmp/my_socket
+qemu-kvm linux.img -hdb nbd+unix://?socket=/tmp/my_socket
 @end example
 
 In this case, the block device must be exported using qemu-nbd:
@@ -848,23 +848,23 @@ qemu-nbd --socket=/tmp/my_socket --share=2 my_disk.qcow2
 @noindent
 and then you can use it with two guests:
 @example
-qemu-system-i386 linux1.img -hdb nbd+unix://?socket=/tmp/my_socket
-qemu-system-i386 linux2.img -hdb nbd+unix://?socket=/tmp/my_socket
+qemu-kvm linux1.img -hdb nbd+unix://?socket=/tmp/my_socket
+qemu-kvm linux2.img -hdb nbd+unix://?socket=/tmp/my_socket
 @end example
 
 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:
 @example
-qemu-system-i386 -cdrom nbd://localhost/debian-500-ppc-netinst
-qemu-system-i386 -cdrom nbd://localhost/openSUSE-11.1-ppc-netinst
+qemu-kvm -cdrom nbd://localhost/debian-500-ppc-netinst
+qemu-kvm -cdrom nbd://localhost/openSUSE-11.1-ppc-netinst
 @end example
 
 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:
 @example
-qemu-system-i386 linux.img -hdb nbd:my_nbd_server.mydomain.org:1024
-qemu-system-i386 linux2.img -hdb nbd:unix:/tmp/my_socket
-qemu-system-i386 -cdrom nbd:localhost:10809:exportname=debian-500-ppc-netinst
+qemu-kvm linux.img -hdb nbd:my_nbd_server.mydomain.org:1024
+qemu-kvm linux2.img -hdb nbd:unix:/tmp/my_socket
+qemu-kvm -cdrom nbd:localhost:10809:exportname=debian-500-ppc-netinst
 @end example
 
 @node disk_images_sheepdog
@@ -889,7 +889,7 @@ qemu-img convert @var{filename} sheepdog:///@var{image}
 
 You can boot from the Sheepdog disk image with the command:
 @example
-qemu-system-i386 sheepdog:///@var{image}
+qemu-kvm sheepdog:///@var{image}
 @end example
 
 You can also create a snapshot of the Sheepdog image like qcow2.
@@ -901,7 +901,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
 snapshot.
 @example
-qemu-system-i386 sheepdog:///@var{image}#@var{tag}
+qemu-kvm sheepdog:///@var{image}#@var{tag}
 @end example
 
 You can create a cloned image from the existing snapshot.
@@ -914,14 +914,14 @@ is its tag name.
 You can use an unix socket instead of an inet socket:
 
 @example
-qemu-system-i386 sheepdog+unix:///@var{image}?socket=@var{path}
+qemu-kvm sheepdog+unix:///@var{image}?socket=@var{path}
 @end example
 
 If the Sheepdog daemon doesn't run on the local host, you need to
 specify one of the Sheepdog servers to connect to.
 @example
 qemu-img create sheepdog://@var{hostname}:@var{port}/@var{image} @var{size}
-qemu-system-i386 sheepdog://@var{hostname}:@var{port}/@var{image}
+qemu-kvm sheepdog://@var{hostname}:@var{port}/@var{image}
 @end example
 
 @node disk_images_iscsi
@@ -963,7 +963,7 @@ Various session related parameters can be set via special options, either
 in a configuration file provided via '-readconfig' or directly on the
 command line.
 
-If the initiator-name is not specified qemu will use a default name
+If the initiator-name is not specified qemu-kvm will use a default name
 of 'iqn.2008-11.org.linux-kvm[:<name>'] where <name> is the name of the
 virtual machine.
 
@@ -1010,7 +1010,7 @@ cat >iscsi.conf <<EOF
   header-digest = "CRC32C"
 EOF
 
-qemu-system-i386 -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
+qemu-kvm -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
     -readconfig iscsi.conf
 @end example
 
@@ -1029,7 +1029,7 @@ tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 2 \
     -b /IMAGES/cd.iso --device-type=cd
 tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL
 
-qemu-system-i386 -iscsi initiator-name=iqn.qemu.test:my-initiator \
+qemu-kvm -iscsi initiator-name=iqn.qemu.test:my-initiator \
     -boot d -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
     -cdrom iscsi://127.0.0.1/iqn.qemu.test/2
 @end example
@@ -1042,11 +1042,11 @@ GlusterFS is a user space distributed file system.
 You can boot from the GlusterFS disk image with the command:
 @example
 URI:
-qemu-system-x86_64 -drive file=gluster[+@var{type}]://[@var{host}[:@var{port}]]/@var{volume}/@var{path}
+qemu-kvm -drive file=gluster[+@var{type}]://[@var{host}[:@var{port}]]/@var{volume}/@var{path}
                                [?socket=...][,file.debug=9][,file.logfile=...]
 
 JSON:
-qemu-system-x86_64 'json:@{"driver":"qcow2",
+qemu-kvm 'json:@{"driver":"qcow2",
                            "file":@{"driver":"gluster",
                                     "volume":"testvol","path":"a.img","debug":9,"logfile":"...",
                                     "server":[@{"type":"tcp","host":"...","port":"..."@},
@@ -1094,22 +1094,22 @@ qemu-img create gluster://@var{host}/@var{volume}/@var{path} @var{size}
 
 Examples
 @example
-qemu-system-x86_64 -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
-qemu-system-x86_64 -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
-qemu-system-x86_64 -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
-qemu-system-x86_64 -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
-qemu-system-x86_64 -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",
+qemu-kvm -drive file=gluster://1.2.3.4/testvol/a.img
+qemu-kvm -drive file=gluster+tcp://1.2.3.4/testvol/a.img
+qemu-kvm -drive file=gluster+tcp://1.2.3.4:24007/testvol/dir/a.img
+qemu-kvm -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]/testvol/dir/a.img
+qemu-kvm -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]:24007/testvol/dir/a.img
+qemu-kvm -drive file=gluster+tcp://server.domain.com:24007/testvol/dir/a.img
+qemu-kvm -drive file=gluster+unix:///testvol/dir/a.img?socket=/tmp/glusterd.socket
+qemu-kvm -drive file=gluster+rdma://1.2.3.4:24007/testvol/a.img
+qemu-kvm -drive file=gluster://1.2.3.4/testvol/a.img,file.debug=9,file.logfile=/var/log/qemu-gluster.log
+qemu-kvm 'json:@{"driver":"qcow2",
                            "file":@{"driver":"gluster",
                                     "volume":"testvol","path":"a.img",
                                     "debug":9,"logfile":"/var/log/qemu-gluster.log",
                                     "server":[@{"type":"tcp","host":"1.2.3.4","port":24007@},
                                               @{"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,
+qemu-kvm -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.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
@@ -1122,13 +1122,13 @@ You can access disk images located on a remote ssh server
 by using the ssh protocol:
 
 @example
-qemu-system-x86_64 -drive file=ssh://[@var{user}@@]@var{server}[:@var{port}]/@var{path}[?host_key_check=@var{host_key_check}]
+qemu-kvm -drive file=ssh://[@var{user}@@]@var{server}[:@var{port}]/@var{path}[?host_key_check=@var{host_key_check}]
 @end example
 
 Alternative syntax using properties:
 
 @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}]
+qemu-kvm -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
 
 @var{ssh} is the protocol.
@@ -1270,7 +1270,7 @@ On Linux hosts, a shared memory device is available.  The basic syntax
 is:
 
 @example
-qemu-system-x86_64 -device ivshmem-plain,memdev=@var{hostmem}
+qemu-kvm -device ivshmem-plain,memdev=@var{hostmem}
 @end example
 
 where @var{hostmem} names a host memory backend.  For a POSIX shared
@@ -1291,7 +1291,7 @@ memory server is:
 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
-qemu-system-x86_64 -device ivshmem-doorbell,vectors=@var{vectors},chardev=@var{id}
+qemu-kvm -device ivshmem-doorbell,vectors=@var{vectors},chardev=@var{id}
                  -chardev socket,path=@var{path},id=@var{id}
 @end example
 
@@ -1316,7 +1316,7 @@ Instead of specifying the <shm size> using POSIX shm, you may specify
 a memory backend that has hugepage support:
 
 @example
-qemu-system-x86_64 -object memory-backend-file,size=1G,mem-path=/dev/hugepages/my-shmem-file,share,id=mb1
+qemu-kvm -object memory-backend-file,size=1G,mem-path=/dev/hugepages/my-shmem-file,share,id=mb1
                  -device ivshmem-plain,memdev=mb1
 @end example
 
@@ -1332,7 +1332,7 @@ kernel testing.
 
 The syntax is:
 @example
-qemu-system-i386 -kernel arch/i386/boot/bzImage -hda root-2.4.20.img -append "root=/dev/hda"
+qemu-kvm -kernel arch/i386/boot/bzImage -hda root-2.4.20.img -append "root=/dev/hda"
 @end example
 
 Use @option{-kernel} to provide the Linux kernel image and
@@ -1347,7 +1347,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
 @option{-nographic} option. The typical command line is:
 @example
-qemu-system-i386 -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \
+qemu-kvm -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \
                  -append "root=/dev/hda console=ttyS0" -nographic
 @end example
 
@@ -1411,7 +1411,7 @@ Network adapter that supports CDC ethernet and RNDIS protocols.  @var{options}
 specifies NIC options as with @code{-net nic,}@var{options} (see description).
 For instance, user-mode networking can be used with
 @example
-qemu-system-i386 [...OPTIONS...] -net user,vlan=0 -usbdevice net:vlan=0
+qemu-kvm [...OPTIONS...] -net user,vlan=0 -usbdevice net:vlan=0
 @end example
 Currently this cannot be used in machines that support PCI NICs.
 @item bt[:@var{hci-type}]
@@ -1421,7 +1421,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
 usage:
 @example
-@command{qemu-system-i386} [...@var{OPTIONS}...] @option{-usbdevice} bt:hci,vlan=3 @option{-bt} device:keyboard,vlan=3
+@command{qemu-kvm} [...@var{OPTIONS}...] @option{-usbdevice} bt:hci,vlan=3 @option{-bt} device:keyboard,vlan=3
 @end example
 @end table
 
@@ -1499,7 +1499,7 @@ For this setup it is recommended to restrict it to listen on a UNIX domain
 socket only. For example
 
 @example
-qemu-system-i386 [...OPTIONS...] -vnc unix:/home/joebloggs/.qemu-myvm-vnc
+qemu-kvm [...OPTIONS...] -vnc unix:/home/joebloggs/.qemu-myvm-vnc
 @end example
 
 This ensures that only users on local box with read/write access to that
@@ -1522,7 +1522,7 @@ is running the password is set with the monitor. Until the monitor is used to
 set the password all clients will be rejected.
 
 @example
-qemu-system-i386 [...OPTIONS...] -vnc :1,password -monitor stdio
+qemu-kvm [...OPTIONS...] -vnc :1,password -monitor stdio
 (qemu) change vnc password
 Password: ********
 (qemu)
@@ -1539,7 +1539,7 @@ support provides a secure session, but no authentication. This allows any
 client to connect, and provides an encrypted session.
 
 @example
-qemu-system-i386 [...OPTIONS...] -vnc :1,tls,x509=/etc/pki/qemu -monitor stdio
+qemu-kvm [...OPTIONS...] -vnc :1,tls,x509=/etc/pki/qemu -monitor stdio
 @end example
 
 In the above example @code{/etc/pki/qemu} should contain at least three files,
@@ -1557,7 +1557,7 @@ then validate against the CA certificate. This is a good choice if deploying
 in an environment with a private internal certificate authority.
 
 @example
-qemu-system-i386 [...OPTIONS...] -vnc :1,tls,x509verify=/etc/pki/qemu -monitor stdio
+qemu-kvm [...OPTIONS...] -vnc :1,tls,x509verify=/etc/pki/qemu -monitor stdio
 @end example
 
 
@@ -1568,7 +1568,7 @@ Finally, the previous method can be combined with VNC password authentication
 to provide two layers of authentication for clients.
 
 @example
-qemu-system-i386 [...OPTIONS...] -vnc :1,password,tls,x509verify=/etc/pki/qemu -monitor stdio
+qemu-kvm [...OPTIONS...] -vnc :1,password,tls,x509verify=/etc/pki/qemu -monitor stdio
 (qemu) change vnc password
 Password: ********
 (qemu)
@@ -1591,7 +1591,7 @@ used for authentication, but assuming use of one supporting SSF,
 then QEMU can be launched with:
 
 @example
-qemu-system-i386 [...OPTIONS...] -vnc :1,sasl -monitor stdio
+qemu-kvm [...OPTIONS...] -vnc :1,sasl -monitor stdio
 @end example
 
 @node vnc_sec_certificate_sasl
@@ -1605,7 +1605,7 @@ credentials. This can be enabled, by combining the 'sasl' option
 with the aforementioned TLS + x509 options:
 
 @example
-qemu-system-i386 [...OPTIONS...] -vnc :1,tls,x509,sasl -monitor stdio
+qemu-kvm [...OPTIONS...] -vnc :1,tls,x509,sasl -monitor stdio
 @end example
 
 
@@ -1773,7 +1773,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
 gdb connection:
 @example
-qemu-system-i386 -s -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \
+qemu-kvm -s -kernel arch/i386/boot/bzImage -hda root-2.4.20.img \
                     -append "root=/dev/hda"
 Connected to host network interface: tun0
 Waiting gdb connection on port 1234
@@ -1955,7 +1955,7 @@ differences are mentioned in the following sections.
 @section PowerPC System emulator
 @cindex system emulation (PowerPC)
 
-Use the executable @file{qemu-system-ppc} to simulate a complete PREP
+Use the executable @file{qemu-kvm} to simulate a complete PREP
 or PowerMac PowerPC system.
 
 QEMU emulates the following PowerMac peripherals:
@@ -2019,7 +2019,7 @@ Set the initial VGA graphic mode. The default is 800x600x32.
 Set OpenBIOS variables in NVRAM, for example:
 
 @example
-qemu-system-ppc -prom-env 'auto-boot?=false' \
+qemu-kvm -prom-env 'auto-boot?=false' \
  -prom-env 'boot-device=hd:2,\yaboot' \
  -prom-env 'boot-args=conf=hd:2,\yaboot.conf'
 @end example
diff --git a/qemu-options.hx b/qemu-options.hx
index d5a002d..b5544ac 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -195,7 +195,7 @@ 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:
 @example
-qemu-system-i386
+qemu-kvm
 -add-fd fd=3,set=2,opaque="rdwr:/path/to/file"
 -add-fd fd=4,set=2,opaque="rdonly:/path/to/file"
 -drive file=/dev/fdset/2,index=0,media=disk
@@ -224,7 +224,7 @@ STEXI
 Set default value of @var{driver}'s property @var{prop} to @var{value}, e.g.:
 
 @example
-qemu-system-i386 -global ide-drive.physical_block_size=4096 -drive file=file,if=ide,index=0,media=disk
+qemu-kvm -global ide-drive.physical_block_size=4096 -drive file=file,if=ide,index=0,media=disk
 @end example
 
 In particular, you can use this to set driver properties for devices which are 
@@ -269,7 +269,7 @@ the recommended is 320x240, 640x480, 800x640.
 
 A timeout could be passed to bios, guest will pause for @var{rb_timeout} ms
 when boot failed, then reboot. If @var{rb_timeout} is '-1', guest will not
-reboot, qemu passes '-1' to bios by default. Currently Seabios for X86
+reboot, qemu-kvm passes '-1' to bios by default. Currently Seabios for X86
 system support it.
 
 Do strict boot via @option{strict=on} as far as firmware/BIOS
@@ -278,11 +278,11 @@ bootindex options. The default is non-strict boot.
 
 @example
 # try to boot from network first, then from hard disk
-qemu-system-i386 -boot order=nc
+qemu-kvm -boot order=nc
 # boot from CD-ROM first, switch back to default order after reboot
-qemu-system-i386 -boot once=d
+qemu-kvm -boot once=d
 # boot with a splash picture for 5 seconds.
-qemu-system-i386 -boot menu=on,splash=/root/boot.bmp,splash-time=5000
+qemu-kvm -boot menu=on,splash=/root/boot.bmp,splash-time=5000
 @end example
 
 Note: The legacy format '-boot @var{drives}' is still supported but its
@@ -311,7 +311,7 @@ For example, the following command-line sets the guest startup RAM size to
 memory the guest can reach to 4GB:
 
 @example
-qemu-system-x86_64 -m 1G,slots=3,maxmem=4G
+qemu-kvm -m 1G,slots=3,maxmem=4G
 @end example
 
 If @var{slots} and @var{maxmem} are not specified, memory hotplug won't
@@ -380,12 +380,12 @@ Enable audio and selected sound hardware. Use 'help' to print all
 available sound hardware.
 
 @example
-qemu-system-i386 -soundhw sb16,adlib disk.img
-qemu-system-i386 -soundhw es1370 disk.img
-qemu-system-i386 -soundhw ac97 disk.img
-qemu-system-i386 -soundhw hda disk.img
-qemu-system-i386 -soundhw all disk.img
-qemu-system-i386 -soundhw help
+qemu-kvm -soundhw sb16,adlib disk.img
+qemu-kvm -soundhw es1370 disk.img
+qemu-kvm -soundhw ac97 disk.img
+qemu-kvm -soundhw hda disk.img
+qemu-kvm -soundhw all disk.img
+qemu-kvm -soundhw help
 @end example
 
 Note that Linux's i810_audio OSS kernel (for AC97) module might
@@ -672,21 +672,21 @@ is off.
 
 Instead of @option{-cdrom} you can use:
 @example
-qemu-system-i386 -drive file=file,index=2,media=cdrom
+qemu-kvm -drive file=file,index=2,media=cdrom
 @end example
 
 Instead of @option{-hda}, @option{-hdb}, @option{-hdc}, @option{-hdd}, you can
 use:
 @example
-qemu-system-i386 -drive file=file,index=0,media=disk
-qemu-system-i386 -drive file=file,index=1,media=disk
-qemu-system-i386 -drive file=file,index=2,media=disk
-qemu-system-i386 -drive file=file,index=3,media=disk
+qemu-kvm -drive file=file,index=0,media=disk
+qemu-kvm -drive file=file,index=1,media=disk
+qemu-kvm -drive file=file,index=2,media=disk
+qemu-kvm -drive file=file,index=3,media=disk
 @end example
 
 You can open an image using pre-opened file descriptors from an fd set:
 @example
-qemu-system-i386
+qemu-kvm
 -add-fd fd=3,set=2,opaque="rdwr:/path/to/file"
 -add-fd fd=4,set=2,opaque="rdonly:/path/to/file"
 -drive file=/dev/fdset/2,index=0,media=disk
@@ -694,28 +694,28 @@ qemu-system-i386
 
 You can connect a CDROM to the slave of ide0:
 @example
-qemu-system-i386 -drive file=file,if=ide,index=1,media=cdrom
+qemu-kvm -drive file=file,if=ide,index=1,media=cdrom
 @end example
 
 If you don't specify the "file=" argument, you define an empty drive:
 @example
-qemu-system-i386 -drive if=ide,index=1,media=cdrom
+qemu-kvm -drive if=ide,index=1,media=cdrom
 @end example
 
 Instead of @option{-fda}, @option{-fdb}, you can use:
 @example
-qemu-system-i386 -drive file=file,index=0,if=floppy
-qemu-system-i386 -drive file=file,index=1,if=floppy
+qemu-kvm -drive file=file,index=0,if=floppy
+qemu-kvm -drive file=file,index=1,if=floppy
 @end example
 
 By default, @var{interface} is "ide" and @var{index} is automatically
 incremented:
 @example
-qemu-system-i386 -drive file=a -drive file=b"
+qemu-kvm -drive file=a -drive file=b"
 @end example
 is interpreted like:
 @example
-qemu-system-i386 -hda a -hdb b
+qemu-kvm -hda a -hdb b
 @end example
 ETEXI
 
@@ -1840,7 +1840,7 @@ can not be resolved.
 
 Example:
 @example
-qemu -net user,dnssearch=mgmt.example.org,dnssearch=example.org [...]
+qemu-kvm -net user,dnssearch=mgmt.example.org,dnssearch=example.org [...]
 @end example
 
 @item tftp=@var{dir}
@@ -1856,7 +1856,7 @@ a guest from a local directory.
 
 Example (using pxelinux):
 @example
-qemu-system-i386 -hda linux.img -boot n -net user,tftp=/path/to/tftp/files,bootfile=/pxelinux.0
+qemu-kvm -hda linux.img -boot n -net user,tftp=/path/to/tftp/files,bootfile=/pxelinux.0
 @end example
 
 @item smb=@var{dir}[,smbserver=@var{addr}]
@@ -1891,7 +1891,7 @@ screen 0, use the following:
 
 @example
 # on the host
-qemu-system-i386 -net user,hostfwd=tcp:127.0.0.1:6001-:6000 [...]
+qemu-kvm -net user,hostfwd=tcp:127.0.0.1:6001-:6000 [...]
 # this host xterm should open in the guest X11 server
 xterm -display :1
 @end example
@@ -1901,7 +1901,7 @@ the guest, use the following:
 
 @example
 # on the host
-qemu-system-i386 -net user,hostfwd=tcp::5555-:23 [...]
+qemu-kvm -net user,hostfwd=tcp::5555-:23 [...]
 telnet localhost 5555
 @end example
 
@@ -1920,7 +1920,7 @@ lifetime, like in the following example:
 @example
 # open 10.10.1.1:4321 on bootup, connect 10.0.2.100:1234 to it whenever
 # the guest accesses it
-qemu -net user,guestfwd=tcp:10.0.2.100:1234-tcp:10.10.1.1:4321 [...]
+qemu-kvm -net user,guestfwd=tcp:10.0.2.100:1234-tcp:10.10.1.1:4321 [...]
 @end example
 
 Or you can execute a command on every TCP connection established by the guest,
@@ -1929,7 +1929,7 @@ so that QEMU behaves similar to an inetd process for that virtual server:
 @example
 # 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
-qemu -net 'user,guestfwd=tcp:10.0.2.100:1234-cmd:netcat 10.10.1.1 4321'
+qemu-kvm -net 'user,guestfwd=tcp:10.0.2.100:1234-cmd:netcat 10.10.1.1 4321'
 @end example
 
 @end table
@@ -1962,13 +1962,13 @@ Examples:
 
 @example
 #launch a QEMU instance with the default network script
-qemu-system-i386 linux.img -net nic -net tap
+qemu-kvm linux.img -net nic -net tap
 @end example
 
 @example
 #launch a QEMU instance with two NICs, each one connected
 #to a TAP device
-qemu-system-i386 linux.img \
+qemu-kvm linux.img \
                  -net nic,vlan=0 -net tap,vlan=0,ifname=tap0 \
                  -net nic,vlan=1 -net tap,vlan=1,ifname=tap1
 @end example
@@ -1976,7 +1976,7 @@ qemu-system-i386 linux.img \
 @example
 #launch a QEMU instance with the default network helper to
 #connect a TAP device to bridge br0
-qemu-system-i386 linux.img \
+qemu-kvm linux.img \
                  -net nic -net tap,"helper=/path/to/qemu-bridge-helper"
 @end example
 
@@ -1994,13 +1994,13 @@ Examples:
 @example
 #launch a QEMU instance with the default network helper to
 #connect a TAP device to bridge br0
-qemu-system-i386 linux.img -net bridge -net nic,model=virtio
+qemu-kvm linux.img -net bridge -net nic,model=virtio
 @end example
 
 @example
 #launch a QEMU instance with the default network helper to
 #connect a TAP device to bridge qemubr0
-qemu-system-i386 linux.img -net bridge,br=qemubr0 -net nic,model=virtio
+qemu-kvm linux.img -net bridge,br=qemubr0 -net nic,model=virtio
 @end example
 
 @item -netdev socket,id=@var{id}[,fd=@var{h}][,listen=[@var{host}]:@var{port}][,connect=@var{host}:@var{port}]
@@ -2016,12 +2016,12 @@ specifies an already opened TCP socket.
 Example:
 @example
 # launch a first QEMU instance
-qemu-system-i386 linux.img \
+qemu-kvm linux.img \
                  -net nic,macaddr=52:54:00:12:34:56 \
                  -net socket,listen=:1234
 # connect the VLAN 0 of this instance to the VLAN 0
 # of the first instance
-qemu-system-i386 linux.img \
+qemu-kvm linux.img \
                  -net nic,macaddr=52:54:00:12:34:57 \
                  -net socket,connect=127.0.0.1:1234
 @end example
@@ -2047,15 +2047,15 @@ Use @option{fd=h} to specify an already opened UDP multicast socket.
 Example:
 @example
 # launch one QEMU instance
-qemu-system-i386 linux.img \
+qemu-kvm linux.img \
                  -net nic,macaddr=52:54:00:12:34:56 \
                  -net socket,mcast=230.0.0.1:1234
 # launch another QEMU instance on same "bus"
-qemu-system-i386 linux.img \
+qemu-kvm linux.img \
                  -net nic,macaddr=52:54:00:12:34:57 \
                  -net socket,mcast=230.0.0.1:1234
 # launch yet another QEMU instance on same "bus"
-qemu-system-i386 linux.img \
+qemu-kvm linux.img \
                  -net nic,macaddr=52:54:00:12:34:58 \
                  -net socket,mcast=230.0.0.1:1234
 @end example
@@ -2064,7 +2064,7 @@ Example (User Mode Linux compat.):
 @example
 # launch QEMU instance (note mcast address selected
 # is UML's default)
-qemu-system-i386 linux.img \
+qemu-kvm linux.img \
                  -net nic,macaddr=52:54:00:12:34:56 \
                  -net socket,mcast=239.192.168.1:1102
 # launch UML
@@ -2073,7 +2073,7 @@ qemu-system-i386 linux.img \
 
 Example (send packets from host's 1.2.3.4):
 @example
-qemu-system-i386 linux.img \
+qemu-kvm linux.img \
                  -net nic,macaddr=52:54:00:12:34:56 \
                  -net socket,mcast=239.192.168.1:1102,localaddr=1.2.3.4
 @end example
@@ -2132,7 +2132,7 @@ brctl addif br-lan vmtunnel0
 # on 4.3.2.1
 # launch QEMU instance - if your network has reorder or is very lossy add ,pincounter
 
-qemu-system-i386 linux.img -net nic -net l2tpv3,src=4.2.3.1,dst=1.2.3.4,udp,srcport=16384,dstport=16384,rxsession=0xffffffff,txsession=0xffffffff,counter
+qemu-kvm linux.img -net nic -net l2tpv3,src=4.2.3.1,dst=1.2.3.4,udp,srcport=16384,dstport=16384,rxsession=0xffffffff,txsession=0xffffffff,counter
 
 
 @end example
@@ -2150,7 +2150,7 @@ Example:
 # launch vde switch
 vde_switch -F -sock /tmp/myswitch
 # launch QEMU instance
-qemu-system-i386 linux.img -net nic -net vde,sock=/tmp/myswitch
+qemu-kvm linux.img -net nic -net vde,sock=/tmp/myswitch
 @end example
 
 @item -netdev hubport,id=@var{id},hubid=@var{hubid}
@@ -2172,11 +2172,11 @@ be created for multiqueue vhost-user.
 
 Example:
 @example
-qemu -m 512 -object memory-backend-file,id=mem,size=512M,mem-path=/hugetlbfs,share=on \
-     -numa node,memdev=mem \
-     -chardev socket,id=chr0,path=/path/to/socket \
-     -netdev type=vhost-user,id=net0,chardev=chr0 \
-     -device virtio-net-pci,netdev=net0
+qemu-kvm -m 512 -object memory-backend-file,id=mem,size=512M,mem-path=/hugetlbfs,share=on \
+         -numa node,memdev=mem \
+         -chardev socket,id=chr0,path=/path/to/socket \
+         -netdev type=vhost-user,id=net0,chardev=chr0 \
+         -device virtio-net-pci,netdev=net0
 @end example
 
 @item -net dump[,vlan=@var{n}][,file=@var{file}][,len=@var{len}]
@@ -2544,7 +2544,7 @@ images for the guest storage. Both disk and cdrom images are supported.
 Syntax for specifying iSCSI LUNs is
 ``iscsi://<target-ip>[:<port>]/<target-iqn>/<lun>''
 
-By default qemu will use the iSCSI initiator-name
+By default qemu-kvm will use the iSCSI initiator-name
 'iqn.2008-11.org.linux-kvm[:<name>]' but this can also be set from the command
 line or a configuration file.
 
@@ -2555,21 +2555,21 @@ is specified in seconds. The default is 0 which means no timeout. Libiscsi
 
 Example (without authentication):
 @example
-qemu-system-i386 -iscsi initiator-name=iqn.2001-04.com.example:my-initiator \
+qemu-kvm -iscsi initiator-name=iqn.2001-04.com.example:my-initiator \
                  -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
 @end example
 
 Example (CHAP username/password via URL):
 @example
-qemu-system-i386 -drive file=iscsi://user%password@@192.0.2.1/iqn.2001-04.com.example/1
+qemu-kvm -drive file=iscsi://user%password@@192.0.2.1/iqn.2001-04.com.example/1
 @end example
 
 Example (CHAP username/password via environment variables):
 @example
 LIBISCSI_CHAP_USERNAME="user" \
 LIBISCSI_CHAP_PASSWORD="password" \
-qemu-system-i386 -drive file=iscsi://192.0.2.1/iqn.2001-04.com.example/1
+qemu-kvm -drive file=iscsi://192.0.2.1/iqn.2001-04.com.example/1
 @end example
 
 iSCSI support is an optional feature of QEMU and only available when
@@ -2599,12 +2599,12 @@ Syntax for specifying a NBD device using Unix Domain Sockets
 
 Example for TCP
 @example
-qemu-system-i386 --drive file=nbd:192.0.2.1:30000
+qemu-kvm --drive file=nbd:192.0.2.1:30000
 @end example
 
 Example for Unix Domain Sockets
 @example
-qemu-system-i386 --drive file=nbd:unix:/tmp/nbd-socket
+qemu-kvm --drive file=nbd:unix:/tmp/nbd-socket
 @end example
 
 @item SSH
@@ -2612,8 +2612,8 @@ QEMU supports SSH (Secure Shell) access to remote disks.
 
 Examples:
 @example
-qemu-system-i386 -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
+qemu-kvm -drive file=ssh://user@@host/path/to/disk.img
+qemu-kvm -drive file.driver=ssh,file.user=user,file.host=host,file.port=22,file.path=/path/to/disk.img
 @end example
 
 Currently authentication must be done using ssh-agent.  Other
@@ -2631,7 +2631,7 @@ sheepdog[+tcp|+unix]://[host:port]/vdiname[?socket=path][#snapid|#tag]
 
 Example
 @example
-qemu-system-i386 --drive file=sheepdog://192.0.2.1:30000/MyVirtualMachine
+qemu-kvm --drive file=sheepdog://192.0.2.1:30000/MyVirtualMachine
 @end example
 
 See also @url{https://sheepdog.github.io/sheepdog/}.
@@ -2657,17 +2657,17 @@ JSON:
 Example
 @example
 URI:
-qemu-system-x86_64 --drive file=gluster://192.0.2.1/testvol/a.img,
+qemu-kvm --drive file=gluster://192.0.2.1/testvol/a.img,
 @                               file.debug=9,file.logfile=/var/log/qemu-gluster.log
 
 JSON:
-qemu-system-x86_64 'json:@{"driver":"qcow2",
+qemu-kvm 'json:@{"driver":"qcow2",
 @                          "file":@{"driver":"gluster",
 @                                   "volume":"testvol","path":"a.img",
 @                                   "debug":9,"logfile":"/var/log/qemu-gluster.log",
 @                                   "server":[@{"type":"tcp","host":"1.2.3.4","port":24007@},
 @                                             @{"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,
+qemu-kvm -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.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
@@ -2727,14 +2727,14 @@ that CURL waits for a response from the remote server to get the size of the
 image to be downloaded. If not set, the default timeout of 5 seconds is used.
 @end table
 
-Note that when passing options to qemu explicitly, @option{driver} is the value
+Note that when passing options to qemu-kvm explicitly, @option{driver} is the value
 of <protocol>.
 
 Example: boot from a remote Fedora 20 live ISO image
 @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
+qemu-kvm --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
+qemu-kvm --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
 
 Example: boot from a remote Fedora 20 cloud image using a local overlay for
@@ -2742,7 +2742,7 @@ writes, copy-on-read, and a readahead of 64k
 @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-system-x86_64 -drive file=/tmp/Fedora-x86_64-20-20131211.1-sda.qcow2,copy-on-read=on
+qemu-kvm -drive file=/tmp/Fedora-x86_64-20-20131211.1-sda.qcow2,copy-on-read=on
 @end example
 
 Example: boot from an image stored on a VMware vSphere server with a self-signed
@@ -2751,7 +2751,7 @@ of 10 seconds.
 @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-system-x86_64 -drive file=/tmp/test.qcow2
+qemu-kvm -drive file=/tmp/test.qcow2
 @end example
 ETEXI
 
@@ -2815,7 +2815,7 @@ and communicate.  Requires the Linux @code{vhci} driver installed.  Can
 be used as following:
 
 @example
-qemu-system-i386 [...OPTIONS...] -bt hci,vlan=5 -bt vhci,vlan=5
+qemu-kvm [...OPTIONS...] -bt hci,vlan=5 -bt vhci,vlan=5
 @end example
 
 @item -bt device:@var{dev}[,vlan=@var{n}]
@@ -2861,7 +2861,7 @@ Options to each backend are described below.
 
 Use 'help' to print all available TPM backend types.
 @example
-qemu -tpmdev help
+qemu-kvm -tpmdev help
 @end example
 
 @item -tpmdev passthrough, id=@var{id}, path=@var{path}, cancel-path=@var{cancel-path}
@@ -3229,14 +3229,14 @@ ETEXI
 
 DEF("realtime", HAS_ARG, QEMU_OPTION_realtime,
     "-realtime [mlock=on|off]\n"
-    "                run qemu with realtime features\n"
+    "                run qemu-kvm with realtime features\n"
     "                mlock=on|off controls mlock support (default: on)\n",
     QEMU_ARCH_ALL)
 STEXI
 @item -realtime mlock=on|off
 @findex -realtime
-Run qemu with realtime features.
-mlocking qemu and guest memory can be enabled via @option{mlock=on}
+Run qemu-kvm with realtime features.
+mlocking qemu-kvm and guest memory can be enabled via @option{mlock=on}
 (enabled by default).
 ETEXI
 
@@ -3250,7 +3250,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
 within gdb and establish the connection via a pipe:
 @example
-(gdb) target remote | exec qemu-system-i386 -gdb stdio ...
+(gdb) target remote | exec qemu-kvm -gdb stdio ...
 @end example
 ETEXI
 
@@ -4059,7 +4059,7 @@ which specify the queue number of cryptodev backend, the default of
 
 @example
 
- # qemu-system-x86_64 \
+ # qemu-kvm \
    [...] \
        -object cryptodev-backend-builtin,id=cryptodev0 \
        -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \
-- 
1.8.3.1