Erstellen eines Snapshot lässt ganzen UVMM-Server abstürzen

Wir versuchen gerade unseren alten Virtualbox VM Server durch einen UCS + UVMM zu ersetzen.
Wir konnten auch alle VMs migrieren und arbeiten nun ausschließlich mit .qcow2 images.

Die Hardware ist ein dual xeon setup (12 Kerne) und 64gb ECC Ram auf einem Z10PA-D8 Mainboard.

Nun ist es so, dass wir gerne von den Maschinen nach dem ersten erfolgreichen boot nach der migration snapshots erstellen würden.
Leider führt das zu einem Komplettabsturz und einer “nicht mehr Erreichbarkeit” aller VMs. :frowning:

dazu ein paar logs:

/var/log/univention/virtual-machine-manager-daemon.log:

2015-10-16 10:12:40,542 - uvmmd.node - ERROR - Cannot recv data: Input/output error
2015-10-16 10:12:40,543 - uvmmd.node - WARNING - 'qemu://usc00.company.intranet/system' broken? next check in 0:00:30.000. internal error: received hangup / error event on socket
2015-10-16 10:12:40,543 - uvmmd.unix - WARNING - [5831] Error doing command "DOMAIN_SNAPSHOT_CREATE": Error creating "623d61ed-b7b7-4bd3-8b96-048bf54f36a1" snapshot: Cannot recv data: Input/output error
2015-10-16 10:12:40,543 - uvmmd.node - ERROR - qemu://usc00.company.intranet/system: Exception in domainEventDeregister
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/uvmm/node.py", line 577, in update_autoreconnect
    self.conn.domainEventDeregister(self.domainCB)
  File "/usr/lib/pymodules/python2.7/libvirt.py", line 4335, in domainEventDeregister
    if ret == -1: raise libvirtError ('virConnectDomainEventDeregister() failed', conn=self)
libvirtError: internal error: client socket is closed
2015-10-16 10:13:10,671 - uvmmd.node - WARNING - 'qemu://usc00.company.intranet/system' broken? next check in 0:01:00.000. unable to connect to server at 'mtdusc00.mtd.intranet:16514': Connection refused
2015-10-16 10:14:10,677 - uvmmd.node - WARNING - 'qemu://usc00.company.intranet/system' broken? next check in 0:02:00.000. unable to connect to server at 'mtdusc00.mtd.intranet:16514': Connection refused
2015-10-16 10:14:28,366 - uvmmd.unix - ERROR - [5878] Exception: Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/uvmm/unix.py", line 149, in handle_command
    res = cmd(self, command)
  File "/usr/lib/pymodules/python2.7/univention/uvmm/commands.py", line 561, in STORAGE_POOLS
    pools = storage.storage_pools(node_stat)
  File "/usr/lib/pymodules/python2.7/univention/uvmm/storage.py", line 450, in storage_pools
    error='no connection'
StorageError: Error listing pools at "qemu://usc00.company.intranet/system": no connection

2015-10-16 10:28:52,123 - uvmmd.node - INFO - timer_callback(qemu://usc00.company.intranet/system) start
2015-10-16 10:28:52,288 - uvmmd.node - WARNING - 'qemu://usc00.company.intranet/system' broken? next check in 0:00:30.000. unable to connect to server at 'mtdusc00.mtd.intranet:16514': Connection refused
2015-10-16 10:29:22,337 - uvmmd.node - INFO - Connected to 'qemu://usc00.company.intranet/system'

/var/log/univention/virtual-machine-manager-node-errors.log:

Oct 16 10:12:33 usc00 libvirtd: does not response, restarting
Restarting UCS libvirt daemon: libvirtdkill: run: univention-libvirt: (pid 5514) 89947s, normally down, got TERM
.
Oct 16 10:18:33 mtdusc00 libvirtd: does not response, restarting
invoke-rc.d: -----------------------------------------------------
invoke-rc.d: WARNING: 'invoke-rc.d libvirtd restart' called
invoke-rc.d: during shutdown sequence.
invoke-rc.d: enabling safe mode: initscript policy layer disabled
invoke-rc.d: -----------------------------------------------------
Restarting UCS libvirt daemon: libvirtdkill: run: univention-libvirt: (pid 30096) 156s, normally down, got TERM

Mein per Mail eingesendeter Stacktrace beinhaltete noch folgendes:

Traceback (8e37d66a6e1a1469aa30b3200d260a16):
Execution of command 'uvmm/domain/put' has failed:

Traceback (most recent call last):
  File "%PY2.7%/univention/management/console/base.py", line 282, in execute
    function(self, request)
  File "%PY2.7%/univention/management/console/modules/uvmm/domains.py", line
479,
in domain_add
    for disk in domain['disks']
  File "%PY2.7%/univention/management/console/modules/uvmm/domains.py", line
297,
in _create_disk
    pool = self.get_pool(node_uri, pool_name)
  File "%PY2.7%/univention/management/console/modules/uvmm/storages.py", line
286,
in get_pool
    pools = dict([(pool.name, object2dict(pool)) for pool in data])
AttributeError: 'str' object has no attribute 'name'

Version:
4.0-3 errata341 (Walle)

Das sollte natürlich nicht passieren. Nur um das vorab besser einschätzen zu können ein paar Fragen:
Suspenden Sie alle Maschinen gleichzeitig (tritt das auch auf, wenn Sie das einzeln durchführen)?
Beim Suspend wird der komplette RAM auf die Platte geschrieben - da passiert sehr viel I/O. Wieviel RAM haben die Instanzen? Wie “stark” ist der Host in Sachen I/O Performance?

Das passiert nicht beim suspenden sondern beim snapshoten.
Wir wollen von VMs vor großen Änderungen einen snapshot machen. (so wie früher in virtualbox auch immer - sogar in laufendem betrieb)

in diesem Fall meckert er, dass die Maschine mehr als 4gb ram hat und daher nicht im laufenden betrieb gesnapshotet werden kann.
also haben wir die zu snapshotende ubuntu-vm herunter gefahren und dann den “Wiederherstellungspunkt” versucht zu erstellen.

da rödelt er dann 5min. um dann die oben geposteten Fehlermeldungen aus zu spucken.
zusätzlich ist danach der libvirtdaemon down und kann nicht neu gestartet werden. was sich auch durch Ausrufezeichen neben allen VMs im webinterface bemerkbar macht.

was auch immer wir dann probieren, ist erst durch einen cold boot zu beseitigen.

Auf dem Server laufen jetzt ca. 40 VMs und die Aktion wurde nur bei einer Maschine getestet.

Shame on me - lesen können müsste man :slight_smile:

Das klingt tatsächlich sehr sonderbar - verstehe ich das richtig, dass das mehrfach versucht und so beobachtet wurde?

Hilft folgendes?

ucr set libvirt/check/interval=15 libvirt/check/timeout=600

[quote=“Petersen”]Shame on me - lesen können müsste man :slight_smile:

Das klingt tatsächlich sehr sonderbar - verstehe ich das richtig, dass das mehrfach versucht und so beobachtet wurde?[/quote]

leider ja - da der Server schon produktiv genutzt wird bin ich da noch nicht so experementierfreudig, aber es wurde an eienr maschine drei mal versucht einen Snapshot zu erstellen was jedes mal dazu führte dass danach nichts mehr möglich war und der komplette Server inkl. aller VMs neu gestartet werden musste.

[quote=“Gohmann”]Hilft folgendes?

ucr set libvirt/check/interval=15 libvirt/check/timeout=600

was soll sich dadurch ändern?
dass der daemon nicht abstützt, oder das libvirt danach neu gestartet werden kann?

[quote=“Mr.Gosh”][quote=“Gohmann”]
was soll sich dadurch ändern?
dass der daemon nicht abstützt, oder das libvirt danach neu gestartet werden kann?[/quote][/quote]

Ich vermute mal, dass der Hinweis von Stefan auf [bug]35101[/bug] abzielt.

Mastodon