Two-Level Nested Virtualization Infrastructure with Proxmox VE & Ubuntu

CHAYMAE HANIDA — Fri, 30 Oct 2026 15:56:13 +0000

📌 Overview & Architecture

Virtualization is at the core of modern cloud environments. In this project, I implemented and validated a Two-Level Nested Virtualization Infrastructure (Hypervisor-on-Hypervisor) to test multi-tier resource allocation, network bridging, and inter-VM connectivity.

🏗️ Environment Topology

Host Level (L0): Physical Workstation (VMware Workstation)
Level 1 (L1 Hypervisors):
- Proxmox VE (L1 Node)
- Ubuntu Server (L1) with Apache2 / Cockpit
Level 2 (L2 Virtual Machines):
- Proxmox VE (L2 Node) running inside L1 Proxmox
- Ubuntu Server (L2 Node) running inside L1 Proxmox

🛠️ Implementation Highlights

CPU Passthrough & Virtualization Flags:
Enabled nested virtualization extensions (VT-x/AMD-V) in VMware to allow L1 hypervisor to host secondary virtual machines (L2).
Network Bridging Configuration:
Configured Linux bridges (vmbr0) across L1 and L2 layers to provide direct network visibility and IP assignment across all instances.
Remote Node Management:
Enabled remote management via Proxmox Web Interface (Port 8006) and Linux Cockpit Admin Dashboard (Port 9090).

🌐 Network Matrix & Connectivity Verification

A structured ICMP Ping Matrix was conducted to verify that all nodes can communicate seamlessly across layers without packet loss or bridge isolation issues:

Source Node	Destination Node	Status
Host (L0)	L1 Proxmox / L1 Ubuntu	✅ Connected
Host (L0)	L2 Proxmox / L2 Ubuntu	✅ Connected
L1 Proxmox	L1 & L2 Guest Virtual Machines	✅ Connected
L2 Proxmox	L1 Hypervisors & L0 Host	✅ Connected

📊 Remote Management & Interface Validation

Remote access was verified from multiple devices on the network, including web management on mobile endpoints:

Proxmox VE (L1 Node): https://10.250.73.43:8006
Proxmox VE (L2 Node): https://10.250.73.249:8006
Ubuntu Cockpit Web Console: Ports 9090 across active Ubuntu instances (vm11ubuntu, vm12ubuntu, vm2ubuntu).

💡 Key Takeaways

Overhead Control: Nested virtualization introduces minor CPU/RAM overhead, requiring careful resource allocation per VM layer.
Bridging vs NAT: Using standard virtual bridging simplifies inter-VM communication in complex nested labs.
Infrastructure Testing: This setup serves as an effective, cost-free sandbox for testing hypervisor clusters, cloud migration, and IaC pipelines locally.

📸 Project Execution Screenshots & Verification Gallery

Below are the operational screenshots verifying system deployment, active services, and multi-device network connectivity across all L1 and L2 instances:

1. Primary Hypervisor (L1 Proxmox VE)

2. Linux Administration Dashboards (Cockpit - Port 9090)

3. Nested Hypervisors & Secondary Nodes (L2 Instances)

Utiliser Claude Code avec Ollama sur Windows

CHAYMAE HANIDA — Wed, 21 Oct 2026 11:27:34 +0000

Introduction

Dans le cadre de mon Master, je voulais tester un agent de programmation sans dépendre d'un abonnement payant. Le plus difficile a été de faire reconnaître la commande claude par Windows (problème de PATH).

Claude Code est un agent de programmation qui s'utilise dans le terminal. Ollama permet de lui fournir un modèle open source, y compris des modèles cloud gratuits. Dans cet article, je décris comment j'ai configuré les deux sur Windows et les problèmes rencontrés.

Prérequis

Windows 10 ou 11
PowerShell
Un compte Ollama (gratuit)
Une connexion internet

Étape 1 : installer Claude Code

Dans PowerShell :

irm https://claude.ai/install.ps1 | iex

Étape 2 : corriger le PATH

Après l'installation, la commande claude n'était pas reconnue. Il faut ajouter le dossier d'installation au PATH :

[Environment]::SetEnvironmentVariable("Path", [Environment]::GetEnvironmentVariable("Path","User") + ";$env:USERPROFILE\.local\bin", "User")

Fermer PowerShell, le rouvrir, puis vérifier :

claude --version

Étape 3 : installer Ollama

Télécharger l'installateur sur ollama.com. Pour l'installer sur un autre disque :

.\OllamaSetup.exe /DIR="D:\Ollama"

Pour stocker les modèles sur ce disque :

[Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\OllamaModels", "User")

Se connecter ensuite à son compte Ollama depuis l'application.

Étape 4 : lancer Claude Code avec Ollama

mkdir D:\test-claude
cd D:\test-claude
ollama launch claude --model gemma4:31b-cloud

Au premier lancement, Claude Code demande si on fait confiance au dossier. Il faut choisir Yes, I trust this folder (le choix par défaut est « No, exit »).

Test

J'ai demandé à Claude Code de créer un fichier :

crée un fichier hello.py qui affiche Bonjour

Résultat : le fichier hello.py a été créé avec le contenu suivant :

print("Bonjour")

Problème rencontré : modèle retiré

Avec glm-5:cloud, j'ai obtenu l'erreur suivante :

API Error: 410 glm-5 was retired on July 15, 2026

Les modèles cloud changent souvent. Pour voir la liste actuelle :

ollama launch claude

Utilisation dans VS Code

En ouvrant le dossier du projet dans VS Code puis en lançant la commande depuis le terminal intégré, l'extension Claude Code pour VS Code s'installe automatiquement.

Précautions

Ne lancez pas Claude Code depuis C:\Users\<nom> : il aurait accès à tout votre dossier utilisateur. Utilisez toujours le dossier du projet.
Le mode « auto » exécute des actions sans demander. Avec Shift + Tab, on peut choisir un mode qui demande une confirmation.
Le modèle utilisé (ici Gemma 4) n'est pas Claude : la qualité des réponses diffère.

Conclusion

La configuration est rapide avec ollama launch claude. Les principales difficultés sont le PATH sous Windows et le choix d'un modèle cloud encore disponible.

DEV Community: CHAYMAE HANIDA