Brtfs + cow2 + brtfs

Estoy utilizando en qemu/kvm varias máquinas virtuales, para trabajar y otra para anonimato, pruebas etc.

Mi sistema principal está con BRTFS y las máquinas siempre he elegido formato COW2 pensando sobre todo en snapshot y que el disco se expande según se necesita. Y dentro la máquina lo configuraba con BRTFS el Sistema operativo.

Pero me llamó la atención que Proxmox montaba los discos en RAW y al indagar, es que parece que es bastante absurdo montar 3 capas de tipo COW. Y lo más eficiente y lógico es montar Sistema Base (BRTFS) + QEMU/KVM (RAW) + Sistema host (ext4 por ejemplo)

¿Es correcto? ¿veis algún fallo a esta lógica?

Creo que estas confundiendo tipo de archivos de las imágenes con sistema de archivos (formateo) de particiones.
Brtfs y ext4 son sistemas de archivos que eliges cuando creas y formateas una partición de una disco duro para instalar un SO o guardar datos.
Cow2 y RAW son tipos de formatos de los archivos o imágenes de disco de las maquinas virtuales. Otros tipos de imágenes son qconv, vmdk, vdi, vhdx…

Si RAW es mejor que COW2 o viceversa, no sabría decirte cual es mejor.

PD: Sobre Brtfs, ext4, xfs, etc… tienes información en algunas de las respuestas de mi compañero karlggest en algunos hilos.
Sobre raw, cow2, vdi… no recuerdo ningún debate sobre ello.

Sí, tienes razón que estoy mezclando imágenes con sistema de archivos, pero lo que me llevó a pensar en esto es que al tener Btrfs en el host (que ya es copy-on-write), luego usar QCOW2 (que también lo es) y dentro de la VM otro Btrfs, me pareció que estaba apilando varias capas que hacen cosas parecidas, snapshots, compresión, etc…

En primer luga rme llamó la atención que proxmox usa RAW porque es más rápido, imagino por ser de tipo copy-on-write y otras funciones COW2
https://pve.proxmox.com/wiki/Performance_Tweaks#Use_raw_disk_image_and_not_qcow2

Después al pensar como enfocar el backup y snapshots, si Opensuse te los hace dentro de la VM, proxmox te los hace de otra manera pero también, y yo por encima podría también tenerlos en el anfitrión… y todos los sistemas están orientados a desempeñar esa función, no parece eficiente, y al final tiene penalización de rendimiento… la cuestión es cuanto :smiley: si es que existe.

No se si lo entiendo bien o me estoy haciendo un lio yo sola,

La virtualización es un lío por definición :grinning:

Mira la captura de estas 3 máquinas:

La primera es un w7 que instalé para probar algo algún día, no me he molestado en hacer ningún ajuste. Usa qcow2 y SATA.

La segunda es un w7 de un disco viejo, esto es: un equipo que tenía W7 instalado con software de W7 y que yo heredé. Algún día lo borraré, aunque el disco ya está un poco hecho polvo así que igual lo tiro directamente. Lo tengo en RAW porque además lo que uso de disco es el propio disco, como puedes ver en la directiva source.

El tercero es un W11 que uso para hacer pruebas, pero que a diferencia de la máquina W7 sí tiene que tener un rendimiento mejor. Así que en lugar de SATA uso Virtio.

En mi caso, suelo instalar Qcow2 en lugar de RAW porque virt-manager usa eso por defecto. Se supone que RAW es más rápido y tal pero me da que la diferencia hoy en día tampoco es mucha. Qcow2 por su parte deja hacer snapshots y algunas cosas más que yo no uso, así que ha ves :grinning:

Imagina que tienes dos particiones XFS y BTRFS en tu máquina virtual: los snapshots de snapper no afectarán al disco XFS. Pero de todas formas tampoco afectan a las carpetas del sistema de ficheros / que tengan subvolúmenes, etc.

Por su parte, Qemu hace copias de toda la máquina, tal cual. Esa máquina puedes emplearla como copia de seguridad, pero también como base para otras máquinas virtuales. Y al sistema en sí le importa muy poco lo que hay debajo: Si tu disco es ext4, Qemu hará su snapshot exactamente igual que si tienes una máquina con varios discos (virtuales).

Piensa en las dos máquinas W7 que he ilustrado. En la primera, hay un fichero. Incluso si fuese RAW tendría el asunto de que es un fichero, manejado por el sistema de ficheros -y depende de dónde lo guarde o cómo configure las cosas, puede estar sujeto a los snapshots de btrfs; en cambio en el otro, el driver de la máquina virtual maneja el disco directamente. Es un poco como usar memoria virtual por defecto en una partición (como Linux) o en un fichero (como Windows).

Por supuesto, hay más combinaciones. Por ejemplo, no tienes por qué tener las instantáneas en ningún sitio manejable con Snapper, y usar Qemu para manejar las instantáneas.

Ah, sí, las máquinas virtuales con Linux las tengo con qcow2 y dentro uso btrfs etc.

Yo para virtualizar no le daría muchas vueltas, piensa que el propio software de máquinas virtuales ya ofrece instantáneas, copias, etc…, y darle una capa más no creo que beneficie mucho.

Para tener un respaldo instalé un W11 IoT en una máquina virtual por si las moscas necesitaba alguna herramienta windows pero por desconocimiento me costo varios días configurar todo correctamente, drivers virtio, la red, etc… Total, la instalé, la configuré y ahí, está, muerta de pena.

Si puedo todos los servicios los trato de utilizar con docker directamente en la máquina. En el mundo profesional se está migrando de las máquinas virtuales que imperaban hace unos 10 años a contenedores, y si tengo que montar una máquina virtual en algún servicio externo como un VPS o un servidor casero de momento me decanto por Debian por su sencillez.

He estado leyendo algo más y sí parece que tenga impacto pero en escenarios más de uso intensivo de BBDD, yo que estoy haciendo cosas ligeras y pruebas no hay mucha diferencia con hardware moderno. Igualmente “tarea para la casa”, lo probaré lo siguiente lo montaré con RAW y XFS

Mucho windows… :speak_no_evil:

Esto tengo que mirarlo, las hace en caliente y son reaprovechables? umm eso si que no se hacerlo, en la GUI si hay algo pero al igual es mejor por consola algun script programado… más tarea para la casa…

Tengo un XP con el que he intentado cambiar el controlador de disco duro de IDE a SATA porque no hay forma de arrancarlo :rofl:

Siempre hay gente qie necesita cosas raras, y así también tengo Autoritas para opinar (para mal) sobre Windows :grinning:

Sigo usando el veterano VirtualBox y su formato por defecto .vdi, tengo varias maquinas virtuales, algunas las uso y otras están muertas de risa como probar una distro GNU/Linux y olvidarme de ella.
Pero coincido con el compi, mejor usar los contenedores como docker, podman … para probar aplicaciones y sistemas operativos que usar maquinas virtuales.

Virtualbox lo use bastante y va genial, sin pegas, de hecho la aceleración de la gráfica va mejor que qemu cuando tienes nvidia (en mi caso). Pero como hace un tiempo (ya di la lata por aquí) conseguí poner integrada y dedicada a la vez en el pc de escritorio, ahora va parecido.

El avance en el desarrollo de soluciones virtualizadas puede ofrecer cierta confusión. Por ejemplo, Distrobox despliega una imagen (vm) de un sistema operativo en un contenedor. Pero como el host es Linux, puedes desplegar Linux y ya.

Por su parte, los contenedores están bien cuando quieres desplegar uno o varios servicios en una máquina física o virtual. La idea es que los posibles errores en el contenedor no afecten al anfitrion o a otros contenedores.

La idea de una máquina virtual es, ejem, proporcionar una máquina entera. Al igual que en el caso de los contenedores, en una vm los errores y problemas no afectan al anfitrión, contenedores en ejecución o otras máquinas virtuales.

Si vas a desplegar algo como Nextcloud para compartir ficheros multimedia con la familia, es suficiente con un contenedor. Si necesitas virtualizar un Windows por una aplicación concreta, necesitas una máquina virtual. En el camino tienes un montón de situaciones intermedias en las que puedes elegir.

Por ejemplo, antes un dicho era: un servicio, una máquina. Con contenedores esto ya no es así. Puedes poner cuantos servicios quieras en la misma máquina.

Ahora imaginaos un colegio con un montón de equipos. Puedes hacer mucho más ágil y robusto el despliegue y mantenimiento de todas las máquinas creando imágenes de los sistemas a utilizar y desplegándolos de alguna forma (copiándolas al disco del equipo o conectándose con vnc o spice). En mi opinión, la virtualización es algo así como “administración para perezosos”.

Aquí es donde cambia mucho de usar Virtualbox a usar KVM. Virtualbox va muy bien para probar sistemas operativos o para usar alguno por tal o cual aplicación. KVM le da mil vueltas para infraestructura. Si en el colegio del ejemplo hay un aula donde un profe se empeña en impartir clases de AutoCaca (y alguien paga las licencias!), puedes desplegar Windows con rapidez. O Mac.

Si quiero meterme más en estas cosas y por eso también Proxmox, los LXC veo que están a medio camino de una máquina virtual y contenedor…

Más bien es al revés. Por lo visto, LXC era lo que usaba Docker al principio (ver wikipedia). Por su parte, se supone que Proxmox permite usar contenedores LXC/openVZ o máquinas virtuales con KVM.

En el segundo enlace anterior iba el tema de las imágenes, pero puedes echar un vistazo aquí directamente: Crear imágenes derivadas con qemu, que de paso es otro ejemplo de cosa que se hace con qcow2 y no con raw.

Algún día tengo que echarle un ojo a Proxmox, pero por ahora todas mis máquinas son locales y me las apaño con virt-manager o cockpit-machines.