Proxmox VE Networking: cómo diseñar Bridges, VLAN, Bonding y LACP correctamente
Una infraestructura Proxmox puede tener excelentes procesadores, mucha memoria RAM, almacenamiento NVMe y varios nodos.
Pero si la red está mal diseñada, toda la plataforma puede terminar limitada por:
- Un único cable
- Un único switch
- Una interfaz de 1 GbE saturada
- Una VLAN mal configurada
- Un bond incorrecto
- Corosync compartiendo una red congestionada
- Storage y migración compitiendo por el mismo ancho de banda
En virtualización empresarial, networking no es solamente “dar Internet a las máquinas virtuales”.
La red puede transportar simultáneamente:
- Administración de Proxmox
- Tráfico de máquinas virtuales
- VLAN
- Storage
- Live Migration
- Corosync
- Ceph
- Backups
- Replicación
Por eso una implementación profesional debe diseñar primero qué tráfico existe, cuánto ancho de banda necesita y qué ocurre cuando una NIC o un switch falla.
En esta guía de la Biblioteca Virtual Sistro 2.0 explicamos cómo funcionan Linux Bridge, VLAN, Bonding y LACP dentro de Proxmox VE y cómo separarlos correctamente en una infraestructura empresarial.
Conoce las soluciones de Virtualización Empresarial de Sistro
¿Cómo funciona el networking en Proxmox VE?
Proxmox VE utiliza el stack de networking de Linux.
Esto permite construir arquitecturas utilizando componentes estándar como:
- Interfaces Ethernet
- Linux Bridge
- Bonding
- VLAN 802.1Q
- Routing
- SDN
La configuración puede administrarse desde la interfaz web de Proxmox y también se representa en:
/etc/network/interfaces
Esto proporciona mucha flexibilidad, pero también significa que debemos comprender cómo se relacionan las capas.
¿Qué es vmbr0?
Una instalación nueva de Proxmox normalmente crea una interfaz denominada:
vmbr0
Este tipo de interfaz es un Linux Bridge.
Podemos pensar en un bridge como un switch virtual dentro del host.
Conceptualmente:
Máquina Virtual
↓
NIC virtual
↓
vmbr0
↓
NIC física
↓
Switch físico
La VM se comporta como si estuviera conectada a un switch.
Linux Bridge no es NAT
Este punto genera confusión con frecuencia.
Un bridge normal no está haciendo automáticamente NAT.
La máquina virtual puede tener su propia dirección IP dentro de la red física correspondiente.
El switch físico verá las direcciones MAC de las máquinas virtuales que utilizan el bridge.
Podemos tener más de un bridge
No estamos limitados a vmbr0.
Podemos diseñar:
vmbr0 → Management
vmbr1 → Máquinas virtuales
vmbr2 → Red aislada
vmbr3 → DMZ
Pero crear múltiples bridges no siempre es necesario.
Muchas redes pueden manejarse utilizando un único bridge VLAN-aware.
¿Qué significa VLAN-aware?
Un Linux Bridge puede configurarse para entender etiquetas VLAN 802.1Q.
Entonces podemos utilizar un enlace trunk desde el switch físico hacia Proxmox.
Por ejemplo:
VLAN 10 → Administración
VLAN 20 → Servidores
VLAN 30 → Aplicaciones
VLAN 40 → DMZ
VLAN 50 → Backup
Las diferentes máquinas virtuales pueden conectarse al mismo bridge y recibir una etiqueta distinta.
Ejemplo de bridge VLAN-aware
Una arquitectura puede verse así:
Switch Core
↓ trunk VLAN 10,20,30,40
bond0
↓
vmbr0 VLAN-aware
├── VM ERP → VLAN 20
├── VM Web → VLAN 30
├── VM DMZ → VLAN 40
└── VM Administración → VLAN 10
Esto reduce la necesidad de crear una interfaz física para cada red lógica.
¿Por qué utilizar VLAN?
Las VLAN permiten segmentar redes aunque compartan infraestructura física.
Podemos separar:
- Administración
- Servidores
- Usuarios
- DMZ
- Storage
- Backup
- Telefonía
- IoT
Esto mejora organización, seguridad y control de tráfico.
No conviertas todas las redes en una sola VLAN
Una infraestructura virtualizada puede terminar alojando aplicaciones muy diferentes.
Una red plana facilita inicialmente la configuración, pero conforme crece la plataforma aparecen problemas de:
- Seguridad
- Broadcast
- Troubleshooting
- Control de acceso
- Escalabilidad
La segmentación debe diseñarse desde el principio.
¿Qué es Bonding?
Bonding permite agrupar varias interfaces físicas dentro de una interfaz lógica.
Por ejemplo:
eno1 + eno2 → bond0
Después podemos utilizar bond0 como puerto de un Linux Bridge.
Conceptualmente:
VM
↓
vmbr0
↓
bond0
├── eno1
└── eno2
¿Para qué sirve un Bond?
Dependiendo del modo puede proporcionar:
- Redundancia
- Distribución de tráfico
- Mayor capacidad agregada
- Tolerancia a falla de una NIC
Pero no todos los modos funcionan igual.
Active-Backup
En modo Active-Backup solamente una NIC transmite normalmente.
La segunda permanece disponible como respaldo.
Si falla la NIC activa:
NIC A falla → NIC B toma el tráfico
Este modo resulta sencillo cuando nuestra prioridad principal es tolerancia a falla.
Active-Backup no duplica el ancho de banda
Si tenemos:
2 × 10 GbE
en Active-Backup, no significa que tengamos 20 Gbps disponibles simultáneamente.
Normalmente tenemos 10 Gbps activos y un segundo camino de contingencia.
¿Qué es LACP?
LACP significa:
Link Aggregation Control Protocol
y corresponde al estándar IEEE 802.3ad.
Permite agrupar múltiples enlaces entre servidores y switches de manera coordinada.
En Proxmox normalmente lo utilizamos mediante un bond:
bond-mode 802.3ad
LACP necesita configuración en el switch
No basta con crear el bond dentro de Proxmox.
Los puertos correspondientes del switch deben formar parte del mismo grupo LACP.
Conceptualmente:
Proxmox eno1 + eno2
↓
bond0 LACP
↓
Switch Port 1 + Port 2
↓
LAG / Port Channel
Ambos extremos deben estar correctamente configurados.
¿Dos interfaces de 10 GbE mediante LACP significan 20 Gbps para una VM?
No necesariamente.
Este es uno de los errores conceptuales más frecuentes.
LACP distribuye diferentes flujos entre interfaces según la política de hashing utilizada.
Una única conversación TCP normalmente utilizará uno de los enlaces.
Pero múltiples máquinas virtuales y múltiples flujos pueden distribuirse entre los enlaces.
Por eso LACP aumenta principalmente la capacidad agregada y proporciona redundancia.
Ejemplo con múltiples máquinas virtuales
Tenemos:
VM01 → flujo A
VM02 → flujo B
VM03 → flujo C
El bond puede distribuir esos flujos entre diferentes miembros físicos.
El resultado puede ser mayor throughput agregado sin que una sola sesión individual utilice necesariamente toda la suma de enlaces.
¿Qué recomienda Proxmox?
Cuando los switches soportan LACP, Proxmox recomienda utilizar bonding 802.3ad para escenarios donde buscamos agregación y redundancia.
Cuando LACP no está disponible, Active-Backup suele ser una alternativa sencilla para tolerancia a fallas.
LACP y dos switches físicos
Aquí debemos tener cuidado.
Si conectamos:
eno1 → Switch A
eno2 → Switch B
y queremos utilizar ambos dentro del mismo LACP, los switches deben soportar una tecnología que les permita presentarse como un mismo dominio lógico de agregación.
Dependiendo del fabricante puede llamarse:
- Stacking
- MLAG
- MC-LAG
- VPC
- VSX
- IRF
La nomenclatura depende del fabricante.
No construyas LACP entre dos switches independientes sin soporte
Si Switch A y Switch B no comparten un mecanismo compatible de agregación multi-chassis, un bond 802.3ad hacia ambos puede no funcionar como esperamos.
En ese caso debemos revisar otra arquitectura.
Redundancia real significa revisar el switch
Una arquitectura puede tener:
- Dos NIC
- Bond
- Dos cables
pero si ambos terminan en:
un solo switch
seguimos teniendo un Single Point of Failure.
Proxmox necesita varias redes lógicas
En una plataforma empresarial debemos distinguir diferentes tipos de tráfico.
1. Management
Administración de los hosts Proxmox.
2. VM Network
Tráfico generado por las máquinas virtuales.
3. Corosync
Comunicación interna del cluster.
4. Storage
NFS, iSCSI, Ceph u otra tecnología de almacenamiento.
5. Migration
Transferencia de memoria y datos durante migraciones.
6. Backup
Tráfico hacia Proxmox Backup Server u otros repositorios.
No necesariamente necesitamos seis tarjetas independientes
Las redes pueden separarse utilizando:
- NIC físicas
- Bonds
- VLAN
- QoS
- Switches independientes
La arquitectura depende de presupuesto y criticidad.
Red de Management
La interfaz de administración permite acceder a:
- GUI
- SSH
- API
- Administración del cluster
Esta red debería protegerse cuidadosamente.
No recomendaría exponer directamente la administración de Proxmox hacia Internet.
Podemos utilizar:
- VLAN dedicada
- Firewall
- VPN
- ACL
- Segmentación
Corosync merece especial atención
Corosync mantiene la comunicación entre nodos del cluster.
No necesita enormes cantidades de ancho de banda.
Pero sí necesita:
latencia baja y estable.
Por eso una red saturada puede convertirse en un problema grave aunque técnicamente siga teniendo conectividad.
1 GbE puede ser suficiente para Corosync
Para muchos clusters, una interfaz dedicada de 1 GbE puede proporcionar suficiente capacidad para Corosync.
El objetivo principal no es throughput.
Es evitar que otro tráfico provoque congestión y latencia.
No mezcles Corosync con tráfico pesado sin analizarlo
Por ejemplo:
Backup saturando 10 GbE
Ceph Recovery saturando 10 GbE
Live Migration saturando 10 GbE
Si Corosync comparte exactamente el mismo camino físico, su latencia puede verse afectada.
Esto puede provocar comportamientos de cluster que parecen inexplicables.
Corosync puede utilizar múltiples links
Proxmox permite configurar más de una red para Corosync.
Esto proporciona resiliencia si una red deja de estar disponible.
Es diferente de confiar únicamente en un bond.
Un bond no sustituye completamente la redundancia de Corosync
Proxmox recomienda utilizar enlaces Corosync adicionales sobre redes físicamente diferentes para obtener redundancia real del tráfico de cluster.
Esto permite que Corosync cambie de camino si una red presenta problemas.
Storage Network
El almacenamiento puede generar enormes cantidades de tráfico.
Esto es especialmente evidente con:
- Ceph
- NFS
- iSCSI
- Replicación
- NVMe
Una red de almacenamiento debe dimensionarse según:
- IOPS
- Throughput
- Latencia
- Número de nodos
- Número de VMs
- Recuperación ante fallas
Consulta Proxmox + Ceph: cuándo conviene una arquitectura HCI
La red puede ser más lenta que tus NVMe
Este es un problema frecuente en HCI.
Podemos comprar discos NVMe extremadamente rápidos.
Pero si los nodos están conectados mediante una red insuficiente, el cuello de botella deja de ser el disco.
Se convierte en:
NIC + switch + uplinks.
Live Migration también utiliza red
Durante una migración en vivo debemos mover el estado de la VM entre nodos.
En determinadas arquitecturas también puede existir transferencia de almacenamiento.
Una red rápida puede reducir considerablemente el tiempo necesario para estas operaciones.
Migration Network
En clusters empresariales podemos definir una red dedicada o VLAN específica para migraciones.
Esto evita que una operación administrativa compita directamente con:
- Usuarios
- Corosync
- Storage
- Backup
¿Necesito 10 GbE para Proxmox?
No existe una respuesta universal.
Una pequeña plataforma puede funcionar perfectamente con Gigabit dependiendo de carga y almacenamiento.
Pero conforme aumenta:
- Número de VMs
- Live Migration
- Storage compartido
- Backup
- Ceph
10 GbE empieza a resultar mucho más atractivo.
¿Y 25 GbE?
Puede resultar apropiado cuando tenemos:
- NVMe
- Ceph de alto rendimiento
- Muchas VMs
- Grandes migraciones
- Storage intenso
No debemos comprar 25 GbE solamente porque exista.
La velocidad debe responder a un workload.
MTU y Jumbo Frames
Las redes de storage pueden utilizar MTU superiores a 1500 en determinados diseños.
Pero aquí existe una regla crítica:
la configuración debe ser consistente de extremo a extremo.
Eso incluye:
- NIC
- Bond
- Bridge
- Switch
- VLAN
- Storage
Una MTU inconsistente puede producir problemas difíciles de diagnosticar.
Jumbo Frames no son obligatorios
No necesitamos utilizar MTU 9000 simplemente porque tengamos storage.
Una arquitectura con MTU 1500 correctamente configurada puede ser perfectamente válida.
El beneficio debe justificar la complejidad adicional.
Open vSwitch vs Linux Bridge
Durante años Open vSwitch fue una recomendación frecuente para determinados entornos avanzados.
Actualmente Proxmox señala que Linux Bridge ha incorporado muchas capacidades y que Open vSwitch rara vez es necesario para una implementación tradicional.
Para la mayoría de los proyectos nuevos comenzaría evaluando:
Linux Bridge + VLAN-aware + Bonding.
¿Cuándo podría necesitar SDN?
Para escenarios más complejos Proxmox incorpora Software Defined Networking.
SDN puede ayudar con arquitecturas como:
- VXLAN
- EVPN
- Redes aisladas
- Multitenancy
- Administración centralizada de redes virtuales
Pero SDN tampoco debe implementarse automáticamente en un cluster pequeño.
Primero debemos identificar el problema que necesitamos resolver.
Consulta soluciones Proxmox VE de Sistro
Ejemplo de arquitectura pequeña
Supongamos:
- 3 nodos Proxmox
- 10 VMs
- Storage local
- Switch administrable
Podemos tener:
NIC 1 → Management + Corosync mediante VLAN separadas
NIC 2 → VM Network
Es una arquitectura sencilla.
Pero debemos reconocer que todavía existen puntos únicos de falla.
Ejemplo de arquitectura intermedia
Tenemos:
- 3 nodos
- 30 VMs
- Storage compartido
- Dos switches
- 4 × NIC por nodo
Podríamos diseñar:
NIC 1 → Management / Corosync
NIC 2 → segundo Corosync / Management redundante
NIC 3 + NIC 4 → Bond LACP para VMs y VLAN
La arquitectura exacta dependerá del tipo de storage.
Ejemplo con 10 GbE
Un nodo puede tener:
- 2 × 1 GbE
- 2 × 10 GbE
Podemos utilizar:
1 GbE A → Management + Corosync Link 0
1 GbE B → Corosync Link 1
10 GbE A + B → Bond LACP → VM Networks / VLAN
Si además tenemos storage pesado puede valer la pena agregar interfaces dedicadas.
Ejemplo HCI con Ceph
Una plataforma más exigente puede separar:
Management
Corosync
VM Network
Ceph Public
Ceph Cluster / Recovery
Migration / Backup
No necesariamente cada red requiere una NIC física exclusiva, pero debemos controlar la competencia por ancho de banda.
Migrar desde VMware implica traducir la arquitectura de red
Cuando migramos VMware hacia Proxmox también debemos migrar conceptos.
Podemos pensar aproximadamente:
VMware vSwitch → Proxmox Linux Bridge
VMware Port Group → VLAN / Bridge
VMware NIC Teaming → Proxmox Bond
VMkernel Networks → Management / Migration / Storage / Cluster Networks
No es una equivalencia perfecta.
Pero ayuda a estructurar el assessment.
Consulta nuestro checklist para migrar VMware a Proxmox
El error de migrar VMs sin mapear VLAN
Una VM puede importar correctamente desde VMware.
Puede arrancar correctamente.
Y aun así quedar sin red.
Antes de migrar debemos documentar:
- Port Group actual
- VLAN ID
- Dirección IP
- Gateway
- DNS
- NIC virtual
- Switch físico
- Trunk
Después mapeamos esa red hacia Proxmox.
VirtIO para las NIC virtuales
Para máquinas virtuales modernas, VirtIO normalmente proporciona la opción de red virtual con menor overhead.
Sistemas operativos antiguos pueden necesitar otros adaptadores o drivers.
Durante migraciones Windows debemos validar los drivers VirtIO antes de asumir que la red estará lista.
La VLAN debe existir también en el switch físico
Configurar:
VLAN Tag = 30
dentro de Proxmox no crea automáticamente la VLAN en nuestra infraestructura física.
El trunk del switch debe permitirla.
La ruta o gateway debe existir.
El firewall debe tener las políticas correspondientes.
Proxmox no reemplaza el diseño del core
Proxmox puede crear redes virtuales.
Pero seguimos necesitando decidir dónde ocurre:
- Routing
- Firewalling
- Inter-VLAN routing
- North-South security
- East-West security
La respuesta dependerá de la arquitectura empresarial.
¿Dónde debe vivir el gateway de las VMs?
Puede estar en:
- Firewall
- Core Layer 3
- Router
- Arquitectura SDN
No existe una respuesta universal.
Debemos analizar rendimiento, seguridad y disponibilidad.
Aplicar cambios de red puede dejarte fuera del servidor
Una mala modificación de:
- Bridge
- Gateway
- VLAN
- Bond
- NIC
puede provocar que perdamos conectividad administrativa.
Por eso los cambios críticos deberían realizarse con:
- Consola física o remota disponible
- iDRAC / iLO / IPMI
- Backup de configuración
- Ventana de mantenimiento
- Plan de rollback
ifupdown2 permite aplicar cambios sin reiniciar en muchos escenarios
Las instalaciones modernas de Proxmox utilizan ifupdown2 para manejar cambios de networking.
Desde la interfaz gráfica podemos preparar modificaciones y aplicar la configuración.
Pero “Apply Configuration” no elimina el riesgo de una configuración incorrecta.
Si cambiamos mal la IP de administración, seguiremos pudiendo quedarnos fuera.
No uses ifdown sobre un bridge productivo sin entender el impacto
Manipular manualmente una interfaz bridge puede interrumpir el tráfico de las máquinas virtuales.
Para producción es mejor seguir los mecanismos de configuración previstos por Proxmox y contar con acceso alternativo al host.
La redundancia debe probarse
Un bond configurado y mostrado como UP no demuestra que el failover funcione.
Debemos realizar pruebas controladas.
Por ejemplo:
- Desconectar NIC A
- Validar conectividad
- Reconectar NIC A
- Desconectar NIC B
- Validar tráfico
- Apagar Switch A
- Validar Switch B
La prueba exacta dependerá de la arquitectura.
También prueba bajo carga
Una red puede funcionar perfectamente sin tráfico y fallar durante:
- Live Migration
- Backup
- Ceph Recovery
- Replicación
- Restauración
Por eso debemos validar no solamente conectividad.
También capacidad y latencia.
Monitoriza errores físicos
Cuando existe un problema de red debemos revisar:
- Errores de interfaz
- Drops
- CRC
- Flapping
- Velocidad negociada
- Duplex
- Transceivers
- Cables
- Switch logs
No todos los problemas virtuales son realmente virtuales.
Errores comunes en Proxmox Networking
1. Utilizar una sola NIC para todo
Puede ser válido en laboratorio, pero crea limitaciones y puntos únicos de falla en producción.
2. Tener dos NIC conectadas al mismo switch y llamarlo HA
El switch sigue siendo un punto único de falla.
3. Configurar LACP solamente en Proxmox
El switch también debe formar el LAG correspondiente.
4. Pensar que 2 × 10 GbE significa 20 Gbps para una sola sesión
LACP distribuye flujos; no necesariamente suma enlaces para una sola conversación.
5. Mezclar Corosync con tráfico saturado
La latencia puede afectar la estabilidad del cluster.
6. Usar Jumbo Frames parcialmente
La MTU debe ser coherente de extremo a extremo.
7. Crear demasiados bridges innecesariamente
Un bridge VLAN-aware puede simplificar muchas arquitecturas.
8. No documentar las VLAN
Las migraciones y troubleshooting se vuelven mucho más difíciles.
9. No mapear Port Groups antes de migrar VMware
Las VMs pueden arrancar sin conectividad.
10. No probar failover
Redundancia no probada es solamente una suposición.
Checklist antes de diseñar networking Proxmox
- Número de nodos
- Número de VMs
- NIC por servidor
- Velocidad de interfaces
- Switches disponibles
- Redundancia de switches
- LACP / MLAG disponible
- VLAN
- Red de administración
- Red de VMs
- Corosync
- Storage
- Ceph
- Migration
- Backup
- MTU
- Routing
- Firewall
- Throughput esperado
- Crecimiento
Preguntas que Sistro debería hacer antes de instalar
- ¿Cuántas NIC tiene cada servidor?
- ¿Son 1, 10, 25 o más GbE?
- ¿Cuántos switches tienes?
- ¿Los switches soportan LACP?
- ¿Soportan stacking o MLAG?
- ¿Cuántas VLAN existen?
- ¿Dónde estará Management?
- ¿Dónde estará Corosync?
- ¿Qué storage utilizaremos?
- ¿Ceph, SAN, NFS o storage local?
- ¿Necesitamos Live Migration frecuente?
- ¿Dónde estará Proxmox Backup Server?
- ¿Qué MTU utiliza la red?
- ¿Qué ocurre si falla una NIC?
- ¿Qué ocurre si falla un switch?
Arquitectura recomendada: no existe una plantilla universal
No recomendamos copiar una configuración encontrada en Internet y aplicarla a cualquier cluster.
Una plataforma con:
3 nodos + 10 VMs + storage local
no necesita la misma red que:
8 nodos + Ceph NVMe + 200 VMs.
La arquitectura debe salir del workload.
Servicios Proxmox en Sistro
Virtualización Empresarial
https://sistro.net/virtualizacion
Proxmox VE
https://sistro.net/proxmox
Instalación y Configuración Proxmox VE
https://sistro.net/proxmox/instalacion-proxmox-ve
Migración a Proxmox VE
https://sistro.net/proxmox/migracion-proxmox-ve
Soporte Administrado Proxmox VE
https://sistro.net/proxmox/soporte-administrado-proxmox-ve
Artículos relacionados
Migrar VMware a Proxmox: checklist antes de la primera VM
Proxmox cluster de 3 nodos: hardware, quorum y HA
Proxmox + Ceph: cuándo conviene una arquitectura HCI
Proxmox Backup Server: respaldo y recuperación empresarial
Recomendación final
La red es una de las capas más importantes de una plataforma Proxmox.
Linux Bridge, VLAN y Bonding permiten construir arquitecturas muy flexibles sin necesidad de utilizar tecnologías propietarias.
Pero flexibilidad no significa que cualquier combinación sea correcta.
Un buen diseño debe separar conceptualmente:
Management + VMs + Corosync + Storage + Migration + Backup.
Después decidimos qué redes necesitan interfaces físicas dedicadas, cuáles pueden compartir un bond y cuáles pueden separarse mediante VLAN.
También debemos probar qué ocurre cuando falla:
una NIC + un cable + un puerto + un switch.
La pregunta correcta no es:
“¿Cuántas tarjetas de red tiene mi servidor?”
La pregunta correcta es:
“¿qué tráfico necesita transportar mi plataforma y qué ocurre si uno de esos caminos desaparece?”
¿Estás diseñando o migrando una plataforma Proxmox?
En Sistro Networks podemos realizar un assessment de servidores, interfaces, switches, VLAN, storage, Corosync, Live Migration y redundancia antes de implementar el cluster.
Podemos diseñar la arquitectura de red desde cero o traducir una infraestructura existente de VMware hacia Proxmox VE.
Consulta nuestro servicio de Instalación y Configuración Proxmox VE
Preguntas frecuentes
¿Qué es vmbr0 en Proxmox?
Es normalmente un Linux Bridge utilizado como switch virtual para conectar máquinas virtuales y el host con una interfaz o red física.
¿Proxmox soporta VLAN?
Sí. Linux Bridge puede configurarse como VLAN-aware y las interfaces virtuales de las VMs pueden utilizar tags 802.1Q.
¿Proxmox soporta LACP?
Sí. Puede utilizar Linux Bonding en modo 802.3ad cuando la infraestructura de switching también está configurada para LACP.
¿Dos interfaces de 10 GbE con LACP dan 20 Gbps a una VM?
No necesariamente. LACP distribuye flujos entre enlaces según la política utilizada. Una sola conversación normalmente no utiliza automáticamente la suma completa de ambos enlaces.
¿Necesito una red dedicada para Corosync?
Para clusters empresariales Proxmox recomienda una red física dedicada para el tráfico de cluster y enlaces adicionales independientes para redundancia.
¿Corosync necesita 10 GbE?
No normalmente. Corosync necesita poca cantidad de ancho de banda pero requiere latencia baja y estable. Para muchos escenarios una interfaz dedicada de 1 GbE es suficiente.
¿Necesito Open vSwitch?
En la mayoría de implementaciones tradicionales actuales Linux Bridge puede cubrir los requerimientos. Open vSwitch sigue estando disponible para casos específicos.
¿Puedo usar VLAN para separar storage y máquinas virtuales?
Sí, aunque la separación lógica mediante VLAN no siempre sustituye la separación física cuando el workload exige mucho ancho de banda o aislamiento.
¿Necesito 10 GbE para Live Migration?
No es obligatorio, pero una red de mayor capacidad puede reducir significativamente los tiempos de migración, especialmente con VMs grandes y operaciones frecuentes.
¿Puedo reutilizar mi switching de VMware?
En muchos casos sí, siempre que soporte las VLAN, LACP, velocidades y arquitectura que necesita Proxmox. Debe evaluarse durante el assessment.
Deja un Comentario