The basement is now doing two jobs at once: studio and server host. The studio is intentionally simple, just a green screen wall and a demo table, because the focus is repeatable technical demonstrations across multiple industry verticals. Right behind that space is the local compute footprint that powers the demos.

This buildout now includes two custom Tenstorrent server paths mixed into my existing NVIDIA-enabled and general-purpose server stack. The point is not to build isolated one-off demos, but to create a reusable local platform that can be switched between demo scenarios with minimal rework.

The broader architecture is hybrid by design. I want the same local inference flow to run with multiple cloud providers, plus a purely local mode when needed. That gives us a practical way to show customers and internal teams what edge-first compute can do, and where cloud orchestration adds value.

Terminology Rule

• Private Cloud means self-hosted infrastructure in my server room.
• Local means local-only execution paths and equivalent services running in Kubernetes.
• This write-up consistently uses Private Cloud or Local terminology based on context.

Private Cloud Topology

flowchart LR
  subgraph Studio["Studio Room"]
    CamA["Camera A"]
    CamB["Camera B"]
    WinRTSP["Windows RTSP Host"]
  end

  subgraph Server["Private Cloud Server Room"]
    TrueNAS["TrueNAS Storage Host"]
    TT["Tenstorrent Servers (Wormhole + Blackhole)"]
    Nvidia["NVIDIA Servers"]
    Proxmox["Proxmox Hosts"]

    subgraph K8sA["Kubernetes Edge Cluster"]
      Ingest["RTSP Ingest Service"]
      Broker["Message Broker"]
      Runtime["Unified Edge Inference Runtime"]
      Flows["Event Processing Pipeline"]
      ObsEdge["Edge Observability"]
    end
  end

  CamA -- "RTSP" --> WinRTSP
  CamB -- "RTSP" --> WinRTSP
  WinRTSP -- "RTSP relay" --> Ingest
  Ingest -- "frame topics" --> Broker
  Broker -- "frame contracts" --> Runtime
  Runtime -- "detections/traffic" --> Flows
  Runtime -- "health" --> ObsEdge

  TT --> Runtime
  Nvidia --> Runtime
  Proxmox -- "hosts cluster nodes" --> Runtime
  TrueNAS --> Ingest
  TrueNAS --> Flows

Azure Integration View

flowchart LR
  subgraph Edge["Private Cloud Edge Runtime"]
    Ingest["RTSP Ingest Service"]
    Runtime["Unified Edge Inference Runtime"]
    Package["Event Packaging + Thresholding"]
  end

  subgraph Azure["Azure Platform"]
    MQTT["IoT Operations MQTT Broker"]
    Flows["IoT Operations Data Flows"]
    Hot["Hot Path Stream Processing"]
    Alerts["Alert Rules + Notifications"]
    Fabric["Fabric Eventstream"]
    Foundry["Microsoft Foundry Endpoint"]
    subgraph Cold["Cold Path (Medallion Architecture)"]
      Bronze["Bronze Lakehouse"]
      Silver["Silver Lakehouse"]
      Gold["Gold Lakehouse"]
    end
    PBI["Power BI Dashboard"]
  end

  Ingest --> MQTT
  MQTT --> Runtime
  Runtime --> Package
  Package --> Flows

  Flows -- "hot path" --> Hot
  Hot --> Alerts

  Flows -- "cold path" --> Fabric
  Fabric --> Bronze
  Bronze --> Silver
  Silver --> Gold
  Gold --> PBI

  Flows -- "cloud verify" --> Foundry
  Foundry -- "verification feedback" --> Flows

Control Plane Overlay (Azure + Private Cloud)

flowchart LR
  Arc["Azure Arc"]
  Flux["Flux GitOps"]
  Policy["Policy + Config Baselines"]
  EdgeK8s["Private Cloud Kubernetes Cluster"]
  EdgeRuntime["Unified Edge Inference Runtime"]
  EdgeFlow["Event Processing Pipeline"]
  AzureSvc["Azure Integration Services"]

  Arc --> Flux
  Flux --> Policy
  Policy -. "deploy + reconcile" .-> EdgeK8s
  Arc -. "governance + extensions" .-> EdgeK8s
  Arc -. "service policy" .-> AzureSvc
  EdgeK8s --> EdgeRuntime
  EdgeK8s --> EdgeFlow

flowchart LR
  A["Solid arrow: data plane"] --> B["Dashed arrow: control plane"]
  C["RTSP: camera transport"] --> D["MQTT: edge message bus"]
  D --> E["Kafka/HTTPS: cloud egress"]

AWS Integration View

flowchart LR
  subgraph Edge["Private Cloud Edge Runtime"]
    Flows["Event Processing Pipeline"]
  end

  subgraph AWS["AWS Platform"]
    IoTCore["IoT Core"]
    SiteWise["SiteWise"]
    GG["Greengrass"]
    SSM["Systems Manager"]
    Bedrock["Bedrock"]
    AwsOps["CloudWatch Dashboards"]
  end

  Flows -- "telemetry bridge" --> IoTCore
  IoTCore --> SiteWise
  IoTCore --> GG
  SSM -- "fleet ops" --> GG
  Bedrock -- "model artifacts" --> GG
  GG --> AwsOps

Local-Only Implementation (Specific Self-Hosted Tools)

flowchart LR
  Cam["RTSP Cameras"] --> MediaMTX["MediaMTX (RTSP ingest/relay)"]
  MediaMTX --> EMQX["EMQX (MQTT frame contracts)"]

  subgraph K3s["K3s Edge Runtime"]
    TTWorker["TT-Forge Inference Worker"]
    NVWorker["Triton Inference Worker"]
  end

  EMQX --> TTWorker
  EMQX --> NVWorker
  TTWorker --> Redpanda["Redpanda (event publish)"]
  NVWorker --> Redpanda
  Redpanda --> Flink["Apache Flink (thresholding + enrichment)"]
  Flink --> MinIO["MinIO (packaged frame/event artifacts)"]
  Flink --> ClickHouse["ClickHouse (cold analytics store)"]
  Flink --> Alertmanager["Alertmanager (hot alerts)"]

  TTWorker --> Prom["Prometheus + Loki (health metrics)"]
  NVWorker --> Prom
  EMQX --> Prom
  Flink --> Prom
  ClickHouse --> Grafana["Grafana (local ops dashboards)"]
  Alertmanager --> Grafana
  Prom --> Grafana

In this local view, each stage is concrete and self-hosted, but still interchangeable by contract. The handoff boundaries are RTSP ingest, MQTT frame topics, event stream topics, and packaged artifact output.

Physical Lab and Studio Layout

The studio side is optimized for fast context switching. I can record walkthroughs, run live demos, and pivot from one vertical scenario to another without rebuilding the room. The server side is optimized for shared hardware utilization across those same scenarios.

This setup makes it easier to:

• Reuse the same edge hardware for multiple business demos.
• Keep model and telemetry pipelines consistent across environments.
• Demonstrate cloud-assisted operations without requiring cloud-only inference.
• Keep local fallback paths available when connectivity is constrained.

flowchart LR
  subgraph StudioRoom["Studio Room"]
    CamWide["Camera A (wide)"]
    CamClose["Camera B (table)"]
    RTSPHost["Windows RTSP Host"]
  end

  subgraph ServerRoom["Server Room"]
    TrueNASHost["TrueNAS Host"]
    Prox1["Proxmox Host 1"]
    Prox2["Proxmox Host 2"]
    K8sCP["K8s Control Plane Host"]
    K8sWTT["K8s Worker Host (TT)"]
    K8sWNV["K8s Worker Host (NVIDIA)"]
    Mon["Grafana Monitoring Wall"]
  end

  CamWide -- "RTSP feed" --> RTSPHost
  CamClose -- "RTSP feed" --> RTSPHost
  RTSPHost -- "RTSP relay" --> K8sCP
  K8sCP --> K8sWTT
  K8sCP --> K8sWNV
  TrueNASHost --> K8sWTT
  TrueNASHost --> K8sWNV
  Prox1 --> K8sCP
  Prox2 --> K8sWNV
  K8sCP --> Mon
  K8sWTT --> Mon
  K8sWNV --> Mon

Current Lab Inventory

Current internal lab components include:

• Windows RTSP stream host
• Wormhole server
• Blackhole server path: staged and not fully onboarded yet
• Two active web cams for a high shot and a low shot
• TrueNAS storage box with two Tesla P400 GPUs running Ollama and other workloads
• Proxmox hosts for general private cloud workloads

The practical goal is to run a mixed accelerator lab where workload placement can be tuned by use case, latency target, and cost profile.

Azure Path: IoT Operations, Arc, and Edge Feedback Loops

On Azure, the control pattern is centered around Azure IoT Operations on Azure Arc-enabled Kubernetes. In the demo repository, this aligns with the Azure/Demo/Shared/AzureInternetOfThingsOperations assets and the shared EdgeInference service.

The local flow is:

1. Cameras publish RTSP to the Windows RTSP host.
2. The AIO RTSP Adapter ingests RTSP and publishes frames to the local MQTT frame topic.
3. Edge inference services consume those frame topics and publish detections, traffic, and enriched messages.
4. AIO Data Flows process, normalize, and extract delta events.
5. Data Flows push upstream to Fabric RTI and call a Foundry endpoint for cloud verification.
6. Results flow into cloud analytics and operations dashboards, with feedback updates pushed back to edge.

In repository terms, that includes topic patterns such as:

• tt/edge/{site}/{camera_id}/detections
• tt/cloud/{site}/{device_id}/verify
• tt/cloud/{site}/{device_id}/verify-result

flowchart LR
  RTSPA["AIO RTSP Adapter"] -->|"tt/edge/{site}/{camera_id}/frames"| Edge["Edge Inference Service"]
  Edge -->|"tt/edge/{site}/{camera_id}/detections"| Flows["AIO Data Flows"]
  Edge -->|"tt/edge/{site}/{camera_id}/traffic"| Flows
  Edge -->|"Enriched msg + sampled frame ref"| Flows
  Flows -->|"Delta events (new/lost detections)"| Fabric["Fabric RTI"]
  Flows -->|"Verify request (sampled frame)"| FEP["Foundry Endpoint"]

Operationally, Arc gives me a consistent management surface for local Kubernetes resources and policy. I am also treating GitOps with Flux on Arc-enabled Kubernetes as the default deployment and configuration strategy for repeatability.

One reason this fits the basement buildout well is that Azure IoT Operations is designed as a unified edge data plane with an industrial MQTT broker and supports routing/normalization before cloud fan-out. That maps directly to how I want to keep high-volume inference local while still enabling cloud-side verification, model lifecycle workflows, and cross-site analytics.

For the Fabric path, I am modeling Data Flows publishing directly to Fabric Eventstream through the documented Fabric endpoint configuration (no required Event Hub bridge in this path).

sequenceDiagram
  autonumber
  participant Cam as Camera
  participant Win as Windows RTSP Host
  participant RTSPA as AIO RTSP Adapter
  participant MQTT as AIO MQTT Broker
  participant Edge as Edge Inference Service
  participant Flow as AIO Data Flows
  participant FReg as Foundry Registry
  participant FTrain as Foundry Distill/Train
  participant FEP as Foundry Endpoint
  participant Fabric as Fabric Eventstream
  participant Log as Log Analytics
  participant Ops as Ops Dashboards

  Cam->>Win: RTSP stream
  Win->>RTSPA: RTSP relay
  RTSPA->>MQTT: Publish frame topic
  MQTT->>Edge: Consume frame topic
  Edge->>MQTT: Publish detections topic
  Edge->>MQTT: Publish traffic topic
  Edge->>MQTT: Publish enriched message + sampled frame ref
  MQTT->>Flow: Route edge topics

  alt Cloud connected
    Flow->>FEP: Verify request (sampled frame + context)
    alt Verify success
      FEP-->>Flow: Verify response
      Flow->>Fabric: Push extracted delta events (new/lost detections)
      Flow->>Fabric: Push verified analytics events
      Flow->>Log: Push ops metrics
      Flow->>Ops: Update cloud dashboards
    else Verify timeout/error
      Flow->>Flow: Retry with backoff
      Flow->>Log: Emit verify_failure metric
      Flow->>Ops: Raise verify alert
    end
  else Cloud unavailable (offline window)
    Flow->>Flow: Buffer and compact delta events
    Flow->>Log: Emit offline_mode metric
    Flow->>Ops: Raise cloud_disconnect alert
  end

  FReg->>FTrain: Model lineage + artifacts
  FTrain->>FEP: Deploy candidate verify model
  FEP-->>Edge: Model and threshold feedback rollout

flowchart LR
  A["RTSP = ingest transport"] --> B["MQTT = edge bus"]
  B --> C["Kafka endpoint = Fabric ingress"]
  D["Delta event = object newly detected or no longer detected"] --> E["Enriched msg = detection + frame reference + context"]

AWS Path: Greengrass, IoT Core, SiteWise, Systems Manager, and Bedrock

On AWS, the equivalent pattern uses:

• AWS IoT Greengrass for edge runtime orchestration.
• AWS IoT Core for secure bi-directional cloud messaging and device state.
• AWS IoT SiteWise for industrial telemetry modeling, transforms, and monitoring.
• AWS Systems Manager for hybrid fleet operations, patching, and command execution.
• Amazon Bedrock as part of the cloud-side model specialization and distillation path.

The AWS side in the demo repository is organized to mirror Azure demo shape where possible, including shared vertical scenarios and analytics assets. The intent is to keep edge behavior portable while changing only cloud control-plane integrations.

At a high level:

1. Local inference continues at the edge.
2. Edge messaging bridges into AWS IoT Core patterns.
3. Industrial telemetry and KPI modeling feed SiteWise analytics.
4. Operations and lifecycle tasks route through Systems Manager.
5. Distilled cloud-side model workflows can feed edge deployment artifacts.

This gives us realistic AWS parity for customer conversations where cloud preference is fixed but the edge architecture should stay consistent.

sequenceDiagram
  participant Cam as Camera
  participant Edge as Tenstorrent Edge Workload
  participant GG as AWS IoT Greengrass
  participant Core as AWS IoT Core
  participant SW as AWS IoT SiteWise
  participant SSM as AWS Systems Manager
  participant BR as Amazon Bedrock

  Cam->>Edge: Local Frames
  Edge->>GG: Inference Output
  GG->>Core: Telemetry Publish
  Core->>SW: Rules to Asset Models
  SSM-->>Edge: Patch and Command Ops
  BR-->>Edge: Distilled Model Artifacts

Cross-Provider Pattern

The architecture pattern stays the same even when control planes differ:

This is the core reason for the buildout: one local edge core, multiple cloud orchestration options, and a purely local fallback.

flowchart TB
  subgraph Core["Shared Edge Core"]
    Ingest["RTSP ingest + frame contracts"]
    TT["TT inference"]
    NV["NVIDIA inference"]
    Publish["Event publish + thresholding"]
    Health["Health metrics"]
    Package["Packaging"]
    Ingest --> TT
    Ingest --> NV
    TT --> Publish
    NV --> Publish
    Publish --> Health
    Health --> Package
  end

  subgraph AZ["Azure Integration"]
    AIO["IoT Operations"]
    Arc["Arc"]
    Fabric["Fabric RTI"]
    Foundry["Foundry"]
  end

  subgraph AW["AWS Integration"]
    GG["Greengrass"]
    CoreIoT["IoT Core"]
    SW["SiteWise"]
    SSM["Systems Manager"]
    BR["Bedrock"]
  end

  subgraph LOC["Local Integration"]
    LMQTT["Local MQTT"]
    LVerify["Local verify"]
    LAnalytics["Local analytics"]
    LOps["Local ops"]
  end

  Publish --> AIO
  Publish --> CoreIoT
  Publish --> LMQTT

  AIO --> Fabric
  AIO --> Foundry
  Arc -. "policy/deploy" .-> AIO

  CoreIoT --> GG
  CoreIoT --> SW
  SSM -. "fleet control" .-> GG
  BR --> GG

  LMQTT --> LVerify
  LMQTT --> LAnalytics
  LAnalytics --> LOps

  Foundry -- "model + threshold updates" --> Package
  BR -- "model updates" --> Package
  LVerify -- "local policy updates" --> Package

flowchart LR
  Build["Build"] --> Pack["Package"]
  Pack --> Deploy["Deploy"]
  Deploy --> Observe["Observe"]
  Observe --> Tune["Tune"]
  Tune --> Rollout["Rollout"]
  Rollout --> Deploy
  Observe --> Reach{"Cloud reachable?"}
  Reach -- "yes" --> Hybrid["Hybrid mode"]
  Reach -- "no" --> LocalOnly["Local-only mode"]
  LocalOnly --> Buffer["Buffer + local analytics"]
  Buffer --> Recover["Backfill on reconnect"]
  Recover --> Hybrid

First Milestone

The first milestone for this personal buildout is to get Azure IoT Operations fully wired to local Tenstorrent inference in a closed loop:

1. Ingest local RTSP streams into the edge inference service.
2. Run local inference on the Tenstorrent host.
3. Publish structured detections into IoT Operations topics.
4. Forward selected events or sampled frames for cloud verification.
5. Return verification and analytics outcomes to operational dashboards.
6. Push updated thresholds and model-management decisions back to the edge.

This gives a concrete demonstration of edge inference plus cloud feedback rather than edge-only or cloud-only narratives.

flowchart TD
  A["RTSP Ingest"] --> B["Tenstorrent Inference"]
  B --> C["Publish to IoT Ops Topics"]
  C --> D["Cloud Verification and Analytics"]
  D --> E["Feedback to Edge Policies and Thresholds"]

Next Steps

1. Complete Blackhole onboarding and benchmark against current Wormhole and NVIDIA paths.
2. Harden deployment automation across Azure and AWS for faster scenario switching.
3. Expand vertical demo packs so the same local hardware can represent more business contexts.
4. Add stronger runbook-level operational checks for edge health, topic flow integrity, and model rollout safety.

References

• Azure IoT Operations overview
• Configure Azure IoT Operations Fabric endpoint
• Azure Arc overview
• Azure Arc-enabled Kubernetes overview
• GitOps with Flux v2 on Azure Arc-enabled Kubernetes
• AWS IoT Greengrass overview
• AWS IoT Core overview
• AWS IoT SiteWise overview
• AWS Systems Manager overview
• Amazon Bedrock overview
• Tenstorrent documentation home
• Tenstorrent TT-Forge documentation
• Tenstorrent Wormhole hardware
• Tenstorrent Blackhole hardware

In a previous post, we discussed how to save money on a home lab. One section was cloud utilization. Let’s expand on that section and have a more in-depth conversation about how to create dynamic resources in Azure. This article will focus on creating a VPN dynamically.

Azure networking is not the most noticeable part of an enterprise bill. In the homelab scenario, it can be a running cost that adds up when not needed. Remember the entire purpose of a homelab is to run most, if not all, items… well in your home, at least. To alleviate this running cost, the components needed in an Azure Site-to-Site VPN can instead be created dynamically to utilize whenever it is required.

Due to the time involved in creating a VPN Gateway in Azure, this won’t be something that can be created and destroyed the same way a virtual machine or container could be. For the VPN Gateway, there should be at least one hour to guarantee that the VPN Gateway and other components can be created in time to meet demand load.

Let’s imagine a scenario where ad-hoc processing power is needed for an upcoming marketing campaign where traffic is expected to exceed our current capacity. In this scenario, our servers will be replicated in Azure Virtual Machines and allow for increased traffic. (This is a basic setup; in later posts, we’ll discuss more advanced scenarios.) To accomplish this, we need to set up a Site-to-Site VPN in Azure from our homelab.

Diagram showing an on-premises network on the left which consists of three computer screens and a gateway. A double sided arrow connecting the on-premises to a cloud labeled internet with “Site-to-site VPN tunnel” above the double sided arrow. Another double sided arrow connects the internet cloud to its right through a dotted rectangle labeled “Azure Virtual Network”. The arrow connects to an item labeled VPN gateway. That gateway has a single arrow leaving it to the right pointing to a load balancer which is pointing to three identical virtual machines.

The steps to accomplish this are:

1. Supported Routers
2. Creating a Site-to-Site Connection
3. Replicating Virtual Machines / Containers
4. Tear Down

Supported Routers (official docs)

Microsoft keeps an updated set of documentation for supported VPN routers. A VPN device is required to configure a Site-to-Site (S2S) cross-premises VPN connection using a VPN gateway. Site-to-Site connections can be used to create a hybrid solution, or whenever you want secure connections between your on-premises networks and your virtual networks.

Important ??” If you are experiencing connectivity issues between your on-premises VPN devices and VPN gateways, refer to Known device compatibility issues.

Items to note when viewing the tables:

• There has been a terminology change for Azure VPN gateways. Only the names have changed. There is no functionality change.
  • Static Routing = PolicyBased
  • Dynamic Routing = RouteBased
• Specifications for HighPerformance VPN gateway and RouteBased VPN gateway are the same, unless otherwise noted. For example, the validated VPN devices that are compatible with RouteBased VPN gateways are also compatible with the HighPerformance VPN gateway.

Validated VPN devices and device configuration guides

In partnership with device vendors, we have validated a set of standard VPN devices. All of the devices in the device families in the following list should work with VPN gateways. See About VPN Gateway Settings to understand the VPN type use (PolicyBased or RouteBased) for the VPN Gateway solution you want to configure.

To help configure your VPN device, refer to the links that correspond to the appropriate device family. The links to configuration instructions are provided on a best-effort basis. For VPN device support, contact your device manufacturer.

(*) Cisco ASA versions 8.4+ add IKEv2 support, can connect to Azure VPN gateway using custom IPsec/IKE policy with “UsePolicyBasedTrafficSelectors” option. Refer to this how-to article.

(**) ISR 7200 Series routers only support PolicyBased VPNs.

Download VPN device configuration scripts from Azure

For certain devices, you can download configuration scripts directly from Azure. For more information and download instructions, see Download VPN device configuration scripts.

Devices with available configuration scripts

( * ) Required: NarrowAzureTrafficSelectors (enable UsePolicyBasedTrafficSelectors option) and CustomAzurePolicies (IKE/IPsec)

Non-validated VPN devices

If you don’t see your device listed in the Validated VPN devices table, your device still may work with a Site-to-Site connection. Contact your device manufacturer for additional support and configuration instructions.

Editing device configuration samples

After you download the provided VPN device configuration sample, you’ll need to replace some of the values to reflect the settings for your environment.

To edit a sample:

1. Open the sample using Notepad.
2. Search and replace all <text> strings with the values that pertain to your environment. Be sure to include < and >. When a name is specified, the name you select should be unique. If a command does not work, consult your device manufacturer documentation.

Default IPsec/IKE parameters

The tables below contain the combinations of algorithms and parameters Azure VPN gateways use in default configuration (Default policies). For route-based VPN gateways created using the Azure Resource Management deployment model, you can specify a custom policy on each individual connection. Please refer to Configure IPsec/IKE policy for detailed instructions.

Additionally, you must clamp TCP MSS at 1350. Or if your VPN devices do not support MSS clamping, you can alternatively set the MTU on the tunnel interface to 1400 bytes instead.

In the following tables:

• SA = Security Association
• IKE Phase 1 is also called “Main Mode”
• IKE Phase 2 is also called “Quick Mode”

IKE Phase 1 (Main Mode) parameters

IKE Phase 2 (Quick Mode) parameters

RouteBased VPN IPsec Security Association (IKE Quick Mode SA) Offers

The following table lists IPsec SA (IKE Quick Mode) Offers. Offers are listed the order of preference that the offer is presented or accepted.

Azure Gateway as initiator

Azure Gateway as responder

• You can specify IPsec ESP NULL encryption with RouteBased and HighPerformance VPN gateways. Null based encryption does not provide protection to data in transit, and should only be used when maximum throughput and minimum latency is required. Clients may choose to use this in VNet-to-VNet communication scenarios, or when encryption is being applied elsewhere in the solution.
• For cross-premises connectivity through the Internet, use the default Azure VPN gateway settings with encryption and hashing algorithms listed in the tables above to ensure security of your critical communication.

Creating a VPN Gateway (official docs)

A Site-to-Site VPN gateway connection is used to connect your on-premises network to an Azure virtual network over an IPsec/IKE (IKEv1 or IKEv2) VPN tunnel. This type of connection requires a VPN device located on-premises that has an externally facing public IP address assigned to it. For more information about VPN gateways, see About VPN gateway.

Before you begin

Verify that you have met the following criteria before beginning configuration:

• Make sure you have a compatible VPN device and someone who is able to configure it. For more information about compatible VPN devices and device configuration, see About VPN Devices.
• Verify that you have an externally facing public IPv4 address for your VPN device.

• If you are unfamiliar with the IP address ranges located in your on-premises network configuration, you need to coordinate with someone who can provide those details for you. When you create this configuration, you must specify the IP address range prefixes that Azure will route to your on-premises location. None of the subnets of your on-premises network can over lap with the virtual network subnets that you want to connect to.

• Use the Bash environment in Azure Cloud Shell.
• If you prefer, install the Azure CLI to run CLI reference commands.
  • If you’re using a local installation, sign in to the Azure CLI by using the az login command. To finish the authentication process, follow the steps displayed in your terminal. For additional sign-in options, see Sign in with the Azure CLI.
  • When you’re prompted, install Azure CLI extensions on first use. For more information about extensions, see Use extensions with the Azure CLI.
  • Run az version to find the version and dependent libraries that are installed. To upgrade to the latest version, run az upgrade.
• This article requires version 2.0 or later of the Azure CLI. If using Azure Cloud Shell, the latest version is already installed.

Example values

You can use the following values to create a test environment, or refer to these values to better understand the examples in this article:Copy

#Example values

VnetName                = TestVNet1?
ResourceGroup           = TestRG1?
Location                = eastus?
AddressSpace            = 10.11.0.0/16?
SubnetName              = Subnet1?
Subnet                  = 10.11.0.0/24?
GatewaySubnet           = 10.11.255.0/27?
LocalNetworkGatewayName = Site2?
LNG Public IP           = <VPN device IP address>
LocalAddrPrefix1        = 10.0.0.0/24
LocalAddrPrefix2        = 20.0.0.0/24  ?
GatewayName             = VNet1GW?
PublicIP                = VNet1GWIP?
VPNType                 = RouteBased?
GatewayType             = Vpn?
ConnectionName          = VNet1toSite2

1. Connect to your subscription

If you choose to run CLI locally, connect to your subscription. If you are using Azure Cloud Shell in the browser, you don’t need to connect to your subscription. You will connect automatically in Azure Cloud Shell. However, you may want to verify that you are using the correct subscription after you connect.

Sign in to your Azure subscription with the az login command and follow the on-screen directions. For more information about signing in, see Get Started with Azure CLI.

az login

If you have more than one Azure subscription, list the subscriptions for the account.

az account list --all

Specify the subscription that you want to use.

az account set --subscription <replace_with_your_subscription_id>

2. Create a resource group

The following example creates a resource group named ‘TestRG1’ in the ‘eastus’ location. If you already have a resource group in the region that you want to create your VNet, you can use that one instead.

az group create --name TestRG1 --location eastus

3. Create a virtual network

If you don’t already have a virtual network, create one using the az network vnet create command. When creating a virtual network, make sure that the address spaces you specify don’t overlap any of the address spaces that you have on your on-premises network.

Note ??” In order for this VNet to connect to an on-premises location, you need to coordinate with your on-premises network administrator to carve out an IP address range that you can use specifically for this virtual network. If a duplicate address range exists on both sides of the VPN connection, traffic does not route the way you may expect it to. Additionally, if you want to connect this VNet to another VNet, the address space cannot overlap with other VNet. Take care to plan your network configuration accordingly.

The following example creates a virtual network named ‘TestVNet1’ and a subnet, ‘Subnet1’.

az network vnet create --name TestVNet1 --resource-group TestRG1 --address-prefix 10.11.0.0/16 --location eastus --subnet-name Subnet1 --subnet-prefix 10.11.0.0/24

4. Create the gateway subnet

The virtual network gateway uses specific subnet called the gateway subnet. The gateway subnet is part of the virtual network IP address range that you specify when configuring your virtual network. It contains the IP addresses that the virtual network gateway resources and services use. The subnet must be named ‘GatewaySubnet’ in order for Azure to deploy the gateway resources. You can’t specify a different subnet to deploy the gateway resources to. If you don’t have a subnet named ‘GatewaySubnet’, when you create your VPN gateway, it will fail.

When you create the gateway subnet, you specify the number of IP addresses that the subnet contains. The number of IP addresses needed depends on the VPN gateway configuration that you want to create. Some configurations require more IP addresses than others. We recommend that you create a gateway subnet that uses a /27 or /28.

If you see an error that specifies that the address space overlaps with a subnet, or that the subnet is not contained within the address space for your virtual network, check your VNet address range. You may not have enough IP addresses available in the address range you created for your virtual network. For example, if your default subnet encompasses the entire address range, there are no IP addresses left to create additional subnets. You can either adjust your subnets within the existing address space to free up IP addresses, or specify an additional address range and create the gateway subnet there.

Use the az network vnet subnet create command to create the gateway subnet.

az network vnet subnet create --address-prefix 10.11.255.0/27 --name GatewaySubnet --resource-group TestRG1 --vnet-name TestVNet1

Important ??” When working with gateway subnets, avoid associating a network security group (NSG) to the gateway subnet. Associating a network security group to this subnet may cause your virtual network gateway (VPN and Express Route gateways) to stop functioning as expected. For more information about network security groups, see What is a network security group?.

5. Create the local network gateway

The local network gateway typically refers to your on-premises location. You give the site a name by which Azure can refer to it, then specify the IP address of the on-premises VPN device to which you will create a connection. You also specify the IP address prefixes that will be routed through the VPN gateway to the VPN device. The address prefixes you specify are the prefixes located on your on-premises network. If your on-premises network changes, you can easily update the prefixes.

Use the following values:

• The ??”gateway-ip-address is the IP address of your on-premises VPN device.
• The ??”local-address-prefixes are your on-premises address spaces.

Use the az network local-gateway create command to add a local network gateway with multiple address prefixes:

az network local-gateway create --gateway-ip-address 23.99.221.164 --name Site2 --resource-group TestRG1 --local-address-prefixes 10.0.0.0/24 20.0.0.0/24

6. Request a Public IP address

A VPN gateway must have a Public IP address. You first request the IP address resource, and then refer to it when creating your virtual network gateway. The IP address is dynamically assigned to the resource when the VPN gateway is created. VPN Gateway currently only supports Dynamic Public IP address allocation. You cannot request a Static Public IP address assignment. However, this does not mean that the IP address changes after it has been assigned to your VPN gateway. The only time the Public IP address changes is when the gateway is deleted and re-created. It doesn’t change across resizing, resetting, or other internal maintenance/upgrades of your VPN gateway.

Use the az network public-ip create command to request a Dynamic Public IP address.

az network public-ip create --name VNet1GWIP --resource-group TestRG1 --allocation-method Dynamic

7. Create the VPN gateway

Create the virtual network VPN gateway. Creating a gateway can often take 45 minutes or more, depending on the selected gateway SKU.

Use the following values:

• The ??”gateway-type for a Site-to-Site configuration is Vpn. The gateway type is always specific to the configuration that you are implementing. For more information, see Gateway types.
• The ??”vpn-type can be RouteBased (referred to as a Dynamic Gateway in some documentation), or PolicyBased (referred to as a Static Gateway in some documentation). The setting is specific to requirements of the device that you are connecting to. For more information about VPN gateway types, see About VPN Gateway configuration settings.
• Select the Gateway SKU that you want to use. There are configuration limitations for certain SKUs. For more information, see Gateway SKUs.

Create the VPN gateway using the az network vnet-gateway create command. If you run this command using the ‘??”no-wait’ parameter, you don’t see any feedback or output. This parameter allows the gateway to create in the background. It takes 45 minutes or more to create a gateway.

az network vnet-gateway create --name VNet1GW --public-ip-address VNet1GWIP --resource-group TestRG1 --vnet TestVNet1 --gateway-type Vpn --vpn-type RouteBased --sku VpnGw1 --no-wait?

8. Configure your VPN device

Site-to-Site connections to an on-premises network require a VPN device. In this step, you configure your VPN device. When configuring your VPN device, you need the following:

• A shared key. This is the same shared key that you specify when creating your Site-to-Site VPN connection. In our examples, we use a basic shared key. We recommend that you generate a more complex key to use.
• The Public IP address of your virtual network gateway. You can view the public IP address by using the Azure portal, PowerShell, or CLI. To find the public IP address of your virtual network gateway, use the az network public-ip list command. For easy reading, the output is formatted to display the list of public IPs in table format.

az network public-ip list --resource-group TestRG1 --output table

To download VPN device configuration scripts:

Depending on the VPN device that you have, you may be able to download a VPN device configuration script. For more information, see Download VPN device configuration scripts.

See the following links for additional configuration information:

• For information about compatible VPN devices, see VPN Devices.
• Before configuring your VPN device, check for any Known device compatibility issues for the VPN device that you want to use.
• For links to device configuration settings, see Validated VPN Devices. The device configuration links are provided on a best-effort basis. It’s always best to check with your device manufacturer for the latest configuration information. The list shows the versions we have tested. If your OS is not on that list, it is still possible that the version is compatible. Check with your device manufacturer to verify that OS version for your VPN device is compatible.
• For an overview of VPN device configuration, see VPN device configuration overview.
• For information about editing device configuration samples, see Editing samples.
• For cryptographic requirements, see About cryptographic requirements and Azure VPN gateways.
• For information about IPsec/IKE parameters, see About VPN devices and IPsec/IKE parameters for Site-to-Site VPN gateway connections. This link shows information about IKE version, Diffie-Hellman Group, Authentication method, encryption and hashing algorithms, SA lifetime, PFS, and DPD, in addition to other parameter information that you need to complete your configuration.
• For IPsec/IKE policy configuration steps, see Configure IPsec/IKE policy for S2S VPN or VNet-to-VNet connections.
• To connect multiple policy-based VPN devices, see Connect Azure VPN gateways to multiple on-premises policy-based VPN devices using PowerShell.

9. Create the VPN connection

Create the Site-to-Site VPN connection between your virtual network gateway and your on-premises VPN device. Pay particular attention to the shared key value, which must match the configured shared key value for your VPN device.

Create the connection using the az network vpn-connection create command.

az network vpn-connection create --name VNet1toSite2 --resource-group TestRG1 --vnet-gateway1 VNet1GW -l eastus --shared-key abc123 --local-gateway2 Site2

After a short while, the connection will be established.

10. Verify the VPN connection

You can verify that your connection succeeded by using the az network vpn-connection show command. In the example, ‘??”name’ refers to the name of the connection that you want to test. When the connection is in the process of being established, its connection status shows ‘Connecting’. Once the connection is established, the status changes to ‘Connected’.

az network vpn-connection show --name VNet1toSite2 --resource-group TestRG1

If you want to use another method to verify your connection, see Verify a VPN Gateway connection.

To connect to a virtual machine

You can connect to a VM that is deployed to your VNet by creating a Remote Desktop Connection to your VM. The best way to initially verify that you can connect to your VM is to connect by using its private IP address, rather than computer name. That way, you are testing to see if you can connect, not whether name resolution is configured properly.

1. Locate the private IP address. You can find the private IP address of a VM by either looking at the properties for the VM in the Azure portal, or by using PowerShell.
   • Azure portal ??” Locate your virtual machine in the Azure portal. View the properties for the VM. The private IP address is listed.
   • PowerShell ??” Use the example to view a list of VMs and private IP addresses from your resource groups. You don’t need to modify this example before using it.Azure PowerShellCopyTry It$VMs = Get-AzVM $Nics = Get-AzNetworkInterface | Where VirtualMachine -ne $null foreach($Nic in $Nics) { $VM = $VMs | Where-Object -Property Id -eq $Nic.VirtualMachine.Id $Prv = $Nic.IpConfigurations | Select-Object -ExpandProperty PrivateIpAddress $Alloc = $Nic.IpConfigurations | Select-Object -ExpandProperty PrivateIpAllocationMethod Write-Output "$($VM.Name): $Prv,$Alloc" }
2. Verify that you are connected to your VNet using the Point-to-Site VPN connection.
3. Open Remote Desktop Connection by typing “RDP” or “Remote Desktop Connection” in the search box on the taskbar, then select Remote Desktop Connection. You can also open Remote Desktop Connection using the ‘mstsc’ command in PowerShell.
4. In Remote Desktop Connection, enter the private IP address of the VM. You can click “Show Options” to adjust additional settings, then connect.

Troubleshoot a connection

If you are having trouble connecting to a virtual machine over your VPN connection, check the following:

• Verify that your VPN connection is successful.
• Verify that you are connecting to the private IP address for the VM.
• If you can connect to the VM using the private IP address, but not the computer name, verify that you have configured DNS properly. For more information about how name resolution works for VMs, see Name Resolution for VMs.
• For more information about RDP connections, see Troubleshoot Remote Desktop connections to a VM.

Common tasks

This section contains common commands that are helpful when working with site-to-site configurations. For the full list of CLI networking commands, see Azure CLI ??” Networking.

To view local network gateways

To view a list of the local network gateways, use the az network local-gateway list command.

az network local-gateway list --resource-group TestRG1

To modify local network gateway IP address prefixes ??” no gateway connection

If you don’t have a gateway connection and you want to add or remove IP address prefixes, you use the same command that you use to create the local network gateway, az network local-gateway create. You can also use this command to update the gateway IP address for the VPN device. To overwrite the current settings, use the existing name of your local network gateway. If you use a different name, you create a new local network gateway, instead of overwriting the existing one.

Each time you make a change, the entire list of prefixes must be specified, not just the prefixes that you want to change. Specify only the prefixes that you want to keep. In this case, 10.0.0.0/24 and 20.0.0.0/24

az network local-gateway create --gateway-ip-address 23.99.221.164 --name Site2 -g TestRG1 --local-address-prefixes 10.0.0.0/24 20.0.0.0/24

To modify local network gateway IP address prefixes ??” existing gateway connection

If you have a gateway connection and want to add or remove IP address prefixes, you can update the prefixes using az network local-gateway update. This results in some downtime for your VPN connection. When modifying the IP address prefixes, you don’t need to delete the VPN gateway.

Each time you make a change, the entire list of prefixes must be specified, not just the prefixes that you want to change. In this example, 10.0.0.0/24 and 20.0.0.0/24 are already present. We add the prefixes 30.0.0.0/24 and 40.0.0.0/24 and specify all 4 of the prefixes when updating.

az network local-gateway update --local-address-prefixes 10.0.0.0/24 20.0.0.0/24 30.0.0.0/24 40.0.0.0/24 --name VNet1toSite2 -g TestRG1

To modify the local network gateway ‘gatewayIpAddress’

If the VPN device that you want to connect to has changed its public IP address, you need to modify the local network gateway to reflect that change. The gateway IP address can be changed without removing an existing VPN gateway connection (if you have one). To modify the gateway IP address, replace the values ‘Site2’ and ‘TestRG1’ with your own using the az network local-gateway update command.

az network local-gateway update --gateway-ip-address 23.99.222.170 --name Site2 --resource-group TestRG1

Verify that the IP address is correct in the output:Copy

"gatewayIpAddress": "23.99.222.170",

To verify the shared key values

Verify that the shared key value is the same value that you used for your VPN device configuration. If it is not, either run the connection again using the value from the device, or update the device with the value from the return. The values must match. To view the shared key, use the az network vpn-connection-list.

az network vpn-connection shared-key show --connection-name VNet1toSite2 --resource-group TestRG1

To view the VPN gateway Public IP address

To find the public IP address of your virtual network gateway, use the az network public-ip list command. For easy reading, the output for this example is formatted to display the list of public IPs in table format.

az network public-ip list --resource-group TestRG1 --output table

With the gateway and router setup complete, the next step is replicating the virtual machines

Replicating Virtual Machines / Containers

Due to the number of different ways to migrate Virtual Machines into Azure from the private cloud, we will not cover migration in depth this time. Whether you use Windows, Linux, KVM, VMWare, Unix, Hyper-V, Docker, K8s, Proxmox, or anything else, Microsoft has a number of guides for migration. Leave questions on this article, if there is information you can’t find.

There are a few items to keep in mind when migrating Virtual Machines / Containers from a homelab to Azure. A major one is that the migration is likely not permanent and likely not one way. Azure has a number of tools and technologies for migrating infrastructure into Azure; it does not, however, have many tools for migrating instances out of Azure (and rightly so). This means that your migration strategy will need to be able to synchronize back to the homelab. Prepare for a bi-directional migration process, if migration is required for entire machines.

Bi-Directional Migrations

Virtual Machines

Bi-directional migration options will differ depending on the hosting technology you use for your homelab. The most basic case, Virtual Machines (KVM, VMWare, Hyper-V, Xen, etc.), has two options based on deployment type:

• Immutable ??” Due to the stateless nature of immutable instances, the synchronization mechanism would target the underlying state storage mechanism if there is one. In the case of a blob or file store, the data can be easily copied between Azure and homelab using any number of tools.
• Mutable ??” Mutable instances will most likely need to have the (virtual) machine disks copied between each host. Use appropriate disk conversion technology so that the disk type is appropriate the host (Azure VHD vs KVM qcow2, etc).

It should be noted that migrations of certain products, like SQL Server, have more advanced migration and synchronization methods. These products are outside the scope of this discussion. For an example, a PostgreSQL cluster has the option to migrate via replication.

Containers

Data Sync

Azure has a number of different options to sync blobs between the home lab and Azure:

• AzCopy
• Azure Data Factory
• Mount storage by using NFS
• Mount storage from Linux using blobfuse
• Transfer data with the Data Movement library

Front Doors

Direct Entry

Another item to consider is what will be the front door into your homelab. The usage of front door here is describing how the applications are accessed over the internet. If the homelab will still use its internet as the front door for application access, then will the available bandwidth be enough for the migration increase? If Azure is to be the front door, then how do you simultaneously handle having two front doors as the DNS update propagates?

Diagram showing an on-premises network on the left, which consists of three computer screens and a gateway. A double-sided arrow connecting the on-premises to a cloud labeled internet with “Site-to-site VPN tunnel” above the double-sided arrow. Another double-sided arrow connects the internet cloud to its right, through a dotted rectangle labeled “Azure Virtual Network”. The arrow connects to an item labeled VPN gateway. That gateway has a single-arrow leaving it to the right pointing to a load balancer which is pointing to three identical virtual machines. At the bottom, there is a computer monitor labeled user. Between the computer monitor labeled user and the cloud labeled internet is two doors. The left door is labeled on-premises front door. The right door is labeled Azure Front Door. There is a blue arrow for each door pointing from the computer labeled user. There is a blue arrow from each door pointing to the cloud labeled internet.

If you wish to use both as a front door, make sure you have an ingress option available that can properly route between the different subnets and servers. In the case of a basic web server, use something like Nginx or HA Proxy for ingress and basic routing, so that it can be mirrored between homelab and Azure.

Once our event is complete, it’s time to synchronize our systems and tear down our gateway.

Tear Down (official docs)

There are a couple of different approaches you can take when you want to delete a virtual network gateway for a VPN gateway configuration.

• If you want to delete everything and start over, as in the case of a test environment, you can delete the resource group. When you delete a resource group, it deletes all the resources within the group. This is method is only recommended if you don’t want to keep any of the resources in the resource group. You can’t selectively delete only a few resources using this approach.
• If you want to keep some of the resources in your resource group, deleting a virtual network gateway becomes slightly more complicated. Before you can delete the virtual network gateway, you must first delete any resources that are dependent on the gateway. The steps you follow depend on the type of connections that you created and the dependent resources for each connection.

Before beginning

1. Download the latest Azure Resource Manager PowerShell cmdlets.

Download and install the latest version of the Azure Resource Manager PowerShell cmdlets. For more information about downloading and installing PowerShell cmdlets, see How to install and configure Azure PowerShell.

2. Connect to your Azure account.

Open your PowerShell console and connect to your account. Use the following example to help you connect:

Connect-AzAccount

Check the subscriptions for the account.

Get-AzSubscription

If you have more than one subscription, specify the subscription that you want to use.

Select-AzSubscription -SubscriptionName "Replace_with_your_subscription_name"

Delete a Site-to-Site VPN gateway

To delete a virtual network gateway for a S2S configuration, you must first delete each resource that pertains to the virtual network gateway. Resources must be deleted in a certain order due to dependencies. When working with the examples below, some of the values must be specified, while other values are an output result. We use the following specific values in the examples for demonstration purposes:

VNet name: VNet1 Resource Group name: RG1 Virtual network gateway name: GW1

The following steps apply to the Resource Manager deployment model.

1. Get the virtual network gateway that you want to delete.

$GW=get-Azvirtualnetworkgateway -Name "GW1" -ResourceGroupName "RG1"

2. Check to see if the virtual network gateway has any connections.

get-Azvirtualnetworkgatewayconnection -ResourceGroupName "RG1" | where-object {$_.VirtualNetworkGateway1.Id -eq $GW.Id}
$Conns=get-Azvirtualnetworkgatewayconnection -ResourceGroupName "RG1" | where-object {$_.VirtualNetworkGateway1.Id -eq $GW.Id}

3. Delete all connections.

You may be prompted to confirm the deletion of each of the connections.

$Conns | ForEach-Object {Remove-AzVirtualNetworkGatewayConnection -Name $_.name -ResourceGroupName $_.ResourceGroupName}

4. Delete the virtual network gateway.

You may be prompted to confirm the deletion of the gateway. If you have a P2S configuration to this VNet in addition to your S2S configuration, deleting the virtual network gateway will automatically disconnect all P2S clients without warning.

Remove-AzVirtualNetworkGateway -Name "GW1" -ResourceGroupName "RG1"

At this point, your virtual network gateway has been deleted. You can use the next steps to delete any resources that are no longer being used.

5 Delete the local network gateways.

Get the list of the corresponding local network gateways.

$LNG=Get-AzLocalNetworkGateway -ResourceGroupName "RG1" | where-object {$_.Id -In $Conns.LocalNetworkGateway2.Id}

Delete the local network gateways. You may be prompted to confirm the deletion of each of the local network gateway.

$LNG | ForEach-Object {Remove-AzLocalNetworkGateway -Name $_.Name -ResourceGroupName $_.ResourceGroupName}

6. Delete the Public IP address resources.

Get the IP configurations of the virtual network gateway.

$GWIpConfigs = $Gateway.IpConfigurations

Get the list of Public IP address resources used for this virtual network gateway. If the virtual network gateway was active-active, you will see two Public IP addresses.

$PubIP=Get-AzPublicIpAddress | where-object {$_.Id -In $GWIpConfigs.PublicIpAddress.Id}

Delete the Public IP resources.

$PubIP | foreach-object {remove-AzpublicIpAddress -Name $_.Name -ResourceGroupName "RG1"}

7. Delete the gateway subnet and set the configuration.

$GWSub = Get-AzVirtualNetwork -ResourceGroupName "RG1" -Name "VNet1" | Remove-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet"
Set-AzVirtualNetwork -VirtualNetwork $GWSub

Delete a VPN gateway by deleting the resource group

If you are not concerned about keeping any of your resources in the resource group and you just want to start over, you can delete an entire resource group. This is a quick way to remove everything. The following steps apply only to the Resource Manager deployment model.

1. Get a list of all the resource groups in your subscription.

Get-AzResourceGroup

2. Locate the resource group that you want to delete.

Locate the resource group that you want to delete and view the list of resources in that resource group. In the example, the name of the resource group is RG1. Modify the example to retrieve a list of all the resources.

Find-AzResource -ResourceGroupNameContains RG1

3. Verify the resources in the list.

When the list is returned, review it to verify that you want to delete all the resources in the resource group, as well as the resource group itself. If you want to keep some of the resources in the resource group, use the steps in the earlier sections of this article to delete your gateway.

4. Delete the resource group and resources.

To delete the resource group and all the resource contained in the resource group, modify the example and run.

Remove-AzResourceGroup -Name RG1

5. Check the status.

It takes some time for Azure to delete all the resources. You can check the status of your resource group by using this cmdlet.

Get-AzResourceGroup -ResourceGroupName RG1

The result that is returned shows ‘Succeeded’.

ResourceGroupName : RG1
Location          : eastus
ProvisioningState : Succeeded

1. VPN assigned IP address is in range 172.16.0.0/24
2. Network for TrueNAS is in range 10.0.0.0/16

Since the VPN address is outside the range of the CIDR block for the TrueNAS ip address subnet, TrueNAS can’t respond to the incoming request. To fix this, add a Static Route for TrueNAS. To add a Static Route, expand the Network tab in the left hand menu and select Static Routes in the menu.

The left main menu in TrueNAS core with the Network tab expanded and the Static Routes tab within Network selected

From the Static Routes screen, click Add in the top right of the new screen. After that the following form will appear:

The form fields for adding a static route in TrueNAS

After the fields are populated correctly, click “Submit” and the VPN connections should now be able to reach the TrueNAS core device.

If you’re considering building a lab, chances are you’ve got a good idea of what you want to do with it. If not, then let me give you one piece of advice: THINK CAREFULLY BEFOREHAND ABOUT WHAT YOU WANT TO ACHIEVE. 10 GPU “super computers” can be great fun but are woefully unnecessary if you want a web development server. Likewise, a petabyte of redundant storage truly lives up to its name if you’re planning to use it to host a Doom multiplayer server. I know it sounds obvious, but it’s just too easy to get distracted by a great eBay deal and end up with a 900w paper weight.

I can already hear you shouting, “EBAY HO, BUY ALL THE THINGS”, but lets just slow down there for one second, soldier. This is a really, really good way to spend a whole lot of money on a stack of stuff that is worth more to a scrapyard than your homelab. There’s a ton of enterprise gear out there ready for the taking, but do your due diligence or you won’t get the good stuff. Instead, you’ll end up with a server with only one ethernet management port and no network card. It’s a bad scene when that happens, so let’s try to preclude it.

Common Use Cases

Open tower PC computers. Depicts computer repair, maintenance, service or upgrade

Most home lab users get started for very specific use cases. The starter use cases are usually:

• Game Servers
• Media Servers
• Storage and Archiving
• Web Hosting
• Certification Study
• Remote Access
• Development Servers
• Home Automation
• Crypto Currency and other Electric Waste

It is important to understand that your homelab project is not the first of its kind. There are an innumerable number of self hosted game servers, media servers, and self hosted web sites. Before breaking out the credit card, use (at-least) a google search to find a similar project which describes their setup to understand how the underlying hardware is being used. Understanding hardware is key to understanding what you will need instead of what you want or think you may need.

For example, a home media server doesn’t need a 24 port 10 G switch. It also doesn’t need an AMD Ryzen Threadripper 3990X 64Core 128Thread 2.9GHz 7nm sTRX4 CPU Processor. Both of those items will add expense and power usage, without providing a better media server. What is most important is overall disk space and making sure the disks are redundant (note disk speed is not of the utmost importance). With this in mind, you can search for a single server setup that can handle an appropriate amount of disk space for your needs.

Larger Use Cases

In the Modern Data Center: IT Engineer Installs New HDD Hard Drive and Other Hardware into Server Rack Equipment. IT Specialist Doing Maintenance, Running Diagnostics and Updating Hardware.

Larger use cases (or enterprise use cases) will combine multiple use cases from above along with new use cases, monitoring, multiple environments, additional access & control mechanisms, and more. An example of a larger use case can be an edge computing solution for home automation combined with a home security system. Another use case could be a web crawler, archiver, and data processor to create a custom search engine. A personal use case of my home lab is snapshotting/archiving documentation of older products and software so that if said documentation were no longer hosted by a third party, I’d still have access to it.

When diving into larger/enterprise use cases you often run into a different level of concerns. This particular blog post wont dive into such details; just understand there are additional costs that comes with enterprise setups. Backup power, layers of redundancy, DR & backup strategies, mitigating for natural and manmade disasters, and more. Each of these will increase cost and slowly transform a home lab into a datacenter.

Find a Deal

Buy nothing

Keep in mind that this post is meant for someone who’s already started labbing, but wants to up their gear to do more and doesn’t know where to begin.

The vast majority of us all started with an old PC or leftover parts from a previous upgrade or, maybe, from that box your parents didn’t need anymore after that they got a new present. Maybe you volunteer to take it and clean it for them and begin to use what they left behind. Personally, this is exactly how I got my original NAS.

I’d be very surprised if you’re not already sitting on a pile of old parts in some way, shape, or form. If you weren’t the kind to collect parts, you probably wouldn’t be labbing. Even if not, if all you have is one PC, use it. These days we have VirtualBox, which does a fine job of running just about everything you might want to try out. It might be a bit slow, but you can get started while you wait for your tax return/birthday money/lottery winnings to get here.

The key point is that nothing about learning the basics of homelab setup requires enterprise hardware, except, of course, for learning how enterprise hardware itself is laid out. That has its merits, but most of it can still be learned from building your own PC. Coding, Linux, FreeBSD, Win 2012 R2, containers, hypervisors, networking, storage; all of it can be done with a fairly recent laptop or desktop.

Understanding Hardware

Male computer technician repairing broken silver rack mount server while opening its parts and analyzing and understanding problem

Let’s discuss the different types of hardware options you’ll encounter; hopefully, this will save you from traveling an expensive learning curve. You don’t want to end up with a server that is so old it doesn’t support virtualization. Older servers can be power hungry and scream every time you turn them on. These tips will hopefully help you understand the difference between a $150 paperweight and a $200 deal.

This is such an important issue to me, because I have witnessed those uninitiated in homelab quickly lose their enthusiasm when they end up getting Pentium 4-era Xeons that are practically worthless. I point this out not to pound those who have just started with homelab builds into the ground, but to point out that if you don’t research, ask around, and make sure of what you’re getting, you could end up getting worthless hardware without even knowing it. And, trust me, it’s not always easy to see when you might be headed down this path. I speak from experience.

Ask Questions

Young woman asking questions to the speaker during the briefing.

There are a number of guides on the internet to help with buying of used/refurbished/old servers. Using your search engine of choice will lead you on many adventures. It cannot be stressed enough that you should understand your use case before you purchase a machine. Here are a list of questions to ask yourself:

• What kind of connections does the motherboard provide for hard drives?
  • Does the server have a raid card?
    • If the raid card fails, how hard will it be to replace?
    • If a drive fails, how hard will it be to recreate the raid cluster?
    • What is the maximum memory supported by the raid card?
  • Is this server primarily reading or writing data?
    • Is the primary reading or writing a central focus of this server?
    • What level of redundancy is needed for this data?
    • Can this server use a NAS instead of local hard drives for the non-OS (or all) data?
  • Will this server need to “trust” the hard drives attached to it? (A server may not be able to read the temperature of a hard drive and consider it to be overheating. The fans will then go full blast driving up the energy consumption and noise generation of the machine. This is a problem in servers like Dells, where there is an expectation of a Dell Certified hard drive)
• What are the network throughput needs of this project?
  • Is the network card fast enough for this project’s needs? Is the switch/router it is connected to fast enough for this project’s needs?
  • Does the card provide enough ports for the considered management setup?
  • Does it provide redundancy at the card or port level?
  • If the network card fails, how hard will it be to replace?
• What are the memory needs for the project and what are the memory options provided by the motherboard?
  • Not a question, but a note - use ECC RAM. Servers are not personal use computers and with multiple workloads running on them, ECC RAM can prevent a systemic crash that destroys all the workloads on the server.
  • Another note, don’t use DDR2 memory. Its a power hog and getting harder and harder to replace.
  • Does the motherboard except UDIMM, RDIMM, or LDIMM and in what configurations?
  • What RAM is currently available from other projects to reuse?
  • Are any processes or workloads memory intensive or is RAM general use?
• What level of compute power is needed?
  • Does the motherboard for this project support the expected CPU?
  • Does the CPU support the RAM for this server?
  • Does the CPU support virtual machine passthrough (Intel VT-d or AMD-Vi)?
  • Are vendors readily stocking this CPU?

Places to purchase

Shopping basket with computer device and accessories, 3D rendering isolated on white background

The primary place to find “deals” on retired server equipment would be eBay. eBay serves as a single point where recyclers, repurchasers, and refurbishers can sell IT equipment. In fact, most shops will have multiple “stores” that they use so that they can have a single location with different store fronts. Some shops will have a brand name that is its own web store. eBay is the place that I personally go to first when I am bored and want to look at stuff I will never buy.

There are a number of different categories to check that are not eBay: (It should be noted that this section is from an American perspective. If you searching elsewhere this guide may not be perfectly applicable to buying in your region)

Local Electronic Recyclers

Electronic recyclers are sometimes tasked to clean out old data centers. This leaves the recycler with enterprise servers and networking equipment that will need to be sold. Some items are best to pick up in person. Renting moving equipment and moving server racks to a house or office space from an electronic recycler can save thousands on such a purchase (from personal experience). Personally, I have built/purchased both my mobile testing platform and my server racks from a local electronics recycler. It’s as simple as setting up an appointment with the recycler and taking a tour of their warehouse. There may be more than just the equipment for the project being planned in there for purchase.

The major benefit of visiting an electronic recycler is that they may be willing to make a deal NOW. You are there, you have money, and they do not need to ship out the product. This can reduce their costs and in turn pass that savings on to you. However, make sure that you can move and transport the items that you bought. Server racks can weigh upwards of 400lbs and not fit in a standard rental box truck standing up. Make sure you can transport whatever you buy and that it will fit, not only in the room you purchase it for, but through the doorways to the room in question.

Government Surplus

A surplus store in the Commonwealth of Nations sells items that are used, or purchased but unused, and no longer needed. A surplus store may also sell items that are past their use by date. Additionally, there are government auctions for similar property where some amazing deals can be found. Note, these amazing deals are sought after by many personal and professional hobbyist, so don’t expect too much of an amazing deal.

Online Sales

All that can be said for online sales in this article has been stated. Anything not said should be known from your own online shopping experience. For the sake of being somewhat useful, here is a list sourced from the reddit homelab wiki buying guide:

• http://ebay.com - the best place to get used servers
  • https://www.labgopher.com/ - Ebay server search tool
  • https://geargrabber.io/ - Ebay search tool for servers and networking gear
• https://www.homelabtech.com - Refurbished Servers, Storage, Networking, and Parts
• https://www.orangecomputers.com - Refurbished Servers, Storage, Networking, and Parts
• https://www.metservers.com/ - Refurbished Servers, Desktop, Networking, and Parts
• http://www.pennelcomonline.com/ - Racks, rack accessories, or modular parts (rack strips, corners, cross-members for custom racks etc)
• https://www.ispsupplies.com - WaveGuard WG-UB-RM1 Rackmount kit for Ubiquiti EdgeRouter Lite and similar models.
• https://www.startech.com/ - Racks, rack accessories, and hard-to-find or otherwise niche tools.
• http://www.navepoint.com/ - Racks, rack accessories, and general office equipment

Using the Cloud

Private cloud left connected to Public cloud right with Hybrid cloud placed between

The cloud can be utilized to keep costs down. You read that last sentence correctly, it can be used to keep costs down. From a business perspective, it can be utilized to shift capital expenses to operational expenses. For a home lab, it can be used so that $10,000 in equipment cost can instead be spread out month to month over the course of years. As a Microsoft MVP for Azure, I have a good sense of when to use the public cloud vs when to invest in the private cloud. Hopefully, this section can provide a quick guide to when and where your project can benefit from either.

A thought that should be shared is that the entire integration with the public cloud can be dynamic, if you so choose. From the VPN components to the different offerings being consumed (unless there is a need for persistent state), the items can all be created on demand. This is said with the understanding that certain items require physical components and long term contracts. If your project requires those parameters, then the project may fall outside the definition of “home lab” being used here. Also, some items, like a VPN Gateway in Azure, may take a half hour to an hour to provision on demand. For a home lab, some pre-planning may be required due to those time constraints (as compared to an enterprise environment, where all those items will be persistent).

For a home lab, the primary purpose is to own and house the equipment running your projects. That being the primary purpose, does not mean there are no other benefits to using the public cloud in a hybrid scenario. The following are a few scenarios where using the public cloud could help reduce costs:

Scaling Out

From the above listed options for projects, some could benefit from being able to scale out due to demand. Web servers, game servers, development servers, and more may have inconsistent demand. If your project involves a forever online game server and suddenly one thousand of your closest friends plan to play together one night, then there may be a need to scale out beyond the capacity of your home lab.

Assuming the project is set up for this scenario, hosting it in the public cloud may be as simple as changing a public DNS entry and uploading your virtualization configuration of the server to a public cloud provider. An example would be Minecraft server running inside of a container. It can be quickly uploaded to something like Azure Container Instances for the evening and cost a fistful of dollars. Compared to the thousands in hardware costs that would be needed for that one evening, the public cloud can provide the required infrastructure for a fraction of the cost.

Another example could be a public web server for a one day conference. For ~360 days out of the year, the site will receive one or two hits a day. When the week of the conference arrives, it may suddenly get hundreds or thousands of hits per day. Instead of running the site in the cloud the entire year or spending capital enough to host it in your lab for the week of the conference, use the cloud the week of and the rest of the year use the home lab (private cloud).

Disaster Recovery

Some of the key tenants to a proper disaster recovery protocol is secondary location, offsite storage, or any other type of physical separation of the recovery environment. This acts as a hedge to a physical disaster in the private cloud region. This multi-locality is a primary tenant of any cloud hosting but in the home lab scenario is mostly not feasible. A public cloud offering can be a cheap disaster recovery option for the home lab. Having encrypted backups of configuration and servers paired with separately located media backups of sensitive data can be combined to form a DR strategy for the home lab.

Not everything will be cheaply hosted in a public cloud for DR purposes. If the project is a media server or data lab, then the storage fees on any media not hosted within the lab may prove to be too costly. The DR scenario that the cloud can help with, on a home lab budget, is one where the underlying data is small enough to make running costs too high.

Core Infrastructure

The recovery strategy used in my personal lab starts with core infrastructure. First, the physical hosts are configured for virtualization and then a mix of VMs and containers are deployed to start:

• Certificate Authority (with root certs being loaded from backup physical media)
• apt-mirror & docker-registry
• DNS
• LDAP
• Data Systems
• Web Servers

By using cloud offerings for some core infrastructure, both costs and restart time are minimized. For each of the following, an option could be:

• CA - Let’s Encrypt
• apt-mirror & docker-registry - use public free apt repos and docker hub
• DNS - use the name servers provided by the registrar
• LDAP - use Azure Active Directory where it can replace LDAP (don’t write me an essay about how AAD is not LDAP! I know its not but for something like an internal website or gitlab it can make a suitable replacement.)

PAAS/SAAS

Some services in the public cloud can easily out scale a home lab configured version for a lower cost point (even over the long run). Also, some offerings in the public cloud can make the completion of specific portions of the home lab project much faster. If you are building a machine learning setup, utilizing the dynamic compute capabilities of something like Azure Machine Learning to host notebooks or add compute power for the models will have a drastically lower price point than configuring the same in a home lab setup.

Another example could be adding a text messaging feature for two factor authentication. Adding in a twilio messaging account will be much lower than trying to add an entire phone. Similarly, using Office 365 or Zoho mail could be cheaper than any self hosted alternative. Moreover, the free tiers offered by Github are so fully featured now that self hosting is purely for the hobby and not for any feature benefit.

At first, the goal was simple; learn about different server technologies and edge computing by building a “data center” in a closet. The “data center” part of it is where most at home sysadmins fall into a bottomless pit of self-hosted technologies and I am no different. First it is a home media server, then a dashboard, then a database, then a data system, then a clustered set of systems, then there is suddenly a need for documentation for a lab you built yourself as it becomes too much to handle at once.

This will, hopefully, be the first of many posts about home labs that is written from personal and professional experience. Throughout the series there should be a showcase of how to use home labs for:

• Home Media
• Automation
• Edge Computing
• Archiving
• Game Servers
• Development Servers
• Access and Control
• Dynamic Public Cloud Integration
• Redundancy and Disaster Recovery
• and… more

The first and foremost discussion to have is price control. Enterprise server contracts can start at seven figures. If this is what you are looking for, then this is not the blog you seek. What this blog will focus on is how to keep a relatively low budget. Lets see how far we can make the homelab budget go!

At this point, you may be wondering why the title is “Home Lab - a lie I tell myself”. When this journey started, this was a 1-2 tower server adventure. Over time this has exploded, both in scope and in price. At this point, the name “homelab” no longer describes the system I’ve built. Not just in size but also due to the fact that it is no longer at my home. Hopefully, this series can serve as both enablement and deterrent to an ever expanding homelab.

Some helpful resources I used when I got started:

• https://www.reddit.com/r/homelab/
• https://www.reddit.com/r/homelabsales
• https://github.com/awesome-foss/awesome-sysadmin
• https://www.ebay.com/
• https://wiki.debian.org/
• https://www.truenas.com/docs/
• https://docs.ansible.com/

If this error is currently blocking progress, be sure to INSTALL MKISOFS ON THE CLIENT and don’t worry about the server!

• Create Azure Blob Storage Account
• Create TrueNAS Cloud Credentials
• Create Cloud Sync Tasks

Create Azure Blob Storage Account

Create a storage account

Every storage account must belong to an Azure resource group. A resource group is a logical container for grouping your Azure services. When you create a storage account, you have the option to either create a new resource group, or use an existing resource group. This article shows how to create a new resource group.

A general-purpose v2 storage account provides access to all of the Azure Storage services: blobs, files, queues, tables, and disks. The steps outlined here create a general-purpose v2 storage account, but the steps to create any type of storage account are similar. For more information about types of storage accounts and other storage account settings, see Azure storage account overview.

Portal

To create a general-purpose v2 storage account in the Azure portal, follow these steps:

1. On the Azure portal menu, select All services. In the list of resources, type Storage Accounts. As you begin typing, the list filters based on your input. Select Storage Accounts.
2. On the Storage Accounts window that appears, choose Add.
3. On the Basics tab, select the subscription in which to create the storage account.
4. Under the Resource group field, select your desired resource group, or create a new resource group. For more information on Azure resource groups, see Azure Resource Manager overview.
5. Next, enter a name for your storage account. The name you choose must be unique across Azure. The name also must be between 3 and 24 characters in length, and may include only numbers and lowercase letters.
6. Select a location for your storage account, or use the default location.
7. Select a performance tier. The default tier is Standard.
8. Set the Account kind field to Storage V2 (general-purpose v2).
9. Specify how the storage account will be replicated. The default replication option is Read-access geo-redundant storage (RA-GRS). For more information about available replication options, see Azure Storage redundancy.
10. Additional options are available on the Networking, Data protection, Advanced, and Tags tabs. To use Azure Data Lake Storage, choose the Advanced tab, and then set Hierarchical namespace to Enabled. For more information, see Azure Data Lake Storage Gen2 Introduction
11. Select Review + Create to review your storage account settings and create the account.
12. Select Create.

The following image shows the settings on the Basics tab for a new storage account:

Create a container

To create a container in the Azure portal, follow these steps:

1. Navigate to your new storage account in the Azure portal.
2. In the left menu for the storage account, scroll to the Blob service section, then select Containers.
3. Select the + Container button.
4. Type a name for your new container. The container name must be lowercase, must start with a letter or number, and can include only letters, numbers, and the dash (-) character. For more information about container and blob names, see Naming and referencing containers, blobs, and metadata.
5. Set the level of public access to the container. The default level is Private (no anonymous access).
6. Select OK to create the container.

Create TrueNAS Cloud Credentials

To begin integrating TrueNAS with a Cloud Storage provider, register the account credentials on the system. After saving any credentials, a Cloud Sync Task allows sending or receiving data from that Cloud Storage Provider.

Saving a Cloud Storage Credential

Transferring data from TrueNAS to the Cloud requires saving Cloud Storage Provider credentials on the system.

It is recommended to have another browser tab open and logged in to the Cloud Storage Provider account you intend to link with TrueNAS. Some providers require additional information that is generated on the storage provider account page. For example, saving an Amazon S3 credential on TrueNAS could require logging in to the S3 account and generating an access key pair on the Security Credentials > Access Keys page.

To save cloud storage provider credentials, go to System > Cloud Credentials and click Add.

Using the Azure Portal we can retrieve our access keys.

Create Cloud Sync Tasks

TrueNAS can send, receive, or synchronize data with a Cloud Storage provider. Cloud Sync tasks allow for single time transfers or recurring transfers on a schedule, and are an effective method to back up data to a remote location.

Go to Tasks > Cloud Sync Tasks and click Add.

Give the task a memorable Description and select an existing cloud Credential. TrueNAS connects to the chosen Cloud Storage Provider and shows the available storage locations. Decide if data is transferring to (PUSH) or from (PULL) the Cloud Storage location (Remote). Choose a Transfer Mode:

Next, Control when the task runs by defining a Schedule. When a specific Schedule is required, choose Custom and use the Advanced Scheduler.Advanced Schedulerexpand

Unsetting Enable makes the configuration available without allowing the Schedule to run the task. To manually activate a saved task, go to Tasks > Cloud Sync Tasks, click to expand a task, and click RUN NOW.

The remaining options allow tuning the task to your specific requirements.Specific Optionsexpand

Transfer

Remote

Control

Advanced Options

Advanced Remote Options

Scripting and Environment Variables

Advanced users can write scripts that run immediately before or after the Cloud Sync task. The Post-script field is only run when the Cloud Sync task successfully completes. You can pass a variety of task environment variables into the Pre- and Post- script fields:

• CLOUD_SYNC_ID
• CLOUD_SYNC_DESCRIPTION
• CLOUD_SYNC_DIRECTION
• CLOUD_SYNC_TRANSFER_MODE
• CLOUD_SYNC_ENCRYPTION
• CLOUD_SYNC_FILENAME_ENCRYPTION
• CLOUD_SYNC_ENCRYPTION_PASSWORD
• CLOUD_SYNC_ENCRYPTION_SALT
• CLOUD_SYNC_SNAPSHOT

There also are provider-specific variables like CLOUD_SYNC_CLIENT_ID or CLOUD_SYNC_TOKEN or CLOUD_SYNC_CHUNK_SIZE

Remote storage settings:

• CLOUD_SYNC_BUCKET
• CLOUD_SYNC_FOLDER

Local storage settings:

• CLOUD_SYNC_PATH

Testing Settings

Test the settings before saving by clicking DRY RUN. TrueNAS connects to the Cloud Storage Provider and simulates a file transfer. No data is actually sent or received. A dialog shows the test status and allows downloading the task logs.

Cloud Sync Behavior

Saved tasks are activated according to their schedule or by clicking RUN NOW. An in-progress cloud sync must finish before another can begin. Stopping an in-progress task cancels the file transfer and requires starting the file transfer over.

To view logs about a running or the most recent run of a task, click the task status.

Cloud Sync Restore

To quickly create a new Cloud Sync that uses the same options but reverses the data transfer, expand () an existing Cloud Sync and click RESTORE.

Enter a new Description for this reversed task and define the path to a storage location for the transferred data.

The restored cloud sync is saved as another entry in Tasks > Cloud Sync Tasks.

One of the major benefits of NFS is being able to easily migrate a container from one environment to another. By using the NFS, the container or VM is pulled over the network which allows any host to host ad hoc. Migrating VMs or containers takes seconds.

TrueNAS NFS support

Creating a Network File System (NFS) share on TrueNAS gives the benefit of making lots of data easily available for anyone with share access. Depending how the share is configured, users accessing the share can be restricted to read or write privileges.To create a new share, make sure a dataset is available with all the data for sharing.

Creating an NFS Share

Go to Sharing > Unix Shares (NFS) and click ADD.

Use the file browser to select the dataset to be shared. An optional Description can be entered to help identify the share. Clicking SUBMIT creates the share. At the time of creation, you can select ENABLE SERVICE for the service to start and to automatically start after any reboots. If you wish to create the share but not immediately enable it, select CANCEL.

NFS Share Settings

To edit an existing NFS share, go to Sharing > Unix Shares (NFS) and click more_vert > Edit. The options available are identical to the share creation options.

Configure the NFS Service

To begin sharing the data, go to Services and click the NFS toggle. If you want NFS sharing to activate immediately after TrueNAS boots, set Start Automatically.

NFS service settings can be configured by clicking (Configure).

Unless a specific setting is needed, it is recommended to use the default settings for the NFS service. When TrueNAS is already connected to Active Directory, setting NFSv4 and Require Kerberos for NFSv4 also requires a Kerberos Keytab.

Proxmox NFS storage pool

The NFS backend is based on the directory backend, so it shares most properties. The directory layout and the file naming conventions are the same. The main advantage is that you can directly configure the NFS server properties, so the backend can mount the share automatically. There is no need to modify /etc/fstab. The backend can also test if the server is online, and provides a method to query the server for exported shares.

The backend supports all common storage properties, except the shared flag, which is always set. Additionally, the following properties are used to configure the NFS server:

server - Server IP or DNS name. To avoid DNS lookup delays, it is usually preferable to use an IP address instead of a DNS name - unless you have a very reliable DNS server, or list the server in the local /etc/hosts file.

export - NFS export path (as listed by pvesm nfsscan). You can also set NFS mount options:

path - The local mount point (defaults to /mnt/pve/<STORAGE_ID>/).

options - NFS mount options (see man nfs).

• Creating a table LIKE our table that needs logging
• Create a function for our table
• Apply that function as a trigger

Table Like

First we need an example table to get started with. For a simple example, lets use a basic address table.

https://gist.github.com/QiMata/ad12fbbf5736fb582249694ac9627757

This basic table has enough constraints to make a decent example. We need to create a copy of this table, one where the columns are the same name and type, but without all of the constraints. Luckily for us, PostgreSQL provides a feature for just a situation. For this, we want to use the like_option for the CREATE TABLE statement. According the latest documentation (PostgreSQL 12) at the time of writing this post:

The LIKE clause specifies a table from which the new table automatically copies all column names, their data types, and their not-null constraints.

Unlike INHERITS, the new table and original table are completely decoupled after creation is complete. Changes to the original table will not be applied to the new table, and it is not possible to include data of the new table in scans of the original table.

Also unlike INHERITS, columns and constraints copied by LIKE are not merged with similarly named columns and constraints. If the same name is specified explicitly or in another LIKE clause, an error is signaled.

The optional like_option clauses specify which additional properties of the original table to copy. Specifying INCLUDING copies the property, specifying EXCLUDING omits the property. EXCLUDING is the default. If multiple specifications are made for the same kind of object, the last one is used.

We will want to exclude all constraints so that when our trigger fires, it can write any data to the columns without worrying if those columns are valid. The resulting table definition looks like the following:

https://gist.github.com/QiMata/32546c1d481fa8f3c04f5976614e1e9d

Logging Function

Next, there needs to be a trigger that logs the data. To create a new trigger in PostgreSQL, you follow these steps:

• • First, create a trigger function using <a href="https://www.postgresqltutorial.com/postgresql-create-function/">CREATE FUNCTION</a> statement.
    • Second, bind the trigger function to a table by using CREATE TRIGGER statement.

A trigger function is similar to an ordinary function. However, a trigger function does not take any argument and has a return value with the type of trigger. Inside this trigger function, insert the old data into the logging table. This makes the trigger function as follows:

https://gist.github.com/QiMata/45d698713e5f703af246e8eef7c16f1a

TG_OP is Data type text; a string of INSERT, UPDATE, DELETE, or TRUNCATE telling for which operation the trigger was fired.

Implementing the Trigger

As we said earlier, Second, bind the trigger function to a table by using CREATE TRIGGER statement. This part is fairly easy.

https://gist.github.com/QiMata/7f7ea3929029bd815821bdcddf444182

Now, whenever you insert, update, or delete a record in the address table, the operation is logged in the logging address table.

• Creating the Custom Vision Model
• Creating the Edge Module in Python
• Adding the model and custom code for Custom Vision
• Deploy the Module

Creating the Custom Vision Model

To use the Custom Vision Service for image classification, you must first build a classifier model. In this guide, you’ll learn how to build a classifier through the Custom Vision website.

Prerequisites

• A valid Azure subscription. Create an account for free.
• A set of images with which to train your classifier. See below for tips on choosing images.

Create Custom Vision resources in the Azure portal

To use Custom Vision Service, you will need to create Custom Vision Training and Prediction resources in the Azure portal. This will create both a Training and Prediction resource.

Create a new project

In your web browser, navigate to the Custom Vision web page and select Sign in. Sign in with the same account you used to sign into the Azure portal.

1. To create your first project, select New Project. The Create new project dialog box will appear.
2. Enter a name and a description for the project. Then select a Resource Group. If your signed-in account is associated with an Azure account, the Resource Group dropdown will display all of your Azure Resource Groups that include a Custom Vision Service Resource.
3. Select Classification under Project Types. Then, under Classification Types, choose either Multilabel or Multiclass, depending on your use case. Multilabel classification applies any number of your tags to an image (zero or more), while multiclass classification sorts images into single categories (every image you submit will be sorted into the most likely tag). You will be able to change the classification type later if you wish.

4. Next, select one of the available domains. Each domain optimizes the classifier for specific types of images, as described in the following table. You will be able to change the domain later if you wish. | Domain | Purpose | |—|—| | Generic | Optimized for a broad range of image classification tasks. If none of the other domains are appropriate, or you are unsure of which domain to choose, select the Generic domain. | | Food | Optimized for photographs of dishes as you would see them on a restaurant menu. If you want to classify photographs of individual fruits or vegetables, use the Food domain. | | Landmarks | Optimized for recognizable landmarks, both natural and artificial. This domain works best when the landmark is clearly visible in the photograph. This domain works even if the landmark is slightly obstructed by people in front of it. | | Retail | Optimized for images that are found in a shopping catalog or shopping website. If you want high precision classifying between dresses, pants, and shirts, use this domain. | | Compact domains | Optimized for the constraints of real-time classification on mobile devices. The models generated by compact domains can be exported to run locally. |

5. Finally, select Create project.

Choose training images

As a minimum, we recommend you use at least 30 images per tag in the initial training set. You’ll also want to collect a few extra images to test your model once it is trained.

In order to train your model effectively, use images with visual variety. Select images with that vary by:

• camera angle
• lighting
• background
• visual style
• individual/grouped subject(s)
• size
• type

Additionally, make sure all of your training images meet the following criteria:

• .jpg, .png, or .bmp format
• no greater than 6MB in size (4MB for prediction images)
• no less than 256 pixels on the shortest edge; any images shorter than this will be automatically scaled up by the Custom Vision Service

Upload and tag images

In this section you will upload and manually tag images to help train the classifier.

1. To add images, click the Add images button and then select Browse local files. Select Open to move to tagging. Your tag selection will be applied to the entire group of images you’ve selected to upload, so it is easier to upload images in separate groups according to their desired tags. You can also change the tags for individual images after they have been uploaded.
2. To create a tag, enter text in the My Tags field and press Enter. If the tag already exists, it will appear in a dropdown menu. In a multilabel project, you can add more than one tag to your images, but in a multiclass project you can add only one. To finish uploading the images, use the Upload [number] files button.
3. Select Done once the images have been uploaded.

To upload another set of images, return to the top of this section and repeat the steps.

Train the classifier

To train the classifier, select the Train button. The classifier uses all of the current images to create a model that identifies the visual qualities of each tag.

The training process should only take a few minutes. During this time, information about the training process is displayed in the Performance tab.

Custom Vision Service supports the following exports:

• Tensorflow for Android.
• CoreML for iOS11.
• ONNX for Windows ML.
• A Windows or Linux container. The container includes a Tensorflow model and service code to use the Custom Vision Service API.

Convert to a compact domain

To convert the domain of an existing classifier, use the following steps:

1. From the Custom vision page, select the Home icon to view a list of your projects. You can also use the https://customvision.ai/projects to see your projects.
2. Select a project, and then select the Gear icon in the upper right of the page.
3. In the Domains section, select a compact domain. Select Save Changes to save the changes.
4. From the top of the page, select Train to retrain using the new domain.

Export your model

To export the model after retraining, use the following steps:

1. Go to the Performance tab and select Export. Tip

   If the Export entry is not available, then the selected iteration does not use a compact domain. Use the Iterations section of this page to select an iteration that uses a compact domain, and then select Export.

2. Select the export format, and then select Export to download the model.

Creating the Edge Module in Python

You can use Azure IoT Edge modules to deploy code that implements your business logic directly to your IoT Edge devices. This tutorial walks you through creating an IoT Edge module that will be edited to use the Custom Vision model exported. In this tutorial, you learn how to:

• Use Visual Studio Code to create an IoT Edge Python module.
• Use Visual Studio Code and Docker to create a Docker image and publish it to your registry.

If you don’t have an Azure subscription, create a free account before you begin.

Prerequisites

Before beginning this tutorial, you should have gone through the previous tutorial to set up your development environment for Linux container development: Develop IoT Edge modules for Linux devices. By completing either of those tutorials, you should have the following prerequisites in place:

• A free or standard-tier IoT Hub in Azure.
• A Linux device running Azure IoT Edge
• A container registry, like Azure Container Registry.
• Visual Studio Code configured with the Azure IoT Tools.
• Docker CE configured to run Linux containers.

To develop an IoT Edge module in Python, install the following additional prerequisites on your development machine:

• Python extension for Visual Studio Code.
• Python.
• Pip for installing Python packages (typically included with your Python installation).

Create a module project

The following steps create an IoT Edge Python module by using Visual Studio Code and the Azure IoT Tools.

Create a new project

Use the Python package cookiecutter to create a Python solution template that you can build on top of.

1. In Visual Studio Code, select View > Terminal to open the VS Code integrated terminal.
2. In the terminal, enter the following command to install (or update) cookiecutter, which you use to create the IoT Edge solution template: pip install --upgrade --user cookiecutter
3. Select View > Command Palette to open the VS Code command palette.
4. In the command palette, enter and run the command Azure: Sign in and follow the instructions to sign in your Azure account. If you’re already signed in, you can skip this step.

In the command palette, enter and run the command Azure IoT Edge: New IoT Edge solution. Follow the prompts and provide the following information to create your solution:

Add your registry credentials

The environment file stores the credentials for your container repository and shares them with the IoT Edge runtime. The runtime needs these credentials to pull your private images onto the IoT Edge device.

1. In the VS Code explorer, open the .env file.
2. Update the fields with the username and password values that you copied from your Azure container registry.
3. Save the .env file.

Select your target architecture

Currently, Visual Studio Code can develop C modules for Linux AMD64 and Linux ARM32v7 devices. You need to select which architecture you’re targeting with each solution, because the container is built and run differently for each architecture type. The default is Linux AMD64.

1. Open the command palette and search for Azure IoT Edge: Set Default Target Platform for Edge Solution, or select the shortcut icon in the side bar at the bottom of the window.
2. In the command palette, select the target architecture from the list of options. For this tutorial, we’re using an Ubuntu virtual machine as the IoT Edge device, so will keep the default amd64.

Adding the model and custom code for Custom Vision

Deploy the Module

Build and push your module

In the previous section, you created an IoT Edge solution and added code to the PythonModule that will filter out messages where the reported machine temperature is within the acceptable limits. Now you need to build the solution as a container image and push it to your container registry.

1. Open the VS Code integrated terminal by selecting View > Terminal.
2. Sign in to Docker by entering the following command in the terminal. Sign in with the username, password, and login server from your Azure container registry. You can retrieve these values from the Access keys section of your registry in the Azure portal. ```

    docker login -u <ACR username> -p <ACR password> <ACR login server>
   
    ```You may receive a security warning recommending the use of ```
    --password-stdin
    ```. While that best practice is recommended for production scenarios, it's outside the scope of this tutorial. For more information, see the <a href="https://docs.docker.com/engine/reference/commandline/login/#provide-a-password-using-stdin">docker login</a> reference. In the VS Code explorer, right-click the <strong>deployment.template.json</strong> file and select <strong>Build and Push IoT Edge solution</strong>.
   

   The build and push command starts three operations. First, it creates a new folder in the solution called config that holds the full deployment manifest, built out of information in the deployment template and other solution files. Second, it runs docker build to build the container image based on the appropriate dockerfile for your target architecture. Then, it runs docker push to push the image repository to your container registry.

Deploy modules to device

Use the Visual Studio Code explorer and the Azure IoT Tools extension to deploy the module project to your IoT Edge device. You already have a deployment manifest prepared for your scenario, the deployment.json file in the config folder. All you need to do now is select a device to receive the deployment.

Make sure that your IoT Edge device is up and running.

1. In the Visual Studio Code explorer, expand the Azure IoT Hub Devices section to see your list of IoT devices.
2. Right-click the name of your IoT Edge device, then select Create Deployment for Single Device.
3. Select the deployment.json file in the config folder and then click Select Edge Deployment Manifest. Do not use the deployment.template.json file.
4. Click the refresh button. You should see the new PythonModule running along with the TempSensor module and the $edgeAgent and $edgeHub.