diff options
Diffstat (limited to 'qemu-options.hx')
-rw-r--r-- | qemu-options.hx | 128 |
1 files changed, 64 insertions, 64 deletions
diff --git a/qemu-options.hx b/qemu-options.hx index b2ba7c5..bbfd936 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -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: @example -qemu-system-i386 --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 +@value{qemu_system} \ + -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 @end example ETEXI @@ -283,7 +283,7 @@ STEXI Set default value of @var{driver}'s property @var{prop} to @var{value}, e.g.: @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 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 # 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 -qemu-system-i386 -boot once=d +@value{qemu_system_x86} -boot once=d # 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 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: @example -qemu-system-x86_64 -m 1G,slots=3,maxmem=4G +@value{qemu_system} -m 1G,slots=3,maxmem=4G @end example 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 @findex -soundhw Enable audio and selected sound hardware. Use 'help' to print all -available sound hardware. +available sound hardware. For example: @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 +@value{qemu_system_x86} -soundhw sb16,adlib disk.img +@value{qemu_system_x86} -soundhw es1370 disk.img +@value{qemu_system_x86} -soundhw ac97 disk.img +@value{qemu_system_x86} -soundhw hda disk.img +@value{qemu_system_x86} -soundhw all disk.img +@value{qemu_system_x86} -soundhw help @end example 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: @example -qemu-system-i386 -drive file=file,index=2,media=cdrom +@value{qemu_system} -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 +@value{qemu_system} -drive file=file,index=0,media=disk +@value{qemu_system} -drive file=file,index=1,media=disk +@value{qemu_system} -drive file=file,index=2,media=disk +@value{qemu_system} -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 --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 +@value{qemu_system} \ + -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 @end example You can connect a CDROM to the slave of ide0: @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 If you don't specify the "file=" argument, you define an empty drive: @example -qemu-system-i386 -drive if=ide,index=1,media=cdrom +@value{qemu_system_x86} -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 +@value{qemu_system_x86} -drive file=file,index=0,if=floppy +@value{qemu_system_x86} -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" +@value{qemu_system_x86} -drive file=a -drive file=b" @end example is interpreted like: @example -qemu-system-i386 -hda a -hdb b +@value{qemu_system_x86} -hda a -hdb b @end example 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 on i386, so the @option{model=e1000} parameter could even be omitted here, too): @example -qemu-system-i386 -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} -netdev user,id=n1,ipv6=off -device e1000,netdev=n1,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 @item -nic none @@ -2344,7 +2344,7 @@ can not be resolved. 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 @item domainname=@var{domain} @@ -2368,7 +2368,7 @@ a guest from a local directory. Example (using pxelinux): @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 @end example @@ -2402,7 +2402,7 @@ screen 0, use the following: @example # 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 xterm -display :1 @end example @@ -2412,7 +2412,7 @@ the guest, use the following: @example # on the host -qemu-system-i386 -nic user,hostfwd=tcp::5555-:23 +@value{qemu_system} -nic user,hostfwd=tcp::5555-:23 telnet localhost 5555 @end example @@ -2431,7 +2431,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-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 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 # 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-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 table @@ -2467,13 +2467,13 @@ Examples: @example #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 @example #launch a QEMU instance with two NICs, each one connected #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=nd1,ifname=tap1 -device rtl8139,netdev=nd1 @end example @@ -2481,7 +2481,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 -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" @end example @@ -2498,13 +2498,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 -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 @example #launch a QEMU instance with the default network helper to #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 @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 # 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 \ -netdev socket,id=n1,listen=:1234 # 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 \ -netdev socket,id=n2,connect=127.0.0.1:1234 @end example @@ -2548,15 +2548,15 @@ Use @option{fd=h} to specify an already opened UDP multicast socket. Example: @example # 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 \ -netdev socket,id=n1,mcast=230.0.0.1:1234 # 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 \ -netdev socket,id=n2,mcast=230.0.0.1:1234 # 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 \ -netdev socket,id=n3,mcast=230.0.0.1:1234 @end example @@ -2564,7 +2564,7 @@ qemu-system-i386 linux.img \ Example (User Mode Linux compat.): @example # 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 \ -netdev socket,id=n1,mcast=239.192.168.1:1102 # launch UML @@ -2573,7 +2573,7 @@ qemu-system-i386 linux.img \ Example (send packets from host's 1.2.3.4): @example -qemu-system-i386 linux.img \ +@value{qemu_system} linux.img \ -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 @end example @@ -2633,7 +2633,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 -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 @end example @@ -2650,7 +2650,7 @@ Example: # launch vde switch vde_switch -F -sock /tmp/myswitch # 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 @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: @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 @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 within gdb and establish the connection via a pipe: @example -(gdb) target remote | exec qemu-system-i386 -gdb stdio ... +(gdb) target remote | exec @value{qemu_system} -gdb stdio ... @end example ETEXI @@ -4578,7 +4578,7 @@ which specify the queue number of cryptodev backend, the default of @example - # qemu-system-x86_64 \ + # @value{qemu_system} \ [...] \ -object cryptodev-backend-builtin,id=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 - # qemu-system-x86_64 \ + # @value{qemu_system} \ [...] \ -chardev socket,id=chardev0,path=/path/to/socket \ -object cryptodev-vhost-user,id=cryptodev0,chardev=chardev0 \ @@ -4634,14 +4634,14 @@ The simplest (insecure) usage is to provide the secret inline @example - # $QEMU -object secret,id=sec0,data=letmein,format=raw + # @value{qemu_system} -object secret,id=sec0,data=letmein,format=raw @end example The simplest secure usage is to provide the secret via a file # 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, 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 @example - # $QEMU \ + # @value{qemu_system} \ -object secret,id=secmaster0,format=base64,file=key.b64 \ -object secret,id=sec0,keyid=secmaster0,format=base64,\ 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 @example - # $QEMU \ + # @value{qemu_system_x86} \ ...... -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=5 \ -machine ...,memory-encryption=sev0 @@ -4742,7 +4742,7 @@ any commas in the distinguished name. An example authorization object to validate a x509 distinguished name would look like: @example - # $QEMU \ + # @value{qemu_system} \ ... -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 would look like: @example - # $QEMU \ + # @value{qemu_system} \ ... -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: @example - # $QEMU \ + # @value{qemu_system} \ ... -object authz-pam,id=auth0,service=qemu-vnc ... |