[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
Next revisionBoth sides next revision
howtos:emulators:helper_script_for_managing_qemu_virtual_machines [2016/09/04 19:47 (UTC)] – [Preface] louigi600howtos:emulators:helper_script_for_managing_qemu_virtual_machines [2016/09/04 20:18 (UTC)] – [Basic Configuration] louigi600
Line 14: Line 14:
   * 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
 howtos:emulators:helper_script_for_managing_qemu_virtual_machines ()