Konvertierung eines qcow2 images zu VMDK

Ich komme mit deinen Bilder nicht ganz klar. Das erste Bild zeigt öffentlich ein Windows mit einem lokalen Laufwerk. Welches Dateisystem wird da verwendet?

Welche NFS Version verwendest du denn? Und würde der NFS Share über das Rechenzentrum vom Proxmox als Storage eingebunden?
 
Hallo,
das erste Bild zeigt einen Windows 2022 Server mit einem NFS-Share. Dieses NFS-Share habe ich in Proxmox eingebunden. Der zweite Scrennshot zeigt die Ordnerstruktur des NFS-Shares. Proxmox ja, dass in dem eingebundenen Verzeichnis Daten leigen -> Übersicht und Auslastung. Nur ich kann die im NFS-Share liegenden Festplatten und vmdisk oder backup nicht sehen. Jetzt sollten die Bilder klarer geworden sein.
 
Wie schaut dein Mount-Point aus?
/mnt/pve/.....
Den schaust du dir dann in der PVE Konsole an. Da sollten dann alle Dateien sichtbar sein.

Nur noch zum Verständnis. Proxmox hat für Backups eigene Dateiendungen, die dann erkannt werden. Wenn das nicht passt, wird auch nicht angezeigt. Deshalb mein Rat mit der Konsole auf den Mount-Point schauen, da hier alle Dateien angezeigt werden sollten.
 
Last edited:
Wie lautet der komplette Befehl für einen Mount-Point. nfs ist hierbei der Name meines NFS-Shares.
 
In der root Konsole einfach ein 'mount' eingeben. Damit werden alle Mount-Points angezeigt.

Alternativ zeigt dir ein 'cat /etc/pve/storage.cfg' alle Storage mit MP.
 
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Jun 19 11:22:25 CEST 2023 on tty1
root@pve:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=17556964k,nr_inodes=4389241,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3518132k,mode=755,inode64)
/dev/mapper/pve-root on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=16625)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
lxcfs on /var/lib/lxcfs type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
/dev/fuse on /etc/pve type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
192.168.32.129:/import on /mnt/pve/nfs type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.32.128,local_lock=none,addr=192.168.32.129)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=3518128k,nr_inodes=879532,mode=700,inode64)
192.168.32.129:/nfs on /mnt/pve/nfs-share type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.32.128,local_lock=none,addr=192.168.32.129)
root@pve:~#

Das bekomme ich jetzt angezeigt.
Mein nfs-share sieht er. wie zeigt er mir jetzt die vms an oder überprüfe ob die da sind?
 
cd /mnt/pve/nfs
ls - al (hier sollten die Verzeichnisse angezeigt werden)
cd /{Name Verzeichnis}
ls - al (Dateien, sofern vorhanden, werden angezeigt)
 
-bash: cd: /mnt/pve/nfs: Permission denied

Also kann er in meinem NFS-Share nicht reinschauen.
 
So, nun kann ich wenn ich per Konsole in die einzelnen Ordner wie Dump oder backup reinschaue die einzelnen Images sehen, nur in Proxmox sehe ich sie innerhalb meines eingebundenen Shares wieder nicht. Was muss ich jetzt tun?
 
@Karschti Um dein Anliegen zu beantworten muss ich etwas weiter ausholen. Vielleicht kannst du auch sagen was du im Detail mit der vmdk vor hast.

Um eine QCOW2-Maschine in eine VMDK-Maschine in Proxmox zu konvertieren, kannst Du die folgenden Schritte befolgen:

1) Installiere zunächst das qemu-img-Tool, falls es noch nicht installiert ist. Auf einem Debian-basierten System kannst Du dies mit dem folgenden Befehl tun:


sudo apt-get install qemu-utils


2) Konvertiere die QCOW2-Datei in eine VMDK-Datei mit dem qemu-img-Tool. Der allgemeine Befehl hierfür lautet:


qemu-img convert -f qcow2 -O vmdk original.qcow2 output.vmdk


Ersetze "original.qcow2" durch den Pfad zu Deiner QCOW2-Datei und "output.vmdk" durch den Pfad, unter dem Du die konvertierte VMDK-Datei speichern möchtest.

3) Überprüfe, ob die Konvertierung erfolgreich war. Du solltest nun eine VMDK-Datei haben, die Du in VMware oder einem anderen System, das VMDK unterstützt, verwenden kannst.

Bitte beachte, dass dies eine grundlegende Konvertierung ist. Es gibt spezielle Optionen und Parameter, die Du möglicherweise hinzufügen möchtest, abhängig von Deiner spezifischen Situation und den Anforderungen Deiner VMDK-Umgebung.

Auch ist es wichtig zu beachten, dass die Konvertierung von QCOW2 zu VMDK möglicherweise nicht alle Funktionen und Daten der ursprünglichen Maschine erhält, insbesondere wenn diese Funktionen oder Daten spezifisch für QCOW2 oder Proxmox sind. Es ist daher eine gute Praxis, die VMDK-Datei nach der Konvertierung gründlich zu testen, um sicherzustellen, dass sie wie erwartet funktioniert.



Wenn du eine QCOW2-Maschine in eine VMDK-Maschine konvertierst und planst, sie auf einem anderen Hypervisor als Proxmox zu verwenden, ist es besonders wichtig, wenn das ursprüngliche Betriebssystem Windows ist. In diesem Fall solltest du vor der Konvertierung die QEMU-Gast-Tools deinstallieren.

Nach der Deinstallation der QEMU-Gast-Tools solltest du das System neu starten.

Nach dem Neustart kannst du nun die Konvertierung von QCOW2 zu VMDK wie in den vorherigen Schritten beschrieben durchführen.

Bitte beachte, dass es wichtig ist, die QEMU-Gast-Tools zu deinstallieren, da sie spezifische Treiber und Software enthalten, die für die Ausführung des Gast-Betriebssystems in einer QEMU-/KVM-basierten Umgebung optimiert sind. Wenn du diese Tools installiert lässt und das Gast-Betriebssystem in einer nicht QEMU-/KVM-basierten Umgebung (wie VMware oder Hyper-V) ausführst, kann dies zu Leistungsproblemen oder anderen unerwarteten Verhaltensweisen führen.



Wenn du mit einer UEFI-Windows-Installation arbeitest und sie zu einer VMDK-Datei konvertieren möchtest, gibt es einige zusätzliche Überlegungen, die du beachten solltest.

Im Kontext des UEFI-Bootschemas ist es erforderlich, eine spezielle UEFI- oder EFI-Partition zu haben. Du könntest auf zwei Arten damit umgehen. Die eine ist etwas komplexer, bietet aber eine sauberere Lösung: Du müsstest die VMDK-Datei nachträglich bearbeiten und manuell eine UEFI/EFI-Partition erstellen. Dieser Vorgang könnte das Verkleinern der Windows-Partition nach vorne erfordern, um Platz für die EFI-Partition zu schaffen.

Die andere Methode ist eine schnellere und weniger komplexe, wenn auch weniger elegante Lösung: Du könntest den Bootloader direkt auf das Laufwerk C: erstellen. Hierbei würdest du den Befehl bcdboot C:\Windows /s C: in der Eingabeaufforderung verwenden, um den Boot-Dateien zu ermöglichen, direkt von Laufwerk C: zu starten.

Die Wahl zwischen diesen Methoden hängt von deinen spezifischen Anforderungen und Fähigkeiten ab. Unabhängig davon, welche Methode du wählst, ist es wichtig, daran zu denken, dass wenn diese Schritte nicht ordnungsgemäß ausgeführt werden, deine Windows-Maschine nach dem Export möglicherweise nicht in Umgebungen wie z.B. ESXi starten wird. Daher ist es entscheidend, sorgfältig vorzugehen und sicherzustellen, dass du die richtigen Schritte unternimmst, um einen erfolgreichen Systemstart nach der Konvertierung zu gewährleisten.

Um den BCD-Boot-Eintrag auf Laufwerk C: zu verschieben, kannst du die Eingabeaufforderung verwenden und den `bcdboot` Befehl nutzen. Hier sind die Schritte:

1. Öffne die Eingabeaufforderung als Administrator. Du kannst dies tun, indem du auf das Startmenü klickst, "cmd" in die Suche eingibst und dann mit der rechten Maustaste auf "Eingabeaufforderung" klickst und "Als Administrator ausführen" wählst.

2. Gib folgenden Befehl ein:

bcdboot C:\Windows /s C: /f ALL
https://learn.microsoft.com/de-de/windows-hardware/manufacture/desktop/bcdboot-command-line-options-techref-di?view=windows-11

Dieser Befehl erstellt neue Boot-Dateien auf dem Laufwerk C: und verwendet die Windows-Installation auf dem gleichen Laufwerk.

3. Nachdem der Befehl ausgeführt wurde, sollte das System jetzt von Laufwerk C: booten.

Bitte beachte, dass du diesen Prozess nur durchführen solltest, wenn du komfortabel und erfahren im Umgang mit der Windows-Eingabeaufforderung und dem Boot-Konfigurationsdatenspeicher (BCD) bist. Ein falscher Befehl oder Fehler kann dazu führen, dass dein System nicht mehr startet. Es ist immer eine gute Idee, vor solchen Änderungen ein Backup deiner Daten zu erstellen.

Viele Grüße
Susanne
Steht eigentlich alles bereits in deinem Thema....
 
Das sind alte Server. Ich möchte die, da ich auf meiner Workstation vmware workstation habe die dort zum laufen bringen um die alten Daten dort umzokopieren da der Server defekt ist. Und mit vmware workstation kenne ich mich aus. Deshalb benötige ich die Konvertierung.

Das Problem mit den Rechten habe ich gelöst. den Access denied bekomme ich nicht mehr.. dennoch sehe ich die Daten nicht gar nichts. Alle liegen auch in den Verzeichnissen wo sie hingehören...
Ich habe kein Debian...kann ich das nicht mit den proxmox server konvertieren?
 
Sorry, ich komme so nicht weiter. Man muss doch diese Images in proxmox sehen können und dann konvertieren können.
 
Proxmox setzt auf Debian auf.
In der Proxmox Root - Konsole sollten alle Dateien sichtbar selbst sein. Da kann man dann auch die Befehle absetzen.

Wenn in der Root - Konsole die Dateien nicht angezeigt werden , gibt es ein Rechteproblen bzw. der (die) Ordner speichert nd leer.
 
Das würde doch passen, wenn ich das auf den Proxmox selber konvertieren kann.
qemu-img convert -f qcow2 -O vmdk F:\test.qcow2 F:\\test\test.vmdk
Wie müsste ich jetzt die Zeile abändern, wenn mein Share: NFS-Share von Namen heißt?
 
1. In Proxmox Konsole öffnen
2. In mount-Verzeichnis wechseln mit' cd /mnt/pve/nfs-share/<Verzeichnisname>'
3. Befehl ' ls - al' ausführen, um die vorhanden Dateien anzuzeigen.
4. Konvertierung starten mit 'qemu-img convert -f qcow2 -O vmdk original.qcow2 output.vmdk'

Groß-/Kleinschreibung bei Verzeichnissen und Dateinamen beachten sowie Namen von Images anpassen!
 
Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!