Proxmox VE

Proxmox Virtual Environment

Instalar Proxmox

Comprobar el sistema de archivos de un contenedor LXC en Proxmox

Convertir imagenes vmdk, raw, qcow2, vdi y vpc con qemu-img

Migrar de VMware a Proxmox

Proxmox Varios

Qemu-guest-agent

Usar Proxmox LXC

LXC Unprivileged container

Proxmox LXC ACL

Gestión de un contenedor LXC

Migrar máquina Windows a Proxmox

Reiniciar los servicios de Proxmox

Ceph

Migrar de Máquina física a Proxmox

Exportar una máquina virtual OVA de VmWare para importar en Proxmox

Descargar e instalar el MergeIDE

Migrar una máquina de Hyper V a Proxmox

Migrar de OVA a Proxmox

Conservar ajustes de una máquina física en Proxmox

Números de serie de discos en Proxmox

Instalar Proxmox
Pasos para instalar Proxmox
Requisitos previos:

Para instalaciones en servidores con arranque redundante (discos en raid1).

Es conveniente configurar un raid1 (en la controladora del servidor) con los discos de
arranque como un sólo volumen

Arrancaremos el servidor con el medio de arranque con la ISO de Proxmox en USB o CD, que
podemos crear con la herramienta ventoy

En cuanto arranque veremos la siguiente pantalla

Ejecutaremos el proceso de instalación pulsando Install Proxmox VE, en el mismo nos pedirá el
nombre de la máquina que debe de ser un nombre de dominio completo, seleccionar el disco de
arranque y el formato del mismo (LVM, ZFS, etc). Una dirección de correo electrónico, la dirección
IP, puerta de enlace y DNS.

Una vez instalado, seguiremos los siguientes pasos:

Cambiar los repositorios

Cambiar los repositorios por los que aparecen aquí en
https://pve.proxmox.com/wiki/Package_Repositories

Para ello debemos ir al fichero /etc/apt/sources.list.d/pve-enterprise.list y modificarlo aparecerá

una línea como la siguiente:

deb https://enterprise.proxmox.com/debian/pve stretch pve-enterprise

La comentamos introduciendo el símbolo # al principio de la línea

 #deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise

Editamos el fichero /etc/apt/sources.list

deb http://ftp.debian.org/debian buster main contrib

deb http://ftp.debian.org/debian buster-updates main contrib

# security updates
deb http://security.debian.org/debian-security buster/updates main contrib

Agregamos el repositorio de Proxmox gratuito (No subscription)

deb http://ftp.debian.org/debian buster main contrib

deb http://ftp.debian.org/debian buster-updates main contrib

# PVE pve-no-subscription repository provided by proxmox.com,

# NOT recommended for production use
deb http://download.proxmox.com/debian/pve buster pve-no-subscription

# security updates
deb http://security.debian.org/debian-security buster/updates main contrib

Instalar ntp
A continuación instalaremos el servicio ntp imprescindible si vamos a configurar un cluster de
Proxmox, o bien Ceph

Configurar la red
En primer lugar deberemos de instalar el open-vswitch, una vez instalado, deberemos de planificar
con sumo cuidado nuestra topología de red para Proxmox. Dependiendo del tipo de despliegue
seleccionaremos las redes segmentadas en VLAN que vamos a utilizar. A modo de ejemplo:

Una red para el cluster de Proxmox

Una red para Ceph
Una red para el almacenamiento Externo (NFS, iSCSI)
Una red para el almacenamiento de los backups.

Dependiendo del número de tarjetas, es conveniente que todas vayan a pares mediante un Bond
balance-slb y que vayan cada una a un switch diferente a efectos de garantizar la redundancia y
disponibilidad de las comunicaciones.

Es decir si tenemos 4 interfaces 10G en el equipo, podemos destinar 2 al cluster, al Ceph y a la

gestión, y las otras dos al almacenamiento y backup.
Comprobar el sistema de
archivos de un contenedor
LXC en Proxmox
Es muy sencillo chequear el sistema de archivos de un contenedor LXC en Proxmox desde la línea
de comandos. Tan sólo tenemos que recurrir al comando pct (Proxmox Container Toolkit).

Por ejemplo, supongamos que queremos comprobar el sistema de archivos del contenedor 135:

Primero pararemos el contenedor:

pct stop 135

Una vez detenido, realizamos el fsck:

pct fsck 135

fsck from util-linux 2.33.1
/var/lib/vz/images/135/vm-145-disk-0.raw: clean, 34327/524288 files, 296495/2097152 blocks
Convertir imagenes vmdk,
raw, qcow2, vdi y vpc con
qemu-img
a herramienta de línea de comandos qemu-img permite manipular y convertir varios formatos de
imagen de disco (vmdk, raw, qcow2, vdi y vpc), utilizados principalmente por sistemas de
virtualización como VMware, KVM, Xen, Virtualbox o Hyper-V.

El funcionamiento es realmente sencillo, lo primero que debemos revisar es que la herramienta

está instalada. En caso contrario, podemos instalarla desde apt:

# whereis qemu-img
qemu-img: /usr/bin/qemu-img /usr/share/man/man1/qemu-img.1.gz

A la hora de hacer la conversión, simplemente tenemos que tener en cuenta el formato e imagen
de disco origen y destino. Si no especificamos el formato de origen (-f ) qemu-img intenta
detectarlo de forma automática. El formato destino se especifica con -O y seguido la imagen de
origen y destino. El siguiente ejemplo convierte una imagen de disco de formato qcow2 (KVM) a
vmdk (VMware):

# qemu-img convert -f qcow2 -O vmdk imagen_origen.qcow2 imagen_destino.vmdk

Otro ejemplo en el que convertimos de imagen raw (.img) a qcow2:

# qemu-img convert -f raw -O qcow2 image_origen.img imagen_destino.qcow2

Una vez que tenemos la imagen convertida, por ejemplo a vmdk, tendríamos que crear una nueva
máquina virtual y en el proceso de creación asignarle el disco .vmdk que hemos creado con la
conversión («Use an existing virtual disk»). Existen otras opciones interesantes como activar la
compresión para la imagen de destino (sólo en qcow):

# qemu-img convert -c -f raw -O qcow2 disco_virtual.img disco_virtual_destino.qcow2

Migrar de VMware a
Proxmox
Instalar el mergeide que se puede descargar de varias ubicaciones, o desde aquí MergeIDE.zip

Este archivo es un ejecutable bat que inserta unas claves de registro. Si no se ejecuta, podemos
insertarlas a mano (vienen en el archivo ZIP) como podemos ver en la imagen inferior.

Comprobar que no están instaladas las VMWARE Tools

SI están instaladas, desinstalarlas y reiniciar

Apagar la máquina de VMWare

Copiar los archivos .vmdk a un almacenamiento en red.

Cuando copiamos los vmdk, hay dos archivos para cada disco, un vmdk y un flat-vmdk (por
ejemplo si tenemos un disco que se llama midisco, tendremos un midisco.vmdk y un midisco-
flat.vmdk). El primer archivo es un descriptor, y el segundo es el disco en sí.

Hay dos formas de realizar el proceso, con conversión de disco y después crear la
máquina, o bien creando la máquina e importando el disco

Conversión de disco
Ejecutar el convertidor de vmdk a qcow2 sobre el midisco.vmdk. Para ello, ambos ficheros vmdk
deben de estar en la misma carpeta.

El comando para realizar esto es:

qemu-img convert -f vmdk midisco.vmdk -O qcow2 midisco.qcow2

Una vez ha terminado el proceso de conversión que será largo, creamos una máquina virtual
nueva, con disco en formato IDE y almacenamiento en la unidad de red, ya que si la creamos en
ceph o en lvm o cualquier sistema de archivos local, creará un fichero de bloques y no un fichero
convencional.

Una vez creada la máquina, si el ID es por ejemplo 500, tendremos un archivo que se llamará
500.qcow2.

Ahora hacemos backup de este archivo (lo podemos llamar old500.qcow2) y renombramos el
archivo midisco.qcow2 como 500.qcow2.

Importando el disco
Otra opción es crear la máquina virtual y desde línea de comando ejecutar:

qm importdisk <machine-number> vmdk storage (lvm, nfs, etc)

machine-number es el número de la máquina creada, y storage es el nombre del almacenamiento

donde la vamos a almacenar.

Procesos a realizar
Arrancamos la máquina, si todo va bien, arrancará el sistema operativo. Si no es así. Podemos
hacer un truco, que es quitar el disco de la máquina virtual, y después agregarle de nuevo el disco
que aparecerá como unused (doble click en unused disk)

Si arranca la máquina, ahora le instalamos los drivers del virtio que los puedes descargar de aquí.

Si no tienes ningún dispositivo virtio (red, etc), para poner el disco en virtio (que es más mejor), lo
que hacemos es crearnos un disco de por ejemplo 5 Gb con virtio y asignarlo a la máquina.
Cuando arranque, nos pedirá los drivers del virtio para el disco, se los instalamos, y cuando
arranque la próxima vez, si reconoce el disco, apagamos, quitamos el disco IDE, luego añadimos el
disco de arranque que acabamos de desconectar y le decimos que es virtio (doble click en unused
disk) y luego, muy importante, vamos a opciones y cambiamos el orden de arranque para que
arranque del virtio en lugar del disco IDE (si no haces esto, te llevas un susto que para que….)

Y ya debería todo de funcionar correctamente.

En nuestro canal de Youtube, tienes un vídeo con el proceso completo.

No olvides suscribirte para estar informado de las novedades del canal.

Proxmox Varios
Ubicación de las VM en Proxmox
La ubicación de las VM en Proxmox es:

/etc/pve/qemu-server/<VMID>
Qemu-guest-agent

Introducción
Quemu-guest-agent es un daemon que se instala en el sistema operativo de la máquina KVM
invitado. Se utiliza para intercambiar información entre el host Proxmox y el invitado, y para
ejecutar comandos en el invitado.

En Proxmox VE, qemu-guest-agent se usa principalmente para dos cosas:

Para apagar correctamente el invitado, en lugar de depender de los comandos de ACPI o las
políticas de Windows

Para congelar el sistema de archivos invitado al hacer una copia de seguridad (en Windows, usa el
servicio de instantáneas de volumen VSS).

Instalación
Host Proxmox
Debe instalar el agente invitado en cada VM y luego habilitarlo, puede hacerlo en la interfaz web
(GUI) de Proxmox VE
O bien desde la linea de comando:

qm set VMID --agent 1

En este caso:

qm set 160 --agent 1

Invitado
Linux
En Linux, simplemente tiene que instalar qemu-guest-agent, según el sistema.

Mostramos aquí los comandos para sistemas basados en Debian / Ubuntu y Redhat:

en sistemas basados en Debian / Ubuntu (con apt-get) ejecuta:

apt install qemu-guest-agent

O bien

apt-get install qemu-guest-agent

Para sistemas basados en Redhat

yum install qemu-guest-agent

Una vez instalado, es necesario que se active, para ello ejecutaremos

systemctl start qemu-guest-agent

Para que se ejecute al inicio del sistema cada vez

systemctl enable qemu-guest-agent

Windows
Primero debe descargar el controlador virtio-win iso

Luego instala el controlador virtio-serial:

Monta la ISO en tu máquina virtual de Windows (virtio - *. Iso)

Vete al Administrador de dispositivos de Windows

Busque "Controlador de comunicaciones simple PCI"

Haz clic en el botón derecho -> Actualizar controlador y seleccione la iso montada en DRIVE: \
vioserial \ <OSVERSION> \ donde <OSVERSION> es su versión de Windows (por ejemplo, 2k12R2
para Windows 2012 R2)

Después de eso, debes instalar el qemu-guest-agent:

Ir al ISO montada en el explorador

El instalador del agente invitado está en el directorio guest-agent.

Ejecuta el instalador con un doble clic (ya sea qemu-ga-x86_64.msi (64 bits) o qemu-ga-i386.msi
(32 bits)

Después de eso, qemu-guest-agent debería estar en funcionamiento. Puede validar esto en la lista
de servicios de Windows, o en un PowerShell con:

PS C:\Users\Administrator> Get-Service QEMU-GA

Status Name DisplayName

 ------ ---- -----------
Running QEMU-GA QEMU Guest Agent

Si no se está ejecutando, puedes usar el panel de control de Servicios para iniciarlo y asegurarte
de que se inicie automáticamente en el próximo inicio.

Comprobando que la comunicación con el agente invitado

está funcionando
La comunicación con el agente invitado se realiza a través de un socket Unix ubicado en
/var/run/qemu-server/<vmid>.qga Puedes probar el agente de comunicación con el comando

qm agent <vmid> ping

Si qemu-guest-agent se está ejecutando correctamente en la VM, devolverá un mensaje de error.

root@hv101:~# qm agent 160 ping

root@hv101:~#

Más información
https://wiki.qemu.org/Features/GuestAgent
Usar Proxmox LXC
A diferencia de las máquinas virtuales KVM, que se pueden instalar desde imágenes ISO, los
contenedores LXC solo se pueden implementar mediante plantillas de contenedor. Las plantillas de
contenedor no son las mismas que las plantillas que creamos para KVM en el capítulo anterior. Las
plantillas LXC de varios sistemas operativos y un contenedor específico de la aplicación se pueden
descargar directamente desde el repositorio de Proxmox. Para ver una lista de plantillas
disponibles ya descargadas, debemos seleccionar un almacenamiento adjunto que pueda
almacenar plantillas de contenedores y hacer clic en la pestaña Contenido, como se muestra en la
siguiente captura de pantalla:

En la captura de pantalla anterior, podemos ver que tenemos una plantilla de contenedor de
Ubuntu que ya está descargada en nuestro almacenamiento local. Para ver una lista de plantillas
LXC disponibles y descargarlas del repositorio de Proxmox, debemos hacer clic en el menú
Plantillas para abrir el cuadro de diálogo:
Hay más de 100 plantillas disponibles para descargar desde este cuadro de diálogo. Si no puedes
ver la lista completa y solo muestra la Sección: plantillas del sistema, ejecuta el siguiente comando
desde la CLI para actualizar la lista de plantillas:

pveam update

Para descargar una plantilla, simplemente selecciónela y haga clic en el botón Descargar. La
plantilla descargada ahora estará disponible en el almacenamiento. La ubicación predeterminada
para almacenar las plantillas de contenedores para el almacenamiento local es la siguiente:

/mnt/pve/<storage>/template/cache

En nuestro caso, tenemos un volumen NFS denominado isos, en el que se almacenan tanto
plantillas como imágenes ISO, a fin de ahorrar espacio en el almacenamiento local de los nodos.

También se puedes descargar desde consola mediante el comando:

La sintaxis es la siguiente:

pveam download <almacenamiento> <nombre_de_la_imagen>

Ejemplo
pveam download isos debian-10.0-standard_10.0-1_amd64.tar.gz
LXC Unprivileged container
Los contenedores sin privilegios son cuando el contenedor se crea y se ejecuta como usuario en
lugar de root. Esta es la forma más segura de usar un contenedor porque si la seguridad del
contenedor se ve comprometida y el intruso sale del contenedor, se encontrará como un usuario
nobody con privilegios extremadamente limitados.

Los contenedores sin privilegios no necesitan ser propiedad del usuario, ya que se ejecutan en
espacios de nombres de usuario. Esta es una función del kernel que permite la asignación del UID
de un host físico en un espacio de nombres dentro del cual puede existir un usuario con UID 0. Los
contenedores sin privilegios también se pueden ejecutar como root. Al asignar un UID y un GID
específicos a root, podemos crear contenedores sin privilegios en todo el sistema y ejecutarlos
como raíz.
Los contenedores privilegiados son cuando son creados y ejecutados solo por el usuario raíz. Estos
contenedores no son seguros porque todos los procesos aún se ejecutan como root. Todos los
contenedores creados a través de la GUI de Proxmox o las herramientas PCT son contenedores
privilegiados.

Si la seguridad total o el aislamiento completo de la máquina virtual es la principal

preocupación para un entorno, es mejor usar una máquina virtual KVM, porque KVM es una
máquina virtual totalmente independiente sin ninguna dependencia del sistema operativo
host ni recursos compartidos.
Como podemos ver en la imagen, por defecto los contenedores LXC se crean como Unprivileged
container
Proxmox LXC ACL
Las listas de control de acceso o ACL nos permiten establecer una propiedad de archivos más
precisa que los modelos tradicionales de acceso de usuarios o grupos de Linux. De forma
predeterminada, Proxmox crea contenedores LXC con ACL. Para crear un contenedor sin ACL,
selecciona Disabled en el menú desplegable.
Gestión de un contenedor
LXC
En Proxmox, cada contenedor LXC tiene dos archivos de configuración. Uno define la asignación de
recursos sin procesar, mientras que el otro, utilizado por Proxmox, se usa para definir un
contenedor. El archivo de configuración del contenedor Proxmox se puede encontrar en la
siguiente ubicación:

/etc/pve/local/lxc/<container_id>.conf

Por ejemplo supongamos un LXC on id 900

El archivo

/etc/pve/local/lxc/900.conf contiene:

arch: amd64

cores: 4

features: nesting=1

hostname: test

memory: 4096

nameserver: 1.1.1.1 9.9.9.9

net0: name=eth0,bridge=vmbr0,hwaddr=CA:A7:6E:28:7B:93,ip=dhcp,tag=18,type=veth

ostype: debian

rootfs: local-lvm:vm-900-disk-0,size=8G

searchdomain: ateinco.net

swap: 0

unprivileged: 1

El archivo de configuración del contenedor sin procesar se puede encontrar en la siguiente

ubicación:

/var/lib/lxc/<container_id>/config

En nuestro caso en /var/lib/lxc/900/config contiene:

arch: amd64

cores: 4

features: nesting=1

hostname: test

memory: 4096

nameserver: 1.1.1.1 9.9.9.9

net0: name=eth0,bridge=vmbr0,hwaddr=CA:A7:6E:28:7B:93,ip=dhcp,tag=18,type=veth

ostype: debian

rootfs: local-lvm:vm-900-disk-0,size=8G

searchdomain: ateinco.net

swap: 0

unprivileged: 1

root@hv201:/etc/pve/local/lxc# pwd

/etc/pve/local/lxc

root@hv201:/etc/pve/local/lxc# cd /var/lib/lxc/

root@hv201:/var/lib/lxc# cd 900

root@hv201:/var/lib/lxc/900# cat config

lxc.cgroup.relative = 0

lxc.cgroup.dir.monitor = lxc.monitor/900

lxc.cgroup.dir.container = lxc/900

lxc.cgroup.dir.container.inner = ns

lxc.arch = amd64

lxc.include = /usr/share/lxc/config/debian.common.conf

lxc.include = /usr/share/lxc/config/debian.userns.conf

lxc.seccomp.profile = /var/lib/lxc/900/rules.seccomp

lxc.apparmor.profile = generated

lxc.apparmor.allow_nesting = 1

lxc.mount.auto = sys:mixed

lxc.monitor.unshare = 1

lxc.idmap = u 0 100000 65536

lxc.idmap = g 0 100000 65536

lxc.tty.max = 2

lxc.environment = TERM=linux

lxc.uts.name = test

lxc.cgroup2.memory.max = 4294967296

lxc.cgroup2.memory.swap.max = 0

lxc.rootfs.path = /var/lib/lxc/900/rootfs

lxc.net.0.type = veth

lxc.net.0.veth.pair = veth900i0

lxc.net.0.hwaddr = CA:A7:6E:28:7B:93
 lxc.net.0.name = eth0

lxc.net.0.script.up = /usr/share/lxc/lxcnetaddbr

lxc.cgroup2.cpuset.cpus = 11,14,17,21

Hay otro directorio para el sistema de archivos raíz que es un punto de montaje para el espacio de
almacenamiento asignado dentro del contenedor. La ubicación del directorio es

/var/lib/lxc/<container_id>/rootfs/

Veamos pues que archivos y carpetas contiene nuestro contenedor:

root@hv201:/var/lib/lxc/900# ls -la

total 24

drwxr-xr-x 4 root root 4096 Mar 17 19:36 .

drwxr-xr-x 12 root root 4096 May 11 11:31 ..

drwxr-xr-x 2 root root 4096 Jan 6 12:43 apparmor

-rw-r--r-- 1 root root 864 Mar 17 19:36 config

drwxr-xr-x 2 root root 4096 Dec 15 12:09 rootfs

-rw-r--r-- 1 root root 265 Mar 17 19:36 rules.seccomp

Vemos que la carpeta rootfs está vacía.

root@hv201:/var/lib/lxc/900/rootfs# ls -la

total 8

drwxr-xr-x 2 root root 4096 Dec 15 12:09 .

drwxr-xr-x 4 root root 4096 Mar 17 19:36 ..

En Proxmox, este directorio no se utiliza para almacenar datos de contenedores. Para el

almacenamiento local, se crea la imagen del disco virtual del contenedor en la carpeta:

/var/lib/vz/images/<container_id>/

Para el almacenamiento compartido, la imagen del disco virtual del contenedor se crea en:

/mnt/pve/<storage>/images/container_id/

Podemos ajustar los recursos asignados para un contenedor en tiempo real sin apagar y encender
el contenedor. Esta característica se conoce como hotplug para máquinas virtuales KVM. Sin
embargo, para los contenedores LXC, esta característica está integrada en la tecnología del
contenedor sin necesidad de ninguna modificación de configuración adicional.

La RAM y la CPU se pueden modificar como hemos comentado sin apagar el contenedor, pero para
el disco solo podemos aumentar el tamaño del almacenamiento asignado, pero no podemos
disminuirlo. Podemos escribir un valor en GB o usar las flechas arriba y abajo para ajustar el
tamaño. Es importante señalar aquí que el valor que seleccionaremos aquí no es el tamaño total
del espacio asignado. Este valor se suma al espacio ya asignado. Por ejemplo, en nuestro
contenedor de ejemplo #900, el espacio asignado actualmente es de 8 GB. Entonces, si queremos
aumentar eso a un tamaño total de 10 GB, escribiremos 2 en el cuadro de diálogo, lo que
aumentará el tamaño en 2 GB. Haz clic en el botón Cambiar tamaño de disco en el cuadro de
diálogo para modificarlo.
Migrar máquina Windows a
Proxmox
Procedimiento para la migración de una máquina física a virtual con Windows

Preparativos:

Instalar los drivers mergeide en la máquina que se va a migrar.

Realizar una copia completa del sistema, para esto se puede usar Acronis, Clonezilla o alguna
herramienta similar.

Provisionar una nueva maquina en Proxmox y proceder a restaurar la máquina desde la imagen
creada. Esta máquina debe de tener un disco con interfaz IDE o SATA a fin de garantizar el primer
arranque

Descargar los drivers virtio desde fedora

Reiniciar los servicios de
Proxmox
Si nuestro servidor Proxmox queda inactivo por cualquier problema y no podemos acceder a la
administración web, para poder solucionar esto podemos probar a reiniciar los servicios de
Proxmox

killall -9 corosync

systemctl restart pve-cluster

systemctl restart pvedaemon

systemctl restart pveproxy

systemctl restart pvestatd

Ceph

Formato de los OSD

Los OSD pueden estar en filestore (obsoleto), discos LVM o discos XFS.

Se han observado problemas en versiones desde la Pacific con los XFS, por lo que es
recomendable convertirlos a LVM. Para ello, es suficiente con recrearlos (antes de la actualización,
en Octopus):

1. Identificar los discos que hay que recrear y anotar sus identificadores.
2. Activar noout para limitar en lo posible el rebalanceo.
3. Por cada disco:
1. Marcarlo "out"
2. Esperar a que Ceph rebalancee
3. Pararlo ("Stop")
4. Limpiarlo (en Proxmox, More/Destroy)
5. Volverlo a crear (en Proxmox, Create: OSD)
4. Desactivar noout al acabar.

Cluster autocontenido de Ceph (sin

Proxmox)
Ceph tiene un director llamado Cephadm que permite crear y gestionar clusters con una cantidad
aceptable de dolor.

Para crear un cluster con Ceph y gestionarlo con Cephadm, se parte de un grupo de servidores
Debian, preferiblemente recién instalados.

Instalación
Para una instalación a lo Debian, el método más recomendable es el indicado en el manual como
método manual.

Solamente se necesita un repo y una clave para la instalación.

Añadir el repo y clave de Ceph
$ sudo tee "deb https://download.ceph.com/debian-quincy/ bullseye main"

/etc/apt/sources.list.d/ceph.list

$ wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add -

Operaciones
Añadir OSDs
$ sudo ceph orch daemon add osd servidor:/dev/disco

Lavar discos
$ sudo ceph orch device zap --force servidor /dev/disco
Migrar de Máquina física a
Proxmox
Pasos previos
Instalar el mergeide que se pude descargar de varias ubicaciones, o desde aquí MergeIDE.zip

Este archivo es un ejecutable bat que inserta unas claves de registro. Si no se ejecuta, podemos
insertarlas a mano (vienen en el archivo ZIP) como podemos ver en la imagen inferior.

Si no se instalan las claves de registro del mergeide, puede que también funcione, pero va a
ser un poco más complicado (atención a lo de "puede que también funcione) porque a
veces no

Generar imagen de la máquina física

Una vez instalado el Mergeide, procedemos a arrancar la máquina desde un sistema Linux desde
CD o USB, recomendamos la utilidad GRML que se puede descargar de grml.org

Una vez que se ha arrancado la máquina, deberemos de tener un disco extraíble o una unidad de
red a la que copiar nuestro archivo de imagen que generaremos con la utilidad ddrescue. El
manual de esta utilidad lo podemos localizar aquí

Montamos la unidad de disco extraible o el NFS en el Linux o en el grml.

En nuestro ejemplo la vamos a llamar copia

mkdir /mnt/copia

Montamos el disco

mount /dev/sdb1 /mnt/copia

O bien si es un NTFS

mount -t ntfs /dev/sdb1 /mnt/copia

Ejecutaremos el comando ddrescue

ddrescue -d -f -r3 /dev/sda /mnt/copia/windows_2019.img rescue.log

Copiar el archivo img a un almacenamiento en red.

Convertir imagen de máquina física a Proxmox

Para esto existen dos formas

qemu-img convert
Ejecutar el convertidor de vmdk a qcow2 sobre el midisco.vmdk. Para ello, ambos ficheros vmdk
deben de estar en la misma carpeta.

El comando para realizar esto es:

qemu-img convert -f raw midisco.raw -O qcow2 midisco.qcow2

Una vez ha terminado el proceso de conversión que será largo, creamos una máquina virtual
nueva, con disco en formato IDE y almacenamiento en la unidad de red, ya que si la creamos en
ceph o en lvm o cualquier sistema de archivos local, creará un fichero de bloques y no un fichero
convencional.
Una vez creada la máquina, si el ID es por ejemplo 500, tendremos un archivo que se llamará
500.qcow2.

Ahora hacemos backup de este archivo (lo podemos llamar old500.qcow2) y renombramos el
archivo midisco.qcow2 como 500.qcow2.

qm importdisk (la más cómoda)

Otra opción es crear la máquina virtual y desde línea de comando ejecutar:

qm importdisk <machine-number> windows_1029.img storage (lvm, nfs, etc)

NOTA IMPORTANTE Personalmente, una vez creada la máquina y para seguir el orden
(vmxxx-disk0, vmxxx-disk1) es aconsejable borrar el disco de la máquina recién creada y
que el proceso de importación del disco cree el disco con el ID 0

machine-number es el número de la máquina creada, y storage es el nombre del almacenamiento

donde la vamos a almacenar.

Esto nos creará un disco sin asignar en la máquina, que asignaremos con el interfaz SATA como
interfaz de disco.

Cambiaremos el orden de arranque para que haga el arranque desde el disco SATA recién asignado

Arrancamos la máquina, si todo va bien, arrancará el sistema operativo. Si no es así. Podemos

hacer un truco, que es quitar el disco de la máquina virtual, y después agregarle de nuevo el disco
que aparecerá como unused (doble click en unused disk)

Si arranca la máquina, ahora le instalamos los drivers del virtio que los puedes descargar de aquí.

Si no tienes ningún dispositivo virtio (red, etc), para poner el disco en virtio (que es más mejor), lo
que hacemos es crearnos un disco de por ejemplo 5 Gb con virtio y asignarlo a la máquina.

Cuando arranque, nos pedirá los drivers del virtio para el disco, se los instalamos, y cuando
arranque la próxima vez, si reconoce el disco, apagamos, quitamos el disco IDE o SATA, luego
añadimos el disco de arranque que acabamos de desconectar y le decimos que es virtio (doble
click en unused disk) y luego, muy importante, vamos a opciones y cambiamos el orden de
arranque para que arranque del virtio en lugar del disco IDE (si no haces esto, te llevas un susto
que para que….)

Y ya debería todo de funcionar correctamente.

Enlace al vídeo en youtube

Por último os pasamos un enlace a un vídeo en YouTube, donde se explica el proceso
Exportar una máquina
virtual OVA de VmWare para
importar en Proxmox
Como en anteriores ocasiones, si tenemos una máquina Windows, lo primero que tendremos que
hacer es instalar el MergeIde.zip en la máquina antes de exportar

Este archivo es un ejecutable bat que inserta unas claves de registro. Si no se ejecuta, podemos
insertarlas a mano (vienen en el archivo ZIP) como podemos ver en la imagen inferior.

"ExportarA continuación procederemos a crear el archivo OVA que se puede hacer desde las
plataformas de Virtualización habituales

VMWARE
En VMWare seleccionaremos la máquina virtual, y en archivo seleccionaremos "Exportar" y
"Exportar Plantilla de OVF"

Ahora nos preguntará en que formato queremos exportar ls máquina virtual, hay dos opciones en
OVF (Carpeta de archivos) o en OVA (Un sólo archivo)
Seleccionaremos el Directorio en el que vamos a exportar y esperamos a que termine el proceso.
Descargar e instalar el
MergeIDE
Instalar el mergeide que se puede descargar de varias ubicaciones, o desde aquí MergeIDE.zip

Este archivo es un ejecutable bat que inserta unas claves de registro. Si no se ejecuta, podemos
insertarlas a mano (vienen en el archivo ZIP) como podemos ver en la imagen inferior.
Migrar una máquina de
Hyper V a Proxmox
A partir de una máquina de Hyper-V podemos realizar una copia del disco duro de dicha máquina y
de esta forma poder migrar la máquina a Proxmox.

La secuencia consiste en copiar el disco duro que se encuentra normalmente en:

C:\Program Data\Microsoft\Windows\Virtual Hard Disks

El disco se compone al igual que en el caso de los discos vmdk de Vmware de dos archivos, un
archivo con la extensión vhdx, que contiene la descripción del disco, y el archivo del disco en sí,
que suele ser el nombre de la máquina y un UID con la extensión avhdx

El formato de las máquinas Hyper V es vhdx, este formato no deja de ser un formato raw de
máquina virtual, para importar una máquina desde Hyper V, tendremos que ejecutar o bien una
conversión de disco

Una vez copiados, podemos hacer lo siguiente para importarlo en Proxmox:

Conversión de disco
qemu-img convert -f vhdx -O raw windowsvmdisk.vhdx proxmoxdisk.raw

Este comando es el que se usa para convertir entre formatos de imágenes en qemu, cómo
podemos ver en detalle en este artículo

Ahora podemos importar el disco en nuestra máquina virtual mediante el qm importdisk

Creación de la máquina e importación del disco

La otra opción es crear la máquina virtual previamente y desde línea de comando ejecutar:

qm importdisk <machine-number> vhdx storage (lvm, nfs, etc)

machine-number es el número de la máquina creada, y storage es el nombre del almacenamiento

donde la vamos a almacenar.

Esto realiza el proceso de conversión en un sólo paso.

Procesos a realizar
Arrancamos la máquina, si todo va bien, arrancará el sistema operativo. Si no es así. Podemos
hacer un truco, que es quitar el disco de la máquina virtual, y después agregarle de nuevo el disco
que aparecerá como unused (doble click en unused disk)

Si arranca la máquina, ahora le instalamos los drivers del virtio que los puedes descargar de aquí.

Si no tienes ningún dispositivo virtio (red, etc), para poner el disco en virtio (que es más mejor), lo
que hacemos es crearnos un disco de por ejemplo 5 Gb con virtio y asignarlo a la máquina.

Cuando arranque, nos pedirá los drivers del virtio para el disco, se los instalamos, y cuando
arranque la próxima vez, si reconoce el disco, apagamos, quitamos el disco IDE, luego añadimos el
disco de arranque que acabamos de desconectar y le decimos que es virtio (doble click en unused
disk) y luego, muy importante, vamos a opciones y cambiamos el orden de arranque para que
arranque del virtio en lugar del disco IDE (si no haces esto, te llevas un susto que para que….)

Y ya debería todo de funcionar correctamente.

Migrar de OVA a Proxmox
Copiaremos el archivo OVA a una carpeta local o NFS en Proxmox.

Tenemos en primer lugar que descomprimir el archivo OVA

tar xvf debian-minimal-12.1.0.ova

En algunos casos, tendremos que instalar el tar si no está en Proxmox

Esto nos dejará tres archivos (o más si la máquina tiene más discos)

debian-minimal-12.1.0.ovf

debian-minimal-12.1.0.mf

debian-minimal-12.1.0-disk1.vmdk

El archivo ovf contiene la descripción e la máquina virtual

<?xml version="1.0" encoding="UTF-8"?>

<!--Generated by VMware ESX Server, User: root, UTC time: 2023-07-30T12:14:21.762012Z-->

<Envelope vmw:buildId="build-14320388" xmlns="http://schemas.dmtf.org/ovf/envelope/1"

xmlns:cim="http://schemas.dmtf.org/wbem/wscim/1/common"

xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1"

xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/>

<References>

<File ovf:href="debian-minimal-12.1.0-disk1.vmdk" ovf:id="file1" ovf:size="459838464"/>

</References>

<DiskSection>

<Info>Virtual disk information</Info>

<Disk ovf:capacity="40000" ovf:capacityAllocationUnits="byte * 2^20" ovf:diskId="vmdisk1"

ovf:fileRef="file1"

ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized"

ovf:populatedSize="1528823808"/>

</DiskSection>

<NetworkSection>

<Info>The list of logical networks</Info>

<Network ovf:name="VM Network">

 <Description>The VM Network network</Description>

</Network>

</NetworkSection>

<VirtualSystem ovf:id="debian-minimal-12.1.0">

<Info>A virtual machine</Info>

<Name>debian-minimal-12.1.0</Name>

<OperatingSystemSection ovf:id="1" vmw:osType="otherGuest">

<Info>The kind of installed guest operating system</Info>

</OperatingSystemSection>..........................................

Ejecutaremos el comando qm importovf

qm importovf <vmid> <manifest> <storage> [OPTIONS]

vmid es el ide nuestra nueva máquina, manifest es el archivo ovf y storage es el almacenamiento
destino

En este caso lo hacemos con --dryrun que no modifica nada, y nos permite comprobar que todo
está correcto.

qm importovf 202 debian-minimal-12.1.0.ovf local-lvm --dryrun

"disks" : [

"backing_file" : "/mnt/pve/NAS/debian-minimal-12.1.0-disk1.vmdk",

"disk_address" : "scsi0",

"virtual_size" : 41943040000

],

"qm" : {

"cores" : "2",

"memory" : "2048",

"name" : "debian-minimal-12.1.0"

Como vemos, ha pasado los chequeos

Ahora podemos ejecutar el comando sin el dry-run y nos creará la máquina virtual

root@pve:/mnt/pve/NAS# qm importovf 202 debian-minimal-12.1.0.ovf local-lvm

Logical volume "vm-202-disk-0" created.

 transferred 0.0 B of 39.1 GiB (0.00%)

transferred 400.0 MiB of 39.1 GiB (1.00%)

transferred 804.0 MiB of 39.1 GiB (2.01%)

transferred 1.2 GiB of 39.1 GiB (3.01%)

transferred 1.6 GiB of 39.1 GiB (4.01%)

transferred 2.0 GiB of 39.1 GiB (5.02%)

transferred 2.4 GiB of 39.1 GiB (6.02%)

transferred 2.7 GiB of 39.1 GiB (7.02%)

transferred 3.1 GiB of 39.1 GiB (8.02%)

transferred 3.5 GiB of 39.1 GiB (9.03%)

transferred 3.9 GiB of 39.1 GiB (10.03%)

transferred 4.3 GiB of 39.1 GiB (11.03%)

transferred 4.7 GiB of 39.1 GiB (12.04%)

transferred 5.1 GiB of 39.1 GiB (13.04%)

transferred 5.5 GiB of 39.1 GiB (14.04%)

transferred 5.9 GiB of 39.1 GiB (15.05%)

transferred 6.3 GiB of 39.1 GiB (16.05%)

transferred 6.7 GiB of 39.1 GiB (17.05%)

transferred 7.1 GiB of 39.1 GiB (18.06%)

transferred 7.4 GiB of 39.1 GiB (19.06%)

transferred 7.8 GiB of 39.1 GiB (20.06%)

transferred 8.2 GiB of 39.1 GiB (21.06%)

transferred 8.6 GiB of 39.1 GiB (22.07%)

transferred 9.0 GiB of 39.1 GiB (23.07%)

transferred 9.4 GiB of 39.1 GiB (24.07%)

transferred 9.8 GiB of 39.1 GiB (25.08%)

transferred 10.2 GiB of 39.1 GiB (26.08%)

transferred 10.6 GiB of 39.1 GiB (27.08%)

transferred 11.0 GiB of 39.1 GiB (28.09%)

transferred 11.4 GiB of 39.1 GiB (29.09%)...............

...........................................

transferred 38.0 GiB of 39.1 GiB (97.30%)

transferred 38.4 GiB of 39.1 GiB (98.30%)

transferred 38.8 GiB of 39.1 GiB (99.31%)

transferred 39.1 GiB of 39.1 GiB (100.00%)

transferred 39.1 GiB of 39.1 GiB (100.00%)

root@pve:/mnt/pve/NAS#

En ese momento tendremos una nueva máquina virtual en nuestro Proxmox con el ID 202
Vemos que ha configurado todo, tal como venía en el fichero ovf

Y ahora podremos realizar los cambios necesarios una vez arranque (MAC, tipo de disco,
procesador, etc)
Problemas que podemos encontrarnos
Algunas veces el disco del archivo manifest (ovf) no está demasiado bien definido, y nos puede dar
problemas

root@pve:/mnt/pve/NAS/PF# qm importovf 204 PacketFence-ZEN-v13.0.0.ovf local-lvm --dryrun

warning: unable to parse the VM name in this OVF manifest, generating a default value

invalid host ressource /disk/vmdisk1, skipping

"disks" : [],

"qm" : {

"cores" : "4",

"memory" : "12288"

En este caso, ejecutaremos, pero no nos creará el disco

root@pve:/mnt/pve/NAS/PF# qm importovf 204 PacketFence-ZEN-v13.0.0.ovf local-lvm

warning: unable to parse the VM name in this OVF manifest, generating a default value
 invalid host ressource /disk/vmdisk1, skipping

Como vemos nos ha creado una máquina sin nombre, y sin disco.

No hay problema, importamos posteriormente el disco.

root@pve:/mnt/pve/NAS/PF# qm importdisk 204 PacketFence-ZEN-v13.0.0-disk1.vmdk local-lvm

importing disk 'PacketFence-ZEN-v13.0.0-disk1.vmdk' to VM 204 ...

Logical volume "vm-204-disk-0" created.

transferred 0.0 B of 195.3 GiB (0.00%)

transferred 2.0 GiB of 195.3 GiB (1.00%)

transferred 3.9 GiB of 195.3 GiB (2.00%)

transferred 5.9 GiB of 195.3 GiB (3.00%)

transferred 7.8 GiB of 195.3 GiB (4.00%)

transferred 9.8 GiB of 195.3 GiB (5.00%)

transferred 11.7 GiB of 195.3 GiB (6.00%)

transferred 13.7 GiB of 195.3 GiB (7.00%)

transferred 15.6 GiB of 195.3 GiB (8.00%)

transferred 17.6 GiB of 195.3 GiB (9.00%)

transferred 19.5 GiB of 195.3 GiB (10.00%)

transferred 21.5 GiB of 195.3 GiB (11.00%)

transferred 23.4 GiB of 195.3 GiB (12.00%)

transferred 25.4 GiB of 195.3 GiB (13.00%)

transferred 27.3 GiB of 195.3 GiB (14.00%)

 transferred 29.3 GiB of 195.3 GiB (15.00%)

transferred 31.2 GiB of 195.3 GiB (16.00%)

transferred 33.2 GiB of 195.3 GiB (17.00%)

..........................................

transferred 183.6 GiB of 195.3 GiB (94.00%)

transferred 185.5 GiB of 195.3 GiB (95.00%)

transferred 187.5 GiB of 195.3 GiB (96.00%)

transferred 189.5 GiB of 195.3 GiB (97.00%)

transferred 191.4 GiB of 195.3 GiB (98.00%)

transferred 193.4 GiB of 195.3 GiB (99.00%)

transferred 195.3 GiB of 195.3 GiB (100.00%)

transferred 195.3 GiB of 195.3 GiB (100.00%)

Successfully imported disk as 'unused0:local-lvm:vm-204-disk-0'

Nos habrá creado un Unsued Disk 0, que si hacemos doble click sobre él, lo podremos asignar a la
máquina

Simplemente hacemos doble click en el disco Unused Disk 0

Escogemos el tipo de Bus/Device (IDE, SATA, etc) en nuestro caso Virtio

Y ya lo tenemos todo a falta de renombrar la máquina

Conservar ajustes de una
máquina física en Proxmox
Muchos sistemas y muchas aplicaciones verifican la información del BIOS durante el proceso de
instalación o bien para conservar los datos de licencia de algún software y si están instaladas en un
hardware diferente al que fueron producidas, la instalación falla con un mensaje como este: "Este
sistema no es una plataforma compatible".

Para ver los datos de la máquina podemos ejecutar lo siguiente

# dmidecode 2.11

SMBIOS 2.6 present.

35 structures occupying 1145 bytes.

Table at 0x000FB330.

Handle 0x0000, DMI type 0, 24 bytes

BIOS Information

Vendor: HP

Version: O41

Release Date: 07/29/2011

...

...

Handle 0x0001, DMI type 1, 27 bytes

System Information

Manufacturer: HPE

Product Name: ProLiantDL380Gen10

Version:U30

Serial Number: 123456AB

UUID: 1E3BD500-1DD2-11B2-8000-009C02ABDD39

Wake-up Type: Power Switch

SKU Number: P24841-B21

Family:

Esto nos da la información de la máquina física, para proceder cuando instalemos o migremos una
máquina a un entorno Proxmox, podríamos necesitar dicha información

A efectos de realizar esto, agregamos esta información en la configuración de la máquina virtual

 <os>

<type arch=’x86_64′ machine=’pc-1.0′>hvm</type>

<boot dev=’hd’/>

<bootmenu enable=’yes’/>

<smbios mode=’sysinfo’/>

</os>

<sysinfo type=’smbios’>

<bios>

<entry name=’vendor’>HP</entry>

<entry name=’version’>P71</entry>

</bios>

<system>

<entry name=’manufacturer’>HP</entry>

<entry name=’product’>ProLiant DL360p Gen8</entry>

<entry name=’serial’>CZJ3210VK4</entry>

<entry name=’sku’>646901-421</entry>

</system>

</sysinfo>

O bien desde la interfaz gráfica (necesitaremos apagar la máquina)

Entramos en opciones, y en el apartado SMBIOS Settings, hacemos doble click

Rellenaremos con los valores que hemos obtenido con el comando dmidecode.

Pulsamos OK, y la máquina ahora tendrá los valores que tenía la máquina original
Por lo que a nivel de datos de hardware será la misma que la máquina física que teníamos

Si esto nos ocurre también con el número de serie de algún disco, la solución la tenemos

aquí.
Números de serie de discos
en Proxmox
Como habíamos comentado en el apartado de conservar los valores de los parámetros físicos de

una máquina física en una máquina virtual, también puede ocurrir algo parecido con los discos.

Muchas aplicaciones en su instalación guardan el valor del número de serie del disco de la
máquina, por lo que una migración puede dejar el registro del aplicativo inservible.

Cambiar o establecer el número de serie de un disco en

Proxmox VE
Para solucionar esto, os vamos a contar como definir un número de serie determinado en un disco
duro en Proxmox VE.

Pongamos el ejemplo de una máquina con discos virtio.

El comando para establecer un número de serie determinado a los discos sería este para por
ejemplo 3 discos de una máquina virtual.

root@hv9:~# qm set 9995 --virtio1 local-lvm:vm-9995-disk-1,serial=vm9995disk1

update VM 9995: -virtio1 local-lvm:vm-9995-disk-1,serial=vm9995disk1

root@hv9:~# qm set 9995 --virtio2 local-lvm:vm-9995-disk-2,serial=vm9995disk2

update VM 9995: -virtio2 local-lvm:vm-9995-disk-2,serial=vm9995disk2

root@hv9:~# qm set 9995 --virtio3 local-lvm:vm-9995-disk-3,serial=vm9995disk3

update VM 9995: -virtio3 local-lvm:vm-9995-disk-3,serial=vm9995disk3

root@hv9:~#

Los discos ahora quedarían pendientes de apagar y reiniciar la máquina para que los valores
queden grabados
SI el número de serie que necesitamos es otro, bastará con obtener el número de serie original del
disco y escribirlo.

Otras controladoras
Esto lo hemos visto para virtio, pero en el caso de otras controladores el proceso es el mismo,
supongamos que el número de serie de nuestro disco es 12345678, en el caso de una controladora
IDE

El comando sería

qm set 104 --ide1 local-lvm:vm-104-disk-1,serial=12345678

Como vemos la sintaxis es qm set [número o id de la máquina] --controlador (virtio,ide,scsi,sata) y
el número, el nombre del archivo o del objeto disco (incluyendo el almacenamiento) y el número de
serie.

Vemos otros ejemplos

En este caso el comando sería

qm set 104 --sata0 local-lvm:vm-104-disk-1,serial=12345678