¿Deben usarse particiones LVM en imágenes de máquinas virtuales?

¿Se debe usar LVM para las particiones al crear imágenes de VM (por ejemplo, imágenes de KVM)? Parece que agrega complejidad si desea, por ejemplo, montar una imagen qcow2 en el host si la imagen tiene particiones LVM.

Por otro lado, no parece que las ventajas de las particiones LVM sean tan significativas en una imagen de VM, ya que es mucho más fácil desconectar una VM y cambiar el tamaño de las particiones que para un sistema físico.

"Depende."

Si está en un entorno que controla (vmware o kvm o lo que sea) y puede tomar sus propias decisiones sobre el rendimiento del disco QoS, le recomiendo no usar LVM dentro de sus máquinas virtuales. No le ofrece mucha flexibilidad que no podría obtener a nivel de hipervisor.

Recuerde, el hipervisor ya está realizando estas tareas de manera efectiva. Si desea poder redimensionar arbitrariamente los sistemas de archivos (una buena idea), simplemente cree un disco virtual separado para cada sistema de archivos.

Una cosa que podría pensar al ir por este camino. Ni siquiera es necesario que coloque particiones en sus discos virtuales de esta manera. Por ejemplo, puede crear un disco virtual para /home; está /dev/vdcdentro de tu vm. Al crear el sistema de archivos, simplemente haga algo como en mke2fs -j /dev/vdclugar de especificar una partición.

Esta es una buena idea, pero ... la mayoría de las herramientas (y otros administradores que vienen después de ti) esperarán ver particiones en cada disco. Recomiendo simplemente poner una única partición en el disco y terminar de una vez. Sin embargo, significa un paso más al cambiar el tamaño del sistema de archivos. Y no olvide alinear correctamente sus particiones: comenzar la primera partición a 1 MB es una buena regla general.

Dicho todo esto: hacer todo esto en el nivel del hipervisor significa que probablemente tenga que reiniciar la VM para cambiar el tamaño de las particiones. El uso de LVM le permitiría agregar un disco virtual en caliente (suponiendo que su combinación de hipervisor / SO lo permita) y expandir el sistema de archivos sin reiniciar. Esto es definitivamente una ventaja.

Mientras tanto, si está utilizando un proveedor de la nube, es más sutil.

No sé mucho sobre Azure, GCP o ninguno de los jugadores más pequeños, por lo que no puedo ayudarlo.

Con AWS puedes seguir mis consejos anteriores y a menudo estarás bien. Puede (ahora) aumentar el tamaño de los volúmenes EBS (discos virtuales) sobre la marcha, y cambiar el tamaño de las particiones, etc.

Sin embargo, en el caso general, podría tener sentido poner todo en un solo volumen grande de EBS y usar LVM (o, supongo, particiones simples). Amazon le ofrece un límite de IOPS en cada volumen. Por defecto, este límite se escala con el tamaño del volumen. por ejemplo, para gp2volúmenes obtienes 3 IOPS por GiB (mínimo de 100 IOPS). Ver https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

Para la mayoría de las cargas de trabajo, querrá que todos sus IOPS disponibles estén disponibles para cualquier sistema de archivos, dependiendo de la necesidad en este momento. Por lo tanto, tiene sentido crear un gran volumen de EBS, obtener todos sus IOPS en un cubo y particionar / LVM.

Ejemplo:

3 discos con sistemas de archivos / áreas de intercambio independientes, cada uno de 100 GB de tamaño. Cada uno recibe 300 IOPS. El rendimiento está limitado a 300 IOPS en cada disco.

1 disco, 300 GB de tamaño. Particiones LVM en el disco de 100GB cada una. El disco recibe 900 IOPS. Cualquiera de las particiones puede usar los 900 IOPS.

Los volúmenes lógicos son más fáciles de crear sobre la marcha, cambiar el tamaño, eliminar.
La pregunta "a LVM o no" siempre tiene la misma respuesta, depende :)
Tiene sentido si necesita flexibilidad a nivel de disco (s), partición (es).
No tiene mucho sentido si no necesita la flexibilidad proporcionada por LVM o si no desea aprovechar otras características de LVM

De hecho, me gusta usar LV porque no son fácilmente accesibles desde el servidor virt. Por lo tanto, estos archivos no se pueden destruir / mover fácilmente por casualidad.

Otras características importantes de los LV:

• Puedes hacer instantáneas
• Puede analizar el disco IO basado en LV ( iostat)
• Fácil de redimensionar
• Mediante el uso de instantáneas, puede hacer un clon consistente de sistemas en ejecución

Para reducir la complejidad, uso un LV como disco (no como partición). El inconveniente es que solo puedo cambiar fácilmente el tamaño de la última partición del "disco", pero mi diseño estándar de disco VM tiene eso en cuenta (por lo que la última partición contiene los datos importantes de la aplicación).

Además de la flexibilidad, las imágenes de VM basadas en LVM tienen potencialmente menos sobrecarga, ya que no se accede a ellas a través de un sistema de archivos. Por otro lado, elimina los medios para mover fácilmente las imágenes, como lo haría con un archivo. No imposible, pero un poco más complicado.

Mi propia experiencia ...

Quería usar un volumen lógico (lv) con lvm2 para un sistema de archivos ext4; no como un disco, o más bien, simplemente como un disco sin particiones para el fs.

Lo que encontré fue que el inicio de la VM se detendría en la etapa initrd; Si comentaba la /etc/fstabentrada, la máquina arrancaría. Dejar la /etc/fstabentrada comentada no fue una solución con la que estaba feliz de vivir. Entonces, creé una imagen de disco normal (todavía un volumen lógico), particioné con una partición usando fdisky creé el sistema de archivos en eso. No hay más problemas.

Las monturas relevantes en mi /etc/fstabestaban usando UUID.

Pensé en usar un archivo o sistema de archivos, pero decidí no hacerlo.

En mi caso, estoy usando un sistema basado en Debian Jessie Devuan

En realidad, solo uso LVM para el almacenamiento de respaldo en el nivel del hipervisor, los archivos de imagen son para las aves. También recomendaría usarlos a nivel de invitado también. Es cierto que no se beneficiará al agrupar fuentes de almacenamiento dispares o le resultará más fácil aumentar el espacio total disponible en el disco (ya que puede obtenerlo con la misma facilidad cambiando el tamaño de lo que presenta el hipervisor), pero a veces asigna demasiado a un sistema de archivos . Es posible que desee una manera fácil de tomar 1 concierto de / opt y dárselo a / var (por ejemplo). Si está haciendo particiones regulares dentro de la propia máquina virtual, entonces el aspecto de cambio de tamaño es mucho más difícil.

Además de las otras buenas respuestas aquí, la única razón realmente buena para usar LVM dentro de una VM es que desea un entorno de prueba para experimentar y obtener experiencia práctica práctica con LVM.

Puede pasar por varios CÓMO y tutoriales, practicar tareas de administración de LVM comunes (y no tan comunes), configurar varios escenarios de falla y aprender a lidiar con ellos.

es decir, como ayuda autodidacta.

Editar: lo siguiente ya no es cierto. El valor de usar el aprovisionamiento delgado proporcionado por LVM para imágenes de disco VM es probablemente situacional;

¿Está ejecutando VM de desarrollo en una computadora portátil? entonces probablemente estés mejor con QCow2.

¿Administrar una granja de máquinas virtuales que posiblemente pueda utilizar grandes cantidades de almacenamiento en varios discos? LVM es probablemente una buena forma de administrar ese almacenamiento.

Una razón para no usar lvm es que no puede comprometer el almacenamiento en exceso usando lvm. Si crea 10 máquinas virtuales con 100 GB de almacenamiento, necesitará 1000 GB de disco real, incluso si 9 de las diez máquinas virtuales solo usarán 20 GB de sus sistemas de archivos. Las imágenes de disco dispersas o las imágenes en formato qcow2 pueden significar que solo el almacenamiento realmente utilizado por los invitados debe asignarse a ellos.

Si esto es realmente útil para usted depende de lo que necesite de su almacenamiento.