Xen: les DomU ne démarrent plus depuis une mise à jour

Bonjour,

je suis un utilisateur amateur de Debian. Ca fait de nombreuses années que je me débrouille avec Debian. Ce forum m’a souvent aidé et je n’ai jamais eu besoin de m’y inscrire jusqu’à aujourd’hui :’(

En Décembre dernier, j’ai voulu me mettre pour m’amuser à la virtualisation. Je me suis donc attaqué à Xen sous Debian et au prix de nombreuses heures, j’ai réussi à faire ce que je voulais. En gros:

  • un Dom0 sous Debian Wheezy
  • un DomU sous Debian Wheezy qui fait DNS perso
  • un DomU sous Debian Squeeze + OpenMediaVault qui me sert de NAS avec des disques en LVM (pour pouvoir étendre le NAS plus tard)

Je précise encore que ce n’est que de l’amateurisme donc le but était que cela fonctionne et pas plus. J’aurais abordé les problèmes de sécurité ou de performance plus tard lorsque j’aurai un peu de temps.
Et donc cela a bien fonctionné jusqu’en Septembre où depuis une mise à jour de toutes les Debian concernées, les DomU ne bootent plus au démarrage (alors que les fichiers .cfg sont bien mis dans le répertoire /etc/xen/auto). Par contre, je peux démarrer les DomU à l’aide de la commande “xm create”.

Je vous donne ici le fichier .cfg du DNS:

[code]cat /etc/xen/deathmask-cancer.cfg

Configuration file for the Xen instance deathmask-cancer, created

by xen-tools 4.2.1 on Mon May 21 00:43:57 2012.

Kernel + memory size

kernel = '/boot/vmlinuz-3.2.0-2-amd64’
ramdisk = ‘/boot/initrd.img-3.2.0-2-amd64’

vcpus = '1’
memory = ‘512’

Disk device(s).

root = '/dev/xvda2 ro’
disk = [
‘file:/home/xen/domains/deathmask-cancer/disk.img,xvda2,w’,
‘file:/home/xen/domains/deathmask-cancer/swap.img,xvda1,w’,
]

Physical volumes

Hostname

name = ‘deathmask-cancer’

Networking

dhcp = 'dhcp’
vif = [ ‘mac=00:16:3E:82:AE:56’ ]

Behaviour

on_poweroff = 'destroy’
on_reboot = 'restart’
on_crash = ‘restart’
[/code]

Je vous donne aussi les messages d’erreur suspects que je trouve dans /var/log/xen/xend.log:

[2012-10-31 00:12:43 3042] DEBUG (XendCheckpoint:278) restore:shadow=0x0, _static_max=0x20000000, _static_min=0x0, [2012-10-31 00:12:43 3042] DEBUG (XendCheckpoint:305) [xc_restore]: /usr/lib/xen-4.1/bin/xc_restore 26 1 1 2 0 0 0 0 [2012-10-31 00:12:43 3042] INFO (XendCheckpoint:423) xc: error: 0-length read: Internal error [2012-10-31 00:12:43 3042] INFO (XendCheckpoint:423) xc: error: read_exact_timed failed (read rc: 0, errno: 0): Internal error [2012-10-31 00:12:43 3042] INFO (XendCheckpoint:423) xc: error: read: p2m_size (0 = Success): Internal error [2012-10-31 00:12:43 3042] DEBUG (XendDomainInfo:3071) XendDomainInfo.destroy: domid=1 [2012-10-31 00:12:44 3042] ERROR (XendDomainInfo:3085) XendDomainInfo.destroy: domain destruction failed. Traceback (most recent call last): File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py", line 3078, in destroy xc.domain_pause(self.domid) Error: (3, 'No such process') [2012-10-31 00:12:44 3042] DEBUG (XendDomainInfo:2406) No device model [2012-10-31 00:12:44 3042] DEBUG (XendDomainInfo:2408) Releasing devices [2012-10-31 00:12:44 3042] DEBUG (XendDomainInfo:2414) Removing vif/0 [2012-10-31 00:12:44 3042] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 [2012-10-31 00:12:44 3042] DEBUG (XendDomainInfo:2414) Removing console/0 [2012-10-31 00:12:44 3042] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = console, device = console/0 [2012-10-31 00:12:44 3042] DEBUG (XendDomainInfo:2414) Removing vbd/51714 [2012-10-31 00:12:44 3042] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/51714 [2012-10-31 00:12:44 3042] DEBUG (XendDomainInfo:2414) Removing vbd/51713 [2012-10-31 00:12:44 3042] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/51713 [2012-10-31 00:12:44 3042] ERROR (XendCheckpoint:357) /usr/lib/xen-4.1/bin/xc_restore 26 1 1 2 0 0 0 0 failed Traceback (most recent call last): File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendCheckpoint.py", line 309, in restore forkHelper(cmd, fd, handler.handler, True) File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendCheckpoint.py", line 411, in forkHelper raise XendError("%s failed" % string.join(cmd)) XendError: /usr/lib/xen-4.1/bin/xc_restore 26 1 1 2 0 0 0 0 failed [2012-10-31 00:12:44 3042] ERROR (XendDomain:1194) Restore failed Traceback (most recent call last): File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomain.py", line 1178, in domain_restore_fd dominfo = XendCheckpoint.restore(self, fd, paused=paused, relocating=relocating) File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendCheckpoint.py", line 358, in restore raise exn XendError: /usr/lib/xen-4.1/bin/xc_restore 26 1 1 2 0 0 0 0 failed

Je n’ai pas trop eu le temps d’approfondir mais je n’ai pas trouvé grand choses sur le net.

Je vous remercie d’avance pour votre aide car j’aimerais bien pouvoir retrouver mes DomU qui démarrent tout seul comme avant.

Oyo

[quote=“TheOyoStyledMan”]les DomU ne bootent plus au démarrage (alors que les fichiers .cfg sont bien mis dans le répertoire /etc/xen/auto). Par contre, je peux démarrer les DomU à l’aide de la commande “xm create”.
[/quote]
Je ne connais pas Xen sous debian, mais les DomU automatiques devraient être démarrés par /etc/init.d/xendomains
Vérifie que le service est bien lancé au boot (cf isalo.org/wiki.debian-fr/ind … Activation)

Regarde aussi si tu as un fichier /etc/default/xendomains et qu’il contient bien XENDOMAINS_AUTO=/etc/xen/auto.

Bonjour kna,

je viens de voir ta réponse… J’ai bien vérifié ce que tu as dit, le service est bien lancé au démarrage ainsi que la ligne faisant référence à /etc/xen/auto …

Mais cela ne fonctionne toujours pas :017

Merci quand même pour ton aide!