[2024-feb-29] Sad news: Eric Layton aka Nocturnal Slacker aka vtel57 passed away on Feb 26th, shortly after hospitalization. He was one of our Wiki's most prominent admins. He will be missed.

Welcome to the Slackware Documentation Project

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
howtos:emulators:helper_script_for_managing_qemu_virtual_machines [2016/09/01 09:00 (UTC)] – [Networking] louigi600howtos:emulators:helper_script_for_managing_qemu_virtual_machines [2023/12/12 08:13 (UTC)] (current) – [Sources] zeebra
Line 1: Line 1:
-====== Preface ====== +====== Helper script for managing QEMU virtual machines ====== 
-Qemu is a popular and powerful open-source emulator often used for running KVM virtual machines. In fact qemu supports emulating so many thins that it can be quite challenging, unless you do it very often, to manually start a VM by using qemu-system-* from console. Who would want to write the below command for starting a VM:+<!--I took the liberty to fix this headline, if it should have another name, change it  --- //[[wiki:user:zeebra|zeebra]] 2023/12/12 08:11 (UTC)// --> 
 +===== Preface ===== 
 +Qemu is a popular and powerful open-source emulator often used for running KVM Virtual Machines (VMs). In fact qemu supports emulating so many things that it can be quite challenging, unless you do it very often, to manually start a VM from a text console. Who would want to write the below command for starting a VM ?
  
   qemu-system-arm -name armedslack -M versatilepb -m 256 -k en-us -vnc :5,password -usb -kernel /VM/armedslack/zImage-versatile -initrd /VM/armedslack/initrd-versatile -append 'root=/dev/sda1 rootfs=ext2' -monitor telnet:127.0.0.1:1035,server,nowait  -drive file=/VM/armedslack/qemu_hdu.raw,index=0,media=disk -drive file=,index=1,media=cdrom  -net nic,macaddr=52:54:57:c0:2c:bb -net tap,ifname=tap5   qemu-system-arm -name armedslack -M versatilepb -m 256 -k en-us -vnc :5,password -usb -kernel /VM/armedslack/zImage-versatile -initrd /VM/armedslack/initrd-versatile -append 'root=/dev/sda1 rootfs=ext2' -monitor telnet:127.0.0.1:1035,server,nowait  -drive file=/VM/armedslack/qemu_hdu.raw,index=0,media=disk -drive file=,index=1,media=cdrom  -net nic,macaddr=52:54:57:c0:2c:bb -net tap,ifname=tap5
  
-Ok everyone might want console redirect on vnc and monitor redirect via telnet but non the less that's still a relatively small subset of the options supported by qemu-system-arm and only has one disk one cdrom and one Network Interface Controller (NIC) so things can be much worse then this.+Not everyone might want console redirect on vnc and monitor redirect via telnet but non the less that's still a relatively small subset of the options supported by qemu-system-arm and only has one disk one cdrom and one Network Interface Controller (NIC) so things can be much worse then this.
  
-Is is common practice that people running qemu VMs use some sort of software to help them createrun and maintain them. If you want an easy way out you might consider virtmanager or something like that. Personally I chose to manage my VMs from text console because for me it's an added value to be able to do such jobs even without GUI, leading me to write my onw scripts for managing my VMs.+Is is common, for people running qemu VMs, to use some sort of software for creatingrunning and maintain the VMs. If you want an easy way out you might consider virtmanager or something like that. Personally I chose to manage my VMs from text console because for me it's an added value to be able to do such jobs even without GUI, so possibly like many others I wrote my onw scripts for managing my qemu VMs.
  
-Over the years I've radically changed the helper script form having text configuration files for each VM to a centarl VM configuration database. I'd like to share my experience in doing so without presumptuously declaring that I do this any better then anyone else, letting you decide what's good or bad for your needs. It's likely that someone else has done this and a lot better then me but nevertheless I'still like to hare with you the route I took.+Over the years I've radically changed the helper script form having text configuration files for each VM to a centarl VM configuration database. I'd like to share my experience in doing so without presumptuously declaring that I do this any better then anyone else, letting you decide what's good or bad for your needs. It's likely that someone else has done this and a lot better then me but nevertheless I'still like to hare with you the route I took.
  
 ====== Problems ====== ====== Problems ======
Line 14: Line 16:
   * ability to run both x86 and ARM virtual machines   * ability to run both x86 and ARM virtual machines
   * ability to run several VMs simultaneously   * ability to run several VMs simultaneously
 +  * have the VMs appear as a real server in the LAN
   * flexibility on the number of disks assigned to a VM   * flexibility on the number of disks assigned to a VM
   * flexibility on the number of NICs assigned to a VM   * flexibility on the number of NICs assigned to a VM
-  * avoid conflicts on tap and MAC address 
   * avoid conflicts on VM console vnc port   * avoid conflicts on VM console vnc port
   * avoid conflicts on VM monitor port   * avoid conflicts on VM monitor port
-Dealing with such issues on a text based configuration file per each VM started making the code unnecessarily complicated. 
-Manually creating a configuration file for a new VM required looking for information across all previously configured VMs configuration files. 
  
-Another problem that you may come across while running VMs in general is networking the VM. Qemu gives you several options (usermode networking, port redirection and taps). I want my VMs to look like real machines on the network the host is attached to to bridging tap devices was my only option.+Wanting the VMs to appear like real servers on the LAN, along with my other requirements, made me opt for bridged tap NICs, which in turn created another potential conflict on the tap device ans MAC address. 
 + 
 +Using the initial, per VM text based configuration, started to make it difficult to deal with such issues automatically (making the code unnecessarily long and complex) while manually creating a configuration file for a new VM required looking for information across all previously configured VMs to avoid potential conflicts  
 ====== Proposed Solution ====== ====== Proposed Solution ======
-It quickly became apparent to me that the VM configuration would need to be generated rather then manually created and that a central configuration repository would much aid the process. Again a text based central configuration file would make the code in inherently complicated (having to deal with an arbitrary number of VMs each with arbitrary number of disks and NICs).  +It quickly became apparent to me that the VM configuration would need to be generated rather then manually created and that a central configuration repository would much aid the process. Again a text based central configuration file would make, either the code or the config file, inherently complicated (having to deal with an arbitrary number of VMs each with arbitrary number of disks and NICs).  
-Having some experience on database administration made it a little unappealing to use LDAP for central repository and even if I had no DB experience at all I doubt I'd actually want the overhead of running LDAP just for this. Running MariaDB or Postgres for the same reason was rather unappealing toofor my small requirements, so I chose to use sqlite3. In my case it would be extremely rare that, 2 or more simultaneous executions of the management script, make a mess on the DB but if you have several people managing creating or deleting VMs you might want to opt for MariaDB or Postgres.+Having some experience on database administration made it a little unappealing to use LDAP for central repository and even if I had no DB experience at all I doubt I'd actually want the overhead of running LDAP just for this. Running MariaDB or Postgres was equally unappealing too for my small requirements, so I chose to use sqlite3. In my case it would be extremely rare that, 2 or more simultaneous executions of the management script, make a mess on the DB but if you have several people managing creating or deleting VMs you might want to opt for MariaDB or Postgres. 
 + 
 + 
 +Another thing that quickly became apparent was the almost repetitive code required to prompt for all the options so I decided to address that in 2 ways: 
 +  - have as much of the promoting automatically generated with a clever workaround 
 +  - use dialog to further simplify the UI for prompting
  
-Another thing quickly became apparent was that a lot of code was required to prompt for all the options on the text console. I find that dialog can be really handy for this along with making a better appealing interface. 
  
 ===== Basic Configuration ===== ===== Basic Configuration =====
-To get better flexibility to where things are stored it's a good idea to have a basic configuration file that tells the management script there the important things are:+To get better flexibility for configuring where things are stored it's a good idea to have a basic configuration file that tells the management script where the important things are:
   * Path to folder that will contain all the VMs   * Path to folder that will contain all the VMs
   * Path to where the centralized VM configuration DB is   * Path to where the centralized VM configuration DB is
Line 385: Line 392:
 ===== Using Qemu from Unprivileged Users ===== ===== Using Qemu from Unprivileged Users =====
 Using root for doing your everyday tasks is commonly discouraged so let's see how we can work around using qemu from unprivileged users. Using root for doing your everyday tasks is commonly discouraged so let's see how we can work around using qemu from unprivileged users.
-Some say that it's sufficient to give sudo execution on /etc/qemi-if* but that not really enough, qemu-system-* +Some say that it's sufficient to give sudo execution on /etc/qemi-if* but that not really enough because qemu-system-* needs to run as root or it will not be able to create the taps and access other resources. Although it is technically possible to give an unprivileged user sufficient privileges to execute correctly qemu-system-* emulators it is much easier to give users the sudo right to run qemu-system-* as privileged user. 
 + 
 +  User_Alias QEMUERS = aljohn, jack 
 +   
 +  Cmnd_Alias QEMUCMD = /usr/bin/qemu-system-* 
 +   
 +  QEMUERS ALL=(ALL) NOPASSWD: QEMU 
 + 
 +This would be sufficient to run the VMs as any of the unprivileged users in QEMUERS user alias (al, john, jack) but the management script would need to run sudo qemu-system-* .... this is easy to obtain: 
 + 
 +  [ $(/usr/bin/id -u) -ne 0 ] && CMD="sudo qemu-system-.... " || CMD="qemu-system-...." 
 +  eval $(echo "$CMD &"
 + 
 +Alternatively you could give privileges to execute the management script as root.
 ===== Examples ===== ===== Examples =====
 Here are examples of the dialogs that user would see wile creating, starting, stopping and deleting a VM. Here are examples of the dialogs that user would see wile creating, starting, stopping and deleting a VM.
Line 604: Line 624:
  
 ====== Sources ====== ====== Sources ======
 +I've a blog entry on LQ where I talk a little more extensively on minimizing the code in bash scripts.
 +[[http://www.linuxquestions.org/questions/blog/louigi600-808242/minimize-the-amount-of-code-in-your-bash-scripts-37137/|Minimize the amount of code in your bash scripts ]]
  
 <!-- If you are copying information from another source, then specify that source --> <!-- If you are copying information from another source, then specify that source -->
 howtos:emulators:helper_script_for_managing_qemu_virtual_machines ()