not a bootable Disk VM MS Server 2016

[CKFrizz]

Hallo,
bei mir hat sich ganz großes Unglück eingestellt. Beim Start der VM eines Microsoft Server 2016 Essential, erhalte ich die Meldung, not a bootable Disk. Leider hat sich meine Backupstation ebenso verabschiedet. qemu-img check, erhalte ich:

root@ck-lenovo-server:/mnt/pve/Dtastor/images/108# qemu-img check /mnt/pve/Dtastor/images/108/vm-108-disk-2.qcow2
No errors were found on the image.
8192000/8192000 = 100.00% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 536953094144
root@ck-lenovo-server:/mnt/pve/Dtastor/images/108# qemu-img check /mnt/pve/Dtastor/images/108/vm-108-disk-0.qcow2
No errors were found on the image.
2120370/4194304 = 50.55% allocated, 18.70% fragmented, 0.00% compressed clusters
Image end offset: 274920112128

Also alles irgendwie top.
Dennoch startet die VM nicht. Kann ich die Bootdisk irgendwie laden und die Booteinträge einsehen? Oder ist der MBR defekt und wie kann er repariert werden. Ich nehme an, dass der Fehler während des Backups eingetreten ist und die Backupstation sich ins Nirwana verabschiedet hat.
Was kann ich tun?
Vielen Dank bereits jetzt
Michael

 

[Neobin]

Welche Schnittstelle(n) benutzen die vDisks, insbesondere die Boot-Disk? Zufällig: sata?
Kannst du mal bitte die VM-Config (qm config 108) posten?
Könnte eventuell: [1] sein.

Was genau ist deine "Backupstation" und inwiefern hat sie sich "verabschiedet"?

Welcher Storage steckt hinter: /mnt/pve/Dtastor/ genau?

[1] https://bugzilla.proxmox.com/show_bug.cgi?id=2874

 

[fiona]

Hi,
falls wirklich nur die Partitionstabelle kaputt ist, sollte ein Tool wie https://www.cgsecurity.org/wiki/TestDisk Abhilfe schaffen.

Bevor Du das versuchst, könntest Du bitte die Ausgabe von

qemu-img dd bs=512 count=1 if=/mnt/pve/Dtastor/images/108/vm-108-disk-2.qcow2 | base64

posten?

Zusätzlich zu den Informationen, die @Neobin angefragt hat, wären noch der /var/log/syslog um die Zeit des Problems herum und Logs aus dem Gast selbst interessant (hoffen wir, dass TestDisk hilft!). Und pveversion -v auch.

 

[CKFrizz]

Welche Schnittstelle(n) benutzen die vDisks, insbesondere die Boot-Disk? Zufällig: sata?
Kannst du mal bitte die VM-Config (qm config 108) posten?
Könnte eventuell: [1] sein.

Was genau ist deine "Backupstation" und inwiefern hat sie sich "verabschiedet"?

Welcher Storage steckt hinter: /mnt/pve/Dtastor/ genau?

[1] https://bugzilla.proxmox.com/show_bug.cgi?id=2874

Hallo,
Hinter meinen Dtastor liegt ein Raid. Wolltest du das wissen. Es handelt sich um SAS Devices.
Die Ausgabe von qm config:
agent: 1 boot: order=sata0;net0;ide0 cores: 4 ide0: Dtastor:iso/virtio-win-0.1.217.iso,media=cdrom,size=519096K machine: pc-q35-5.2 memory: 65536 meta: creation-qemu=6.2.0,ctime=1653394109 name: MS-Server-Essentiell-2016-CAD-KON net0: virtio=8E:1C:66:33:B9:8E,bridge=vmbr0,firewall=1 net1: virtio=76:FB:77:23:89:60,bridge=vmbr0,firewall=1 numa: 0 onboot: 1 ostype: win10 sata0: Dtastor:108/vm-108-disk-0.qcow2,size=256G sata1: Dtastor:108/vm-108-disk-2.qcow2,size=500G scsihw: virtio-scsi-pci smbios1: uuid=25ba0ff5-92d4-4332-b283-2aff3adda596 sockets: 2 vmgenid: 1d5696df-3d84-4c6e-b2e1-e378878e0863 vmstatestorage: backups

 

[CKFrizz]

Hi,
falls wirklich nur die Partitionstabelle kaputt ist, sollte ein Tool wie https://www.cgsecurity.org/wiki/TestDisk Abhilfe schaffen.

Bevor Du das versuchst, könntest Du bitte die Ausgabe von

qemu-img dd bs=512 count=1 if=/mnt/pve/Dtastor/images/108/vm-108-disk-2.qcow2 | base64

posten?

Zusätzlich zu den Informationen, die @Neobin angefragt hat, wären noch der /var/log/syslog um die Zeit des Problems herum und Logs aus dem Gast selbst interessant (hoffen wir, dass TestDisk hilft!). Und pveversion -v auch.

qemu-img..... :

root@ck-lenovo-server:~# qemu-img dd bs=512 count=1 if=/mnt/pve/Dtastor/images/108/vm-108-disk-2.qcow2 | base64
M8CO0LwAfI7Ajti+AHy/AAa5AAL886RQaBwGy/u5BAC9vgeAfgAAfAsPhQ4Bg8UQ4vHNGIhWAFXG
RhEFxkYQALRBu6pVzRNdcg+B+1WqdQn3wQEAdAP+RhBmYIB+EAB0JmZoAAAAAGb/dghoAABoAHxo
AQBoEAC0QopWAIv0zROfg8QQnusUuAECuwB8ilYAinYBik4Cim4DzRNmYXMc/k4RdQyAfgCAD4SK
ALKA64RVMuSKVgDNE13rnoE+/n1VqnVu/3YA6I0AdRf6sNHmZOiDALDf5mDofACw/+Zk6HUA+7gA
u80aZiPAdTtmgftUQ1BBdTKB+QIBcixmaAe7AABmaAACAABmaAgAAABmU2ZTZlVmaAAAAABmaAB8
AABmYWgAAAfNGloy9uoAfAAAzRigtwfrCKC2B+sDoLUHMuQFAAeL8Kw8AHQJuwcAtA7NEOvy9Ov9
K8nkZOsAJALg+CQCw0ludmFsaWQgcGFydGl0aW9uIHRhYmxlAEVycm9yIGxvYWRpbmcgb3BlcmF0
aW5nIHN5c3RlbQBNaXNzaW5nIG9wZXJhdGluZyBzeXN0ZW0AAABje5pYBur4AAAAICEAB/7//wAI
AAAA6H8+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVao=

und pveversion -v:

proxmox-ve: 7.3-1 (running kernel: 5.15.83-1-pve)
pve-manager: 7.3-4 (running version: 7.3-4/d69b70d4)
pve-kernel-helper: 7.3-3
pve-kernel-5.15: 7.3-1
pve-kernel-5.15.83-1-pve: 5.15.83-1
pve-kernel-5.15.74-1-pve: 5.15.74-1
pve-kernel-5.15.64-1-pve: 5.15.64-1
pve-kernel-5.15.60-2-pve: 5.15.60-2
pve-kernel-5.15.53-1-pve: 5.15.53-1
pve-kernel-5.15.30-2-pve: 5.15.30-3
ceph: 16.2.9-pve1
ceph-fuse: 16.2.9-pve1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.3
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.3-1
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.3-2
libpve-guest-common-perl: 4.2-3
libpve-http-server-perl: 4.1-5
libpve-storage-perl: 7.3-2
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.0-3
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.3.2-1
proxmox-backup-file-restore: 2.3.2-1
proxmox-mini-journalreader: 1.3-1
proxmox-offline-mirror-helper: 0.5.0-1
proxmox-widget-toolkit: 3.5.3
pve-cluster: 7.3-2
pve-container: 4.4-2
pve-docs: 7.3-1
pve-edk2-firmware: 3.20220526-1
pve-firewall: 4.2-7
pve-firmware: 3.6-3
pve-ha-manager: 3.5.1
pve-i18n: 2.8-2
pve-qemu-kvm: 7.1.0-4
pve-xtermjs: 4.16.0-1
qemu-server: 7.3-3
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+2
vncterm: 1.7-1
zfsutils-linux: 2.1.9-pve1

und syslog zeigt:

Feb 15 20:00:29 ck-lenovo-server pvestatd[1451]: storage 'backups' is not online
Feb 15 20:00:32 ck-lenovo-server pvestatd[1451]: status update time (12.794 seconds)
Feb 15 20:04:50 ck-lenovo-server pvedaemon[950393]: authentication failure; rhost=::ffff:5.42.199.51 user=root@pam msg=Authentication failure
Feb 15 20:05:30 ck-lenovo-server pvedaemon[761280]: authentication failure; rhost=::ffff:5.42.199.51 user=root@pam msg=Authentication failure
Feb 15 20:06:46 ck-lenovo-server pvedaemon[713296]: authentication failure; rhost=::ffff:5.42.199.51 user=root@pam msg=Authentication failure
Feb 15 20:07:06 ck-lenovo-server pvedaemon[950393]: authentication failure; rhost=::ffff:5.42.199.51 user=root@pam msg=Authentication failure
Feb 15 20:11:32 ck-lenovo-server pvedaemon[713296]: authentication failure; rhost=::ffff:5.42.199.51 user=root@pam msg=Authentication failure
Feb 15 20:12:09 ck-lenovo-server pvedaemon[950393]: authentication failure; rhost=::ffff:5.42.199.51 user=root@pam msg=Authentication failure
Feb 15 20:13:39 ck-lenovo-server pvedaemon[713296]: authentication failure; rhost=::ffff:5.42.199.51 user=root@pam msg=Authentication failure
Feb 15 20:14:04 ck-lenovo-server pvedaemon[761280]: authentication failure; rhost=::ffff:5.42.199.51 user=root@pam msg=Authentication failure
Feb 15 20:17:01 ck-lenovo-server CRON[2091483]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Feb 15 20:1

das deutet auf einen Brutforce hin. Ja, gehärtet habe ich den Server mit Fail2Ban oder denyhost, noch nicht.

Meine Backupstation war eine QNAP 473. Das war natürlich suboptimal.

Vielen Dank. Ich kümmere mich um Testdisk.

 

[fiona]

Falls Du das mit Testdisk noch nicht gemacht hast, könntest Du auch das erste Megabyte irgendwo hochladen, also die dump.raw-Datei nach dem folgenden Kommando?

qemu-img dd bs=512 count=2048 if=/mnt/pve/Dtastor/images/108/vm-108-disk-2.qcow2 of=dump.raw

 

[fiona]

Also der MBR schaut nicht vollständig korrupt aus (hier im Vergleich mit einem anderen):

00000000: 33c0 8ed0 bc00 7c8e c08e d8be 007c bf00  3.....|...   00000000: 33c0 8ed0 bc00 7c8e c08e d8be 007c bf00  3.....|...
00000010: 06b9 0002 fcf3 a450 681c 06cb fbb9 0400  .......Ph.   00000010: 06b9 0002 fcf3 a450 681c 06cb fbb9 0400  .......Ph.
00000020: bdbe 0780 7e00 007c 0b0f 850e 0183 c510  ....~..|..   00000020: bdbe 0780 7e00 007c 0b0f 850e 0183 c510  ....~..|..
00000030: e2f1 cd18 8856 0055 c646 1105 c646 1000  .....V.U.F   00000030: e2f1 cd18 8856 0055 c646 1105 c646 1000  .....V.U.F
00000040: b441 bbaa 55cd 135d 720f 81fb 55aa 7509  .A..U..]r.   00000040: b441 bbaa 55cd 135d 720f 81fb 55aa 7509  .A..U..]r.
00000050: f7c1 0100 7403 fe46 1066 6080 7e10 0074  ....t..F.f   00000050: f7c1 0100 7403 fe46 1066 6080 7e10 0074  ....t..F.f
00000060: 2666 6800 0000 0066 ff76 0868 0000 6800  &fh....f.v   00000060: 2666 6800 0000 0066 ff76 0868 0000 6800  &fh....f.v
00000070: 7c68 0100 6810 00b4 428a 5600 8bf4 cd13  |h..h...B.   00000070: 7c68 0100 6810 00b4 428a 5600 8bf4 cd13  |h..h...B.
00000080: 9f83 c410 9eeb 14b8 0102 bb00 7c8a 5600  ..........   00000080: 9f83 c410 9eeb 14b8 0102 bb00 7c8a 5600  ..........
00000090: 8a76 018a 4e02 8a6e 03cd 1366 6173 1cfe  .v..N..n..   00000090: 8a76 018a 4e02 8a6e 03cd 1366 6173 1cfe  .v..N..n..
000000a0: 4e11 750c 807e 0080 0f84 8a00 b280 eb84  N.u..~....   000000a0: 4e11 750c 807e 0080 0f84 8a00 b280 eb84  N.u..~....
000000b0: 5532 e48a 5600 cd13 5deb 9e81 3efe 7d55  U2..V...].   000000b0: 5532 e48a 5600 cd13 5deb 9e81 3efe 7d55  U2..V...].
000000c0: aa75 6eff 7600 e88d 0075 17fa b0d1 e664  .un.v....u   000000c0: aa75 6eff 7600 e88d 0075 17fa b0d1 e664  .un.v....u
000000d0: e883 00b0 dfe6 60e8 7c00 b0ff e664 e875  ......`.|.   000000d0: e883 00b0 dfe6 60e8 7c00 b0ff e664 e875  ......`.|.
000000e0: 00fb b800 bbcd 1a66 23c0 753b 6681 fb54  .......f#.   000000e0: 00fb b800 bbcd 1a66 23c0 753b 6681 fb54  .......f#.
000000f0: 4350 4175 3281 f902 0172 2c66 6807 bb00  CPAu2....r   000000f0: 4350 4175 3281 f902 0172 2c66 6807 bb00  CPAu2....r
00000100: 0066 6800 0200 0066 6808 0000 0066 5366  .fh....fh.   00000100: 0066 6800 0200 0066 6808 0000 0066 5366  .fh....fh.
00000110: 5366 5566 6800 0000 0066 6800 7c00 0066  SfUfh....f   00000110: 5366 5566 6800 0000 0066 6800 7c00 0066  SfUfh....f
00000120: 6168 0000 07cd 1a5a 32f6 ea00 7c00 00cd  ah.....Z2.   00000120: 6168 0000 07cd 1a5a 32f6 ea00 7c00 00cd  ah.....Z2.
00000130: 18a0 b707 eb08 a0b6 07eb 03a0 b507 32e4  ..........   00000130: 18a0 b707 eb08 a0b6 07eb 03a0 b507 32e4  ..........
00000140: 0500 078b f0ac 3c00 7409 bb07 00b4 0ecd  ......<.t.   00000140: 0500 078b f0ac 3c00 7409 bb07 00b4 0ecd  ......<.t.
00000150: 10eb f2f4 ebfd 2bc9 e464 eb00 2402 e0f8  ......+..d   00000150: 10eb f2f4 ebfd 2bc9 e464 eb00 2402 e0f8  ......+..d
00000160: 2402 c349 6e76 616c 6964 2070 6172 7469  $..Invalid   00000160: 2402 c349 6e76 616c 6964 2070 6172 7469  $..Invalid
00000170: 7469 6f6e 2074 6162 6c65 0045 7272 6f72  tion table   00000170: 7469 6f6e 2074 6162 6c65 0045 7272 6f72  tion table
00000180: 206c 6f61 6469 6e67 206f 7065 7261 7469   loading o   00000180: 206c 6f61 6469 6e67 206f 7065 7261 7469   loading o
00000190: 6e67 2073 7973 7465 6d00 4d69 7373 696e  ng system.   00000190: 6e67 2073 7973 7465 6d00 4d69 7373 696e  ng system.
000001a0: 6720 6f70 6572 6174 696e 6720 7379 7374  g operatin   000001a0: 6720 6f70 6572 6174 696e 6720 7379 7374  g operatin

Die einzigen Unterschiede sind in dem Bereich hier wo die Signatur ist und die Partitionen selbst codiert sind:

000001b0: 656d 0000 0063 7b9a 5806 eaf8 0000 0020  em...c{.X. | 000001b0: 656d 0000 0063 7b9a 3201 c85c 0000 8020  em...c{.2.
000001c0: 2100 07fe ffff 0008 0000 00e8 7f3e 0000  !......... | 000001c0: 2100 071d 1746 0008 0000 0028 1100 001d  !....F....
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  .......... | 000001d0: 1846 07fe ffff 0030 1100 00c8 6e07 0000  .F.....0..

Hier könnte es aber möglicherweise nicht ganz stimmen? fdisk -l gibt:

Device                 Boot Start        End    Sectors  Size Id Type
dump-forum-122849.raw1       2048 1048571903 1048569856  500G  7 HPFS/NTFS/exFAT

aus, also nur eine Partition und die ist nicht als Boot markiert.

Das Ende ist wieder gleich:

000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ..........   000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ..........
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..........   000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..........

 

[CKFrizz]

Falls Du das mit Testdisk noch nicht gemacht hast, könntest Du auch das erste Megabyte irgendwo hochladen, also die dump.raw-Datei nach dem folgenden Kommando?

qemu-img dd bs=512 count=2048 if=/mnt/pve/Dtastor/images/108/vm-108-disk-2.qcow2 of=dump.raw

 

[CKFrizz]

Die beiden Festplatten bezogenen Kommandos beziehen sich auf die 2. Platte. Und von der sollte nicht gebootet werden. Demzufolge habe ich beide Kommandos noch einmal auf die erste Platte bezogen eingegeben und habe dann diese Informationen:

AAMiAE50RnPaTKMcO/V9GWClptQMqP//MBXZ5gyo//9cAFMAbwBmAHQAdwBhAHIAZQBEAGkAcwB0
AHIAaQBiAHUAdABpAG8AbgBcAEQAbwB3AG4AbABvAGEAZABcADcAMwBjADYAMwBlADIAZAA3AGYA
ZgA4AGYANgA1ADEAMQA5ADYAYwBlAGEAMQBlADAAOQBmAGYANgAyADAAZQBcAGkAbgBzAHQAXABw
AGEAYwBrAGEAZwBlAF8AOQAxADcAMQBfAGYAbwByAF8AawBiADUAMAAyADIAOAAzADgAfgAzADEA
YgBmADMAOAA1ADYAYQBkADMANgA0AGUAMwA1AH4AYQBtAGQANgA0AH4AfgAxADAALgAwAC4AMQAu
ADEAMwAuAGMAYQB0AB0IDaj//xMDDwBOdEZz6k2jHDv1fRmQBU0PDaj//6AMVQ0NqP//Q1JPU09G
VC1XSU5ET1dTLUQuLi1XSU5QUk9WSURFUlMtQVNTT0NfMzFCRjM4NTZBDANnAHAAcwBjAHIAaQBw
AHQALgBlAHgAZQA3ADYANAA3AGIAMwA2ADAAMABjAGQAZQAwADQAMQA1ADkANQAyADEALgB0AG0A
cABHAFAAUwBDAFIASQBQAFQALgBFAFgARQA3ADYANAA3AEIAMwA2ADAAMABDAEQARQAwADQAMQA=

qemu-img dd bs=512 count=2048 if=/mnt/pve/Dtastor/images/108/vm-108-disk-0.qcow2 of=dump.raw

erzeugt diese Datei

 

[fiona]

Die beiden Festplatten bezogenen Kommandos beziehen sich auf die 2. Platte. Und von der sollte nicht gebootet werden. Demzufolge habe ich beide Kommandos noch einmal auf die erste Platte bezogen eingegeben und habe dann diese Informationen:

AAMiAE50RnPaTKMcO/V9GWClptQMqP//MBXZ5gyo//9cAFMAbwBmAHQAdwBhAHIAZQBEAGkAcwB0
AHIAaQBiAHUAdABpAG8AbgBcAEQAbwB3AG4AbABvAGEAZABcADcAMwBjADYAMwBlADIAZAA3AGYA
ZgA4AGYANgA1ADEAMQA5ADYAYwBlAGEAMQBlADAAOQBmAGYANgAyADAAZQBcAGkAbgBzAHQAXABw
AGEAYwBrAGEAZwBlAF8AOQAxADcAMQBfAGYAbwByAF8AawBiADUAMAAyADIAOAAzADgAfgAzADEA
YgBmADMAOAA1ADYAYQBkADMANgA0AGUAMwA1AH4AYQBtAGQANgA0AH4AfgAxADAALgAwAC4AMQAu
ADEAMwAuAGMAYQB0AB0IDaj//xMDDwBOdEZz6k2jHDv1fRmQBU0PDaj//6AMVQ0NqP//Q1JPU09G
VC1XSU5ET1dTLUQuLi1XSU5QUk9WSURFUlMtQVNTT0NfMzFCRjM4NTZBDANnAHAAcwBjAHIAaQBw
AHQALgBlAHgAZQA3ADYANAA3AGIAMwA2ADAAMABjAGQAZQAwADQAMQA1ADkANQAyADEALgB0AG0A
cABHAFAAUwBDAFIASQBQAFQALgBFAFgARQA3ADYANAA3AEIAMwA2ADAAMABDAEQARQAwADQAMQA=

Ja, das hingegen schaut korrupt aus

qemu-img dd bs=512 count=2048 if=/mnt/pve/Dtastor/images/108/vm-108-disk-0.qcow2 of=dump.raw

erzeugt diese Datei

Leider sind solche großen Anhänge im Forum nicht möglich. Könntest Du versuchen die Datei zu komprimieren, oder woanders upzuloaden?

 

[CKFrizz]

Versuche mal bitte diese beiden Links. gelten 2 Tage
1. dump.raw (2.te HD)

2. dump.raw (Boot HD)
Danke.

 

[fiona]

Versuche mal bitte diese beiden Links. gelten 2 Tage
1. dump.raw (2.te HD)

2. dump.raw (Boot HD)
Danke.

Vielen Dank!

Bei der Boot Disk ist genau der erste Sektor (512 Byte) korrupt, danach kommen nur noch Nullen, was zu erwartet ist. Wir werden versuchen, Logging einzubauen, um die Ursache für den Fehler endlich finden zu können. Mit viel Glück könnte auch eine Patch-Serie schon Abhilfe schaffen, aber will da wirklich nix versprechen.

Hoffe das mit TestDisk haut hin. Wenn Du kannst, besser SCSI benutzen also SATA: https://pve.proxmox.com/wiki/Windows_2016_guest_best_practices
Leider ist die SATA-Emulation nicht so gut gepflegt wie SCSI bei QEMU. Und für Updates, am besten den Bug-Report verfolgen.

 

[CKFrizz]

Ich habe vor dem Versuch mit Testdisk ein Backup mit der Proxmox eigenen Sicherungsroutine gestartet. Anschließend bin ich in das Imageverzeichnis gewechselt und habe mit
testdisk vm-108-disk-0.qcow2

Unter Analyse habe ich die erste Option, also Intel gewählt. Es gab keine Fehlermeldungen oder Widersprüche. Mit der Funktion MBR Rekord schreiben, habe ich dann diese Funktion ausgeführt. Beim Versuch, dann diese VM zu starten, erhielt ich die folgende Warnung:

kvm: -drive file=/mnt/pve/Dtastor/images/108/vm-108-disk-0.qcow2,if=none,id=drive-sata0,format=qcow2,cache=none,aio=io_uring,detect-zeroes=on: Image is not in qcow2 format TASK ERROR: start failed: QEMU exited with code 1

erhalten. Welchen Fehler habe ich begangen?

 

[fiona]

Schätze, dass TestDisk sich mit qcow2 nicht auskennt. Ich würd das Image vom Backup restoren, dann nach raw konvertieren (kann auch über die UI gemacht werden, beim Verschieben auf eine Storage kann auch die gleiche mit anderem Format gewählt werden) und nochmal versuchen. Und nachher wieder nach qcow2 zurückkonvertieren, wenn Du willst.

 

[CKFrizz]

Vielen Dank für die Antwort. Ich habe momentan kein Backup. Bis auf die gesicherte Version des nicht bootwilligen Images. So müsste ich dann also mal gucken, wie ich von qcow2 nach RAW konvertiere und zurück.
Vielen Dank für den Tipp.
Besten Dank
Michael

 

[CKFrizz]

Ich habe einen Restore der gesicherten VM 108 auf eine VM mit dem Index 110 wiederhergestellt. Anschließend habe ich einen neuen Bootsektor von Testdisk schreiben lassen. Der Start dieser Instanz brach ab, mit der Meldung:
TASK ERROR: Failed to run vncproxy.
In der Konsole erscheint in einer Zeile, 1234F.
Das war es dann. Vermutlich liegt es an dem Umstand, dass die Konfiguration der gestarteten VM [110] in sich jedoch die Konfigurationsinformationen der VM [108] in sich trägt.
Aus diesem Grund habe ich die noch bestehende VM 108 gelöscht und aus dem Sicherungspool wieder hergestellt.
Liege ich einem Irrtum auf und muss meine Hoffnung beerdigen, die defekte VM wieder zum Laufen zu bringen?

 

[fiona]

Ich habe einen Restore der gesicherten VM 108 auf eine VM mit dem Index 110 wiederhergestellt. Anschließend habe ich einen neuen Bootsektor von Testdisk schreiben lassen.

Konntest Du sehen welche Partitionen gefunden wurden? Ansonsten z.B. mit fdisk -l /pfad/zur/datei.raw anzeigen lassen.

Der Start dieser Instanz brach ab, mit der Meldung:
TASK ERROR: Failed to run vncproxy.

Was steht beim VM 110 - Start Task (beim unteren Panel in der UI, Doppelklick, um den Log anzuzeigen).

In der Konsole erscheint in einer Zeile, 1234F.

In welcher Konsole?

Das war es dann. Vermutlich liegt es an dem Umstand, dass die Konfiguration der gestarteten VM [110] in sich jedoch die Konfigurationsinformationen der VM [108] in sich trägt.

Beim Restore sollten die Disken der neuen ID zugewiesen werden, wie schaut denn die Konfiguration aus (qm config 110).

 

[CKFrizz]

Konntest Du sehen welche Partitionen gefunden wurden? Ansonsten z.B. mit fdisk -l /pfad/zur/datei.raw anzeigen lassen.
[/QUOTE] root@ck-lenovo-server:/mnt/pve/Dtastor/images/110# fdisk -l vm-110-disk-0.img Disk vm-110-disk-0.img: 256 GiB, 274877906944 bytes, 536870912 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00390035 Device Boot Start End Sectors Size Id Type vm-110-disk-0.img1 7340141 12583091 5242951 2.5G 2e unknown vm-110-disk-0.img2 5505104 10027133 4522030 2.2G 52 CP/M vm-110-disk-0.img3 3604532 6946933 3342402 1.6G 37 unknown vm-110-disk-0.img4 4522052 7929971 3407920 1.6G 30 unknown

Was steht beim VM 110 - Start Task (beim unteren Panel in der UI, Doppelklick, um den Log anzuzeigen).

da steht

no content

In welcher Konsole?

in der Konsole der VM

Beim Restore sollten die Disken der neuen ID zugewiesen werden, wie schaut denn die Konfiguration aus (qm config 110).

agent: 1
boot: order=sata0;net0;ide2
cores: 4
ide2: Dtastor:iso/virtio-win-0.1.229.iso,media=cdrom,size=522284K
machine: pc-q35-5.2
memory: 65536
meta: creation-qemu=6.2.0,ctime=1653394109
name: MS-Server-Essentiell-2016-CAD-KON
net0: virtio=8E:1C:66:33:B9:8E,bridge=vmbr0,firewall=1
net1: virtio=76:FB:77:23:89:60,bridge=vmbr0,firewall=1
numa: 0
ostype: win10
sata0: Dtastor:110/vm-110-disk-0.qcow2,size=256G
sata1: Dtastor:110/vm-110-disk-1.qcow2,size=500G
scsihw: virtio-scsi-pci
smbios1: uuid=25ba0ff5-92d4-4332-b283-2aff3adda596
sockets: 2
vmgenid: a61ec752-7008-406e-987c-99f3d913e985
vmstatestorage: backups

 

[fiona]

Also die Partitionstabelle schaut nicht richtig aus:

• Keine Partition als Boot markiert
• Typen unbekannt
• Alle kleiner als 2 GiB

Möglicherweise musst Du andere Optionen für TestDisk benutzen? Hab das Tool leider selbst nur probeweise benutzt, aber vielleicht gibt's da irgendwo gute Tutorials.

Falls Du noch irgendwo ein älteres Backup hast, könntest Du versuchen, die Partitionstabelle von dort rüberzukopieren.

 

[fiona]

Wie genau wurde eigentlich die qcow2-Datei zu raw konvertiert?