Virtuelle Umgebung Proxmox
Als weitere Option können Sie den Aufbau eines Labors in Proxmox VE in Betracht ziehen. Intern ist der Hypervisor auf EVE-NG, Ubuntu nativem KVM mit libvirtd und Proxmox VE identisch. In allen drei Umgebungen führt QEMU die VM aus. Jede Umgebung hat ihre eigene CLI und GUI und verwendet entweder Debian- oder Ubuntu-Linux-Distributionen.
Die Vorteile von Proxmox VE gegenüber EVE-NG und Ubuntu nativem KVM mit libvirtd sind:
- Einfach zu erstellende Cluster von Hypervisoren, die den Umfang eines einzelnen BMS einschränken.
- Einfach anzuschließende gemeinsam genutzte Speicher wie Ceph.
- Virtualisieren Sie Netzwerke zwischen Servern mithilfe der SDN-Option.
- REST API betreibt Ihre Systeme.
Nachteile der Vorteile von Proxmox VE gegenüber EVE-NG und Ubuntu nativem KVM mit libvirtd sind:
- Beim Erstellen eines UKSM-Kernels kann die RAM-Nutzung mehrerer vJunos-Switch-Instanzen nicht gespeichert werden. Daher benötigt jede vJunos-Switch-VM 5 GB RAM.
- Führt keine komprimierten oder gesicherten qcow2-Images aus, stattdessen werden sie als RAW-Image in der Speicheroption erweitert. Daher benötigt jede vJunos-Switch-VM 32 GB Speicher.
Dieses Dokument enthält Beispiele für die Erstellung von vJunos-Switch-VMs auf Proxmox VE mit einem lokal konfigurierten einzelnen Proxmox-Server und den Standard-Linux-Bridges. Dies hilft beim Vergleich mit den beiden zuvor beschriebenen anderen Umgebungen. Da Sie die Proxmox-GUI für VMs nicht verwendet haben, müssen Sie Konfigurationsänderungen lokal ausführen, nachdem Sie juniper.conf-Images und Linux-Bridge- und VM-Schnittstellenänderungen nach der VM-Erstellung auf Proxmox VE erstellt haben. Das CLI-Beispiel erleichtert es Ihnen, es in ein Skript zum Starten mehrerer vJunos-Switch-VMs einzubinden.
Für Scale-out-Labs mit mehreren Servern empfehlen wir die Verwendung von SDN mit VXLAN als Netzwerktransportoption anstelle von lokalen Linux-Bridges.
Proxmox VE Präparate
Erstellen Sie nach der Installation des Hypervisors die Netzwerke, die für vJunos-Switch-VMs und andere in Ihrem Lab verwendet werden sollen. Verwenden Sie wie im obigen Beispiel die Proxmox-GUI, um Standard-Linux-Bridges wie die drei unten gezeigten zu erstellen, und stellen Sie sicher, dass sie aktiviert sind.
Weisen Sie jeder Linux-Bridge einen Namen zu und Sie können die MTU optional auf 9200 setzen. Sie können den MTU-Wert mithilfe des Skripts ändern, nachdem Sie die VM erstellt haben. Vermeiden Sie das Auffüllen/Ändern der anderen Werte.
Verwenden Sie für alle verbleibenden Schritte SSH zum Server, um BASH-Befehle lokal auszuführen. Zuerst laden Sie das qcow2-Image von vJunos-switch auf den Server.
mkdir -p /root/download
Laden Sie nun Ihre kostenlose Kopie der vJunos-switch-VM über URL: https://support.juniper.net/support/downloads/?p=vjunos in das Verzeichnis herunter, und überprüfen Sie dann, ob die Kopie heruntergeladen wurde.
ls -l /root/download/ -rw-r--r-- 1 root root 3966631936 Aug 1 2023 vJunos-switch-23.2R1.14.qcow2
Bereitstellen einer vJunos-Switch-VM auf Proxmox VE
Vermeiden Sie es, die anfängliche vJunos-Switch-VM mit der Proxmox-GUI zu erstellen, da die GUI zusätzliche Parameter hinzufügen kann, die dazu führen können, dass die VM nicht ordnungsgemäß funktioniert. Erstellen Sie stattdessen die erste VM über die CLI, und legen Sie sie als Vorlage fest. Verwenden Sie dann diese Vorlage, um alle weiteren VMs über die GUI zu starten.
Führen Sie mithilfe von BASH die nächsten Schritte lokal auf dem Server aus:
- Konfigurieren Sie die VM individuell:
- Die VM-ID/-Nummer. Im Beispiel ist
200.es - Der Speicher, in dem das Image des virtuellen Computers ausgeführt wird. Im Beispiel ist es der Speicher
local-lvm.
- Die VM-ID/-Nummer. Im Beispiel ist
- Löschen, wenn eine vorhandene VM mit derselben ID ausgeführt wird. Dies ist nützlich, wenn Sie einen Fehler gemacht haben und es erneut versuchen möchten.
- Erstellen Sie die neue vJunos-switch-VM mit allen erforderlichen Parametern, um sie später korrekt zu starten:
- Name des virtuellen Computers. Im Beispiel
vswitch. Sie können den Namen ändern. - RAM und CPU. Nicht ändern.
- Spezielle BIOS- und CPU-Optionen, die erforderlich sind, damit diese VM ordnungsgemäß angezeigt wird. Ändern Sie die Optionen nicht.
- Boot-Reihenfolge und serieller Bildschirm. Nicht ändern.
- Zuerst das Netzwerk
net0, das der fxp0-Schnittstelle des virtuellen Computers zugewiesen wird. Ändern Sie bei Bedarf, aber stellen Sie sicher, dass das Netzwerk eine DHCP-Lease für die VM bereitstellen kann. - Zweitens: Weitere Netzwerke, beginnend mit
net1, welches die Schnittstellege-0/0/0der vJunos-Switch-VM sein wird. Sie müssen dies entsprechend Ihrem Labordesign ändern, indem Sie mehr Schnittstellen und andere Linux-Bridges verwenden. Es wird empfohlen, die Optionfirewall=0für jede dieser Schnittstellen beizubehalten, um das interne Design nicht zu kompliziert zu gestalten.
- Name des virtuellen Computers. Im Beispiel
- Importieren Sie das vJunos-switch qcow2-image in die ausgewählte Speicheroption. Möglicherweise müssen Sie den Speicherort der vJunos-switch qcow2-Imagedatei ändern.
- Importieren Sie den Speicherort des Konfigurationsabbilds, der extrahiert werden soll, in eine BASH-Variable.
- Fügen Sie der erstellten VM den Speicherort des Images hinzu, von dem aus gestartet werden soll.
- Erstellen Sie eine Standardeinstellung
juniper.confmit unserer anfänglichen Junos OS-Konfiguration für diese VM. - Verwenden Sie das
make-config.shSkript, um ein Bild zu erstellen, das Ihre individuellejuniper.confDatei einbettet. - Importieren Sie das Junos OS-Konfigurations-Image in die ausgewählte Speicheroption.
- Importieren Sie den Speicherort des Konfigurationsabbilds, der extrahiert werden soll, in eine BASH-Variable.
- Fügen Sie der erstellten VM den Speicherort des Konfigurationsimages hinzu.
- Überprüfen und überprüfen Sie die vollständige Konfiguration der VM.
- Optional: Verwenden Sie die VM als Vorlage für zukünftige Starts von vJunos-switch:
- Definieren Sie die aktuelle VM als Vorlage.
- Wählen Sie eine neue VMID für den Klon aus.
- Erstellen Sie eine Klon-VM, um sie später zu verwenden.
- Ändern Sie bei Bedarf die Schnittstellenzuweisungen für den Klon.
- Starten Sie die VM oder ihren Klon.
- Überprüfen Sie die Linux-Bridge-Zuweisung lokal für die gestartete VM.
- Überprüfen Sie auf der Proxmox-GUI, ob die VM gestartet wurde, und greifen Sie dann auf die Konsole zu.
# configure the management ID for the VM and your storage location VMID="200" VMSTORAGE="local-lvm" # make sure any prior instance of this VM is down and deleted qm stop $VMID qm destroy $VMID # create a new VM without a virtual disk qm create $VMID --name switch1 --memory 5120 --cores 4 \ --args "-machine accel=kvm:tcg -smbios type=1,product=VM-VEX -cpu 'host,kvm=on'" \ --boot order=virtio0 --serial0 socket \ --net0 virtio,bridge=vmbr0 \ --net1 virtio,bridge=ge000,firewall=0 \ --net2 virtio,bridge=ge001,firewall=0 \ --net3 virtio,bridge=ge002,firewall=0 # import the vJunos image as qcow2 format in proxmox qm disk import $VMID /root/download/vJunos-switch-23.2R1.14.qcow2 $VMSTORAGE --format qcow2 | tee diskimport.txt . . transferred 31.6 GiB of 31.8 GiB (99.52%) transferred 31.8 GiB of 31.8 GiB (100.00%) transferred 31.8 GiB of 31.8 GiB (100.00%) Successfully imported disk as 'unused0:local-lvm:vm-200-disk-0' # extract image location from import VMIMAGE=`cat diskimport.txt | grep "imported disk" | awk '{print $5}' | sed 's/.:/ /' | awk '{print $2}' | sed 's/.$//'` echo $VMIMAGE local-lvm:vm-200-disk-0 # attach the qcow2 disk to the vm qm set $VMID --virtio0 $VMIMAGE,iothread=1,size=32G update VM 200: -virtio0 local-lvm:vm-200-disk-0,iothread=1,size=32G
Lesen Sie das Kapitel Standardkonfiguration von Junos OS für vJunos-switch. In diesem Kapitel erfahren Sie, wie Sie eine individuelle Junos OS-Konfiguration für Ihre vJunos-Switch-VM erstellen, die in den anderen Umgebungen ähnlich ist. In diesem Kapitel werden Sie auch durch das Hinzufügen einer Adopt-Konfiguration geführt, anhand derer jede neue vJunos-Switch-VM automatisch im Juniper Mist Cloud-Bestand angezeigt wird. Hier haben Sie, ohne die gleichen Schritte zu wiederholen, eine minimale Startkonfiguration für den Remote-SSH-Zugriff wie root mit dem Kennwort ABC123 auf der fxp0-Schnittstelle verwendet.
cat <<EOF >juniper.conf
system {
host-name vjunos;
root-authentication {
encrypted-password "\$6\$DOvFAxW9\$HpxgOaGEe5L6MtDJqbWepS5NT6EW23rCuu69gwwGVFr7BpzY2MHS34mPrR0LKRqoGI19tRgpz3vFJkEueW9mQ1"; ## SECRET-DATA
}
services {
ssh {
root-login allow;
protocol-version v2;
}
}
name-server {
8.8.8.8;
9.9.9.9;
}
arp {
aging-timer 5;
}
syslog {
file interactive-commands {
interactive-commands any;
}
file messages {
any notice;
authorization info;
}
}
}
interfaces {
fxp0 {
unit 0 {
family inet {
dhcp force-discover;
}
}
}
}
protocols {
lldp {
interface all;
}
lldp-med {
interface all;
}
}
EOF
Zu diesem Zeitpunkt müssen Sie eine individuelle Junos OS-Startkonfiguration erstellt haben und den Vorgang fortsetzen.
# download the make-config.sh script from the Juniper CDN if you do not have it yet
# https://webdownload.juniper.net/swdl/dl/anon/site/1/record/168885.html
chmod 777 make-config.sh
./make-config.sh juniper.conf myconfig.img
.
./config/juniper.conf
Cleaning up...
removed '/var/tmp/tmp.hhQ0rcM92K/config/juniper.conf'
removed directory '/var/tmp/tmp.hhQ0rcM92K/config'
removed directory '/var/tmp/tmp.hhQ0rcM92K'
removed directory '/var/tmp/tmp.gvCkmgmvXy'
Config disk myconfig.img created
# import the junos config image to proxmox storage
qm disk import $VMID myconfig.img $VMSTORAGE --format raw | tee diskimport.txt
.
transferred 1.0 MiB of 1.0 MiB (100.00%)
transferred 1.0 MiB of 1.0 MiB (100.00%)
Successfully imported disk as 'unused0:local-lvm:vm-200-disk-1'
# extract image location from import
VMIMAGE=`cat diskimport.txt | grep "imported disk" | awk '{print $5}' | sed 's/.:/ /' | awk '{print $2}' | sed 's/.$//'`
echo $VMIMAGE
local-lvm:vm-200-disk-1
# attach the config-image disk to the vm
qm set $VMID --ide0 $VMIMAGE,size=16M
update VM 200: -ide0 local-lvm:vm-200-disk-1,size=16M
Jetzt sind alle unsere Vorbereitungen abgeschlossen. Sie können die resultierende VM-Konfiguration überprüfen.
# review the VM configuration made qm config $VMID args: -machine accel=kvm:tcg -smbios type=1,product=VM-VEX -cpu 'host,kvm=on' boot: order=virtio0 cores: 4 ide0: local-lvm:vm-200-disk-1,size=4M memory: 5120 meta: creation-qemu=8.1.5,ctime=1728988040 name: switch1 net0: virtio=BC:24:11:01:06:0E,bridge=vmbr0 net1: virtio=BC:24:11:6B:0B:84,bridge=ge000,firewall=0 net2: virtio=BC:24:11:7E:5C:07,bridge=ge001,firewall=0 net3: virtio=BC:24:11:FB:40:37,bridge=ge002,firewall=0 serial0: socket smbios1: uuid=5b184467-bffe-45f3-8a4c-bb2182aa3aa5 virtio0: local-lvm:vm-200-disk-0,iothread=1,size=32524M vmgenid: a3299ccf-293b-4df2-9458-b0fa444a9c61
Da die VM keine Anmeldeinformationen oder andere einschränkende Faktoren enthält, verwenden Sie diese VM als Vorlage, bevor Sie sie zum ersten Mal starten. Auf diese Weise können Sie mehrere VMs vollständig starten oder später mit den Image-Klonen verknüpfen. Führen Sie die folgenden Schritte aus, wenn Sie fortfahren möchten.
qm template $VMID
Renamed "vm-200-disk-1" to "base-200-disk-1" in volume group "pve"
Logical volume pve/base-200-disk-1 changed.
WARNING: Combining activation change with other commands is not advised.
Renamed "vm-200-disk-0" to "base-200-disk-0" in volume group "pve"
Logical volume pve/base-200-disk-0 changed.
WARNING: Combining activation change with other commands is not advised.
# select a new VMID for the clone
VMID2="201"
# create a clone of of your template VM
qm clone $VMID $VMID2 --name switch1
create linked clone of drive ide0 (local-lvm:base-200-disk-1)
Logical volume "vm-201-disk-0" created.
create linked clone of drive virtio0 (local-lvm:base-200-disk-0)
Logical volume "vm-201-disk-1" created.
#
# at this point you may change the interfaces assigned according to your topology
#
# review the VM configuration for the clone
qm config $VMID2
args: -machine accel=kvm:tcg -smbios type=1,product=VM-VEX -cpu 'host,kvm=on'
boot: order=virtio0
cores: 4
ide0: local-lvm:vm-201-disk-0,size=4M
memory: 5120
meta: creation-qemu=8.1.5,ctime=1729094281
name: switch1
net0: virtio=BC:24:11:87:61:1B,bridge=vmbr0
net1: virtio=BC:24:11:B2:11:52,bridge=ge000,firewall=0
net2: virtio=BC:24:11:79:0C:A1,bridge=ge001,firewall=0
net3: virtio=BC:24:11:DF:BC:BF,bridge=ge002,firewall=0
serial0: socket
smbios1: uuid=b81068a9-8f7e-423a-bbb8-7738da5f98df
virtio0: local-lvm:vm-201-disk-1,iothread=1,size=32524M
vmgenid: de47f143-5f48-44c4-8674-beb7d1b91bd2
# start the clone vJunos-switch VM
qm start $VMID2
brctl show
bridge name bridge id STP enabled interfaces
ge000 8000.de5f3a3d3a9b no tap201i1
ge001 8000.da08ff719f7c no tap201i2
ge002 8000.8614a67130b7 no tap201i3
vmbr0 8000.5847ca7543fe no enp2s0
tap201i0
Wenn Sie sich entschieden haben, noch keine Vorlage/Klone zu verwenden, starten Sie jetzt die erste vJunos-Switch-VM zu Testzwecken.
# start the new vJunos-switch VM
qm start $VMID
# review the linux-bridges and attached interfacs for our first VM
brctl show
bridge name bridge id STP enabled interfaces
ge000 8000.0ac0df72ec4b no tap200i1
ge001 8000.623437ae4bac no tap200i2
ge002 8000.72c0fc5f9933 no tap200i3
vmbr0 8000.5847ca7543fe no enp2s0
tap200i0
Sie können jetzt die VM-Konsole in der Proxmox-GUI überprüfen. Stellen Sie sicher, dass Sie die richtige Schaltfläche verwenden, um Änderungen am äußeren VM-Bildschirm in der Routing-Engine zu vermeiden. Die Routing-Engine ist der Ort, an dem die gesamte Junos OS-Konfiguration beginnt und über einen eigenen Bildschirm verfügt. In der folgenden Abbildung finden Sie die auszuwählenden Konsolenoptionen.
Linux-Bridge und VM-Schnittstelle nach VM-Erstellungsänderungen auf Proxmox VE
Das Starten der vJunos-Switch-VM entspricht nicht den Anforderungen der meisten Labs. Sie müssen die im Beispiel verwendete Standard-Linux-Bridge nach jedem Start einer neuen VM anpassen. Eine ausführliche Erklärung finden Sie im Kapitel Linux Bridge und VM-Schnittstelle nach Änderungen an der VM-Erstellung. Daher müssen Sie es hier nicht wiederholen. EVE-NG verwaltet diese Optimierungen automatisch.
Proxmox VE stellt keine Details zu VM-Schnittstellen und deren Namen lokal über die CLI bereit. Diese Details sind jedoch in der REST-API für die GUI verfügbar. Mit dem bereitgestellten Befehl pveshkönnen Sie problemlos auf die VM-Schnittstelle zugreifen und JSON-basierte Informationen zu den erstellten VM-Schnittstellen extrahieren. Daher ist es einfacher, ein neues Skript vm-bridge-update.sh mit pvesh UND-Befehlen jq und regulärer BASH-Programmierung neu zu erstellen. Weitere Informationen finden Sie in den unten gezeigten Anweisungen.
apt-get install jq rm -f vm-bridge-update.sh touch vm-bridge-update.sh chmod 777 vm-bridge-update.sh vi vm-bridge-update.sh
Kopieren Sie die folgende Konfiguration und fügen Sie sie in Ihren Editor ein. Speichern und schließen Sie dann.
#!/bin/bash
# use API to get first nodename
pvesh get /nodes --output-format json | jq -r '.[].node' >nodes.txt
VMNODE=`cat nodes.txt | head -1`
echo 'We run this on node: '$VMNODE
# use API to get nic interfaces of our VM
pvesh get /nodes/$VMNODE/qemu/$1/status/current --output-format json | jq -r '.nics | keys[]' >/tmp/vminterfacelist.txt
# ignore first interface fxp0
cat /tmp/vminterfacelist.txt | tail -n +2 >/tmp/vminterfacelist2.txt
#cat /tmp/vminterfacelist2.txt
while IFS= read -r line
do
INTERFACE="$line"
#echo $INTERFACE
BRIDGE=`find /sys/devices/virtual/net -name $INTERFACE | grep '/brif/' | sed 's/// /g' | awk '{print $5}'`
# change MTU to higher value
RUNME="ip link set dev "$INTERFACE" mtu 9200"
echo $RUNME
eval $RUNME
# enable LLDP and 802.1x on bridge
RUNME="echo 65528 > /sys/class/net/"$BRIDGE"/bridge/group_fwd_mask"
echo $RUNME
eval $RUNME
# enable LACP on link
RUNME="echo 16388 > /sys/class/net/"$INTERFACE"/brport/group_fwd_mask"
echo $RUNME
eval $RUNME
done < /tmp/vminterfacelist2.txt
num=0
while IFS= read -r line
do
INTERFACE="$line"
BRIDGE=`find /sys/devices/virtual/net -name $INTERFACE | grep '/brif/' | sed 's/// /g' | awk '{print $5}'`
MTU=`cat /sys/class/net/$BRIDGE/mtu`
if [ "$MTU" != "9200" ]; then
echo 'Warning! Bridge:'$BRIDGE' did not follow new MTU setting of interface:'$INTERFACE' check other interfaces attached to same bridge and correct please!'
num=1
fi
done < /tmp/vminterfacelist2.txt
exit $num
Mit dem neuen Skript können Sie nun die Linux-Bridges und -Schnittstellen der VM aktualisieren, nachdem sie gestartet wurde. Der erste Knoten der ausgewählten API ist für eine einzelne Proxmox VE-Installation geeignet. Wenn Sie über einen Cluster verfügen, müssen Sie möglicherweise das obige Skript ändern.
./vm-bridge-update.sh $VMID We run this on node: proxmox1 ip link set dev tap200i1 mtu 9200 echo 65528 > /sys/class/net/ge000/bridge/group_fwd_mask echo 16388 > /sys/class/net/tap200i1/brport/group_fwd_mask ip link set dev tap200i2 mtu 9200 echo 65528 > /sys/class/net/ge001/bridge/group_fwd_mask echo 16388 > /sys/class/net/tap200i2/brport/group_fwd_mask ip link set dev tap200i3 mtu 9200 echo 65528 > /sys/class/net/ge002/bridge/group_fwd_mask echo 16388 > /sys/class/net/tap200i3/brport/group_fwd_mask
Um den ersten Test für Ihre Linux-Bridge-Verbesserungen zu validieren, suchen Sie auf LLDP-Nachbarankündigungen von Ihrer vJunos-Switch-VM. Mit den juniper.conf Anweisungen, aber ohne die Anpassung, sehen Sie die Ankündigungen nicht mit tcpdump ). Siehe das Beispiel unten.
root@proxmox1:~# tcpdump -eni ge000 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ge000, link-type EN10MB (Ethernet), snapshot length 262144 bytes 13:47:37.917669 bc:24:11:6b:0b:84 > 01:80:c2:00:00:0e, ethertype LLDP (0x88cc), length 322: LLDP, length 308: vjunos 13:48:07.692425 bc:24:11:6b:0b:84 > 01:80:c2:00:00:0e, ethertype LLDP (0x88cc), length 322: LLDP, length 308: vjunos
Um einen letzten Test durchzuführen, starten Sie einen zweiten vJunos-Switch, der 1:1 mit der ersten VM verbunden ist. Richten Sie dann eine LAG mit aktivem LACP zwischen den beiden VMs ein. Die Konfiguration für beide virtuellen Switches in der GUI von Juniper Mist Cloud ist unten dargestellt.
Wenn Sie lokal auf der vJunos-Switch-Konsole untersuchen, sollten Sie LLDP-Nachbarn und die eingerichteten LACP-Verbindungen zwischen den beiden Switches sehen. In diesem Schritt wird überprüft, ob Ihr Lab wie erwartet funktioniert.
root@switch1> show lldp neighbors
Local Interface Parent Interface Chassis Id Port info System Name
ge-0/0/0 ae0 2c:6b:f5:3b:3b:c0 ge-0/0/0 switch2
ge-0/0/1 ae0 2c:6b:f5:3b:3b:c0 ge-0/0/1 switch2
ge-0/0/2 ae0 2c:6b:f5:3b:3b:c0 ge-0/0/2 switch2
root@switch1> show lacp interfaces
Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/0 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/0 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/0 Current Fast periodic Collecting distributing
ge-0/0/1 Current Fast periodic Collecting distributing
ge-0/0/2 Current Fast periodic Collecting distributing