Comment lancer une machine virtuelle de Virtualbox au démarrage de Linux ?
17 réponses
Francois Lafont
Bonjour à tous,
Je suis sous Ubuntu 9.04 (Jaunty) et j'utilise Virtualbox
version 3.1.6 et, je préfère vous prévenir, je ne suis pas
très calé en shell etc.
Je souhaiterais lancer une machine virtuelle au démarrage
(et non à l'ouverture de session) de mon PC. En fait, je
pensais que ce n'était pas possible, mais quelques
recherches sur Internet semblaient indiquer que si.
Voici mes deux tentatives qui ne marchent pas :
1) Si je lance en ligne de commandes
~$ /usr/bin/VBoxVRDP --startvm XPpro
alors ma machine virtuelle "XPpro" se lance sans interface
graphique et je peux bien accéder à cette machine via une
prise en main à distance. J'ai pu voir, qu'au démarrage de
Ubuntu, le script /etc/rc.local était le dernier script
exécuté. Du coup, j'ai édité rc.local comme ceci :
Je redémarre le PC : pas de machine virtuelle lancée. Dans,
le fichier sortie.txt, rien, le vide complet.
2) Autre tentative, qui dépasse largement mes compétences,
faire un service via les scripts du dossier /etc/init.d/. Je
ne sais pas faire mais il y avait cette page qui avait l'air
bien :
D'après la doc, VBoxManage ne renvoie pas de log. Il faut utiliser VBoxHeadless, donc : sudo -H -u $VM_OWNER VBoxHeadless --startvm $VM_NAME >>ton_log || {
au moins tu devrais avoir du grain à moudre dans ton log.
Même pas hélas. En mettant la ligne que tu donnes ci-dessus, lorsque je tape /etc/init.d/virtualbox-XPpro start :
a) nouveau, je n'ai jamais la main sur le prompt b) la machine virtuelle est bien lancée et j'y ai accès. c) si j'éteins la machine virtuelle, alors j'ai à nouveau la main sur le prompt et le log contient ceci :
#---------------------------- Sun VirtualBox Headless Interface 3.1.6 (C) 2008-2010 Sun Microsystems, Inc. All rights reserved.
Listening on port 3389. VRDP server is inactive. #----------------------------
Pas grand chose à moudre.
Comment se fait-il qu'après /etc/init.d/virtualbox-XPpro start je n'ai pas immédiatement la main sur le prompt ? Ce n'est pas normal, non ?
Dans tous les différents essais de etc/init.d/virtualbox-XPpro start, je n'ai jamais la main juste après sur le prompt.
-- François Lafont
Toxico Nimbus a écrit :
D'après la doc, VBoxManage ne renvoie pas de log. Il faut utiliser
VBoxHeadless, donc :
sudo -H -u $VM_OWNER VBoxHeadless --startvm $VM_NAME >>ton_log || {
au moins tu devrais avoir du grain à moudre dans ton log.
Même pas hélas. En mettant la ligne que tu donnes ci-dessus,
lorsque je tape /etc/init.d/virtualbox-XPpro start :
a) nouveau, je n'ai jamais la main sur le prompt
b) la machine virtuelle est bien lancée et j'y ai accès.
c) si j'éteins la machine virtuelle, alors j'ai à nouveau la
main sur le prompt et le log contient ceci :
#----------------------------
Sun VirtualBox Headless Interface 3.1.6
(C) 2008-2010 Sun Microsystems, Inc.
All rights reserved.
Listening on port 3389.
VRDP server is inactive.
#----------------------------
Pas grand chose à moudre.
Comment se fait-il qu'après /etc/init.d/virtualbox-XPpro
start je n'ai pas immédiatement la main sur le prompt ? Ce
n'est pas normal, non ?
Dans tous les différents essais de
etc/init.d/virtualbox-XPpro start, je n'ai jamais la main
juste après sur le prompt.
D'après la doc, VBoxManage ne renvoie pas de log. Il faut utiliser VBoxHeadless, donc : sudo -H -u $VM_OWNER VBoxHeadless --startvm $VM_NAME >>ton_log || {
au moins tu devrais avoir du grain à moudre dans ton log.
Même pas hélas. En mettant la ligne que tu donnes ci-dessus, lorsque je tape /etc/init.d/virtualbox-XPpro start :
a) nouveau, je n'ai jamais la main sur le prompt b) la machine virtuelle est bien lancée et j'y ai accès. c) si j'éteins la machine virtuelle, alors j'ai à nouveau la main sur le prompt et le log contient ceci :
#---------------------------- Sun VirtualBox Headless Interface 3.1.6 (C) 2008-2010 Sun Microsystems, Inc. All rights reserved.
Listening on port 3389. VRDP server is inactive. #----------------------------
Pas grand chose à moudre.
Comment se fait-il qu'après /etc/init.d/virtualbox-XPpro start je n'ai pas immédiatement la main sur le prompt ? Ce n'est pas normal, non ?
Dans tous les différents essais de etc/init.d/virtualbox-XPpro start, je n'ai jamais la main juste après sur le prompt.
-- François Lafont
Francois Lafont
Francois Lafont a écrit :
Comment se fait-il qu'après /etc/init.d/virtualbox-XPpro start je n'ai pas immédiatement la main sur le prompt ? Ce n'est pas normal, non ?
J'ai regardé dans la doc de Virtualbox et ils disent de "VBoxManage startvm" que, je cite, "This is provided for backwards compatibility". Ils recommandent plutôt un truc comme :
VBoxHeadless --startvm "XPpro" --vrdp=off
qui d'ailleurs fonctionne dans le script virtualbox-XPpro (en tout cas, ça lance bien la machine virtuelle), mais je n'ai pas la main sur le prompt juste après. J'obtiens la main qu'une fois la MV éteinte. Et là c'est logique car il se passe exactement la même chose quand je lance manuellement la commande
VBoxHeadless --startvm "XPpro" --vrdp=off
Donc mon problème, c'est que la commande ad hoc (VBoxHeadless) pour lancer la VM sans GUI ne redonne pas la main et donc, dans la fonction do_start() du script, ceci
echo "$VM_NAME" started or resumed. return 0 } #-------------------------------
ne peut pas fonctionner à cause du "||" qui fait que le script attend la valeur de retour de la commande VBoxHeadless qui ne viendra qu'une fois la VM éteinte.
Mais si je remplace ce qui précède par simplement ça :
echo "$VM_NAME" started or resumed. return 0 } #-------------------------------
alors le /etc/init.d/virtualbox-XPpro start fonctionne mais je perds la partie "Désolé le lancement a échoué". C'est grave ? Y a-t-il moyen de faire quelque chose pour avoir le beurre et l'argent du beurre ?
Ensuite, il va falloir regarder l'aspect "stoppage" du service...
-- François Lafont
Francois Lafont a écrit :
Comment se fait-il qu'après /etc/init.d/virtualbox-XPpro start je n'ai
pas immédiatement la main sur le prompt ? Ce n'est pas normal, non ?
J'ai regardé dans la doc de Virtualbox et ils disent de
"VBoxManage startvm" que, je cite, "This is provided for
backwards compatibility". Ils recommandent plutôt un truc
comme :
VBoxHeadless --startvm "XPpro" --vrdp=off
qui d'ailleurs fonctionne dans le script virtualbox-XPpro
(en tout cas, ça lance bien la machine virtuelle), mais je
n'ai pas la main sur le prompt juste après. J'obtiens la
main qu'une fois la MV éteinte. Et là c'est logique car il
se passe exactement la même chose quand je lance
manuellement la commande
VBoxHeadless --startvm "XPpro" --vrdp=off
Donc mon problème, c'est que la commande ad hoc
(VBoxHeadless) pour lancer la VM sans GUI ne redonne pas la
main et donc, dans la fonction do_start() du script, ceci
echo "$VM_NAME" started or resumed.
return 0
}
#-------------------------------
ne peut pas fonctionner à cause du "||" qui fait que le
script attend la valeur de retour de la commande
VBoxHeadless qui ne viendra qu'une fois la VM éteinte.
Mais si je remplace ce qui précède par simplement ça :
echo "$VM_NAME" started or resumed.
return 0
}
#-------------------------------
alors le /etc/init.d/virtualbox-XPpro start fonctionne mais
je perds la partie "Désolé le lancement a échoué". C'est
grave ? Y a-t-il moyen de faire quelque chose pour avoir le
beurre et l'argent du beurre ?
Ensuite, il va falloir regarder l'aspect "stoppage" du
service...
Comment se fait-il qu'après /etc/init.d/virtualbox-XPpro start je n'ai pas immédiatement la main sur le prompt ? Ce n'est pas normal, non ?
J'ai regardé dans la doc de Virtualbox et ils disent de "VBoxManage startvm" que, je cite, "This is provided for backwards compatibility". Ils recommandent plutôt un truc comme :
VBoxHeadless --startvm "XPpro" --vrdp=off
qui d'ailleurs fonctionne dans le script virtualbox-XPpro (en tout cas, ça lance bien la machine virtuelle), mais je n'ai pas la main sur le prompt juste après. J'obtiens la main qu'une fois la MV éteinte. Et là c'est logique car il se passe exactement la même chose quand je lance manuellement la commande
VBoxHeadless --startvm "XPpro" --vrdp=off
Donc mon problème, c'est que la commande ad hoc (VBoxHeadless) pour lancer la VM sans GUI ne redonne pas la main et donc, dans la fonction do_start() du script, ceci
echo "$VM_NAME" started or resumed. return 0 } #-------------------------------
ne peut pas fonctionner à cause du "||" qui fait que le script attend la valeur de retour de la commande VBoxHeadless qui ne viendra qu'une fois la VM éteinte.
Mais si je remplace ce qui précède par simplement ça :
echo "$VM_NAME" started or resumed. return 0 } #-------------------------------
alors le /etc/init.d/virtualbox-XPpro start fonctionne mais je perds la partie "Désolé le lancement a échoué". C'est grave ? Y a-t-il moyen de faire quelque chose pour avoir le beurre et l'argent du beurre ?
Ensuite, il va falloir regarder l'aspect "stoppage" du service...
-- François Lafont
Francois Lafont
Bon, concernant le démarrage du service, la commande
VBoxHeadless --startvm "XPpro" --vrdp off >/dev/null &
me convient très bien, même s'il est impossible de savoir si la commande s'est bien passée.
En revanche, pour l'arrêt du service, le script que j'ai donné dans un de mes premiers messages revient à faire ça :
VBoxManage controlvm "XPpro" savestate
ce qui sauvegarde l'état de l'OS. Mais cela ne me convient pas trop. Moi, je préférerais que l'arrêt du service provoque plutôt un "vrai" shutdown "bien propre" de la VM (car en fait la VM ne sera pas un XPpro mais en principe un petit serveur windows). Et là, j'ai un souci.
Il y a bien la commande
VBoxManage controlvm "XPpro" acpipowerbutton
qui fait exactement cela (un shutdown "bien propre"), en tout cas quand la VM est lancée *via l'interface graphique*. Car, quand la VM est lancée en mode "remote virtual machine" (pour reprendre l'expression de la doc de Virtualbox), c'est-à-dire avec la commande
VBoxHeadless --startvm "XPpro" --vrdp off >/dev/null &
alors là, comme par hasard, l'option "acpipowerbutton" ne fonctionne pas. Je vois une option possible : lancer un shutdown de la VM par le réseau, sachant que la machine hôte est un Linux. Question : comment peut-on faire ça en ligne de commande de manière automatique ?
Si j'arrive à faire ça, je crois que je tiendrai un script qui me conviendra à peu près.
-- François Lafont
Bon, concernant le démarrage du service, la commande
VBoxHeadless --startvm "XPpro" --vrdp off >/dev/null &
me convient très bien, même s'il est impossible de savoir si
la commande s'est bien passée.
En revanche, pour l'arrêt du service, le script que j'ai
donné dans un de mes premiers messages revient à faire ça :
VBoxManage controlvm "XPpro" savestate
ce qui sauvegarde l'état de l'OS. Mais cela ne me convient
pas trop. Moi, je préférerais que l'arrêt du service
provoque plutôt un "vrai" shutdown "bien propre" de la VM
(car en fait la VM ne sera pas un XPpro mais en principe un
petit serveur windows). Et là, j'ai un souci.
Il y a bien la commande
VBoxManage controlvm "XPpro" acpipowerbutton
qui fait exactement cela (un shutdown "bien propre"), en
tout cas quand la VM est lancée *via l'interface graphique*.
Car, quand la VM est lancée en mode "remote virtual machine"
(pour reprendre l'expression de la doc de Virtualbox),
c'est-à-dire avec la commande
VBoxHeadless --startvm "XPpro" --vrdp off >/dev/null &
alors là, comme par hasard, l'option "acpipowerbutton" ne
fonctionne pas. Je vois une option possible : lancer un
shutdown de la VM par le réseau, sachant que la machine hôte
est un Linux. Question : comment peut-on faire ça en ligne
de commande de manière automatique ?
Si j'arrive à faire ça, je crois que je tiendrai un script
qui me conviendra à peu près.
Bon, concernant le démarrage du service, la commande
VBoxHeadless --startvm "XPpro" --vrdp off >/dev/null &
me convient très bien, même s'il est impossible de savoir si la commande s'est bien passée.
En revanche, pour l'arrêt du service, le script que j'ai donné dans un de mes premiers messages revient à faire ça :
VBoxManage controlvm "XPpro" savestate
ce qui sauvegarde l'état de l'OS. Mais cela ne me convient pas trop. Moi, je préférerais que l'arrêt du service provoque plutôt un "vrai" shutdown "bien propre" de la VM (car en fait la VM ne sera pas un XPpro mais en principe un petit serveur windows). Et là, j'ai un souci.
Il y a bien la commande
VBoxManage controlvm "XPpro" acpipowerbutton
qui fait exactement cela (un shutdown "bien propre"), en tout cas quand la VM est lancée *via l'interface graphique*. Car, quand la VM est lancée en mode "remote virtual machine" (pour reprendre l'expression de la doc de Virtualbox), c'est-à-dire avec la commande
VBoxHeadless --startvm "XPpro" --vrdp off >/dev/null &
alors là, comme par hasard, l'option "acpipowerbutton" ne fonctionne pas. Je vois une option possible : lancer un shutdown de la VM par le réseau, sachant que la machine hôte est un Linux. Question : comment peut-on faire ça en ligne de commande de manière automatique ?
Si j'arrive à faire ça, je crois que je tiendrai un script qui me conviendra à peu près.
-- François Lafont
Francois Lafont
Bon petit à petit j'arrive à quelque chose qui fonctionne en manuel, c'est-à-dire que
fonctionnent (bon, j'ai bien des petits soucis sur quelques trucs, mais on verra plus tard). Ensuite, j'installe le service comme ceci :
sudo update-rc.d virtualbox-XPpro defaults
Ensuite je teste un redémarrage de mon poste. Au démarrage j'ai bien la VM accessible. Mais à l'arrêt du poste hôte, des processus concernant Virtualbox sont tués *avant* l'arrêt de mon service, si bien que cela tue mon service mais pas de manière propre (*avant* qu'il ne se stoppe lui-même).
Comment faire pour que mon service soit arrêté en premier lors de l'extinction du poste et que, ce soit seulement une fois mon service stoppé que le poste tue les processus restants et finit son extinction ?
Merci d'avance.
-- François Lafont
Bon petit à petit j'arrive à quelque chose qui fonctionne en
manuel, c'est-à-dire que
fonctionnent (bon, j'ai bien des petits soucis sur quelques
trucs, mais on verra plus tard). Ensuite, j'installe le
service comme ceci :
sudo update-rc.d virtualbox-XPpro defaults
Ensuite je teste un redémarrage de mon poste. Au démarrage
j'ai bien la VM accessible. Mais à l'arrêt du poste hôte,
des processus concernant Virtualbox sont tués *avant*
l'arrêt de mon service, si bien que cela tue mon service
mais pas de manière propre (*avant* qu'il ne se stoppe
lui-même).
Comment faire pour que mon service soit arrêté en premier
lors de l'extinction du poste et que, ce soit seulement une
fois mon service stoppé que le poste tue les processus
restants et finit son extinction ?
fonctionnent (bon, j'ai bien des petits soucis sur quelques trucs, mais on verra plus tard). Ensuite, j'installe le service comme ceci :
sudo update-rc.d virtualbox-XPpro defaults
Ensuite je teste un redémarrage de mon poste. Au démarrage j'ai bien la VM accessible. Mais à l'arrêt du poste hôte, des processus concernant Virtualbox sont tués *avant* l'arrêt de mon service, si bien que cela tue mon service mais pas de manière propre (*avant* qu'il ne se stoppe lui-même).
Comment faire pour que mon service soit arrêté en premier lors de l'extinction du poste et que, ce soit seulement une fois mon service stoppé que le poste tue les processus restants et finit son extinction ?
Merci d'avance.
-- François Lafont
Francois Lafont
Francois Lafont a écrit :
sudo update-rc.d virtualbox-XPpro defaults
J'ai fait ça finalement
sudo update-rc.d virtualbox-XPpro defaults 99 0
Le 99 c'est pour que le service se lance en dernier au démarrage (ça semble ok) et le 0 c'est pour qu'il se lance en premier à l'extinction et là ça ne marche pas.
J'ai mis un simple
echo Salut > /francois/home/Bureau/out.txt
dans la fonction do_stop() et pourtant rien sur mon Bureau. À croire que la commande /etc/init.d/virtualbox-XPpro stop (qui fonctionne) n'est jamais lancée à l'extinction ? Si quelqu'un a une idée, je lui en serais très reconnaissant... :-)
-- François Lafont
Francois Lafont a écrit :
sudo update-rc.d virtualbox-XPpro defaults
J'ai fait ça finalement
sudo update-rc.d virtualbox-XPpro defaults 99 0
Le 99 c'est pour que le service se lance en dernier au
démarrage (ça semble ok) et le 0 c'est pour qu'il se lance
en premier à l'extinction et là ça ne marche pas.
J'ai mis un simple
echo Salut > /francois/home/Bureau/out.txt
dans la fonction do_stop() et pourtant rien sur mon Bureau.
À croire que la commande /etc/init.d/virtualbox-XPpro stop
(qui fonctionne) n'est jamais lancée à l'extinction ? Si
quelqu'un a une idée, je lui en serais très reconnaissant... :-)
Le 99 c'est pour que le service se lance en dernier au démarrage (ça semble ok) et le 0 c'est pour qu'il se lance en premier à l'extinction et là ça ne marche pas.
J'ai mis un simple
echo Salut > /francois/home/Bureau/out.txt
dans la fonction do_stop() et pourtant rien sur mon Bureau. À croire que la commande /etc/init.d/virtualbox-XPpro stop (qui fonctionne) n'est jamais lancée à l'extinction ? Si quelqu'un a une idée, je lui en serais très reconnaissant... :-)
-- François Lafont
Francois Lafont
Bonjour à tous,
je me permets de relancer le fil car je suis vraiment à 2 doigts de toucher au but. Je me heurte à un dernier problème.
Quand je lance la commande suivante en tant que root
J'ai bien ma VM qui est lancée et quand je tape ceci
# sudo -H -u francois VBoxManage showvminfo "XPpro" | grep "^State" State: running # <-- ok la VM est lancée
j'ai bien une ligne qui s'affiche contenant "running" ce qui signifie que la VM est bien lancée.
En revanche, via un script de démon /etc/init.d/MyVM, avec la même commande de lancement (celle cité au dessus), la VM est bien lancée, en revanche, quand je teste le lancement avec la ligne de commande
# sudo -H -u francois VBoxManage showvminfo "XPpro" | grep "^State" State: powered off # <-- la VM est vue en mode off
J'obtiens une ligne m'indiquant que la VM est éteinte, alors que c'est faux, la preuve, j'ai accès à cette VM via le réseau !?!
Avez vous une explication ? Ce point est important car dans mon script de démon, j'utilise pas mal la commande ci-dessus pour tester si la VM est bien lancée.
Comment expliquer cette différence de comportement entre une commande faite en ligne de commande et la *même* commande lancée à travers un script de démon ?
Merci d'avance.
-- François Lafont
Bonjour à tous,
je me permets de relancer le fil car je suis vraiment à 2
doigts de toucher au but. Je me heurte à un dernier problème.
Quand je lance la commande suivante en tant que root
J'ai bien ma VM qui est lancée et quand je tape ceci
# sudo -H -u francois VBoxManage showvminfo "XPpro" | grep
"^State"
State: running # <-- ok la VM est lancée
j'ai bien une ligne qui s'affiche contenant "running" ce qui
signifie que la VM est bien lancée.
En revanche, via un script de démon /etc/init.d/MyVM, avec
la même commande de lancement (celle cité au dessus), la VM
est bien lancée, en revanche, quand je teste le lancement
avec la ligne de commande
# sudo -H -u francois VBoxManage showvminfo "XPpro" | grep
"^State"
State: powered off # <-- la VM est vue en mode off
J'obtiens une ligne m'indiquant que la VM est éteinte, alors
que c'est faux, la preuve, j'ai accès à cette VM via le
réseau !?!
Avez vous une explication ? Ce point est important car dans
mon script de démon, j'utilise pas mal la commande ci-dessus
pour tester si la VM est bien lancée.
Comment expliquer cette différence de comportement entre une
commande faite en ligne de commande et la *même* commande
lancée à travers un script de démon ?
J'ai bien ma VM qui est lancée et quand je tape ceci
# sudo -H -u francois VBoxManage showvminfo "XPpro" | grep "^State" State: running # <-- ok la VM est lancée
j'ai bien une ligne qui s'affiche contenant "running" ce qui signifie que la VM est bien lancée.
En revanche, via un script de démon /etc/init.d/MyVM, avec la même commande de lancement (celle cité au dessus), la VM est bien lancée, en revanche, quand je teste le lancement avec la ligne de commande
# sudo -H -u francois VBoxManage showvminfo "XPpro" | grep "^State" State: powered off # <-- la VM est vue en mode off
J'obtiens une ligne m'indiquant que la VM est éteinte, alors que c'est faux, la preuve, j'ai accès à cette VM via le réseau !?!
Avez vous une explication ? Ce point est important car dans mon script de démon, j'utilise pas mal la commande ci-dessus pour tester si la VM est bien lancée.
Comment expliquer cette différence de comportement entre une commande faite en ligne de commande et la *même* commande lancée à travers un script de démon ?
Merci d'avance.
-- François Lafont
Francois Lafont
Le 08/05/2010 18:50, Francois Lafont a écrit :
Comment expliquer cette différence de comportement entre une commande faite en ligne de commande et la *même* commande lancée à travers un script de démon ?
Là, aussi je conclus le fil histoire que ça soit "complet", ce script de démon marche très bien
http://sisco.laf.free.fr/codes/MyVM.html
Attention, il y a une restriction :
- sous Ubuntu 9.04, il fallait enlever l'option "splash" dans le chargement du noyau dans /boot/grub/menu.lst pour que le script marche correctement (je ne sais pas pourquoi).
- en revanche sous Ubuntu 10.04, la restriction n'est plus valable (je ne sais pas pourquoi non plus).
Voilà. :-)
-- François Lafont
Le 08/05/2010 18:50, Francois Lafont a écrit :
Comment expliquer cette différence de comportement entre une commande
faite en ligne de commande et la *même* commande lancée à travers un
script de démon ?
Là, aussi je conclus le fil histoire que ça soit "complet",
ce script de démon marche très bien
http://sisco.laf.free.fr/codes/MyVM.html
Attention, il y a une restriction :
- sous Ubuntu 9.04, il fallait enlever l'option "splash"
dans le chargement du noyau dans /boot/grub/menu.lst pour
que le script marche correctement (je ne sais pas pourquoi).
- en revanche sous Ubuntu 10.04, la restriction n'est plus
valable (je ne sais pas pourquoi non plus).
Comment expliquer cette différence de comportement entre une commande faite en ligne de commande et la *même* commande lancée à travers un script de démon ?
Là, aussi je conclus le fil histoire que ça soit "complet", ce script de démon marche très bien
http://sisco.laf.free.fr/codes/MyVM.html
Attention, il y a une restriction :
- sous Ubuntu 9.04, il fallait enlever l'option "splash" dans le chargement du noyau dans /boot/grub/menu.lst pour que le script marche correctement (je ne sais pas pourquoi).
- en revanche sous Ubuntu 10.04, la restriction n'est plus valable (je ne sais pas pourquoi non plus).
