Overview
Comment: | Some documentation improvements |
---|---|
Downloads: | Tarball | ZIP archive | SQL archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
bea4cf20e92555610afbf84726d68644 |
User & Date: | vitus on 2020-01-14 12:00:09 |
Other Links: | manifest | tags |
Context
2020-01-16
| ||
18:18 | Fix moninor command for python3 check-in: 9be36c3e65 user: vitus tags: trunk | |
2020-01-14
| ||
12:00 | Some documentation improvements check-in: bea4cf20e9 user: vitus tags: trunk | |
2019-10-04
| ||
17:14 | Removed some pylint warnings check-in: 86c3c38746 user: vitus tags: trunk | |
Changes
Modified vws.mkd from [9b1750f173] to [2d1f675075].
︙ | ︙ | |||
88 89 90 91 92 93 94 95 96 97 98 99 100 101 | By default, our VWs are accessible from localhost only, but it is easy to set up password which lets to connect them via network. It is allowed to redirect USB devices either via SPICE (i.e. from the user workplace), or from host where VW is running. ISO images can be mounted as CDROMs only from host. VW CREATION =========== **vws create** command creates basic layout of the virtual machine - virtual disk image and startup script and optionally starts installation process connecting specified ISO-image to virtual CD-ROM drive. | > > > > > > > > > > > > > > > > > | 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 | By default, our VWs are accessible from localhost only, but it is easy to set up password which lets to connect them via network. It is allowed to redirect USB devices either via SPICE (i.e. from the user workplace), or from host where VW is running. ISO images can be mounted as CDROMs only from host. USERS AND GROUPS ================ Most linux systems allow to run virtual machines to any user, who is member of group **kvm**. **vws** makes same assumption. VMs are running under rights of invoking user. VWs, autostarted during system boot, however, need special user to run under. If you use bridge networking, QEMU would need administrative rights to add its virtual interface to the bridge. QEMU includes special utility **qemu-bridge-helper**, which is designed to run with elevated privileges, and safely can be installed setuid root. It only allows actions on bridge interface, which is listed in **allow** statement in **/etc/qemu/bridge.conf**. VW CREATION =========== **vws create** command creates basic layout of the virtual machine - virtual disk image and startup script and optionally starts installation process connecting specified ISO-image to virtual CD-ROM drive. |
︙ | ︙ | |||
142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 | tun interface which would be connected to some bridge. To use this mode, you have to perform following setup tasks 1. Make qemu-bridge-helper utility setuid root. (it is designed to run setuid root, but Debian doesn't install it such way). It is required to allow qemu, started from non-root user to add interface to bridge. 2. Create bridge interface to use. You can have several bridges and specify which one would be used on VW creation. Really, by manual editing of the startup script, you can add several network interfaces to VW and connect them to the different bridges. You should assign some MAC address to the bridge interface used by virtual machines. If you ethernet interface is part of the bridge, it already have one. Otherwise use command ip link set dev *bridge_name* address XX:XX:XX:XX:XX:XX or some distribution-specific configuration file. 3. Setup you host system to forward packets from bridge network to outside internet. You can either use NAT, or include your ethernet interface into bridge. 4. Make sure DHCP server is running in the bridge network. If your ethernet interface is part of the bridge, VWs would get their dynamic IP from your network router. If you use NAT, you'll need to run DHCP server, for instance **dnsmasq**(8) on your host and make it serve your bridge interface. You can live without DHCP on bridge, but it would be your problem to configure IP address on each VW manually. If you are planning to deploy many VWs with different operating systems, it is better to | > > > | 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 | tun interface which would be connected to some bridge. To use this mode, you have to perform following setup tasks 1. Make qemu-bridge-helper utility setuid root. (it is designed to run setuid root, but Debian doesn't install it such way). It is required to allow qemu, started from non-root user to add interface to bridge. (this is done automatically by postinst script in Debian package). 2. Create bridge interface to use. You can have several bridges and specify which one would be used on VW creation. Really, by manual editing of the startup script, you can add several network interfaces to VW and connect them to the different bridges. You should assign some MAC address to the bridge interface used by virtual machines. If you ethernet interface is part of the bridge, it already have one. Otherwise use command ip link set dev *bridge_name* address XX:XX:XX:XX:XX:XX or some distribution-specific configuration file. 3. Setup you host system to forward packets from bridge network to outside internet. You can either use NAT, or include your ethernet interface into bridge. 4. Make sure DHCP server is running in the bridge network. If your ethernet interface is part of the bridge, VWs would get their dynamic IP from your network router. If you use NAT, you'll need to run DHCP server, for instance **dnsmasq**(8) on your host and make it serve your bridge interface. You can live without DHCP on bridge, but it would be your problem to configure IP address on each VW manually. If you are planning to deploy many VWs with different operating systems, it is better to |
︙ | ︙ | |||
464 465 466 467 468 469 470 | Autostart VMs are started automatically on boot of host. If you are using more or less sensible disk layout, i.e. create separate partitions for /usr and /var, you probably want to tune this parameters, because you don't want to store your vms in the /var/cache. It is recommended to have both these directories on the same partition, so moving VM from autostart to shared and vice versa would not involve physically copying of the files. | < < | > | | > > > | | | 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 | Autostart VMs are started automatically on boot of host. If you are using more or less sensible disk layout, i.e. create separate partitions for /usr and /var, you probably want to tune this parameters, because you don't want to store your vms in the /var/cache. It is recommended to have both these directories on the same partition, so moving VM from autostart to shared and vice versa would not involve physically copying of the files. Permissions ----------- Options of this section controls interaction with unix user names and groups for shared and authostarted VMs. * autostart_user - user name of user which should all autostart vms run run as * vm_group - group name which should own all shared VMs. * setgid_vm - boolean, true if setgid attribute should be set on shared VM directory Create options -------------- This section list default values, used by **vws create** to create new virtual machines. Following parameters can be used: * **net=user** or **net=**_inteface name_ - network type by default. Can be either **user** or name of existing bridge interface. If you have set up bridge, you'll probably want to specify name of bridge interface here. * **size=**_virtual disk sizex_ - size of the disk image to create by default. 20G is probably big enough for most modern OS-es and small enough to fit on the modern disks. Note that we use **qcow2** format, so all disk space is not preallocated. You can use G or M suffixes to specify size. * **mem=**_memory size_ - default memory size. Also can have M or G suffix. * **diskif=**_interface_ where _interface_ can be **ide**, **scsi** or **virtio**. Disk interface. **virtio** offer best performance, but only if supported by quest operating system. **ide** offers best compatibility. Windows vms must be created with ide, although it is possible to convert to virtio after installation. * **arch=**_architecture_ In most cases your choice is limited between **i386** and **x86_64**. Although you probably have qemu binaries for many other architectures, and it is theoretically possible to use them, they would be emulated without hardware acceleration and require some queer QEMU parameters, which are not supported by **vws** now. * **sound=**_list of sound cards_ specify which sound cards are emulated in the virtual machine. In most cases **hda** is all you need. But qemu supports long list of sound cards which can be found out by typing: qemu-system-i386 -soundhw help You can specify several of them, separated by comma. * **vga=**_type_ Type of emulated video adapter **qxl** offers best performance with spice, but have mouse glitches with some old versions of X11. If you encounter such a problem, try to use some other type of videoadapter, listed on the manual page **qemu-system**(1). TOOLS SECTION ------------- Following programs can be specified via this section: * **viewer=** Name of spice client to run. %s in the command line is replaced by spice URI. Default |
︙ | ︙ | |||
544 545 546 547 548 549 550 | 2. monitor socket named **monitor** 3. pid file **pid** 4. One or more drive images. Each image can have several backing files (snapshots). All references to the drive images or to backing files within drive images use relative paths, so you can move directory around, and machine would still work. FILES ===== | | > | 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 | 2. monitor socket named **monitor** 3. pid file **pid** 4. One or more drive images. Each image can have several backing files (snapshots). All references to the drive images or to backing files within drive images use relative paths, so you can move directory around, and machine would still work. FILES ===== **/etc/vws.conf**, _\${HOME}_**/.vwsrc**, _\${HOME}_**/VWs**, **/etc/qemu/bridge.conf** SEE ALSO ======== **find\_free\_port**(1), **qemu-system**(1), **brctl**(8) |