BenchKit - CosyVerif
Contents
1. a value is the number of nodes to be activated Nodes are numbered from 1 to a value Each one must be described in a line having the following format node number host name login node number it is a value between 1 and the number of remote nodes specified as shown above it denotes a logical note where virtual machines will be executed to process programs on the examinations for each test host name this is the name or IP address of the physical host to be contacted login is the login to access this host Several logical node can be executed on the same physical node with one or more logins It is better that a public key is installed on the physical machines that will operate the tests For the three txt configuration files empty lines as well as lines beginning with a are ignored Based on these configuration files the main script launch benchmark sh generates one shell script per remote node upload the system to each physical machine and then execute the scripts for each remote node It is possible to set up notification emails in the configuration sh file to be warned when a run is finished or when the execution on a remote node is terminated Remote Nodes execute a subset of the benchmark tests For each involved physical machine the following elements must be set up e a directory to put BenchKit sources and configuration files e a directory to put the image disks for the virtual machines e a2. directory where BenchK it drops its outputs These elements must be specified in the configuration sh file All the physical nodes must respect the same location rules Be sure that the login used for remote nodes have write permission access to the directory where outputs ill be dropped It is important that in the directory containing BenchKit sources there is a file bk private key with the private key associated to the login used to connect the virtual machines This file must have rwx Page 3 out of 13 NN Lf MT 27 RAN mitt 1 TELL Fabrice Kordon BenchKit User Manual 1 MI WR Frid Kordon lip6 fr 11111111 lii BenchKiti head sh Figure 3 Structure of the VM for the login specified for the execution labels in squares are the mandatory ones permission access If this file is not present with the appropriate permission then a password will be required each time BenchK it runs a test You may generate any pair store the private key in bk private key and install the corresponding public key in the ssh directory of both root and the login you use for your tests A default Key is provided it is installed in the default VM we propose The Virtual Machine executes one software on one examination and for one test Execution is performed using a login specified in the configuration sh file environment variable VM LOGIN The corresponding user account must be configured as presented in Figure 3 T
3. runId 135055571500055 _n _1 runnning ExplDecMStrongSE05 on anderson _4 _F003 1t1 We got on stdout Probing ssh Waiting ssh to respond Ssh up and responding Sleep 20 Generated by BenchKit 1 0 Test is anderson _4 _F003 examination is ltl content from stdout START 1350557182 FORMULA properties VIOLATED Explicite SEO5 _OPT VIOLATED BA 0 21 21 22 1UC P _1 p3 FC P _1 p2 lt gt FG P _O p1 STOP 1350557183 content from stderr Figure 7 Example of the execution capture from a tool Page 8 out of 13 An Wmi Tintti SAA iii TITIT F Fabrice Kordon BenchKit User Marh Aill 100000011 WRIT Fer ie Kordon lip6 fr TI ITS Tools CPU Memory over execution for MAPK 160 100 80 fI 60 H 40 ne a es ee 20 o 0 l e d a KA Q E a E execution time s Figure 8 Example of chart generated for the Model Checking Contest Petri Net in 2012 Page 9 out of 13 NN r nit llf N Mi mit Brit I Fabrice Kordon BenchKit User Manuall 100010111 WT Fidri Kordon lip6 fr 11111111 I i Ip x References 1 F Kordon A Linard D Buchs M Colange S Evangelista L Fronc L M Hillah N Lohmann E Paviot Adet F Pommereau C Rohr Y Thierry Mieg and K Wolf Raw Report on the Model Checking Contest at Petri Nets 2012 Technical report CoRR September 2012 2 F Kordon A Linard D Buchs M Colange S Evangelista K Lampka N Lohmann E Pa
4. 00035 n 1 1350560135 76 2 18362003122 14 5 1350560136 35 2 66309068418 15 7 1350560136 91 2 72247867034 16 8 1350560137 5 2 81846807578 17 9 b Sampled CPU and time a Summary file Figure 6 Example of BenchKit CSV outputs e node_ i OUTPUTS there are two types of outputs Your program execution traces stdout and the error traces stderr They respectively display what was displayed during the execution on the virtual machine on stdout and stderr Figure 7 shows an example of execution capture for a tool The trace is encapsulated into two tags START and STOP that show the time in seconds measured at the beginning of the execution and the end of the execution This allows to investigate more deeply in the run files to suppress the data sampled before your tool start These files can be associated to an execution summary thanks to the unique run identifier We highly recommend that the output of your tool is strictly formatted if you want to post process your files in order to extract dedicated information Post analysis The CSV structure as well as the identification of each run via its identifier allows an easy post processing of the collected data The Figure 8 shows an example of chart generated with gnuplot from the sampling files during the model checking contest Petri Nets 2012 It is a quasi immediate use of the data collected by BenchKit See http www gnuplot info execution on node 1 clusterlu26 1ip6 fr
5. AMINATION in StateSpace home mcc BenchKit bin my tool sh gen 1t1 home mcc BenchKit bin my tool sh 1tl 33 echo 0 Wrong invocation gt gt BK_LOG_FILE exit 1 esac Remind that this version of BenchKit does not handle several virtual nodes to be run on the same physical host yet Page 12 out of 13 NM Le AV Tn i Iii Fabrice Kordon BenchKit User Mar All l III IHH Hass Kordon lip6 fr LIT HH B Version History version date comment a Feb 5 2013 First version to be published only one virtual machine per remote host in the context of the Model Checking Contest Petri Nets 2013 Page 13 out of 13
6. COL 225 CSRepetitions COL 400 CSRepetitions COL 625 CSRepetitions COL 900 CSRepetitions PT 025 CSRepetitions PT 049 CSRepetitions PT 100 CSRepetitions PT 225 CSRepetitions PT 400 CSRepetitions PT 625 CSRepetitions PT 900 Dekker PT 02 Dekker PT 05 Dekker PT 10 Dekker PT 15 Dekker PT 20 Dekker PT 50 DrinkVendingMachine PT 001 Echo PT d02r09 Page 11 out of 13 An m jill XM 1111 MN T Fabrice Kordon BenchKit User MadtuAn l III AHHH asd Kordon lip6 fr The tool_list txt file this file name can be parameterized in configuration sh associates examination tools and images disk for virtual machines Here we consider 3 tools MyTooli and MyToo12 that are installed on the same VM and MyToo13 that is installed on another image disk Examinations identifiers are StateSpace and ltl Transmitted value of the environment variable BK EXAMINATION this is a comment starting wtith HOMERO each field is separated by a field 1 Examination name field 2 name of the tool field 3 associated VM disk image StateSpace MyTooli1 mcc 2013 vmdk ltl MyTooli mcc 2013 vmdk StateSpace MyTool2 mcc 2013 vmdk ltl MyTool2 mcc 2013 vmdk StateSpace MyTool3 mcc2 2013 vmdk 1t1 MyTool3 mcc2 2013 vmdk The machine list txt file this file name can be parameterized in configuration sh lists the machines associated to a virtual node 4 Here we consider two hosts sharing a unique login It is advised that connection
7. HIEHETHEIHEHEEHETHEIEEIEEHETHEIHEIEHETHEIEEHIEHEHEIHHEHEHHHEHIEHEHHBHEHHBHHI On the origin machine where you start everything export TOOL_LIST_FILE tool_list txt the file containing the list of tools examination to be processed export TEST LIST FILE inputs list txt the file containing the list of inputs to be processed export REMOTE MACHINES LIST FILE rmachine list txt the list of remote nodes EEREIEEHIEHETHEIHEHEEHETHEIEEIEHETHEIBEHIETHETHEIEHIEHEHEBHEIHEHHIHEHIEHEHHBHEHHHHHER On the execution machines where you operate runs export BENCHKIT DIR BenchKitSources source directory in the physical machines executing the remote nodes export OUTPUT DIR datai directory to put execution outputs export VM_DIRECTORY datal directory where the disk images for virtual machines are located export VM LOGIN mcc the login used on the virtual machine to execute tyour software The input _list txt file this file name can be parameterized in configuration sh specifies the inputs for beanchmarking Each input will correspond to a directory in the HOME BenchKit INPUTS directory where the data required for the benchmark will be located We only provide here the first 25 lines of this file for the MCC 2013 it is about 250 lines length this is a comment starting with EHEIEERIEHEHEIBHERHEHHEHHEHHHBHBHEBNE each line represent one input CSRepetitions COL 025 CSRepetitions COL 049 CSRepetitions COL 100 CSRepetitions
8. Version 81 February 5 2013 u NY T A mitt 21110 TULIT TT m PUAN se HH VILA OW I USER M 1881 SORBONNE UNIVERSIT S Contents 1 Introduction What is BenchKit 2 The BenchKit Architecture 3 How to use BenchKit 4 BenchKit Outputs References A An Example B Version History N http benchkit cosyverif org Fabrice Kordon Fabrice KordonQOlip6 fr ant HET TITHTIE Te iif A HINA T HEEL RA apes 10 11 13 Warning the current version of BenchKit does not yet handle the execution of several virtual machine on the same remote node that is mentioned in the current document This is to be fixed in a later version of this tool Developers BenchKit was primarily developed by Fabrice Kordon with the precious help of Nicolas Gibelin Francis Hulin Hubard and Franck Pommereau mostly for the virtual machine stuff as well as the monitoring aspects BenchKit is developed within the context of the Cosy V erif project founded by three laboratories in the Paris area LIP6 universit Pierre amp Marie Curie LIPN Universit Paris Nord and LSV Ecole Nationale Sup rieure de Cachan Inttp cosyverif org Sm INN If RN VA i H1 l Fabrice Kordon BenchKit User Manual 1 HH III Hha Kordon lip6 fr 11111111 ALAA 1 Introduction What is BenchKit Do you want to evaluate time and memory consumption of any software BenchKit is made for you This is a tool that allows you to e
9. a separate file default vm vmdk You may use it to set up your programs default user login is mcc or set up another one with your dedicated settings Deployment of BenchKit on the remote nodes as well as some checks is performed using launch benchmark sh This commands provides online help as shown below nttp benchkit cosyverif org BENHMARKS bk private key zip Downloadable at benchkit cosyverif org BENCHMARKS BK empty vmdk zip It runs a Linux Debian 7 0 in 32 bit mode Page 5 out of 13 An T XM im 11 Es Fabrice Kordon BenchKit User Marh All HH III HEA Kordon lip6 fr 11111111 l THE sh launch benchmark sh help usage launch benchmark sh deploy effective deploy enforces the deployment of all scripts on the target machines and checks for the existence of image files for the VMs effective requested to execute the files on the remote nodes otherwise only the files to be executed are generated for checks BenchKit is distributed under the GPL licence 3 How to use BenchKit This section shows how to use BenchKit to perform measures on a software There are two steps e preparation of your software e launching a benchmark once your software is prepared Preparing Your Software Preparing your software to be executed under BenchKit is relatively simple You just have to elaborate the image disk to be executed in the virtual machine The main actions are 1 Compile your programs ta
10. all architecture of BenchKit It follows a classical master slave structure By similarity to the terminology of cluster computing we call head the master part and remote the slave nodes Hardware Architecture The BenchKit architecture is depicted in Figure 1 We distinguish two types of machine the head machine and the remote nodes The distinction is conceptual since all these machines can be located in a unique physical one However these two types of machine do have different roles The head machine is the one where an analysis is started It contains the scripts and the three configuration files e a list of inputs to be processed e a list of programs associated to VMs to process these tests e a list of remote machines where these programs will operate the tests The remote nodes are the computers processing the tests This notion is logical since there can be several remote nodes per physical computer Typically a multi core computer can host several nodes if it contains a sufficient amount of memory See http www uppaal org Page 1 out of 13 An MAN Mi T 1 l Fabrice Kordon BenchKit User Marh All 101100011 HHHHH HEA Kordon lip6 fr 11101111 IN head machine ii P Figure 1 the BenchKit hardware architecture remote nodes To operate BenchKit we assume that all physical machines operate Unix BenchKit was developed and experimented under Linux Execution of the programs will b
11. d software may perform several type of computations This is required by ssh otherwise it does not accept the Key SOf course only the one of the virtual machine http benchkit cosyverif org BENHMARKS bk private key zip Page 4 out of 13 age An La ho TT 7 Xy im Mri ll Fabrice Kordon BenchKit User Manh llll III 9 III Hui Kordon lip6 fr AN Hd 1s 1h total 6704 4768 rw r r 1 fko fko 2 3M 21 oct 22 36 BenchKit pdf fko fko 1 6K 21 oct 22 36 bk private key fko fko 1 2K 21 oct 22 36 configuration sh fko fko 52B 21 oct 22 36 halt a vm sh fko fko 983B 21 oct 22 36 invocation template txt fko fko 2 7K 21 oct 22 36 launch a command sh fko fko 1 2K 21 oct 22 36 launch a run sh fko fko 219B 21 oct 22 36 launch a vm sh fko fko 8 7K 21 oct 22 36 launch benchmark sh fko fko 911K 21 oct 22 36 monitor supp tgz fko fko 561B 21 oct 22 36 rmachine list txt fko fko 260B 21 oct 22 36 test list txt fko fko 655B 21 oct 22 36 tool list txt fko fko 943B 21 oct 22 36 vm sh l H z I I m 4 00 OO CO OO OO l H 1 H I l H l l e N 1824 rw r r 00 I H F H I H l l e PRPRPRPRPRRPRP PRP qu 00 l H 1 H l l H l l e Figure 4 Content of the distribution e BK INPUT this variable contains the name of the current input being processed This can be useful when invoking your tool but it allows BenchKit to go in the appropriate test director
12. e performed under virtual machines we heavily experimented virtual machines under Linux but Windows is supported too provided that CygWin is installed Prerequisite BenchKit requires bash and python to be installed on the head machine and the remote nodes It also requires qemu to be installed on the remote nodes It is highly recommended that the physical machines where remote nodes are executed operate hardware acceleration of virtual machines otherwise execution is very slow Software Architecture The software architecture of BenchKit is dispatched over threes entities the head machine the remote nodes and the virtual machines that contain the software to be executed head machine remote nodes virtual machines i configuration files sources dir inputs dir source dir VM dir head script outputs dir binaries private ssh key public ssh key Figure 2 the BenchKit software architecture The Head Machine hosts the source the configuration files The main script is launch benchmark sh It is operated when you want to launch and distribute the execution of your tools over the remote nodes It uses information gathered from five configuration files e configuration sh allows you to refer to the other configuration files and to set up the time and memory you allocate to your software to be executed e tool list txt defines the list of tools and functions to be operated Each line defi
13. he HOME must contain a directory named BenchKit that must contain the BenchKit head script i e the one communicating with the invocation system It also contains the INPUTS directory for inputs itself containing one directory per test to be performed We recommend to locate in BenchKit a bin directory that contains the binaries of your software However this last directory can be located elsewhere Important be sure to provide binaries compatible with the architecture of the VM Moreover these binaries must be standalone i e they are compatible with the installation of the VM you use Structure of the INPUTS directory The philosophy is to establish one directory per test This directory must contain all the files needed to process your tool on a given test for all the examinations listed in the tool list txt file It is important to note that BenchKit goes in this directory prior to invoke BenchKit head sh Thus your software can find all the required data in its current directory The role of BenchKit head sh this shell script is invoked by BenchKit with the following environment variables set up e BK TOOL this variable contains the name of the invoked program Then if you have several programs located in the same virtual machine BenchKit head sh can select the appropriate one e BK EXAMINATION this variable contains the name of the action your software must perform This is a way to select an action when the evaluate
14. king in account the constraints of the VM OS 2 set up the image disk of the virtual machine with your compiles programs and the tests to be processed In particular you must install the public key that allows to connect to this virtual machine if you d not use the provided default one You must also implement BenchKit head sh to invoke appropriately your tool as explained in section 2 3 deploy the disk images on the remote nodes 4 Configure BenchKit as specified in section 2 Launching a benchmark Once the virtual machine is ready and deployed on the nodes you must deploy BenchKit unless this has been already done Type the following command sh launch benchmark sh deploy BenchKit deploy the sources on the executing physical machines you must do that each time you change the remote node configuration and checks if the disk images are located where expected The scripts to be executed on the remote nodes are also generated you may want to check them they are named BenchKit node node sh If you want to regenerate these scripts you may type sh launch benchmark sh To generate these scripts and launch the tests on the remote nodes then type sh launch benchmark sh effective This can take a while it can be useful to have emails sent regularly to follow the progression of the execution This is configured in configure sh Emails title are formatted to let you set up rules then enabling a redirection into a dedica
15. nes a tool to be operated and must respect the following format examination name software name vm image name 3see http www cygwin com Checks were done with bash version 4 2 8 5Checks were done with python version 2 7 1 This the default name of this file you can modify it by changing the default value of the corresponding environment variable in configuration sh Page 2 out of 13 i 2 o Wi ni Lf eee LAT VELLA RAN IILH Fabrice Kordon BenchKit User Manuall 140001111 TT Kor onelipe er 11111111 HH MIT LLL examination name is an identifier that will be passed to the virtual machine it denotes the function to activate in your software software_name is the identifier of the program to be activated on the virtual machine vm_image_name is the image disk to be operated by the virtual machine You can set up as many programs as you want in a virtual machine as long as the head BenchKit script see later is able to recognize them and launch the appropriate one e test list txt defines a list of test identifier to be processed for each tool There is one test identifier per line Each of this identifier corresponds to a directory where all the date to be processed for an examination by a given program is located e rmachine list txt defines the list of nodes that will execute the programs It must define the number of remote nodes in the following way NB REMOTE NODES a value where
16. ted mailbox Page 6 out of 13 An AN Wow M l Fabrice Kordon BenchKit User Manual 1 I III qm Kordon lip6 fr HH 4 BenchKit Outputs This section describes the output provided by BenchKit These can be sent automatically by email when the execution on a remote node is terminated After the execution all the information remains in the output directory you specified It is erased when you launch a new benchmark on the same machines with the same configurations The outputs from BenchKit The archive as well as the remaining information on the physical machine is structured as shown in Figure 5 It contains three directories e node_ i CONFIGURATIONS the information was initially intended for debug purpose but it remains since it can be useful to understand how your programs behave on the virtual machine It basically provides the list of commands executed to operate your tool for a given configuration one file per test x examination processed on this node e node i CSV it contains two types of CSV files summarizing the executions performed on the remote node see Figure 6 files summary tool csv provide a summary of the executions performed for tool on the node Each line reports a run in the following format column per column l the name of the tool in order to merge these files later the name of the test the name of the examination performed on the test the maximum amount of memory
17. to these machines are handled b a pair of public private keys this is a comment starting wtith EREREHETEEEEHEHEHEHEHETETETEHEHEHEHEHEEEHEIEI I B TE each field is separated by a specify number of machines NB REMOTE NODES 2 specify machines one by one with the following format tt field 1 number of the machine description between 1 and the value specified with NB MACHINE field 2 hostname field 3 login for that host assume ssh key allows to log without requesting a password r cluster1u26 1ip6 fr fkordon 2 clusteriu27 1ip6 fr fkordon The BenchKit head sh file this file is the one located on the image Disk to make a link between BenchKit and the software to be evaluated bin bash TEIIEETHETHETHERETHETHETHBIETHETHEI BETHETHETHBIETHETHEIHBETHEIHETHBIETHETHEI BETHETHEI BETHEIHEHBEIHEIHEI BER RN This is an example for the MCC 2013 TEEIEETHETHETHERETHETHEIHBIETHETHEI BETHETHETHBIETHETHEIHBETHETHEIHBETHETHEI BETHETHEIHBETHEIHEIHHEIHEIHE BER BR In this script you will affect values to your tool in order to let BenchKit launch it in an apropriate way AEEIEETHETHETHERETHETHEIHBIETHETHEI BIETHETHETHBIETHETHEI BIETET BETHETHEI BETHETHEIHBETHEIHEIHBEIHEIHH BER BR BK EXAMINATION it is a string that identifies your examination BK INPUT it is a string that identifies your test used to build the name of the directory where you execute export PATH PATH home mcc BenchKit bin case BK EX
18. used during the execution percentage the average percentage of CPU used during the execution the time required to execute your program the status of the termination normal or timeout when time confinement is reached a unique run identifier that allows you to access additional data files run tool test runId n i csv provide for a given run identifier regular samples of CPU and memory consumption as a percentage Each line contains three columns time seconds since 1970 of sampling CPU sampled at this time percentage memory sampled at this time percentage Figure 6 shows examples of the data BenchKit produces This identifier is unique even considering an execution on several remote nodes ls lh archive node 1 total O O drwxr xr x 4 xxx xxx 136B 18 oct 13 27 node_1_CONFIGURATIONS O drwxr xr x 42 xxx xxx 1 4K 18 oct 13 50 node 1 CSV O drwxr xr x 58 xxx xxx 1 9K 18 oct 13 49 node 1 OUTPUTS Figure 5 Structure of the archive provided for a node 1 in our example Page 7 out of 13 An l MF NAM TOR TITLE Fabrice Kordon BenchKit User Marh All II TL HEA Kordon lip6 fr HH 1350560133 4 2 18068239019 13 6 1350560133 98 2 18020601597 13 5 1350560134 57 2 23562421696 13 6 tool test 1 1t1 2 68151048738 17 5 7 23868918419 normal 135055571400033 n 1 1350560135 17 2 17822112339 13 9 tool test 2 1t1 2 55138092947 16 1 6 51366186142 timeout 1350555714
19. valuate these data It measures e the time to run your software the user experience point of view e the CPU average consumption of your software e the maximum memory used by your software e the evolution of time and CPU over the execution of your software as a percentage of what is allocated BenchK it is of particular interest when you want to evaluate these on numerous inputs for a given program You also confine the software execution up to a maximal execution time or memory usage Compared to other solutions such as memtime an efficient solution developed by the UPPAAL commu nity BenchKit is able to evaluate memory and CPU consumption of multi processes or multi threaded applications A Typical use BenchKit was elaborated aside the Model Checking Contest Petri Net in 2011 and 2012 where several model checking tools are evaluated against a set of models 2 1 Preliminary versions were also used to benchmark prototype tools for various papers Where BenchKit could be operated BenchKit has been designed to be operated on any type of machine It is mostly of interest when you have access to a cluster or a machine with numerous cores and a large amount of memory BenchKit runs under Unix but is based on virtual machines technology Thus the virtual machine can embed other types of operating systems So far it has been tested for Linux windows virtual machines 2 The BenchKit Architecture This section presents the over
20. viot Adet Y Thierry Mieg and H Wimmel Report on the Model Checking Contest at Petri Nets 2011 Transactions on Petri Nets and Other Models of Concurrency ToPNoC V1 169 196 march 2012 Page 10 out of 13 NN AL iti Ain Fabrice Kordon BenchKit User MadtuAn 1 HII Ir ie Kordon lip6 fr iLL A An Example We provide here the default configuration for a simple example It is based on the configuration to be used for the Model Checking Contest Petri Nets 2013 The configuration sh file It specifies the main elements where data are taken by BenchKit and results sent by BenchKit Here confinement is 5 minutes and 2GByte HHHHHRRRRERRRRIRRIHRRIRRIRRIHRERRIRBIHRHIRBIRRHERERHERRIHFRIHIRBIRRHFRIERHIRBIHFRIHIHBIHRIHFRIERIHIRHIHIHIHIHIENE This is the configuration file of the benchmark kit TEIIEETHETHETHERETHETHEIHBIETHETHEI BETHETHETHBIETHETHETIHBETHETHET BETHETHEI BETHETHERHBETHEIHEI HETHEIHE BER RN TERETEHEETEEEHEREHEHEHETETETEHEREREHEHEETETETEREREHEHEHETETETEREHEREHEHETETETEHEREHEHEHEETETEEREHEH HE E EE EEG Benchkit not touch please BENCHKIT VERSION 1 0 HOMERO General configuration EMAIL_GLOBAL_REPORT Fabrice KordonClip6 fr empty if no global report by email they are in the output_directory EMAIL_RUN_REPORT Fabrice Kordon lip6 fr empty if no execution report by email they are in the output_directory TIME_CONFINMENT 300 duration in seconds MEM_CONFINMENT 2048 memory in megaByte EEREIEE
21. y prior to the invocation of your software The BenchKit head sh file is your way to interface your programs with BenchKit You most probably want to normalize outputs in order to perform post processing of the collected data see section 4 Distribution The content of the BenchKit distribution is shown in Figure 4 The main files to be considered are e BenchKit pdf this documentation e bk private key the default private key associated to the default public kay proposed in the default disk image allows access to root and the default user login proposed in the virtual machine that executes your program it is to be replaced by another couple public private key if you want so do not mismatch with the public private keys used to connect to remote nodes e configuration sh the script where the main configuration variables are set You need to check these in order to adapt BenchKit to your own configuration e launch benchmark sh the main script that launches the execution of your program on all tests once the virtual machine and all data have been configured e a default image disk to be used in a VM This dish image is compatible with qemu used by BenchKit or VirtualBox On a Linux machine with qemu kvm installed it can be operated with the launch a vm sh and halt a vm sh service scripts that allow to manually start stop a virtual machine to configure it A default virtual machine Linux 32bits Unbuntu is also provided in
Download Pdf Manuals
Related Search