It all sounds important...but also a little confusing. Like, why are there so many moving parts? And what do they actually do?

In this guide, we’re going to break it all down – step by step – using real examples and simple language.

You’ll learn:

• What load balancers are (and why apps even need them)

• How apps were deployed before load balancers existed (hint: everything lived on one lonely server)

• How Azure Virtual Machines work – and how they let you scale up your apps

• What Virtual Machine Scale Sets are, and how they help handle sudden traffic spikes

• The differences between Azure Load Balancer and Azure Application Gateway, and when to use each

By the end, you won’t just understand what these tools do – you’ll know when and why to use them in real-world scenarios.

Whether you’re a curious beginner, a hands-on builder, or someone just trying to wrap their head around Azure’s ecosystem, this guide is for you.

Ready to untangle the cloud spaghetti? Let’s go! 🍝🚀

📚 Table of Contents

1. 🧊 What Are Load Balancers?

2. 🖥️ How Applications Were Deployed Before Load Balancers

3. ⚙️ Azure Virtual Machines (VMs) – The Building Blocks

4. 📈 The Need for Scaling – Vertical vs Horizontal

5. 🔁 Azure Virtual Machine Scale Sets (VMSS) – Scaling Made Simple

6. 📦 Azure Load Balancer – Spreading the Traffic

7. 🍴 Azure Application Gateway – Smart Routing for Modern Apps

8. 🔍 Azure Load Balancer vs Azure Application Gateway

9. 🧭 Use Cases: When to Use Each One

10. ✅ Conclusion

11. Study Further 📚

12. About the Author 👨‍💻

🧊 What Are Load Balancers?

Imagine you're running a small restaurant with just one chef in the kitchen. Everything goes smoothly when you have a few customers – each order is prepared one after the other, and everyone leaves satisfied.

But what happens when 50 people walk in all at once?

🍽️ One chef can’t handle that many orders at the same time.
⏳ People start waiting longer.
😤 Some customers leave.
💥 The chef gets overwhelmed – and eventually burns out.

This is what can happen to a server (the computer running your app) when too many users try to access it at the same time.

So, What Does a Load Balancer Do?

A load balancer is like a smart restaurant manager. But instead of food orders, it handles user requests – the things people do when they open your app, click buttons, or load data.

Let’s say you now have three chefs (servers) instead of one. The load balancer’s job is to:

• 👀 Watch for incoming orders (user requests)

• 🧠 Decide which chef (server) is available or least busy

• 🍽️ Send that request to the right one

• 🔁 Repeat this over and over, making sure things stay fast and smooth

So in simple terms, a load balancer takes all the incoming traffic to your app and distributes it across multiple servers so no single server gets overloaded – cool, right? 🙂

Why Were Load Balancers Introduced?

Back in the early days, many applications were hosted on just one machine – called a Single Server Deployment.

That was okay when you had a small number of users. But once things started to grow – more users, more actions, more data – single servers became a bottleneck:

• They could only handle a limited number of requests.

• If they went down, your entire app would stop working.

• Scaling (adding more power) was expensive and manual.

💡 Enter load balancers – designed to solve this by making it possible to:

• Spread traffic across multiple servers (so no one server crashes under pressure),

• Replace or restart servers without downtime,

• Add or remove servers as needed, depending on how busy your app is (this is called scaling).

A Simple Use-Case Scenario

Let’s say you're building an online store — your own mini Amazon. At first, you host your app on one Azure Virtual Machine. Things are great. But one day, you run a huge promo and suddenly…thousands of people flood in to browse, shop, and check out.

Your single VM starts lagging.

Orders fail. People complain. Your dream app? Crashing fast. 💥

So what do you do?

You spin up two more VMs to help out – but now you’ve got another problem: How do you divide the traffic between the three?

This is where the load balancer steps in. It:

• Looks at every incoming user request

• Figures out which VM is available and least busy

• Sends the request there

• Keeps rotating requests in real-time

And the result?
✅ No single VM gets overwhelmed
✅ Your app stays fast and responsive
✅ Users are happy (and buying stuff again!)

🖥️ How Applications Were Deployed Before Load Balancers

Before cloud tools like load balancers came along, the typical way to run an application was pretty simple: You’d deploy the entire app on a single server, like running a small business from one tiny shop.

First Things First: What’s a Server?

Think of a server as a special computer that’s always connected to the internet. Its job is to “serve” your app to people when they visit your website, open your app, or use your service.

In cloud platforms like Azure, we usually call these Virtual Machines (VMs) – basically, software-powered servers you can spin up with a few clicks.

Monoliths vs Microservices

Now, applications come in different “shapes.” The two most common are:

• Monoliths: Everything is bundled together into one big app. All the code – from user login to shopping cart to checkout – lives in a single unit.

• Microservices: The app is broken into smaller, independent apps (services). Each service does one job – like login, payments, orders – and runs separately.

How Were These Apps Deployed?

Whether it was a monolith or a bunch of microservices, they were all usually deployed on a single server (VM).

For monoliths, you just ran the entire app directly on the server. For microservices: you'd run each service in a separate space on that same server, using containers.

Wait — What’s a Container?

A container is like a mini-computer inside a computer. It has everything an app needs to run – code, tools, settings – and it keeps each app isolated from the others.

Why use containers?

• You can run multiple services on the same server without their underlying software (software needed for each app to run) interfering with each other.

• It’s faster and more efficient than installing everything directly on the server.

• They make moving apps between environments (for example, test → production) super smooth (no more “But, it works on my machine…”).

Popular tools like Docker make working with containers easy.

Connecting It All Together: Domains, Subdomains, and Reverse Proxies

When your app lives on a server, you want people to be able to reach it. That’s where domain names come in.

• Your server has a public IP address – a set of numbers like 102.80.1.23, that gives it a unique identifier on the public internet

• But instead of asking users to type numbers, you link that IP to a domain name, like mycoolapp.com

If your app has microservices, you might even assign subdomains like:

• api.mycoolapp.com for the backend

• dashboard.mycoolapp.com for the user interface

• payments.mycoolapp.com for payments

To manage all this, you’d use a reverse proxy (like Nginx or Apache). It listens on the main domain and subdomains, and forwards traffic to the right app or service.

Example:

• Someone visits dashboard.mycoolapp.com

• The reverse proxy checks the domain and forwards the request to the correct container running the dashboard service

And to help with all of this setup – from deploying containers to configuring reverse proxies – there are developer-friendly tools like Coolify. Coolify is an open-source platform that makes it super easy for developers and DevOps teams to:

• Deploy apps in containers

• Set up domains and subdomains

• Configure reverse proxies – all from a clean dashboard, no complex terminal commands needed

All this was set up on ONE SERVER/VM. But here’s the catch: when that one server got overloaded or went down…💥 everything stopped.

That’s why we needed a better way. And that's where scaling and load balancing came in – to keep apps running smoothly, no matter the traffic.

⚙️ Azure Virtual Machines (VMs) – The Building Blocks

When it comes to running apps in the cloud, Virtual Machines (VMs) are the basic building blocks – kind of like renting an apartment in a giant digital skyscraper.

You don’t need to buy the whole building (aka physical servers), you just rent the space you need, when you need it.

What Exactly Is a Virtual Machine?

A Virtual Machine is a software-based computer that runs inside a real, physical computer (a server) – hosted in a data center, like those run by Microsoft Azure.

It looks and behaves like a normal computer:

• It has an operating system (Windows, Linux)

• You can install apps

• It has memory (RAM), storage (disks), and CPU

But the best part? You don’t need to worry about the hardware. Azure takes care of that behind the scenes – all you do is say:

“Hey Azure, give me a Linux VM with 4GB RAM and 2 CPUs.”

And boom 💥 — it spins up in minutes.

Why Use a VM?

Let’s say you’ve built a web app – it’s just a simple blog. You want to deploy it and make it accessible to the world.

Here's what you can do with a VM:

• Set it up with your favorite OS (for example, Ubuntu)

• Install web servers like Nginx or Apache

• Deploy your app

• Bind it to your domain name

• Let the world visit your blog at myawesomeblog.com

It’s your own personal environment – no sharing, full control.

📈 The Need for Scaling – Vertical vs Horizontal

Imagine your app is growing. At first, it’s just a few users. Then a few hundred. Then thousands are logging in, placing orders, chatting, uploading photos – all at once 😮

Suddenly, your server (VM) is under pressure. It’s like trying to pour a flood through a straw.

So, What Do You Do When One Server Isn’t Enough?

This is where scaling comes in – the art of upgrading your app’s infrastructure to keep up with traffic.

There are two main ways to scale:

🧱 Option 1: Vertical Scaling (aka Scaling Up)

You take your existing VM and give it more power:

• Add more CPUs 🧠

• Increase RAM 🧵

• Add faster disks ⚡

Think of it like upgrading from a regular car to a sports car. It’s the same vehicle, just faster and stronger.

Pros:

• Simple to do

• No major changes to your app setup

Cons:

• There’s a limit to how much you can upgrade

• Still a single point of failure: if the VM crashes, everything goes down 😬

🧩 Option 2: Horizontal Scaling (aka Scaling Out)

Instead of boosting one server, you add more servers – multiple VMs running copies of your app.

Now:

• Users can be distributed across all these VMs

• If one goes down, others keep serving traffic

• You can dynamically add or remove VMs based on traffic

It’s like opening more checkout counters in a busy supermarket 🛒

Pros:

• The load is evenly distributed. For example, if one server previously handled 100% of the traffic, adding two more servers would result in the traffic being split into approximately 33% to 34% for each server.

• Improves both performance and reliability

• You can scale based on real-time demand, that is traffic inflow

Cons:

• Needs something to split traffic between VMs – Load Balancers

• More expensive. You end up paying the original amount for 1 VM (for example $30) for the number of VMs you provide – if you provide 3 VMs at $30 each, you end up paying $90 at the end of the month

Quick Real-World Example

Let’s say you’ve launched an e-commerce site for sneakers 👟 Traffic spikes during a big sale? Your vertical scaling (bigger VM) might choke.

But with horizontal scaling:

• You spin up 5 VMs across different regions

• Traffic is shared between them

• If one VM slows down, others handle the load

So, remember 👇🏾

🔁 Azure Virtual Machine Scale Sets (VMSS) – Scaling Made Simple

Okay – so we’ve talked about horizontal scaling: adding multiple VMs to handle growing traffic. Sounds great, right?

But here’s the thing: manually spinning up and configuring 5, 10, or 100 VMs... every time your app gets busy? Yeah, that’s not fun 🙃

Enter: Virtual Machine Scale Sets (VMSS)

VMSS is Azure’s way of automating horizontal scaling. Instead of creating each VM one by one, you define a template, and Azure takes care of the rest:

• How many VMs to start with

• How to configure them (OS, apps, settings) ⚙️

• When to add or remove VMs based on traffic 📈📉

A Simple Analogy 🧃

Think of VMSS like a juice dispenser at a party:

• At first, it pours into 2 cups (VMs)

• If 10 guests show up? It starts filling 5 cups

• Party slows down? Back to 2 cups again

You never have to refill manually – the dispenser adjusts on its own. 🎉

How It Works (Without the Jargon 😌)

1. You set the rules: “If CPU usage goes above 70%, add 2 more VMs.”

2. Azure watches traffic and adjusts the number of VMs automatically.

3. All VMs are identical – like clones, all running the same app setup.

4. It works with Azure Load Balancer to spread traffic across all these VMs smoothly.

Real-Life Example: Food Delivery App 🍕📱

You’ve built an app where users order food. During lunch and dinner, traffic explodes.

💡 With VMSS:

• You start with 3 VMs in the morning

• At 12PM, Azure sees high CPU usage, so it spins up 5 more VMs

• At 3PM, traffic drops, so Azure removes the extra VMs

You only pay for what you use. And users get a smooth experience – no delays, no crashes 👌🏾

📦 Azure Load Balancer – Spreading the Traffic

By now, you know that your app can live on multiple Virtual Machines (VMs), and that you can scale them easily using Virtual Machine Scale Sets (VMSS).

But here's the big question: when users start accessing your app – hundreds, even thousands at once – how do you make sure that all that traffic is fairly and efficiently distributed across those VMs?

You don’t want one VM to be overwhelmed while others are just chilling. You need a middleman – something smart enough to balance the load.

That’s where Azure Load Balancer steps in. It’s Azure’s way of saying, “Don’t worry, I got this” when traffic starts rolling in.

🏢 So, What Is Azure Load Balancer?

Azure Load Balancer is a traffic director. It takes incoming traffic from the internet (or even internal sources within your network) and intelligently spreads it across multiple backend machines – usually VMs.

It's like having a well-trained receptionist who routes every customer to the next available agent, so no one waits too long and no one gets overwhelmed 😃.

And the best part? This entire process happens in the background – fast, silent, and seamless. Users visiting your app have no idea a traffic manager is working behind the scenes. They just see a fast, responsive experience.

🌐 The Frontend IP – Your App’s Public Face

Every Azure Load Balancer is tied to a Frontend IP, which is basically the public IP address of your application – the one users connect to when they open www.yourapp.com.

This IP acts as the entry point. All user traffic comes through it first. But the Load Balancer doesn’t actually run your app. Instead, it accepts the traffic and forwards it to one of the VMs in the backend pool (we’ll get to that shortly).

You can configure this Frontend IP to be either public (accessible over the internet) or private (used for internal traffic within your cloud network – say, between microservices or internal tools).

🗂️ Backend Pool – Where the Magic Happens

Behind every Azure Load Balancer is a backend pool – a group of VMs (or VM Scale Set instances) where your actual app is running. These are the real workers, doing all the heavy lifting.

When traffic hits the Frontend IP, the Load Balancer takes that request and hands it off to one of the VMs in the backend pool.

But it doesn’t just randomly pick one. It checks a few things first – like whether the VM is healthy, whether it's already busy, and what rules you’ve set.

Each VM in the pool typically runs the same app or service. This means any of them can handle any incoming request, which is what makes load balancing possible in the first place.

🩺 Health Probes – Keeping Tabs on the VMs

Now, how does the Load Balancer know which VM is healthy or not? This is where health probes come in. Think of them as regular check-ups.

You configure the Load Balancer to periodically "ping" each VM – maybe by hitting a specific URL (like /health) or a certain port (like 80 for HTTP). If a VM doesn’t respond correctly, Azure marks it as unhealthy and temporarily removes it from the rotation.

This ensures users never get routed to a broken or unresponsive instance of your app. And once the VM becomes healthy again, it's automatically added back to the pool.

⚖️ Load Balancing Rules – Who Gets What?

Next, we have Load Balancing Rules. These are the instructions that tell Azure Load Balancer exactly how to behave.

You can define rules like:

• “Forward all HTTP (port 80) traffic to backend pool VMs on port 80”

• “Forward HTTPS (port 443) traffic to VMs on port 443”

• “Only route traffic to healthy VMs”

These rules make Azure Load Balancer highly customizable. You get to decide how traffic flows, which protocols to support, and how to handle backend ports. It's like customizing the rules of a relay race – who gets the baton and when.

👟 Real-World Example: Sneaker Sale Rush

Imagine you're running an online sneaker store at www.sneakerblast.com. You’re launching a flash sale, and thousands of users are hitting your website all at once.

Thanks to your Azure Load Balancer, here’s what happens:

1. All those users land on your Frontend IP, the public face of your site.

2. The Load Balancer accepts the traffic and checks the health probes of all VMs in the backend pool.

3. Based on its rules, it forwards each user to a healthy, available VM.

4. One VM might serve a user in Lagos, another in Nairobi, another in Accra – all seamlessly.

If one VM crashes or lags? The Load Balancer detects it instantly and stops routing traffic to it until it’s back online.

That’s smooth traffic management without any manual effort.

🍴 Azure Application Gateway – Smart Routing for Modern Apps

So far, we’ve seen how Azure Load Balancer helps you split traffic across multiple VMs running a single service – like a monolithic app or a web frontend.

Let’s say you have a web application deployed on a VM. It listens on port 80, and you’ve scaled it into 3 instances. The Azure Load Balancer takes requests from the internet and spreads them across all 3 instances of the same service. Easy, right?

You can even link the Load Balancer’s public IP address to your domain – like mydomain.com – so users can visit your site normally.

🧠 But What If You Have Multiple Services?

Now imagine you’ve gone beyond just one app. You’re building something more modern, like a set of microservices.

You now have:

• A payment service listening on port 5000

• An authentication service on port 6000

• A purchase service on port 7000

All deployed across the same VMs (or Virtual Machine Scale Set), just on different ports.

Here’s the problem: an Azure Load Balancer is designed to route traffic to one backend pool – basically one service – on one port. If you tie it to mydomain.com, it can only send traffic to one of your microservices. 😬

So… what do you do?

You might think: “Let me just create a separate Load Balancer for each service!” 🤕

But that means:

• You’ll have to pay for multiple load balancers

• You’ll end up managing 3–5 public IP addresses

• You might even need to buy multiple domains like mypayment.com, myauth.com, and so on to route users properly

Yikes. That’s impractical, messy, and expensive 😖💸

🎉 Enter Azure Application Gateway

Azure Application Gateway solves this problem beautifully. It’s designed to route traffic intelligently – not just to one service, but to multiple services using just one gateway.

It works like this:

1. You create one public-facing frontend IP (like 52.160.100.5)

2. You link that IP address to your main domain, for example mydomain.com

3. Then, you define multiple backend pools – one for each service:

   • Payment service (port 5000)

   • Auth service (port 6000)

   • Purchase service (port 7000)

4. Next, you set up routing rules that decide how to forward each request.

✨ Two Ways to Route with Application Gateway

You can configure smart routing based on:

• URL paths:

  • mydomain.com/payment → Payment service

  • mydomain.com/auth → Auth service

• Subdomains (host headers):

  • payment.mydomain.com → Payment service

  • auth.mydomain.com → Auth service

This way, all your services share one public IP and one domain – super clean, super efficient 🙌🏾

🤓 Real-Life Scenario (Let’s Break It Down)

Let’s say you’re building a startup platform that has three key microservices:

• Payment service that handles transactions

• Authentication service that handles login and user identity

• Purchase service that manages product ordering

Each service is containerized and deployed on the same VM (or across several VMs using a VM Scale Set). But – and this is key – they all listen on different ports inside the VMs:

• Payment → port 3000

• Auth → port 6000

• Purchase → port 7000

Now, without a smart routing solution, you’d be stuck trying to expose just one of these services using a standard Azure Load Balancer. But you need all three to be accessible from the internet – and you don’t want to pay for or manage 3 different Load Balancers 😅

So, what do you do?

🧠 Using Azure Application Gateway to Route Traffic Intelligently

Here's how you can fix this using one Application Gateway:

1. Deploy your microservices inside each VM:

   • Each service runs on a specific port

   • All VMs in your scale set are identical (they contain all three services)

2. Create backend pools in Application Gateway:

   • A backend pool for the payment service (pointing to port 3000 on all VMs)

   • One for the auth service (port 6000)

   • Another for the purchase service (port 7000)

3. Create routing rules:

   • Option A (Path-based routing):

     • Requests to mydomain.com/payment → go to the payment backend pool

     • Requests to mydomain.com/auth → go to the auth backend pool

     • Requests to mydomain.com/purchase → go to the purchase backend pool

   • Option B (Subdomain-based routing):

     • payment.mydomain.com → payment service

     • auth.mydomain.com → auth service

     • purchase.mydomain.com → purchase service

You just tell the Application Gateway: “Hey, if a request comes in for this URL or subdomain, send it to this port on these VMs.” And it does just that – consistently and intelligently 🔁

📦 So, What’s Really Happening?

Imagine a user visits mydomain.com/auth. Here’s what goes on behind the scenes:

1. The DNS translates mydomain.com to your Application Gateway’s public IP

2. The Gateway receives the request

3. It checks your routing rules

4. It sees that /auth should go to the backend pool for port 6000

5. It forwards the request to one of the VMs running the auth service

6. The response goes back to the user – fast and seamless ✨

This happens in milliseconds, for every request. And because the Application Gateway is aware of multiple ports and services, it can handle routing logic that a regular Load Balancer just can’t do.

🔍 Azure Load Balancer vs Azure Application Gateway

By now, you've seen how both tools help route traffic in Azure – but they solve different problems.

Let’s break down how they compare, and when you should use one over the other 👇🏾

🛣️ 1. Routing Logic

Azure Load Balancer
It simply distributes incoming traffic evenly across a pool of VMs. It doesn’t care what the request is – it just balances the load.

Imagine a delivery guy who doesn't ask questions – he just drops each package at the next available house.

That’s what Azure Load Balancer does: it sends traffic to one of your servers without looking inside the request.

Azure Application Gateway
This is the smart one. It looks at what’s inside each request (like the URL path or domain) and makes intelligent decisions.

Just like a smarter delivery guy who looks at the address and decides where to go: "Oh! This one is for the payment office, not the main office."

That’s what Application Gateway does: it reads the request (like the URL or domain name) and sends it to the right place according to the routing rules.

🌐 2. Protocols Handled

Load Balancer
Works at the transport layer (Layer 4 in the OSI model). It deals with TCP/UDP traffic – raw network traffic, like HTTP, video streaming, games, and so on.

Application Gateway
Works at the application layer (Layer 7). It handles web traffic only – like websites and apps (HTTP/HTTPS) – and it can actually read what's being asked, like:

• “Go to /login”

• “Go to payment.mydomain.com”.

TL;DR: Load Balancer just pushes packets. App Gateway actually reads your web requests.

🔁 3. Use Case Scenarios

🔐 4. SSL Termination & Security Features

Load Balancer doesn’t handle security stuff. You’ll need to secure each server yourself (for example, set up HTTPS on each one).

Application Gateway can secure everything in one place – you upload your SSL certificate once and it takes care of HTTPS for all services.

It can also protect you from hackers and bad traffic with something called WAF (Web Application Firewall), which protects your app from threats like SQL injection, XSS, and so on (you need to set this up manually).

💰 5. Pricing and Complexity

Load Balancer is cheaper and easier to set up. Great when you don’t need anything fancy.

Application Gateway costs more, but gives you more control and less headache when working with complex apps and microservices.

Trying to use Load Balancer for multiple services? You’ll need to create one Load Balancer per service, which becomes costly and impractical.

🧠 Summary Table

🧭 Use Cases: When to Use Each One

There’s no one-size-fits-all when it comes to hosting apps in the cloud. The right setup depends on what you’re building, how much traffic you expect, and how complex your app is.

Let’s walk through 4 different use-case scenarios, starting from the most basic setup all the way to a fully auto-scaled and smartly routed architecture.

1️⃣ Single VM Instance – For Small Projects or Internal Tools

Use this when:
You're just getting started. You’ve built a small app – maybe a portfolio, a blog, or a side project – and you want to make it live, OR You’re a startup that just launched.

How it works:
You spin up one Azure VM, install your app on it, and open the port it listens on (for example, port 80 for a web server). You can then attach a public IP to the VM and bind it to a custom domain like myawesomeapp.com.

Real-life examples:

• A developer hosting a portfolio website or blog

• A startup testing a new product with only a few users

• An internal company tool for a small team

Pros:

• Super simple setup

• Low cost

• Full control of your environment

Cons:

• If the VM goes down, your app goes down

• No auto-scaling – performance may drop with traffic spikes (the only way to adapt to increased CPU/memory usage due to traffic inflow is via manually scaling the VM vertically)

• You manually maintain and monitor everything

2️⃣ Manual Horizontal Scaling – For Apps With Medium, Predictable Traffic

Use this when:
Your app is growing – maybe you have a few thousand users now, and performance matters. You want more than one server so your app doesn’t crash during busy hours.

How it works:
You manually create 2 or 3 Azure VMs with the same app setup. You then add a Load Balancer in front to split traffic evenly across them.

Real-life examples:

• A business with a customer portal

• A school website that handles regular logins, lecture video streaming, and so on during class hours

• An app that gets traffic mostly during the day (predictable load)

Pros:

• Better performance and availability

• Load is shared across multiple VMs

• You can scale manually when needed

Cons:

• You must manually add or remove VMs – which takes effort

• Still need to monitor performance manually

• No built-in automation or auto-healing

3️⃣ Auto-Scaling with VM Scale Sets + Azure Load Balancer – For Apps With Spiky or Unpredictable Traffic

Use this when:
You’re building something more serious – traffic comes in waves (for example, a fitness/coach booking app), and you don’t want to sit around scaling VMs all day. You want Azure to automatically scale your infrastructure for you.

How it works:
You set up a Virtual Machine Scale Set (VMSS) that can automatically create more VMs when needed (like during high traffic), and remove them when things are calm — saving money. A Load Balancer distributes traffic across all those VMs.

Real-life examples:

• A media platform where people upload videos or photos

• A shopping site that gets surges during promotions, for example Black Fridays

• A booking platform with peak traffic in evenings/weekends

Pros:

• Automatic scaling – saves time and money

• High availability: VMs can be replaced if one fails

• Easy to grow as your user base grows

Cons:

• Works best if your app is monolithic (one big service)

• No support for routing traffic to specific services – just spreads traffic across VMs

• Load Balancer can’t look at URL paths or subdomains

4️⃣ VM Scale Set + Azure Application Gateway – For Microservices or Complex Web Apps

Use this when:
You have a modern, multi-service app – maybe built with microservices. Each service (like payments, authentication, search, and so on) lives on a different port or even in a container.

You want to route traffic smartly – like /login goes to the auth service, /pay to payments, and /search to the search service – all on the same domain.

How it works:
You still use a VM Scale Set for auto-scaling, but instead of a basic Load Balancer, you add an Application Gateway. It can inspect each request and send it to the right service based on things like:

• URL path (for example, /payments, /orders)

• Subdomain (for example, payments.mydomain.com, auth.mydomain.com)

Real-life examples:

• A full-blown SaaS product with multiple services

• An e-commerce site with checkout, account, orders, and admin dashboards

• A business migrating from a monolith to a microservices setup

Pros:

• Smart routing based on path or subdomain

• Everything runs under one public IP and one domain

• Secure HTTPS handling + optional Web Application Firewall (WAF)

• Auto-scaling and high availability

Cons:

• More complex setup

• Slightly higher cost due to Application Gateway

• Needs planning around port numbers and backend pools

🧠 Quick Summary Table

✅ Conclusion

By now, you’ve gone from simply hearing the words “load balancer” or “scale set” to understanding exactly how they work, when to use them, and what problems they solve. Whether you’re just launching a small app or scaling up a high-traffic service, Azure gives you flexible, powerful tools to grow with confidence.

We started from the very beginning – a single virtual machine. It’s simple and great for small apps, but it quickly becomes a bottleneck as traffic grows.

That’s where scaling comes in. We explored:

• 🧱 Vertical scaling – Upgrading the same VM (quick fix, but limited)

• 🧩 Horizontal scaling – Adding more VMs to handle traffic better

Then we introduced Azure Virtual Machine Scale Sets (VMSS) – which bring auto-scaling to life. No more manual intervention – Azure can scale your servers up and down based on demand.

But where things really get smart is with load balancers:

• 📦 Azure Load Balancer helps spread traffic across your VMs — great for single-service apps

• 🍴 Azure Application Gateway takes it further by routing requests based on URL paths or subdomains — perfect for multi-service or microservice apps

🎯 TL;DR – What Should You Use?

• Single VM: For side projects, portfolios, or internal tools

• Manual scaling + Load Balancer: For medium apps with predictable load

• VMSS + Load Balancer: For monolithic apps with auto-scaling needs

• VMSS + Application Gateway: Also includes auto-scaling but for microservices or smart routing needs

💡 Final Thoughts

Cloud apps grow – fast. And with growth comes complexity. But with the right Azure setup, you can stay one step ahead of your traffic, serve users better, and keep costs under control.

Remember: you don’t need to start big. Start small, understand your app's traffic patterns, and scale only when you need to. Tools like Azure VM Scale Sets, Load Balancer, and Application Gateway give you the control and power to build scalable, modern applications without over-engineering.

Thanks for sticking with me through this deep dive. I hope this made things clearer, simpler, and maybe even a little fun 😊

Study Further 📚

If you would like to learn more about Azure Virtual Machines, Scale Sets, Load Balancer, and Application Gateway, you can check out the courses below:

• Microsoft Azure Fundamentals AZ-900 Exam Prep Specialization — Microsoft, Coursera

• Azure Virtual Machine Tutorial | Creating A Virtual Machine In Azure | Azure Training | Simplilearn — YouTube

• Virtual machine scale sets — YouTube

• Azure Load Balancer | Azure Load Balancer Tutorial | All About Load Balancer | Edureka — YouTube

• Azure Application Gateway Deep dive | Step by step explained — YouTube

About the Author 👨‍💻

Hi, I’m Prince! I’m a DevOps engineer and Cloud architect passionate about building, deploying, and managing scalable applications and sharing knowledge with the tech community.

If you enjoyed this article, you can learn more about me by exploring more of my blogs and projects on my LinkedIn profile. You can find my LinkedIn articles here. You can also visit my website to read more of my articles as well. Let’s connect and grow together! 😊

A hypervisor is the software that lets you run multiple virtual machines on a single physical machine, and the Kernel-based Virtual Machine (KVM) is one of the best. Built into Linux, KVM is fast (near-native performance), open-source (free!), and flexible (supports Windows, Linux, and more). It’s trusted by both cloud providers and homelabbers for its stability and low overhead.

If you want to turn your Ubuntu 24.04 or Kubuntu 24.04 (Kubuntu is a Ubuntu variant with KDE Plasma desktop) system into a powerful hypervisor without Proxmox’s complexity, this guide is for you. With KVM, you’ll spin up virtual machines (VMs) in minutes, and with Cockpit’s web-based manager, you’ll control them from your browser.

In this tutorial, you’ll transform an Ubuntu 24.04 or Kubuntu 24.04 Desktop or Server – fresh or existing – into a KVM hypervisor. You’ll set up the backend (KVM, QEMU, libvirt), add Cockpit for web-based VM management, and create a guest VM to test it all. Whether you’re a coder, homelabber, or IT enthusiast, this guide is beginner-friendly.

Table of Contents

• Before You Start: What You Should Know

• What You’ll Need

• Why KVM on Ubuntu/Kubuntu 24.04?

• Step 1: Check Virtualization Support

• Step 2: Install KVM and Backend Tools

• Step 3: Set Up a Network Bridge

• Step 4: Install Cockpit for Web Management

• Step 5: Create a Guest VM

• Step 6: Run and Test Your Guest VM

• Keep Exploring Your Hypervisor

• Wrapping Up

Before You Start: What You Should Know

This guide is designed for virtualization newcomers, but you’ll need a few basic skills:

• Running terminal commands like sudo apt install or nano and so on.

• Basic Linux navigation (for example, editing files in /etc).

• Basic networking knowledge, such as understanding network interfaces (for example, enp4s0 or wlp3s0), IP addresses, and concepts like bridging or NAT. You’ll use tools like ip link or nmcli to set up a network bridge in Step 3.

• Optional: Experience with VMs helps but isn’t required – I’ll explain everything.

No worries if terms like “libvirt” sound new. I’ll break them down as we go.

What You’ll Need

• A computer: Running Ubuntu 24.04 or Kubuntu 24.04 Desktop or Server (fresh or existing). Minimum: 4GB RAM, 20GB storage, CPU with virtualization support (Intel VT-x or AMD-V). More RAM/storage for multiple VMs.

• Internet access: To download packages and VM ISOs.

• A web browser: Firefox (default on Ubuntu) or Chrome to access Cockpit.

• An ISO image: An ISO image for your guest VM (for example, Ubuntu 24.04 Desktop ISO from ubuntu.com or Windows ISO if you have it already).

• 30–45 minutes: Depending on your setup speed.

Why KVM on Ubuntu/Kubuntu 24.04?

KVM turns your Linux kernel into a hypervisor, letting you run VMs with near-native speed. Paired with QEMU (for hardware emulation) and libvirt (for management), it’s a lightweight alternative to Proxmox or VMware. Its strengths include:

• Performance: Runs VMs efficiently, ideal for homelabs or dev environments.

• Free and Open-Source: No licenses, just like Ubuntu/Kubuntu, and so on.

• Flexibility: Supports diverse guest OSs (Linux, Windows, BSD).

• Integration: Cockpit’s web UI makes VM management a breeze, no CLI required.

Here’s what each tool does:

• KVM: A Linux kernel module that turns your system into a hypervisor, enabling VMs to run with near-native performance by leveraging CPU virtualization features (for example, Intel VT-x).

• QEMU: A powerful emulator that provides the virtual hardware (for example, CPU, disk, network) for your VMs, working with KVM for fast execution.

• libvirt: A management layer that simplifies VM creation, networking, and storage, offering tools like virsh and APIs for automation.

• Cockpit: A web-based interface for managing VMs, system resources, and networks, perfect for beginners who want a visual dashboard.

Ubuntu 24.04 (“Noble Numbat”) brings the latest kernel and tools, ensuring top-notch KVM compatibility. Let’s build your hypervisor!

Step 1: Check Virtualization Support

First, you’ll want to confirm that your CPU supports virtualization (most modern ones do). To do that, open a terminal (like Konsole on Kubuntu) and run:

lscpu | grep Virtualization

Look for "VT-x" (Intel) or "AMD-V" (AMD). If present, you’re good!

If nothing shows, check your BIOS/UEFI:

• Reboot, enter BIOS (usually F2, Del, or Esc).

• Enable "Intel VT-x" or "AMD-V" under CPU settings.

• Save and reboot.

Step 2: Install KVM and Backend Tools

Let’s install KVM, QEMU, and libvirt. These will form the backbone of your hypervisor:

Start by updating your system (you may need to restart your computer after the update):

sudo apt update && sudo apt upgrade -y

Then install the virtualization packages:

sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils -y

• qemu-kvm: Emulates hardware for VMs.

• libvirt-daemon-system: Manages VMs.

• libvirt-clients: CLI tools like virsh for hypervisor management.

• bridge-utils: For network bridging.

Next, verify that KVM is loaded:

lsmod | grep kvm

You’ll see “kvm_intel” or “kvm_amd” if successful.

Finally, add your (current) user to the libvirt group for permission:

sudo usermod -aG libvirt $USER

Log out and back in to apply these changes.

Step 3: Set Up a Network Bridge

VMs need network access, so you’ll create a bridge (br0) to connect them to your physical network. This allows VMs to act like devices on your network (bridged networking).

Ubuntu 24.04 and Kubuntu 24.04 Desktop typically use NetworkManager, while Ubuntu Server may use Netplan. We’ll prioritize the NetworkManager approach, with Netplan as an alternative.

Note: Installing libvirt (Step 2) creates a default bridge called virbr0 for NAT-based networking, which isolates VMs from the physical network (IPs like 192.168.122.x). For direct network access (IPs like 192.168.0.x), use br0 as described below, and select it in Step 5’s VM setup.

You can verify whether your system is using NetworkManager or Netplan. Open a console and run systemctl status NetworkManager. If you see the status active and running, go with NetworkManager.

Option 1: NetworkManager (Recommended for Kubuntu/Ubuntu desktop)

Check your network interface:

ip link

Example: enp4s0. Replace enp4s0 below if yours differs.

First, find your Ethernet connection name:

nmcli connection show

Look for the NAME column where DEVICE is enp4s0 (for example, “Wired connection 1” or “Ethernet connection”). Note this name. Ignore virbr0, which is libvirt’s default NAT bridge.

Then create a bridge named br0:

sudo nmcli connection add type bridge ifname br0 con-name bridge-br0

Enslave your interface to the bridge:

sudo nmcli connection add type ethernet ifname enp4s0 master br0 con-name bridge-slave-enp4s0

Disable the old connection (replace with your connection name identified earlier):

sudo nmcli connection down "Wired connection 1"
sudo nmcli connection delete "Wired connection 1"

Enable DHCP on the bridge:

sudo nmcli connection modify bridge-br0 ipv4.method auto

Activate the bridge:

sudo nmcli connection up bridge-br0

Verify:

ip addr show br0
nmcli connection show

Now you’ll want to ensure br0 is active, enp4s0 is enslaved, and virbr0 is separate. First, test the internet with ping 8.8.8.8.

Then you need to define br0 in libvirt (to appear in Cockpit’s VM network dropdown). To do this, create br0.xml in your home directory:

nano ~/br0.xml

Then add the following:

<network>
  <name>br0</name>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>

Save and exit (Ctrl+O, Enter, Ctrl+X).

Now define and start the following:

sudo virsh net-define ~/br0.xml
sudo virsh net-start br0
sudo virsh net-autostart br0

Verify like this:

virsh net-list --all

You can now delete ~/br0.xml after defining, as libvirt stores it in /etc/libvirt/qemu/networks/.

rm ~/br0.xml

Option 2: Netplan (For Ubuntu Server or If Preferred)

If you see renderer: networkd in /etc/netplan/???.yaml or prefer Netplan, follow these steps.

First, check your interface:

ip link

Example: enp4s0.

Next, edit the Netplan config like so:

sudo nano /etc/netplan/01-netcfg.yaml

Use the following:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp4s0:
      dhcp4: no
  bridges:
    br0:
      interfaces: [enp4s0]
      dhcp4: yes

Save and exit (Ctrl+O, Enter, Ctrl+X).

Now, set strict permissions to avoid errors:

sudo chmod 600 /etc/netplan/01-netcfg.yaml

And apply:

sudo netplan apply

Now verify:

ip addr show br0

Test the internet with ping 8.8.8.8 (from console).

Troubleshooting:

• Permissions error: If Netplan complains about “too open” permissions, recheck sudo chmod 600 /etc/netplan/01-netcfg.yaml.

• NetworkManager conflict: If using Netplan, ensure /etc/netplan/01-network-manager-all.yaml is backed up or deleted (sudo mv /etc/netplan/01-network-manager-all.yaml /etc/netplan/01-network-manager-all.yaml.bak).

• No onternet: Restart NetworkManager (sudo systemctl restart NetworkManager) or reboot.

• Wrong bridge: If a VM uses virbr0 (NAT, 192.168.122.x), recheck Step 5’s network setting and select br0.

• br0 missing in Cockpit: Define br0 in libvirt (step 9 above) or ensure br0 is active (ip addr show br0).

Step 4: Install Cockpit for Web Management

Cockpit provides a slick web UI to manage VMs. Let’s go ahead and set it up.

First, you’ll need to install Cockpit and its VM plugin:

sudo apt install cockpit cockpit-machines -y

Then you can start and enable Cockpit:

sudo systemctl enable --now cockpit.socket
systemctl status cockpit.socket

Now open your browser (for example, Firefox on Ubuntu) and visit:

https://localhost:9090

Or use your KVM server’s IP (for example, https://192.168.0.100:9090) if remote. Log in with your username and password. Ignore the self-signed certificate warning.

Allow Cockpit’s port if you’re using a firewall:

sudo ufw allow 9090

You’ll see Cockpit’s dashboard. Turn on administrative access by clicking on “Turn on administrative access”. Then, click “Virtual Machines” to manage VMs.

Step 5: Create a Guest VM

Let’s create a guest VM using Cockpit. We’ll use an Ubuntu 24.04 Desktop ISO as an example:

To start, download the Ubuntu 24.04 Desktop ISO from ubuntu.com and save it (for example, /home/ranju/Downloads/ubuntu-24.04.1-desktop-amd64.iso).

In Cockpit, go to “Virtual Machines” and click “Create VM”. Here are the specs:

• Name: TestVM

• Installation Type: Local install media (or your desired installation type)

• Installation Source: Browse to your ISO (for example, /home/ranju/Downloads/ubuntu-24.04.1-desktop-amd64.iso).

• OS: Select “Ubuntu 24.04” (usually Cockpit auto-detects).

• Storage: Create new qcow2 volume (preferred). Note: disk is created in /var/lib/libvirt/images/.

• Storage limit: 20GB (adjust as needed).

• Memory: 4GB (adjust as needed).

Click “Create and Edit”. Cockpit opens an advanced dialog where there are options for customization (for example, CPU, Network Interfaces and Boot order, and so on). Make sure that br0 has been selected as interface source. Finally, click “Install”.

In Cockpit’s VM console, follow the installer to set up the guest OS (username, password, and so on).

Troubleshooting:

• Permissions error: If you have permission error for the ISO, then copy the ISO to the default temp folder (/tmp/) and locate the ISO from there.

    cp /home/ranju/Downloads/ubuntu-24.04.1.iso /tmp/
  

Step 6: Run and Test Your Guest VM

Your VM is running! Let’s test it:

1. In Cockpit, under “Virtual Machines,” click TestVM. You’ll see its console (a live view of the VM’s screen).

2. Log into the guest Ubuntu using the credentials you set.

3. Test networking:

   • Open a terminal in the VM (via Cockpit’s console).

   • Run ip addr in the console to confirm a physical network IP (for example, 192.168.0.x with br0, not 192.168.122.x with virbr0).

   • Run ping 8.8.8.8 to confirm internet access.

4. Experiment: Open a browser in the VM, visit a website, or install apps to simulate real use.

If the VM boots and connects to your network, your KVM hypervisor is rocking! You can stop, restart, or delete it from Cockpit.

Keep Exploring Your Hypervisor

You’ve turned your Ubuntu 24.04 into a KVM hypervisor – congrats! Try these next steps:

• Add more VMs: Create Windows or other Linux VMs using different ISOs.

• Use virt-manager: Install virt-manager for a desktop-based alternative to Cockpit (sudo apt install virt-manager).

• Back up VMs: Export VM disks with virsh for safety.

• Scale up: Add storage or RAM for heavier workloads, like my Proxmox cluster guide.

Check your VMs anytime via CLI:

virsh list --all

Wrapping Up

You’ve built a fast, free KVM hypervisor on Ubuntu 24.04, complete with Cockpit’s web UI and a running guest VM. It’s a perfect playground for coding, testing, or homelab fun.

Share your ideas or comments with me – I’d love to hear them!

In this guide, you'll learn about VM-specific risks for data and workloads. I'll also provide some recommendations that can help you mitigate them. Implementing these data protection best practices can help you ensure production continuity, data availability, and regulatory compliance for your organization.

Table of Contents

• Two of the Main Players: VMWare and Proxmox
• Understanding the Risks of Virtual Environments
• Specific Risks Associated with Virtual Environments
  • Hypervisor security vulnerabilities
  • VM sprawl
  • Insecure VM configurations
  • Snapshot and clone risks
• VM Data Protection and Secure Virtualization Best Practices
  • Secure the Virtualized Environment
  • Backup and Recovery Strategies
  • Monitoring and Auditing
• Advanced Protection Techniques
  • Encryption
  • Intrusion Detection and Prevention Systems (IDPS)
  • Application and Network Security

Two of the Main Players: VMWare and Proxmox

Both VMware and Proxmox offer robust solutions for virtualization, but they come with their own set of challenges and risks that can impact VM data protection.

VMware is the market leader in virtualization with almost 50% of the market share, which is both a boon and a bane.

On the one hand, VMware has a high-end, efficient portfolio of solutions to build IT environments of any complexity and size. On the other, such popularity means that malicious actors know what they can target during cyberattacks, posing challenges in virtualization security for VMware users.

Proxmox, a prominent alternative to VMware, also offers robust virtualization solutions. While Proxmox may have a smaller market share compared to VMware, it provides a comprehensive set of tools for managing virtual environments. It can also be a good choice for those looking for open-source solutions with flexibility and cost-efficiency.

Over three-quarters of organizations that have 50+ workers use server virtualization. So it's hard to overestimate the importance of the data that's circulating in their virtualized workloads.

The workloads themselves can be mission-critical and cause global disruption and downtime in case of failures. The data can also be crucial to run efficient services and generate revenue or be subject to compliance requirements.

Understanding the Risks of Virtual Environments

Before we proceed with VM security best practices, let’s go over some general security issues associated with virtual environments.

• Data breaches are a regular issue that most IT protection systems experience. A lone hacker or an organized cybercriminal group can intrude into corporate environments to steal data. Their targets are typically clients' personal data, credit card info, credentials, and intellectual property.

• Insider threats are usually the most underrated yet exceptionally dangerous issue. Malicious insiders sneakily strike from the inside of an organization’s security perimeter and may have advanced access privileges. This can lead to a global IT disaster, and preventing it is a high-level challenge.

• Malware and ransomware attacks are an ever-evolving threat for organizations of all sizes and types.

• System vulnerabilities and exploits. The supply chains of today’s IT services can be complicated and consist of multiple synchronized solutions. Every solution involved in service provisioning is a potential source of vulnerabilities that malicious actors can exploit upon discovery.

Specific Risks Associated with Virtual Environments

Understanding the risks of virtualization – particularly with VMware, one of the most popular virtualization platforms for enterprises, and Proxmox, which has seen increasing adoption in recent times – will help you and your team build an effective data protection system in your virtualized environments.

The unique threats associated with these platforms dictate how you should secure your virtual machines, servers, networks, and other virtualized nodes.

Key factors that can weaken virtualized infrastructure security include:

Hypervisor security vulnerabilities

• VMware: Because of its extensive use in enterprises, attackers frequently target VMware. Major issues can arise due to the integration and complexity of VMware's hypervisor. The "ESXiArgs" ransomware strain takes advantage of VMware vulnerabilities to infiltrate computers before the distribution of updates.

• Proxmox: While this open-source technology does have the potential for hypervisor vulnerabilities, the community can also provide security improvements such as timely patches, vulnerability reports, and enhancements to security protocols. Insufficiently managed upgrades or third-party modules can put Proxmox users at risk of security vulnerabilities.

VM sprawl

• VMWare: The ease of deploying VMs in VMware can lead to VM sprawl, where numerous virtual machines are created but not adequately managed. IT teams can create a virtual machine, for example, to test a new feature in an isolated environment before releasing it in production. If not deleted after completing the task, the new virtual machine can remain in an environment without attention, maintenance, or security updates.

• Proxmox: Proxmox's flexibility in managing virtual environments causes VM sprawl, which is more likely to affect smaller teams lacking strong monitoring. Its straightforward interface and streamlined deployment processes help to make creating and managing many virtual machines (VMs) a delight. While this helps with development and testing quickly, it can also cause an influx of virtual machines (VMs) to be launched without proper management or preparation.

Insecure VM configurations

• VMware: A VMWare virtual machine itself is a complex environment with multiple configurations and dependencies. Misconfiguration of VMware's resources, operating systems, or applications can lead to additional virtual desktop security risks.

• Proxmox: Users of Proxmox might also face security pitfalls due to misconfigured VMs, especially when utilizing custom templates or third-party integrations. Insufficient security settings can expose services and open ports, enabling unauthorized access.

Snapshot and clone risks

• Inappropriate VM snapshot retention and maintenance policies in both Proxmox and VMware environments can cause storage overload. Creating too many VM clones can eventually lead to RAM and CPU deficiencies. Insufficiency of hardware resources then causes performance degradation and disk failures, resulting in downtime and data loss.

VM Data Protection and Secure Virtualization Best Practices

Data loss in virtualized environments, such as VMWare or Proxmox, can lead to fines, financial losses, and reputational damage for an organization.

Below are some recommendations on how to improve VM data security for virtual nodes, clusters, and infrastructures. The tips cover both virtualization-specific risks and those common to IT security, providing valuable insights for managing data protection effectively in both VMware and Proxmox environments.

Secure the Virtualized Environment

For starters, you can strengthen your environment with regular VM security practices. Consider implementing the following:

Strong access controls and authentication mechanisms.

Role-based access control (RBAC) is an efficient security measure that ensures users have only the access and privileges required to fulfill job duties. With roles set for every employee, their accounts become less dangerous under unauthorized access in case of, for example, compromised credentials.

This can help you either completely counter a security breach attempt or at least significantly mitigate the consequences of a protection failure. Two-factor authentication (2FA) added on top of that purposely complicates the login process, making regular passwords insufficient to hack and exploit an account.

Regular updates and patch management

Set up regular update checks for solutions included in your supply chain. Installing updates and especially security patches on time means that your system closes known vulnerabilities. This reinforces the security perimeter and can protect your environment from random breaches and brute-force attacks, supporting secure virtualization.

Network segmentation and isolation

Combined with external protection reinforcement, segmenting your network using virtual routers, firewalls and switches can be efficient in isolating critical workloads and data from major threats.

A complex internal environment poses an additional challenge for hackers preparing their attacks. Also, if a network scan shows that the infrastructure is ramified and segmented, some bad actors may even conclude that an attack is not worth the effort.

Backup and Recovery Strategies

Backups are essential in building an efficient VM data protection system. When all else fails, a backup can help you restore critical data and workloads with little to no downtime.

An efficient VM backup and recovery system includes:

Regular and automated VM backups. To ensure minimal downtime, you need a backup with a “fresh” recovery point recorded. Given the complexity of even the smallest corporate virtualized environments, only automation and scheduling backups can ensure their regularity.

Offsite and cloud-based backup solutions. In addition to onsite backups, consider sending data copies to offsite and cloud repositories. This helps you avoid a single point of failure and keep up with the 3-2-1 backup rule.

In case your main infrastructure is down due to a disruption, offsite backups in two different destinations can remain recoverable and accessible.

Disaster recovery planning and testing. Virtualized environments can include hundreds and thousands of virtual machines, servers and clusters to provide stable and efficient services.

To minimize downtime after global failures, you need to plan disaster recovery (DR) sequences and test them regularly. Set up a scheduled testing workflow to ensure checks.

Also, you might want to conduct disaster recovery testing sessions every time you introduce changes into your main virtualized environment.

Advanced VM data protection solutions for secure virtualization, such as NAKIVO Backup & Replication, provide the set of features and functions required to implement the above-mentioned VM backup recommendations.

As a regular user of the NAKIVO solution, specifically for protecting virtualized environments, I’ve experienced firsthand the benefits of its robust features. I highly recommend taking advantage of the free version of this solution, which is available until the end of 2024.

Monitoring and Auditing

One of the most efficient VM data protection best practices for virtualized environments is to monitor resource usage, VM health, and behavior. This includes the following:

Continuous monitoring of virtualized environments. Sufficient hardware resources are crucial for production continuity in virtualized environments. You may want to keep track of infrastructures in general and mission-critical VMs in particular. Thus, you can know the current resource consumption and predict scaling needs and budgets to support system stability as your organization grows.

Audit trails and logging. Audit trails and logging help you get a sequential record of specific activities and data within systems and their components. This includes failed and successful logins, MAC addresses and IPs of involved devices, access locations, data transactions as well as VM and policy changes.

Anomaly detection and response. With monitoring and logging established and functioning, you can detect anomalies in the behavior of users and VMs, and resource consumption changes within system nodes. With such behavioral data, you can timely react to potential security threats.

Advanced Protection Techniques

Advanced threat protection tips for virtual machines describe techniques related to encryption, intrusion detection and prevention systems, and additional security of applications and networks. Let’s review every technique in detail.

Encryption

In a modern IT landscape where any user is able to download and use traffic interception tools, unencrypted data is most likely public data. To enhance your VM data protection for secure virtualization, you can ensure:

• Encrypting data at rest and in transit. Encrypt data during transmission (in flight) and throughout retention (at rest). Such all-round data encryption enables you to enhance protection from unauthorized access in most situations.

• Implementing secure key management. For additional security, consider setting up an encryption key management system. This includes regular generation, secure exchange, storage and use, timely destruction and replacement of encryption keys.

Intrusion Detection and Prevention Systems (IDPS)

Intrusion detection and prevention systems are designed to scan and monitor networks and automatically take action to counter possible breaches.

• Integrating IDPS with VMs. IDPS integration is about revealing the key nodes of your virtual environment and installing program “sensors” that track the situation around them. You can then count on software automation to take the first actions to counter possible intrusions as they occur.

• Real-time threat detection and response. Consider developing specialized workflows for responding to intrusions after the IDPS detects them and stops the most obvious malicious activities. Keep in mind that modern cyberattacks can involve a multi-layered series of smaller hits to distract and deceive the defenders.

Application and Network Security

In addition to supply chain control, network segmentation, and isolation, you can make your VM data protection system more reliable with additional app and network security enhancements. For instance, consider the following steps:

• Hardening VM applications. As apps can become weak links in your protection chain, consider hardening their protection. For example, remove unnecessary components and disable unwanted services that such applications might run. Also, you can set reliable passwords, regular code reviews and role-based access controls within apps.

• Implementing firewall and VPN solutions. These are additional VM data protection best practices that specifically harden networks. External and internal firewalls can prevent unauthorized access to system elements, while VPN connections ensure secure access for authorized users.

Future Trends in VM Data Protection

The future of secure virtualization mainly depends on the evolution of relevant threats. The popularity of virtualization solutions, such as VMWare and Proxmox, defines the close attention that hackers pay to VM vulnerabilities and specifics.

Malicious actors also shape their ransomware, interception, and intrusion tools to become more dangerous to virtualized IT infrastructure. Sophisticated malware enables deeply customized attacks that exploit the VM security weaknesses of the organization’s infrastructure.

The improvement of AI algorithms can bring additional challenges to the field, making malware spread faster, becoming less detectable, and targeting priority nodes with efficient strikes.

However, the same idea works for VM security best practices. AI-driven cyber defense solutions can help detect and counter specific threats in VM environments with significantly better performance and efficiency.

Advanced VM threat detection based on behavioral analysis throughout the entire infrastructure can help reveal malware earlier. Prevention tools independently reacting to potentially dangerous changes in an environment can enable quick response and counter cyberattacks right after they begin.

Lastly, AI can learn how to enhance protection flexibility and introduce defensive changes in an environment depending on how a cyberattack develops. The boosted speed and variety of cybersecurity moves then promote virtualized security (and data protection as a whole) to notably higher effectiveness levels.

Conclusion

Thorough VM security is crucial for any organization that's using virtualized IT environments. Consider implementing strong access controls, patch management, network segmentation, monitoring, auditing and app security to counter key threats and mitigate their outcomes.

You might also want to build an advanced Proxmox replication or VMware backup system to have a swift data recovery option in case of a breach or system failure.

So you’ve discovered the world of ethical hacking and you want to try your hands on something. Trouble is, doing some ‘practical application’ on the wrong thing could get you fined, arrested, and even undesired jail time.

You don’t have to give up your dreams just yet though. There is a legal, ethical way to sharpen your cyber offensive skills: Vulnerable Virtual Machines.

In this tutorial, we’ll take a look at the following:

1. What is a Virtual Machine?
2. What is Metasploitable?
3. How to Set Up Metasploitable
4. A Quick Word on Vulnerable VMs

So without further ado, let’s jump in.

What is a Virtual Machine?

Virtual Machines ¦ Credit: [Hackersarts](https://www.deviantart.com/hackersarts" rel="noopener noreferrer)

A Virtual Machine (VM) is an emulation of a computer system. Think of it like a mini disposable environment where you can play around with different operating systems and software.

On a VM, you can delete critical system files, test software, or even install a virus (not recommended), and nothing will happen to your actual system.

All this is made possible with a hypervisor, a software that takes some of your ‘host’ system’s hardware resources, and makes it available for the ‘guest’ machine. A hypervisor allows you to determine things like how much RAM, storage, and even screens (if you have multiple displays), you want to hand over to the VM.

There are 2 types of hypervisors, namely:

• Type 1 hypervisors
• Type 2 hypervisors

Mind blowing naming scheme, I know.

Type 1 hypervisors run directly on the physical host machine and have direct access to hardware resources. They tend to be used for servers and enterprise-level infrastructure. They are considered more efficient because of their direct access to the host resources. Examples of type 1 hypervisors include Microsoft Hyper-V and VMware ESXi.

Type 2 hypervisors, on the other hand, are installed on the host OS, and manages the hardware resources for the guest. You would find these on personal computers and they make hardware resource management pretty easy for the average user. Examples of type 2 hypervisors are Oracle VirtualBox (my personal favourite 😌) and VMware Workstation.

We’ll be using Oracle VirtualBox, a type 2 hypervisor, for simplicity (and because I don’t have a server randomly lying around the house). Now, let’s find an appropriate vulnerable VM to install.

What is Metasploitable?

A mere box ¦ Credit: [Rostislav Uzunov](https://www.pexels.com/@rostislav/" rel="noopener noreferrer)

Metasploitable is an ‘intentionally vulnerable virtual machine’ by Rapid7, owners of the popular security project, Metasploit. Note that Metasploitable and Metasploit are two different things entirely. The previous is a VM while the latter is a cyber offense tool (which may or may not be covered in a later article 😉).

VMs, much like any other computer, need to be as secure as possible. Metasploitable does the complete opposite. It comes out of the box with enough vulnerabilities to give the cybersecurity professionals at CYSED serious nightmares. The VM is a Linux-based system with various ports open, insecure configurations, and outdated software.

Now, let’s figure out how to install it securely on our systems.

How to Set Up Metasploitable

The metasploitable interface ¦ Credit: Author

Before we go further, you’re going to need a few things:

• An Internet Connection
• A Computer with at least 8 GB RAM and 20 GB free storage
• A flair to be an awesome geek

And with those boxes checked, let’s get started.

To download the VM, head over to Google and type in ‘Metasploitable download’. Click on the first link by SourceForge, and hit download. The file is about 800 megabytes so feel free to pull up an episode of Scooby-Doo while that’s downloading.

You should have a zip file like this once that is done:

The metasploitable zip file ¦ Credit: Author

Right-click and hit ‘Extract All…’ to get the VM Disk. You should see some files like this:

The zip file contents ¦ Credit: Author

We’re going to need VirtualBox to install our VM. You can quickly setup VirtualBox using this tutorial by Beau Carnes. To import Metasploitable, open VirtualBox and click on ‘New’. Set the following options:

Name: Metasploitable (or whatever you like)

Type: Linux

Version: Other Linux (64-bit)

You don't have to select an ISO image because the OS is already in the virtual hard disk which will be installed as we go along.

Setting up the VM ¦ Credit: Author

Click on ‘Next’, which should take you to the hardware section. As mentioned before, a VM is a simulation of the real system, which requires resources like RAM and a Processor. You can change the amount of RAM and logical processors your VM uses.

Keep in mind that the more resources you allocate to the VM, the less resources you have for your system.

On that note, I would suggest leaving the default hardware settings.

Deciding how much hardware we need ¦ Credit: Author

Quick lesson: Your system likely only has 1 physical processor but can have as many as 8 or more logical processors. This is because of something called hyperthreading, where a computer basically converts it’s physical cores into multiple smaller virtual ones. Now back to the tutorial.

Click ‘Next’ and you’ll be directed to the ‘Virtual Hard disk’ section. Normally, you’d create a virtual hard disk for your VM but we already have one.

Click on ‘Use an Existing Virtual Hard Disk File’ and hit ‘Add’ at the top right.

Selecting a Virtual hard disk ¦ Credit: Author

This will open up File Explorer, where you will proceed to select the ‘Metasploitable.vmdk’ file. Once that is done, Metasploitable should appear under the ‘Not Attached’ list.

Selecting the Metasploitable hard disk ¦ Credit: Author

Select it, hit ‘Choose’ and click on ‘Next’. You will be led to a ‘Summary’ section which will give you information about the VM before it is finally setup.

Putting in the final touches ¦ Credit: Author

Let’s finish it up by literally hitting ‘Finish’ and you should get a screen like so.

Metasploitable installed on VirtualBox ¦ Credit: Author

Congratulations on setting up Metasploitable 🎉. Now you can build your cybersecurity skills without risking a trip to your local prison 😉.

The credentials for the machine are msfadmin:msfadmin. Feel free to boot up your Kali machine, ping the machines, and start hacking. Here, I’ll give you a hint: It starts with ‘nmap’ 👁️.

A Quick Word on Vulnerable Machines

A network of sorts ¦ Credit: [AcatXIo](https://pixabay.com/users/acatxio-20233758/" rel="noopener noreferrer)

Just like a real system, a virtual machine is vulnerable to real world attacks. Try not to leave Metasploitable up when not in use and definitely do not expose it to an untrusted network.

By default, the VM is set to use NAT (Network Address Translation) which adds a layer of security by isolating it from the external network while providing it access to the internet.

However, this may not be a comprehensive solution. One common alternative is to change the network adapter settings to ‘Host-Only’, which shuts the VM off from the Internet but allows it to communicate with other VMs and the host.

If you’re wondering what the other options are, here is a quick summary for each:

• NAT: Shares host network, provides internet access to VM.
• Bridged Adapter: VM connects directly to the physical network.
• Internal Network: Isolated network for VMs on the same host.
• Host-Only Adapter: VMs communicate with host and among themselves.
• Generic Driver: Allows using custom, non-standard network drivers.
• NAT Network: Similar to NAT but allows defining network properties.
• Cloud Network: Experimental feature for cloud-based networking.
• Not Attached: No network connection for the virtual machine.

Conclusion

And now, let’s summarize what you’ve learned in this tutorial:

1. What a Virtual Machine is and how it works
2. What Metasploitable is
3. How to install Metasploitable and any other VM
4. What different network adapters do in VirtualBox

Playing with Metasploitable is a great way to practice offensive cybersecurity skills and the defensive if you want to try and patch it up. Vulnhub is a great place to download more virtual machines if you want to move beyond Metasploitable.

You could also use platforms like TryHackMe and HackTheBox which are gamified and make things more fun if you want something a little different.

Good luck and Happy Hacking 🙃

Resources

1. Learn more about Cybersecurity in Africa
2. The Metasploitable Exploitability Guide from Rapid7

Acknowledgements

Thanks to Anuoluwapo Victor, Chinaza Nwukwa, Holumidey Mercy, Favour Ojo, Georgina Awani, and my family for the inspiration, support and knowledge used to put this post together. You’re all amazing.

Cover image credit: Google DeepMind

And one of the most popular tools for working with containers is Docker.

Docker is both the name of the company (Docker Inc) and the software they have created which packages software into containers.

To understand how containers work and why they are incredibly useful for software development, you need to understand two seemingly unrelated topics – shipping containers and virtual machines.

A Brief History of Shipping Containers

"The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger" is a book by Marc Levinson. It explores the profound impact of the shipping container on global trade and the world economy.

While the history of the shipping container may seem irrelevant in a discussion about Docker containers, they have more in common than you would expect.

Before shipping containers, cargo handling was labor-intensive and time-consuming, leading to inefficiencies and delays in global trade. Cargo arrived in various shapes and sizes, and the lack of standardised packaging made it challenging to stack and secure items efficiently.

Without standardised containers, cargo was often stored haphazardly in the holds of ships or in dockyards. This inefficient use of space meant that ships were not carrying as much cargo as they could potentially hold, leading to higher transportation costs.

The adoption of uniform container dimensions and handling procedures allowed for seamless transfer of cargo between different modes of transportation – ships, trucks, trains, and the cranes used to move the containers around.

Image showing how standardised container sizes allow them to be easily moved between ships, trains and trucks.

This standardisation was the key to the success of shipping containers. After all, if one company’s containers didn't fit on another company's ship, truck, or freight train, they couldn't be properly transported. Every company would need its own fleet of containers to be able to send things to each of their customers – which would be an operational nightmare.

Standardisation of shipping containers makes them portable, that is easy to move from one place to another. This portability is a key feature of Docker containers as well, which we'll discuss shortly.

What are Virtual Machines?

Virtual machines (VMs) are created through a process called virtualisation.

Virtualisation is a technology that allows you to create multiple simulated environments or virtual versions of something, such as an operating system, a server, storage, or a network, on a single physical machine.

These virtual environments behave as if they are independent, separate entities, even though they share the resources of the underlying physical system.

Virtualisation is like having a magician's hat that can conjure up multiple hats within it. Just as the magician's hat creates the illusion of many hats appearing from just a single physical hat, virtualisation allows a single physical computer or server to appear as multiple virtual machines (VMs), each with its own operating system and resources.

VMs virtualise the hardware. This simply means that a VM takes a single piece of hardware – a server – and creates virtual versions of other servers running their own operating systems. Physically, it is just a single piece of hardware.

Logically, multiple virtual machines can run on top of a single piece of hardware. This is essentially one or more computers running within a computer, as shown below.

Image showing how virtualisation creates several virtual machines (VMs) from a single physical server

How does virtualisation work?

So you might be wondering – how exactly does virtualisation work? Have a look at the image below:

Image showing how virtualisation works by virtualising a single piece of hardware to create multiple virtual machines

At the base, you have the host hardware and OS. This is the physical machine that is used to create the virtual machines. On top of this, you have the hypervisor. This allows multiple virtual machines, each with their own operating systems (OS), to run on a single physical server.

VMs have a few downsides, though, which containers address. Two downsides particularly stand out:

1. VMs consume more resources: VMs have a higher resource overhead due to the need to run a full OS instance for each VM. This can lead to larger memory and storage consumption. This in turn can have a negative effect on performance and startup times of the virtual machine.

2. Portability: VMs are typically less portable due to differences in underlying OS environments. Moving VMs between different hypervisors or cloud providers can be more complex.

The major cloud providers all have VMs. For AWS, it's EC2, GCP has Compute Engine, and Azure has Azure Virtual Machines.

What are Containers?

A container is a lightweight, standalone, and executable software package that includes everything needed to run a piece of software, including the code, runtime, system tools, and libraries.

Containers are designed to isolate applications and their dependencies, ensuring that they can run consistently across different environments. Whether the application is running from your computer or in the cloud, the application behaviour remains the same.

Unlike VMs which virtualise the hardware, containers virtualise the operating system. This simply means that a container uses a single OS to create a virtual application and its libraries. Containers run on top of a shared OS provided by the host system.

This is illustrated below:

Image showing how containers works by virtualising the OS

The container engine allows you to spin up containers. It provides the tools and services necessary for building, running, and deploying containerised applications.

Containers have several benefits:

1. Portability: Containers are designed to be platform-independent. They can run on any system that supports the container runtime, such as Docker, regardless of the underlying operating system. This makes it easier to move applications between different environments, including local development machines, testing servers, and different cloud platforms.

2. Efficiency: Containers share the host system's operating system, which reduces the overhead of running a virtual machine with multiple operating systems. This leads to more efficient resource utilization and allows for a higher density of applications that can run on a single host.

3. Consistency: Containers package all the necessary components, including the application code, runtime, libraries, and dependencies, into a single unit. This eliminates the "it works on my machine" problem and ensures that the application runs consistently across different environments, from development to production.

4. Isolation: Containers provide a lightweight and isolated environment for running applications. Each container encapsulates the application and its dependencies, ensuring that they do not interfere with each other. This isolation helps prevent conflicts and ensures consistent behaviour across different environments.

5. Fast Deployment: Containers can be created and started quickly, often in a matter of seconds. This rapid deployment speed is particularly beneficial for applications that need to rapidly scale up or down based on demand.

What is Docker?

Now that we have covered VMs and containers, what exactly is Docker? Docker is simply a tool for creating and managing containers.

At its core, Docker has two concepts that are useful to understand: the Dockerfile and Docker Images.

A Dockerfile contains the set of instructions for building a Docker Image.

A Docker Image serves as a template for creating Docker containers. It contains all the necessary code, runtime, system tools, libraries, and settings required to run a software application.

So, a Dockerfile is used to build a Docker Image which is then used as the template for creating one or more Docker containers. This is illustrated below.

Image showing the steps to create a docker container. First you create the Dockerfile which is used to build the Docker Image which is finally used to run a Docker container

If this explanation still causes you to scratch your head, consider the following analogy using shipping containers.

Imagine you need to build multiple shipping containers to transport items all over the world. You start with a document listing out the requirements for your shipping container. This will contain information like the container dimensions, type of seals, door locking mechanisms, ventilation and refrigeration requirements (if you are shipping food that needs a temperature controlled environment, for example), and so on.

This requirement document will then be used to create a detailed template for the container which will include engineering drawings showing the dimensions and other specifications.

From this template, the physical containers will then be built. This single template can be used to build one or many physical containers which will all be identical and match the specifications in the container template.

This is illustrated below:

Image showing a shipping container analogue for docker containers

The Dockerfile is analogous to the requirements document, which simply has a set of instructions for building the container template.

The Docker Image is analogous to the container template, which details all the instructions needed for building the physical container.

Once created, Docker images are immutable, meaning they cannot be changed. If you need to make changes to an application, you need to modify the Dockerfile and create a new image. This immutability ensures consistency and reproducibility in application deployment.

And finally, the Docker container is analogous to the physical shipping container.

Bringing it Together

In summary, containers provide a portable and efficient way to package applications and their dependencies, ensuring consistency across various environments. The benefits they bring to software development is similar to the benefits brought to the global economy by the humble shipping container.

Portability

Shipping containers, through standardisation, ensure that any container, anywhere in the world, can be seamlessly used to move items across various modes of transportation – ships, trucks, trains and the cranes used to load them on and off different forms of transport.

Similarly, Docker containers allow for portability. They ensure that applications can run consistently across different environments, from development laptops to production servers, and across different cloud providers.

Increased Efficiency

With standard container sizes, the packing density of goods you can move increases. Now, you can squeeze more things into a single shipping container, compared to the days before the shipping container existed where you had cargo in non standard shapes and sizes stored haphazardly in the holds of ships or on dockyards. So, every ship, freight train or truck can carry more goods during every trip, making it cheaper to move goods around the world.

With Docker containers, better efficiency comes from the fact that containers share the host operating system, making them lightweight compared to VMs. This leads to rapid container startup times and less CPU, memory, and storage use.

Less resource utilisation also means that containers can increase the application density when compared to VMs. With containers, you can run more applications on the same hardware without a significant drop in performance.

To conclude, the shipping container by itself is not magical. After all, it is just a metal box. It is the standardisation of shipping containers which made them portable and a cheap and efficient way to move goods around the world.

In application development, containers benefit from standardisation in the same way. Containers provide a portable and efficient way to package applications and their dependencies, ensuring consistency across various environments.

But then Vagrant came along, a command-line or shell tool that generally works with Type 2 hypervisors. You use it to create and manage virtual machines. It is a powerful tool that can help simplify the setup and management of your development environment.

Vagrant can be really helpful if you work on a team or with multiple people. This is because it guarantees consistency in your development environment by ensuring that everyone utilizes the same environment, preventing compatibility issues.

This tutorial will guide you through the process of setting up a single Ubuntu Linux virtual machine with Vagrant and configuring a web server inside it.

Prerequisites for this tutorial include:

• A computer with at least 8GB of RAM

• Basic knowledge of the Linux operating system

Required Tools and Installation

• Oracle VirtualBox: Go to the Oracle VirtualBox website, find the version of VirtualBox that is compatible with your operating system, and follow the instructions to download and install it. Virtual Box will provide the virtual environment, while Vagrant will set it up and manage it.

• Vagrant: Visit the Vagrant website and follow the instructions to download and install the binary that is suitable for your operating system. In this tutorial, we'll be utilizing the open-source Vagrant binary.

To check if the installation was successful, launch your preferred command line tool and enter the following command to output the installed version number:

$ vagrant --version

How to Create a Development Environment with Vagrant

To create a Vagrant project, start by creating a new project directory in your preferred location for Vagrant configuration and related files.

$ mkdir vagrant-project && cd vagrant-project

Within this directory, create a new Vagrantfile. Vagrant uses the configuration in the Vagrantfile to build the VM. By default, Vagrant syncs the project directory where the Vagrantfile is initialized to /vagrant. This eliminates the need to worry about volumes for persisting data.

Vagrant uses the concept of boxes. Boxes are a complete base image of an operating system. The public vagrant box repository contains a list of possible boxes. Choosing a box that matches the operating system used in your production environment is good practice.

A Vagrant box has the name of the user or organization that created it and the box name user/boxname. To initialize the Vagrant configuration file with an Ubuntu box, run the command:

$ vagrant init ubuntu/trusty64

This generates a Vagrantfile with a Ubuntu/trusty64 box in the current directory. The Vagrantfile, which is written in Ruby, contains the kind of VM to be used and various additional commented options such as network, port forwarding, disc capacity, and so on to assist in configuring the development environment.

You can add the --minimal flag to the initialization command of the Vagrantfile to generate a Vagrantfile without any additional settings.

Open the Vagrantfile with any editor of your choice. I will use the Vim editor in this tutorial.

 $ vim Vagrantfile

Removing the informational comments and some advanced configurations will leave the file like this:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/xenial64"
    config.vm.network "forwarded_port", guest: 8000, host: 8000
    config.vm.provider "virtualbox" do |vb| vb.memory = "1024"
 end
  config.vm.provision :shell, path: "simple-node-project.sh", privileged: false
end

The simple-node-project.sh is a bash script that installs Node.js and Git, clones a project that creates a simple Node.js web server, and starts the server.

#!/bin/bash

 sudo apt-get update -y

 ## Git ##
 echo '###Installing Git..'
 sudo apt-get install git -y

 git clone https://github.com/Aijeyomah/simple-node-app.git

# Installing latest Node and npm version
 sudo apt-get install -y curl software-properties-common

# Add Node.js PPA
curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash -

# Install Node.js and npm
sudo apt-get install -y nodejs

# Verify installation
node -v
npm -v

echo "Node.js has been installed successfully."

# navigate to app directory and start app
cd simple-node-app
node index.js &

This Vagrant configuration sets up the following:

• ubuntu/trusty64 is specified as the virtual box base image

• Forwards port 8000 of the VM to port 8000 of the host machine.

• Allocates 1GB of memory to the VM

• Runs simple-node-project to provision the VM

• For the shell provisioner to run the script as a non-root user in a login shell, privileged is set to false

Save the Vagrantfile and start the virtual machine by running the following command:

$ vagrant up

The first time this command is run, it will download the latest version of the specified box, and it will configure and start the VM. This process might take some time, but when the Ubuntu box exists in the local machine the VM will start immediately.

Once the VM is running, you can access the web page by opening a web browser and navigating to http://localhost:8000. You should see the Hello World message page if everything was set up correctly.

How to Manage Vagrant

You can use Vagrant to manage the running virtual machine. Here are some useful Vagrant commands:

vagrant up: Launches the virtual machine and provisions it according to the settings in the Vagrantfile. This command will simply connect to the virtual machine if it is already running.

vagrant halt: Stops the virtual machine by delivering a shutdown signal to the guest operating system. This command is similar to shutting down a real computer.

vagrant reload: Restarts the virtual machine and re-provisions it depending on any changes in the Vagrantfile.

vagrant ssh: Connects to the virtual machine via SSH. This command is useful for accessing the command line interface of the virtual machine.

vagrant status: Shows the current status of the virtual machine, including whether it's running, stopped, or suspended.

vagrant destroy: Deletes the virtual machine and all associated resources. This command is useful for cleaning up your development environment.

Conclusion

In this article, we have learned how to utilize Vagrant to set up a reproducible and consistent development environment.

Using Vagrant can help you set up a virtual development environment that closely mimics your production environment. This allows you to test and develop your code in a consistent and isolated environment.

Both virtual machines and containers help replicate the development environment, and manage dependencies and configurations better. But there are certain differences you should be aware of that will help you choose a VM or a Docker container depending on the application.

Over the next few minutes, we'll go over how virtual machines and Docker containers work, and then summarize the key differences between the two.

Let's begin!

Challenges in Application Development and Deployment

When you work as part of a development team, each application requires installation of multiple third-party software and packages. In order to collaborate and work together, every developer on the team should configure their local development environment.

However, setting up the development environment is a tedious process. The installation steps can be potentially different depending on the operating system and system configuration. Even during deployment, you have to configure the same environment on the server.

Different applications also require multiple versions of a specific software, say, PostgreSQL. In such cases, managing dependencies across applications becomes difficult.

To address the above challenges, it really helps if the applications run in isolated environments that you can replicate easily—independent of the system configuration. Both Virtual Machines (VMs) and Docker containers help you achieve this. Let's learn how!

How Does a Virtual Machine Work?

A Virtual Machine or VM is the emulation of a physical computer inside a host machine.

How a VM works (image by the author)

Running on top of the host operating system is a piece of software called a hypervisor that controls the VM instances. Each VM instance has its own guest operating system. The applications run inside this isolated environment.

You can have multiple VMs, each running a different application on a different operating system.

How Does a Docker Container Work?

Recently, container technology has revolutionized the software development process and the way development and operation teams work together. With time, Docker has become the go-to choice for containerizing applications.

Dockers containers are analogous to physical containers that you can use to store, package, and transport goods. But instead of tangible goods, they’re containers for software applications. 🙂

A docker container is a portable unit of software—that has the application—along with the associated dependency and configuration.

How containers work (image by the author)

Unlike a VM, Docker containers do not boot up their own guest OS. Rather, they run on top of the host operating system. This is facilitated by a container engine.

Docker vs VM – A Comprehensive Comparison

1️⃣ Virtualization

From our understanding thus far, both virtual machines and Docker containers provide isolated environments to run applications. The key difference between the two is in how they facilitate this isolation.

Recall that a VM boots up its own guest OS. Therefore, it virtualizes both the operating system kernel and the application layer.

A Docker container virtualizes only the application layer, and runs on top of the host operating system.

Container vs VM (image by the author)

2️⃣ Compatibility

A virtual machine uses its own operating system and is independent of the host operating system that it’s running on. Therefore, a VM is compatible with all operating systems.

A Docker container, on the other hand, is compatible with any Linux distribution. You may run into some problems running Docker on a Windows machine or an older Mac.

3️⃣ Size

A Docker image is lightweight and is typically in the order of kilobytes.

💡 Note: A Docker image denotes the artifact containing the application, its associated dependencies, and configuration. A running instance of the Docker image is called a container.

A VM instance can be as large as a few gigabytes or even terabytes.

4️⃣ Performance

In terms of performance, Docker containers provide near-native performance. Because they are lightweight, you can start them in a few milliseconds.

Starting a VM is equivalent to setting up a standalone machine inside your computer. It can take as long as a few minutes to start a VM instance.

5️⃣ Security

Docker containers run on top of the host operating system. Therefore, if the host OS is susceptible to security vulnerabilities, so are the Docker containers.

Virtual machines, on the other hand, boot up their own operating system, and are more secure. Recall: each virtual machine is a fully blown machine running inside another. If you have stringent security constraints to be met for sensitive applications, you should consider using a virtual machine instead.

6️⃣ Replicability

The next factor we'll consider is the ease with which you can replicate the isolated environments provided by VMs and containers. We can infer the ease of replicability from our earlier discussions on size and performance.

When there are multiple applications, each of which should run on a VM instance, using VMs can be inefficient and resource intensive. Docker containers, by virtue of being lightweight and performant, are preferred when you need to run multiple applications. ✅

Summing Up

I hope this tutorial helped you understand how Docker containers and VMs work, and the key differences between the two.

Here's a summary of what you've learned:

Thank you for reading this far. See you all soon in another tutorial! 😄

If you have an Android phone, one of your guilty pleasures might be playing some very entertaining games. Or it could be that there is an application that only runs on your phone.

And then you think – what if you could run the same games on your desktop PC?

To simplify the scenario, let's assume the applications run on Android.

One approach to solve your problem is to run an Android emulator on your PC. But some of them, like Android-x86, require rebooting your machine so they can take control of the hardware.

If you don't mind a small performance hit you can run a virtual machine at the same time as your native operating system. Specifically on Linux, there are several choices, like QEMU and VirtualBox, to name a few.

By the end of this article you will be able to do the following:

• Install VirtualBox on Fedora Linux

• Run android-x86 and finish the basic setup

• Install an application from the Google Play Store, just like on your phone.

Basic Requirements

Before you start, I assume that you have the following:

• Ability to run commands as the superuser (like SUDO)

• An account on Google.com, so you can use the Play store from within the virtual machine.

How to Install VirtualBox

The first step is to install VirtualBox. For practical purposes, our installation will be basic, just enough to run our games:

sudo dnf install -y kernel-devel kernel-devel-5.14.18-100.fc33.x86_64
curl --remote-name --location https://www.virtualbox.org/download/oracle_vbox.asc
sudo rpm --import ./oracle_vbox.asc
sudo dnf install -y https://download.virtualbox.org/virtualbox/6.1.36/VirtualBox-6.1-6.1.36_152435_fedora33-1.x86_64.rpm
sudo dnf install -y virtualbox-guest-additions.x86_64
sudo /sbin/vboxconfig

How to Install the Android-x86 ISO

The first step is to download the ISO image from Android-x86. This ISO contains the Android operating system that will be installed on our virtual hard drive.

After that we can set up our virtual machine like this:

How a finished virtual machine looks like on VirtualBox

A few things to note:

• After booting the first time, I found that 1GB for the Android image was not enough. Performance improved a lot after I bumped the ram to 3GB.

• Another change was the 'Graphics Controller'. Originally it was VMSVGA but then Android refused to start in graphic mode, so I switched to VboxVGA and it worked.

• 2 CPUS and 8GB of disk space were enough for my game.

• Finally, I specified that the IDE controller was the android-x86 ISO.

To start the virtual machine, you click the 'Start' button on the GUI, and then you will have to make a few decisions like bootable partition:

Partitioning your virtual disk. We assign 8 GB and make sure the partition can boot

Once this is done you can choose your new partition to perform the installation:

After the new partition is created, you can choose it and you can install the Android OS there

Then the installation will proceed:

The installer copies the files from the Android ISO image into the virtual hard drive

After the installation is complete, you can shut down the virtual machine.

First Boot

Now you'll need to go to the advanced options and select the virtual disk (instead of the ISO image) to boot:

You can either boot from disk on this menu or change the boot order on the virtual machine

After that, Android will ask you some basic setup information, just like it does on your phone. The final result may look like this:

The virtual machine looks exactly like your Android phone.

How to Install Games from the Google Play Store

In my case I decided to install a game where I can fight forces of evil as 1970 Mazinger Z/ Tranzor Z (Yes, I love Go Nagai Mazinger Z). To do that, search on the play store and install the game:

After Android is running and your credentials are set you can download and install any Android program you want.

And now, success! We got the game up and running.

Sorry, but now it is time to play as Mazinger Z!

What Did We Learn Here?

• We managed to install a virtual machine engine and successfully run the Android operating system along with our regular Fedora OS

• You saw how you can try and discard whole operating systems' setup, without going through the hassle of setting up a dual boot system with Grub on Linux

Another nice feature of running the game inside a virtual machine is that you can fully freeze the game, then come back and restore it at exactly the same point where you left it.

Finally, you can do many more things with a virtual machine than just running games, for example:

• You can analyze malware safely, run un-trusted applications, and contain any damage they can cause.

• Try a new operating system version before deciding to commit a proper installation (not a big issue these days as most of them provide a lice CD you can boot to try), but this is still very convenient.

• Be able to run multiple operating systems simultaneously, without rebooting your machine. You most likely will start trying more advanced options of your virtual machine of choice, like VirtualBox.

Playing games on your PC is a gateway for learning more complex stuff later. Also the fun factor is undeniable. Enjoy!

Whether you have used Java to develop programs or not, you might have heard about the Java Virtual Machine (JVM) at some point or another.

JVM is the core of the Java ecosystem, and makes it possible for Java-based software programs to follow the "write once, run anywhere" approach. You can write Java code on one machine, and run it on any other machine using the JVM.

JVM was initially designed to support only Java. However, over the time, many other languages such as Scala, Kotlin and Groovy were adopted on the Java platform. All of these languages are collectively known as JVM languages.

In this article, we will learn more about the JVM, how it works, and the various components that it is made of.

#What is a Virtual Machine?

Before we jump into the JVM, let's revisit the concept of a Virtual Machine (VM).

A virtual machine is a virtual representation of a physical computer. We can call the virtual machine the guest machine, and the physical computer it runs on is the host machine.

A single physical machine can run multiple virtual machines, each with their own operating system and applications. These virtual machines are isolated from each other.

#What is the Java Virtual Machine?

In programming languages like C and C++, the code is first compiled into platform-specific machine code. These languages are called compiled languages.

On the other hand, in languages like JavaScript and Python, the computer executes the instructions directly without having to compile them. These languages are called interpreted languages.

Java uses a combination of both techniques. Java code is first compiled into byte code to generate a class file. This class file is then interpreted by the Java Virtual Machine for the underlying platform. The same class file can be executed on any version of JVM running on any platform and operating system.

Similar to virtual machines, the JVM creates an isolated space on a host machine. This space can be used to execute Java programs irrespective of the platform or operating system of the machine.

#Java Virtual Machine Architecture

The JVM consists of three distinct components:

1. Class Loader
2. Runtime Memory/Data Area
3. Execution Engine

Let's take a look at each of them in more detail.

Class Loader

When you compile a .java source file, it is converted into byte code as a .class file. When you try to use this class in your program, the class loader loads it into the main memory.

The first class to be loaded into memory is usually the class that contains the main() method.

There are three phases in the class loading process: loading, linking, and initialization.

Loading

Loading involves taking the binary representation (bytecode) of a class or interface with a particular name, and generating the original class or interface from that.

There are three built-in class loaders available in Java:

• Bootstrap Class Loader - This is the root class loader. It is the superclass of Extension Class Loader and loads the standard Java packages like java.lang, java.net, java.util, java.io, and so on. These packages are present inside the rt.jar file and other core libraries present in the $JAVA_HOME/jre/lib directory.
• Extension Class Loader - This is the subclass of the Bootstrap Class Loader and the superclass of the Application Class Loader. This loads the extensions of standard Java libraries which are present in the $JAVA_HOME/jre/lib/ext directory.
• Application Class Loader - This is the final class loader and the subclass of Extension Class Loader. It loads the files present on the classpath. By default, the classpath is set to the current directory of the application. The classpath can also be modified by adding the -classpath or -cp command line option.

The JVM uses the ClassLoader.loadClass() method for loading the class into memory. It tries to load the class based on a fully qualified name.

If a parent class loader is unable to find a class, it delegates the work to a child class loader. If the last child class loader isn't able to load the class either, it throws NoClassDefFoundError or ClassNotFoundException.

Linking

After a class is loaded into memory, it undergoes the linking process. Linking a class or interface involves combining the different elements and dependencies of the program together.

Linking includes the following steps:

Verification: This phase checks the structural correctness of the .class file by checking it against a set of constraints or rules. If verification fails for some reason, we get a VerifyException.

For example, if the code has been built using Java 11, but is being run on a system that has Java 8 installed, the verification phase will fail.

Preparation: In this phase, the JVM allocates memory for the static fields of a class or interface, and initializes them with default values.

For example, assume that you have declared the following variable in your class:

private static final boolean enabled = true;

During the preparation phase, JVM allocates memory for the variable enabled and sets its value to the default value for a boolean, which is false.

Resolution: In this phase, symbolic references are replaced with direct references present in the runtime constant pool.

For example, if you have references to other classes or constant variables present in other classes, they are resolved in this phase and replaced with their actual references.

Initialization

Initialization involves executing the initialization method of the class or interface (known as <clinit>). This can include calling the class's constructor, executing the static block, and assigning values to all the static variables. This is the final stage of class loading.

For example, when we declared the following code earlier:

private static final boolean enabled = true;

The variable enabled was set to its default value of false during the preparation phase. In the initialization phase, this variable is assigned its actual value of true.

Note: the JVM is multi-threaded. It can happen that multiple threads are trying to initialize the same class at the same time. This can lead to concurrency issues. You need to handle thread safety to ensure that the program works properly in a multi-threaded environment.

Runtime Data Area

There are five components inside the runtime data area:

Let's look at each one individually.

Method Area

All the class level data such as the run-time constant pool, field, and method data, and the code for methods and constructors, are stored here.

If the memory available in the method area is not sufficient for the program startup, the JVM throws an OutOfMemoryError.

For example, assume that you have the following class definition:

public class Employee {

  private String name;
  private int age;

  public Employee(String name, int age) {

    this.name = name;
    this.age = age;
  }
}

In this code example, the field level data such as name and age and the constructor details are loaded into the method area.

The method area is created on the virtual machine start-up, and there is only one method area per JVM.

Heap Area

All the objects and their corresponding instance variables are stored here. This is the run-time data area from which memory for all class instances and arrays is allocated.

For example assume that you are declaring the following instance:

Employee employee = new Employee();

In this code example, an instance of Employee is created and loaded into the heap area.

The heap is created on the virtual machine start-up, and there is only one heap area per JVM.

Note: Since the Method and Heap areas share the same memory for multiple threads, the data stored here is not thread safe.

Stack Area

Whenever a new thread is created in the JVM, a separate runtime stack is also created at the same time. All local variables, method calls, and partial results are stored in the stack area.

If the processing being done in a thread requires a larger stack size than what's available, the JVM throws a StackOverflowError.

For every method call, one entry is made in the stack memory which is called the Stack Frame. When the method call is complete, the Stack Frame is destroyed.

The Stack Frame is divided into three sub-parts:

• Local Variables – Each frame contains an array of variables known as its local variables. All local variables and their values are stored here. The length of this array is determined at compile-time.
• Operand Stack – Each frame contains a last-in-first-out (LIFO) stack known as its operand stack. This acts as a runtime workspace to perform any intermediate operations. The maximum depth of this stack is determined at compile-time.
• Frame Data – All symbols corresponding to the method are stored here. This also stores the catch block information in case of exceptions.

For example assume that you have the following code:

double calculateNormalisedScore(List<Answer> answers) {

  double score = getScore(answers);
  return normalizeScore(score);
}

double normalizeScore(double score) {

  return (score – minScore) / (maxScore – minScore);
}

In this code example, variables like answers and score are placed in the Local Variables array. The Operand Stack contains the variables and operators required to perform the mathematical calculations of subtraction and division.

Note: Since the Stack Area is not shared, it is inherently thread safe.

Program Counter (PC) Registers

The JVM supports multiple threads at the same time. Each thread has its own PC Register to hold the address of the currently executing JVM instruction. Once the instruction is executed, the PC register is updated with the next instruction.

Native Method Stacks

The JVM contains stacks that support native methods. These methods are written in a language other than the Java, such as C and C++. For every new thread, a separate native method stack is also allocated.

Execution Engine

Once the bytecode has been loaded into the main memory, and details are available in the runtime data area, the next step is to run the program. The Execution Engine handles this by executing the code present in each class.

However, before executing the program, the bytecode needs to be converted into machine language instructions. The JVM can use an interpreter or a JIT compiler for the execution engine.

Interpreter

The interpreter reads and executes the bytecode instructions line by line. Due to the line by line execution, the interpreter is comparatively slower.

Another disadvantage of the interpreter is that when a method is called multiple times, every time a new interpretation is required.

JIT Compiler

The JIT Compiler overcomes the disadvantage of the interpreter. The Execution Engine first uses the interpreter to execute the byte code, but when it finds some repeated code, it uses the JIT compiler.

The JIT compiler then compiles the entire bytecode and changes it to native machine code. This native machine code is used directly for repeated method calls, which improves the performance of the system.

The JIT Compiler has the following components:

1. Intermediate Code Generator - generates intermediate code
2. Code Optimizer - optimizes the intermediate code for better performance
3. Target Code Generator - converts intermediate code to native machine code
4. Profiler - finds the hotspots (code that is executed repeatedly)

To better understand the difference between interpreter and JIT compiler, assume that you have the following code:

int sum = 10;
for(int i = 0 ; i <= 10; i++) {
   sum += i;
}
System.out.println(sum);

An interpreter will fetch the value of sum from memory for each iteration in the loop, add the value of i to it, and write it back to memory. This is a costly operation because it is accessing the memory each time it enters the loop.

However, the JIT compiler will recognize that this code has a HotSpot, and will perform optimizations on it. It will store a local copy of sum in the PC register for the thread and will keep adding the value of i to it in the loop. Once the loop is complete, it will write the value of sum back to memory.

Note: a JIT compiler takes more time to compile the code than for the interpreter to interpret the code line by line. If you are going to run a program only once, using the interpreter is better.

Garbage Collector

The Garbage Collector (GC) collects and removes unreferenced objects from the heap area. It is the process of reclaiming the runtime unused memory automatically by destroying them.

Garbage collection makes Java memory efficient because because it removes the unreferenced objects from heap memory and makes free space for new objects. It involves two phases:

1. Mark - in this step, the GC identifies the unused objects in memory
2. Sweep - in this step, the GC removes the objects identified during the previous phase

Garbage Collections is done automatically by the JVM at regular intervals and does not need to be handled separately. It can also be triggered by calling System.gc(), but the execution is not guaranteed.

The JVM contains 3 different types of garbage collectors:

1. Serial GC - This is the simplest implementation of GC, and is designed for small applications running on single-threaded environments. It uses a single thread for garbage collection. When it runs, it leads to a "stop the world" event where the entire application is paused. The JVM argument to use Serial Garbage Collector is -XX:+UseSerialGC
2. Parallel GC - This is the default implementation of GC in the JVM, and is also known as Throughput Collector. It uses multiple threads for garbage collection, but still pauses the application when running. The JVM argument to use Parallel Garbage Collector is -XX:+UseParallelGC.
3. Garbage First (G1) GC - G1GC was designed for multi-threaded applications that have a large heap size available (more than 4GB). It partitions the heap into a set of equal size regions, and uses multiple threads to scan them. G1GC identifies the regions with the most garbage and performs garbage collection on that region first. The JVM argument to use G1 Garbage Collector is -XX:+UseG1GC

Note: There is another type of garbage collector called Concurrent Mark Sweep (CMS) GC. However, it has been deprecated since Java 9 and completely removed in Java 14 in favour of G1GC.

Java Native Interface (JNI)

At times, it is necessary to use native (non-Java) code (for example, C/C++). This can be in cases where we need to interact with hardware, or to overcome the memory management and performance constraints in Java. Java supports the execution of native code via the Java Native Interface (JNI).

JNI acts as a bridge for permitting the supporting packages for other programming languages such as C, C++, and so on. This is especially helpful in cases where you need to write code that is not entirely supported by Java, like some platform specific features that can only be written in C.

You can use the native keyword to indicate that the method implementation will be provided by a native library. You will also need to invoke System.loadLibrary() to load the shared native library into memory, and make its functions available to Java.

Native Method Libraries

Native Method Libraries are libraries that are written in other programming languages, such as C, C++, and assembly. These libraries are usually present in the form of .dll or .so files. These native libraries can be loaded through JNI.

#Common JVM Errors

• ClassNotFoundExcecption - This occurs when the Class Loader is trying to load classes using Class.forName(), ClassLoader.loadClass() or ClassLoader.findSystemClass() but no definition for the class with the specified name is found.
• NoClassDefFoundError - This occurs when a compiler has successfully compiled the class, but the Class Loader is not able to locate the class file at the runtime.
• OutOfMemoryError - This occurs when the JVM cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.
• StackOverflowError - This occurs if the JVM runs out of space while creating new stack frames while processing a thread.

#Conclusion

In this article, we discussed the Java Virtual Machine's architecture and its various components. Often we do not dig deep into the internal mechanics of the JVM or care about how it works while our code is working.

It is only when something goes wrong, and we need to tweak the JVM or fix a memory leak, that we try to understand its internal mechanics.

This is also a very popular interview question, both at junior and senior levels for backend roles. A deep understanding of the JVM helps you write better code and avoid pitfalls related to stack and memory errors.

Thank you for staying with me so far. Hope you liked the article. You can connect with me on LinkedIn where I regularly discuss technology and life. Also take a look at some of my other articles and my YouTube channel. Happy reading. 🙂

Google Cloud offers many tools and services. One of these services is creating highly customizable virtual machines. If you are not familiar with what a virtual machine is, here is a definition from Microsoft:

A virtual machine is a computer file, typically called an image, that behaves like an actual computer. In other words, creating a computer within a computer. It runs in a window, much like any other program, giving the end user the same experience on a virtual machine as they would have on the host operating system itself. The virtual machine is sandboxed from the rest of the system, meaning that the software inside a virtual machine can’t escape or tamper with the computer itself.

Virtual machines are needed in many situations to test applications against other operating systems, to access virus-infected data, or to experiment with other operating systems. You can install virtual machines on your computer. You can also create them in the cloud and simply connect to them.

In this tutorial, I will walk you through how to create a virtual machine in Google Cloud. We can connect to it with SSH from your computer.

1. If you don’t have one already, create a Google Cloud account from here.

You will get $300 credit to play around with for a year! It is more than enough to learn and play with everything Google Cloud offers.

2. Create a new project or use an existing one. You can create a new project called project1, for example, as in the following gif:

3. Now you are set to create a virtual machine. Go to the top left corner of your Google Cloud home page, click on the triple bar icon ≡ and select Compute Engine ->VM instance and click Create.

Enter whatever name you want in the Name field as shown below:

Keep the default region and zone. Any region/zone will do for this tutorial. If you are curious about what they mean, you can read Google Cloud’s documentation about them here.

You can keep default machine type or click Customize to select the number of CPU cores, memory, and GPUs you would like your virtual machine to have. You will see the cost on the right side changes!

For your first experiments with Google Cloud, you can be conservative with the $300 credit for some actual work. In such a case, you can choose the following configuration:

Next choose a boot disk. For example, you can choose 20 GB, SSD, Ubuntu 16.04 LTS as shown below:

Then set the Service Account under Identity and API access to No service account as shown below:

Finally, go to the Security tab under Firewall. You will see an SSH Key field as shown below:

This where you are going to connect your computer to the virtual machine using your SSH Key!

If you are not familiar with SSH (Secure Shell) and why you may want to use it, it is a network protocol that provides encrypted data communication between two computers (your computer and Google’s servers, in this case) which are connected over an insecure network (the Internet here).

To establish an SSH connection, you may need an application that can do that, depending on your operating system. Follow the rest of this post depending on your operating system (Windows or Mac/Linux).

Windows

I recommend PuTTY. It is an open-source and easy to use SSH client. You can download PuTTY and install it from here.

After installing PuTTY, open PuTTY Key Generator and click create. It will generate a random key by you moving the mouse over the blank area. After it is done, you will get something like this:

Change the key comment field to something recognizable and easy to type, as this will become a user name later!

Then save both the public and private keys by clicking the corresponding icons shown in the picture above.

Highlight the whole Key field from the PuTTY Key Generator, and copy and paste it in the key data field in Google Cloud:

Click create and wait for the virtual machine instance to be created.

In the meantime, you can go to PuTTY. Go to SSH ->Auth and browse for the private key file that you saved.

Next, go to Google Cloud and copy the external IP from the virtual machine instance that you just created as shown below:

And paste it on the Host field under Sessions in PuTTY and hit Enter:

Note: you might get an error message. Ignore it and click yes. (It just says the key is not already in the registry. Are you sure you want to connect?)

Then enter the username you created when generating the key (key comment above). Boom! you are in the virtual machine that you just created.

You can install python and Google APIs on it, for example, to start making some magic! Don’t forget to shut it down in Google Cloud after you are done to be economic with your credit :)

Mac/Linux

Mac and Linux support SSH connection natively. You just need to generate an SSH key pair (public key/private key) to connect securely to the virtual machine.

The private key is equivalent to a password. Thus, it is kept private, residing on your computer, and should not be shared with any entity. The public key is shared with the computer or server to which you want to establish the connection. To generate the SSH key pair to connect securely to the virtual machine, follow these steps:

Enter the following command in Terminal: ssh-keygen -t rsa . It will start the key generation process. You will be prompted to choose the location to store the SSH key pair. Press ENTER to accept the default location as shown below:

Next, choose a password for your login to the virtual machine or hit ENTER if you wish not to use a password. The private key (i.e. identification) and the public key will be generated as shown below:

Now run the following command: cat ~/.ssh/id_rsa.pub . It will display the public key in the terminal as shown below. Highlight and copy this key:

and paste it in the SSH key field in Google Cloud and hit Create:

Now you can use the External IP of the virtual machine you just created:

to ssh to it as follows:

You will get “The authenticity of host…etc.” warning as shown in the picture below. This is normal. Whenever SSH connects to a system it hasn’t seen before, it will generate a warning like this. Reply yes to connect, and bingo! You are in the virtual machine, as you can see from host name instance-3. To exit the virtual machine, just type exit.

Don’t forget to shut the virtual machine in Google Cloud after you are done to save that $300 credit!

Originally published at assawiel.com/blog on December 23, 2017. Updated: Oct 10, 2018