Hello everyone, in this video I will show you how to convert a Windows operating system installed on a physical server into a VMware ESXi virtual machine.

• Here is my ESXi environment.

• 10.2.7.11 is my ‘physical’ server. It’s not an actual physical machine — it’s a VM running on ESXi, but for demonstration purposes, you can think of it as a physical server. I don’t have a physical server in my test environment, so I’m using a VM to simulate one.

• 10.2.7.10 , This is the server I’ll be using as a proxy to convert the physical server into a virtual machine. I’ll install VMware Converter tools here, and then use them to carry out the conversion. The advantage of this method is that you don’t need to install anything on the source Windows server.

Click for download VMware Converter tools

• Now, let’s install VMware Converter tools on this server.

• Run as administrator.

• Next.

• Next.

• Here we have two options: Local Installation and Client-Server Installation.
Local Installation means the Converter will be installed and used directly on this machine.
Client-Server Installation allows you to install the Converter service here and control it remotely from another computer, which is great if you need to manage multiple conversions from one place.
If you want to convert another machine, you should choose the Client-Server option.

• Here we have two options: Local Installation and Client-Server Installation.
Local Installation installs everything on this computer, and you can only manage conversions from here.
Client-Server Installation lets you manage conversions from another computer by connecting to this one. This is useful if you want to control the process remotely or from a central location.
In our case, we want to convert another machine, so we’re choosing the Local Installation option.

• Next.

• Next.

• Install.

• Now, click Finish to launch the application.

• This is VMware Converter, a tool that lets you convert physical machines, VMware virtual machines, and Hyper-V virtual machines into VMware virtual machines.

• Now, let’s start converting our physical server into a virtual machine.

• Click ‘Convert Machine’.

• This is your source machine information. You need to enter the IP address and credentials of your source machine. The credentials entered here must have full permissions on the source machine.

• By clicking on ‘View Source Information’, this tool will install a small agent on the source machine to gather information and perform the tasks required to convert that machine into a virtual machine.

• As you can see, the agent is installed temporarily, and after a successful conversion, it will be automatically removed from the source machine.

• Yes.

• OK, this is the source machine information.

• Close.

• We also have three options here: Remote Windows Machine, Remote Linux Machine, and This Local Machine.

• Next.

• This is our target, or destination, information.

• 10.2.6.2 is our ESXi target.

• Enter the ESXi root credentials. It’s not necessary to use the root username, but the account you use should have full permissions.

• Next.

• This is a certificate warning. Click Ignore.

• Here we should give the name of the machine that will be imported to ESXi.

• Next.

• Here you can see the datastores available on your ESXi host. The files for the converted machine will be stored on the selected datastore.

• Next.

• You can see the tasks that will be performed during the conversion, and you can edit these settings.

• These are the volumes on the source machine.

• You can change the volume settings on the destination virtual machine — for example, you can change the disk type to thin provisioning on the destination virtual machine.

• Next.

• Finish.

• OK, the conversion process has started, and you can monitor the tasks and their status from here. The duration will depend on the network connection speed between the source and destination.

• The conversion task has not yet completed, but as you can see, the virtual machine has been created.

• The data has been copied to the ESXi datastore, and the conversion is being finalized in the background. Do not power on the virtual machine until the conversion task is finished.

• OK, that’s completed. Now, power on the virtual machine.

• The physical server has been converted to a virtual machine. You can change its settings just like any other virtual machine.

• That’s great, everything works fine.

Hello everyone, in this video I will show you how to install MSSQL Always On and configure an Availability Group on the servers

·         In this video, we will install MSSQL Server on two servers: MSSQL1 and MSSQL2. These are our servers. I have already added them to the domain and created a specific Organizational Unit, placing these servers under that Organizational Unit.

·         This is MSSQL1.

·         This is MSSQL2.

·         Before installing SQL on these servers, I need to activate the Failover Clustering feature on them.

·         First, activate the Failover Clustering feature on the MSSQL1 server.

·         Click on Add Roles and Features.

·         Click Next.

·         Next.

·         Next.

·         Select the Failover Clustering feature.

·         Click Add Features.

·         Next.

·         Install.

·         Activate Failover Clustering on MSSQL2 in the same way.

·         Okay, wait for a few minutes to complete activating Failover Clustering on both servers.

·         To use the Failover Clustering feature, a dedicated network interface is used on both servers to handle cluster traffic. Using a dedicated interface on the servers is recommended.

·         Rename this interface to ‘Cluster’.

·         Rename the interface on the MSSQL2 server to ‘Cluster’ as well.

·         Ethernet0 is the management interface we use to handle server traffic.

·         If you plan to use MSSQL Always On, the SQL service must run on the servers using domain user accounts instead of service accounts. Therefore, I created a user in Active Directory.

·         Uncheck this box and check that box.

·         Alright, Failover Clustering has been enabled on MSSQL1.

·         Close.

·         Open Run and type control userpasswords2.

·         Add the user created for the MSSQL service to the local administrators group on both servers.

·         Finish.

·         Add that user to the local administrators group on MSSQL2 in the same way.

·         Failover Clustering has also been enabled on MSSQL2.

·         Now, it’s time to configure the Failover Cluster on these servers.

·         Open the Failover Cluster Manager.

·         Click on ‘Validate Configuration’ to check and verify the servers’ prerequisites and requirements before creating a cluster between these servers.

·         Next.

·         Here, we select the servers that we want to join the cluster and work as part of the cluster.

·         Check name.

·         Select.

·         Select both of the servers.

·         Ok.

·         Next.

·         Run All Tests.

·         Next.

·         The checking process is currently ongoing.

·         There is no need to run validation and cluster configuration on another server.

·         We received some errors and warnings, but because this is a test environment, they are not critical. These issues are typically related to network interfaces and server connections. In a production environment, you should ideally not encounter any warnings or errors.

·         After validating the configuration, it’s time to create the cluster.

·         Click on ‘Create Cluster’.

·         Next.

·         Select the servers to be part of the cluster.

·         Next.

·         Next, we need to assign a name and IP address to the cluster. This is for the Windows Cluster service and is not related to MSSQL.

·         Next.

·         Next.

·         When you look in Active Directory Users and Computers, you’ll find the cluster name object created in the Computers container, within the same Organizational Unit as your servers.

·         Okay, our cluster has been created.

·         Check the status of the cluster nodes.

·         Both servers are online.

·         As you can see, there is no witness configured.

·         Right-click the cluster, then go to More Actions and select ‘Configure Cluster Quorum Settings’.

·         Choose ‘Select the quorum witness’ and click Next.

·         Choose ‘Configure a File Share Witness’ and then click Next.

·         Here, choose a shared folder. I prefer to use a shared folder located on the Active Directory server.

·         Click ‘Browse’ to choose the Active Directory server.

·         Click ‘Browse’ again.

·         Since there is no shared folder, click on ‘New Shared Folder’.

·         The local path of the shared folder points to a folder on the Active Directory server.

·         As you can see, I am using a root folder on the C drive.

·         Specify the name of the shared folder to be created on the Active Directory server’s C drive, and assign read and write permissions to all users.

·         Ok.

·         Ok.

·         Next.

·         Finish.

·         Okay, the witness has been created.

·         The Windows Failover Cluster configuration is now complete and functioning correctly. Both servers monitor each other, so if one fails, the other takes over seamlessly. Services continue to run without interruption.

·         In the next step, we are going to install the MSSQL service on the servers.

·         Run the setup as an administrator to start installing SQL on MSSQL1.

·         Go to Installation and choose ‘New SQL Server stand-alone installation’.

·         Begin installing SQL on MSSQL2 at the same time as on MSSQL1. While this isn’t required, I run the setup on both servers simultaneously to save time.

·         The SQL Server installation steps are the same for both servers.

·         Enter your product key and click Next.

·         Accept.

·         Next.

·         Select the features you want to install based on your needs, but make sure to select Database Engine Services to install the SQL service on the server.

·         Next.

·         Repeat the same steps on MSSQL2.

·         Keep the default instance or modify it according to your requirements.

·         At this point, change the service account to the domain account we created earlier, which is already added as a local administrator on MSSQL1 and MSSQL2.

·         Enter the account password and set the startup type to Automatic.

·         Applying the same changes to the Database Engine service.

·         Leave the settings for SQL Server Browser as they are.

·         Select Mixed Mode from the authentication section and enter a strong password. This is your SQL Server SA account.

·         Also, click on ‘Add Current User’ to add the logged-in user as a SQL administrator. These settings can be adjusted based on your requirements.

·         Next.

·         Install.

·         Continue the installation on the MSSQL2 server.

·         SQL installation on both servers is complete. Next, we’ll configure SQL Server to work as Always On.

·         Open SQL Server Configuration Manager.

·         In SQL Server Services, right-click on SQL Server and choose Properties.

·         Select ‘Always On Availability Groups’ and check ‘Enable Always On Availability Groups’.

·         Ok.

·         You need to restart the SQL Server service for the change to take effect.

·         Repeat the same steps on the other server.

·         Ok.

·         Restart.

·         Alright, now open SQL Server Management Studio.

·         Connect to MSSQL1.

·         Now, we need to assign permissions to the Organizational Unit containing the MSSQL servers. Provide full permissions to the user running the SQL services, and also grant permissions to the computers and cluster objects to manage the Organizational Unit. This allows the SQL service to manage the cluster computers properly.

·         As you can see, the Security tab is not visible. To fix this, enable Advanced Features from the View menu.

·         Return to Management Studio.

·         In Always On High Availability, right-click on Availability Groups and choose ‘New Availability Group Wizard’.

·         Next.

·         Enter a name for the Availability Group.

·         Next.

·         Since we don’t have any database, I can’t proceed with the wizard. Let’s create a test database before we start.

·         Right-click on Databases and select ‘New Database’.

·         Enter a name for the database.

·         Go to the Options section and verify that the Recovery Model is set to Full.

·         To add any database to an Availability Group, the database recovery model must be set to Full.

·         Ok.

·         Additionally, before adding a database to the Availability Group, a full backup of the database must be taken.

·         Right-click the database, go to Tasks, and click Backup.

·         Set the backup type to Full.

·         Ok.

·         Ok.

·         Open the New Availability Group Wizard again.

·         Next.

·         Write the name of Availability Group.

·         Next.

·         Select Test database.

·         Next.

·         Here is MSSQL1. Click ‘Add Replica’ to add MSSQL2 as a replica and configure the availability group to synchronize data between both servers.

·         These are the availability modes, and here you can see the differences between them.

·         The mode you choose depends on your requirements.

·         I prefer to use synchronous commit.

·         And here you can see the endpoints.

·         Backup preferences are also shown here.

·         At this step, the Listener section is the most important.

·         Choose ‘Create an Availability Group Listener’.

·         Type the DNS name for the listener.

·         Specify the port to be used for SQL connections from clients.

·         Select the interface subnet that will listen for SQL connections.

·         Specify the virtual IP address that will be used for SQL Always On.

·         Since we granted permissions to the SQL service account and server computers, the listener DNS name and IP address will be created automatically.

·         Next.

·         Choose Automatic Seeding, then click Next.

·         Next.

·         Finish.

·         Alright, all tasks have been completed successfully.

·         As you can see, both servers are listed under Available Replicas.

·         Under Available Databases, you can find the databases added to Always On. They will function correctly during server failures, with data maintained on all replicas.

·         You can add more databases to this list later.

·         Databases added to Always On appear as synchronous.

·         Let’s verify the listener and try connecting to the database through the listener name.

·         Enter the listener name.

·         Alright, as you can see, we connect to the database via the listener name. Even if one server fails, our connection remains intact.

·         To check the replication status, right-click the Availability Group name and select ‘Show Dashboard’.

·         MSSQL1 is currently the primary server. I will do a failover to switch the primary server to MSSQL2.

·         Next.

·         Choose the new primary server.

·         Next.

·         Connect to the new primary MSSQL server instance.

·         Next.

·         Finish.

·         Alright, as you can see, the failover happened, and after a few seconds, the sync status will show green. During this time, the database remains fully functional.

·         Performing failover again to change the primary server back to MSSQL1.

·         Next, create a new database on MSSQL1 and include it in Always On.

·         The recovery model is set to Full.

·         Take a full backup.

·         Right-click on the available database.

·         Add database.

·         Choose the database you want to add to Always On.

·         Next.

·         Connect to MSSQL2 server instance.

·         Next.

·         Next.

·         Finish.

·         You can see that both databases are marked as synchronous.

1. Update YUM

Updating YUM itself might solve some compatibility issues:

yum update

yum install wget 

2. Check Network Connectivity

Ensure the server has internet access, as YUM needs to download packages from repositories online. Test with:

ping google.com

If there’s no response, troubleshoot the network connection first.

3. Verify Repository Configuration

Check that your repository configuration files are correctly set up in /etc/yum.repos.d/ Sometimes, repositories may be disabled or misconfigured. Ensure all necessary repositories are enabled.

4. Install CentOS Base and Updates Repositories (Default Repos)

CentOS comes with default repositories configured in /etc/yum.repos.d/CentOS-Base.repo. This file contains sections for:

• base: The main OS packages.
• updates: Updates to the packages.
• extras: Additional packages that complement the base OS.
• centosplus: Extended packages not included in the base.

Make sure this file exists and has the necessary sections. You can edit it using a text editor like nano or vi:

vi CentOS-Base

    [base]
    name=CentOS-$releasever - Base
    baseurl=https://vault.centos.org/7.9.2009/os/$basearch/
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
    enabled=1

    [updates]
    name=CentOS-$releasever - Updates
    baseurl=https://vault.centos.org/7.9.2009/updates/$basearch/
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
    enabled=1

    [extras]
    name=CentOS-$releasever - Extras
    baseurl=https://vault.centos.org/7.9.2009/extras/$basearch/
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
    enabled=1

    [centosplus]
    name=CentOS-$releasever - Plus
    baseurl=https://vault.centos.org/7.9.2009/centosplus/$basearch/
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
    enabled=0

insert mode changes to action mode

now type…

  : w q ! 

to save the file and close file editor.

5. Run Yum Update Again

yum update

okay fixed.

Migrating a VMware virtual machine (VM) to Proxmox involves a series of steps to convert and transfer the VM to the new environment. Here’s a detailed description of the process:

1. Prepare the VMware VM for Migration:
   – Shutdown the VM: Ensure the VMware VM is properly shut down to avoid any corruption during the migration.
   – Check Disk Format: Verify the format of the VMware VM’s disk files. VMware typically uses VMDK (Virtual Machine Disk) format, which will need to be converted for use in Proxmox.

2. Export the VM from VMware:
   – Export OVF/OVA: In VMware vSphere or Workstation, you can export the VM as an OVF (Open Virtualization Format) or OVA (Open Virtualization Appliance) package. This exports both the VM’s disk and configuration files.
   – Download the VMDK: Alternatively, if exporting to OVF/OVA isn’t an option, you can directly copy the VMDK file.

3. Convert the Disk Format:
   – Install qemu-img on Proxmox: Proxmox uses the QCOW2 or raw disk format, so the VMDK disk from VMware needs to be converted.
     – Run the following command on Proxmox to convert the disk:
       qemu-img convert -f vmdk -O qcow2 /path/to/source.vmdk /path/to/destination.qcow2
     – Alternatively, you can convert the disk to raw format:
       qemu-img convert -f vmdk -O raw /path/to/source.vmdk /path/to/destination.raw

4. Create a New VM on Proxmox:
   – Create a New VM: In the Proxmox Web UI, create a new VM with the same configuration as the original VMware VM (e.g., CPU, RAM, and network settings).
   – Attach Converted Disk: In the new VM settings, attach the converted disk file (QCOW2 or raw) by navigating to the “Hardware” tab and selecting the correct storage type.

5. Configure Network and Drivers:
   – Adjust Network Settings: Ensure the network settings in Proxmox match those from VMware, particularly IP addressing and VLAN configuration.
   – Install Proxmox Guest Tools: If necessary, install the Proxmox guest tools (similar to VMware Tools) to optimize performance and compatibility with Proxmox drivers.
6. Start the VM on Proxmox:
   – Boot the VM: Start the VM and verify that it functions as expected. Check if the OS boots properly and if all services are running correctly.
   – Install/Update Drivers: If the VM was using VMware-specific drivers (like VMware Tools), you might need to install the appropriate drivers for Proxmox/KVM to ensure optimal performance.

7. Post-Migration Checks:
   – Check Disk and Network Performance: Ensure that disk I/O and network performance are stable. Proxmox uses KVM/QEMU for virtualization, so some configurations might need tuning.
   – Remove VMware Tools: If applicable, uninstall VMware Tools from the guest OS to avoid conflicts.

Optional: Storage and Backup Integration:
   – Backup Configuration: If you’re using Proxmox’s built-in backup solution (or integrating with Veeam Backup), configure backups for the migrated VM.
   – Proxmox Cluster: If the Proxmox environment is clustered, ensure the VM is properly integrated into the Proxmox Cluster for High Availability (HA).

1. Prerequisites:

• A Proxmox VE cluster or standalone Proxmox server running.
• Veeam Backup & Replication 12.2 installed on a Windows server.
• Ensure Proxmox has the Veeam Agent for Linux installed if you’re doing an agent-based backup.

2. Backup Process:

A. Adding the Proxmox Host to Veeam:

1. Open the Veeam Backup & Replication console.
2. Go to “Inventory” > “Managed Servers.”
3. Right-click and select “Add Server.”
4. Choose “Linux,” as Proxmox is based on Debian.
5. Enter the IP address or hostname of the Proxmox server and provide the SSH credentials (root or a user with appropriate permissions).
6. Verify the connection, and Veeam will add Proxmox to its managed inventory.

B. Creating Backup Jobs:

1. Go to the “Home” tab and select “Backup Job.”
2. Choose “Virtual Machine” as the backup type.
3. Select the Proxmox VMs you want to back up.
4. Choose your backup repository (storage location for backups).
5. Configure the backup schedule, retention policies, and any advanced options like encryption or compression.
6. Save and start the backup job.

C. Monitoring Backups:

• You can monitor backup jobs in the “History” or “Home” tab to ensure backups run successfully.

3. Restore Process:

A. Full VM Restore:

1. In the Veeam console, go to the “Home” tab and select “Restore.”
2. Choose “Entire VM” and select the Proxmox VM from your backup repository.
3. Choose the restore point you want to use and follow the wizard to select the destination Proxmox server.
4. Confirm and start the restore process.

B. File-Level Restore:

1. Go to “Home” > “Restore” and select “Guest files (Linux).”
2. Choose the backup point and select the VM you want to restore files from.
3. Browse the file system and restore specific files or directories.

C. Instant Recovery:

1. Select “Instant Recovery” to start the VM directly from the backup storage.
2. This allows for minimal downtime while restoring the actual VM in the background.

4. Key Features of Veeam with Proxmox:

• Incremental Backups: Efficient use of storage by backing up only changes after the initial backup.
• Compression and Deduplication: Reduces backup size and storage requirements.
• Instant VM Recovery: Allows quick recovery of critical VMs with minimal downtime.
• Application-Aware Backups: Ensures consistency for applications like databases.

Setting up your own free cloud server with features like voice and video calls, file sharing, and screen sharing is possible using Nextcloud. Nextcloud is an open-source platform that offers cloud storage and collaboration tools, making it an ideal choice for both office and home environments. Here’s an overview of how you can set it up:

1. What is Nextcloud?

Nextcloud is a self-hosted cloud platform that allows you to store files, share documents, and collaborate with others. It includes apps for productivity, communication, and team collaboration. Some of the key features include:

– File storage and sharing
– Collaboration tools (calendars, tasks, document editing)
– Communication tools (video and voice calls, chat)
– Screen sharing for meetings and remote support
– End-to-end encryption and strong security controls

2. Core Features for Office or Home Use

– File Sharing: Store your files securely and share them with your team or family members. You can set permissions and use password-protected links for sensitive documents.
– Voice and Video Calling: With the Nextcloud Talk app, you can host voice and video calls directly from your Nextcloud instance, eliminating the need for third-party services.
– Screen Sharing: Perfect for online meetings or remote support, you can share your screen with others during video calls using Nextcloud Talk.
– Collaborative Editing: You can edit documents collaboratively using integrated apps like OnlyOffice or Collabora Online.

3. How to Set It Up

Step 1: Choose Your Hosting Environment

– Self-hosted: You can set up Nextcloud on your own hardware, such as a server at home or in the office. This gives you full control but requires some technical know-how.
– Cloud VPS: If you prefer a managed solution, you can rent a VPS from providers like DigitalOcean, Linode, or Hetzner. Install Nextcloud on the VPS to make it accessible from anywhere.

Step 2: Install Nextcloud

– Linux Installation: Install Nextcloud on a Linux server (Ubuntu, Debian, CentOS, etc.). Follow the official installation guide, which includes setting up a web server (Apache or Nginx), database (MySQL or MariaDB), and securing it with HTTPS.
– Docker Installation: If you prefer containerized environments, you can use Docker to install and manage your Nextcloud instance.

Step 3: Configure Nextcloud

– Install Apps: After the basic installation, you can enhance Nextcloud by installing additional apps. For voice and video calls, install the Nextcloud Talk app. For document editing, install OnlyOffice or Collabora Online.
– Security Settings: Configure your security settings, including enabling SSL/TLS for encrypted connections, setting up a firewall, and using strong passwords.

Step 4: Set Up Communication Tools

– Nextcloud Talk: This app allows you to set up voice and video calls as well as screen sharing. You can create chat rooms, invite participants, and start video conferences directly within the Nextcloud interface. For additional functionality like STUN/TURN servers to improve connection reliability, you may need to configure a dedicated server.

Step 5: Customize for Office or Home

For Office Use: Set up group folders for department-specific file sharing, integrate calendars for scheduling, and use Nextcloud Talk for remote meetings and collaboration.
– For Home Use: Use Nextcloud to store family photos, share important documents, and stay connected with voice and video calls.

4. Why Choose Nextcloud?

– Free and Open Source: Nextcloud is free to use, with no licensing fees, and you can customize it according to your needs.
– Data Privacy: By hosting your own cloud, you retain full control over your data and privacy, unlike with third-party services.
– Extensibility: Nextcloud has a large app ecosystem that lets you add features like email integration, project management, password management, and more.

5. Conclusion

Nextcloud provides a powerful platform to create your own cloud service for both personal and business use. Whether you’re looking for a secure file sharing solution, a collaboration tool for your team, or a way to keep your family connected, Nextcloud can meet your needs.
By leveraging the built-in apps like Nextcloud Talk, OnlyOffice, and more, you can create a comprehensive communication and file-sharing platform that rivals commercial services, all while maintaining complete control over your data.

Step 1: Prepare Proxmox Nodes

1. Update and Upgrade Proxmox VE on all nodes:

apt update && apt full-upgrade -y

2. Ensure that all nodes have the same version of Proxmox VE:

pveversion

Step 2: Set Up the Proxmox Cluster

1. Create a new cluster on the first node:
   • pvecm create my-cluster
2. Add the other nodes to the cluster:
   • pvecm add <IP_of_first_node>
3. Verify the cluster status:
   • pvecm status

Step 3: Install Ceph on Proxmox Nodes

1. Install Ceph packages on all nodes:

install ceph ceph-mgr -y

Step 4: Create the Ceph Cluster

1. Initialize the Ceph cluster on the first node:
   • pveceph init --network <cluster_network>
2. Create the manager daemon on the first node:
   • pveceph createmgr

Step 5: Add OSDs (Object Storage Daemons)

1. Prepare disks on each node for Ceph OSDs:
   • pveceph createosd /dev/sdX
2. Repeat the process for each node and disk.

Step 6: Create Ceph Pools

1. Create a Ceph pool for VM storage:
   • pveceph pool create mypool 128

Step 7: Configure Proxmox to Use Ceph Storage

1. Add the Ceph storage to Proxmox:
   • Navigate to Datacenter > Storage > Add > RBD.
   • Enter the required details like ID, Pool, and Monitor hosts.
   • Save the configuration.

Step 8: Enable HA (High Availability)

1. Configure HA on Proxmox:
   • Navigate to Datacenter > HA.
   • Add resources (VMs or containers) to the HA manager.
   • Configure the HA policy and set desired node priorities.

Step 9: Testing High Availability

1. Simulate node failure: Power off one of the nodes and observe how the VMs or containers are automatically migrated to other nodes.

Step 10: Monitoring and Maintenance

1. Use the Proxmox and Ceph dashboards to monitor the health of your cluster.
2. Regularly update all nodes to ensure stability and security.

Optional: Additional Ceph Configuration

1. Add Ceph Monitors for redundancy:bashKodu kopyalapveceph createmon
2. Add more Ceph MDS (Metadata Servers) if using CephFS:bashKodu kopyalapveceph createmds
3. Tune Ceph settings for performance and reliability based on your specific needs.

By following these steps, you will have a robust Proxmox VE and Ceph high availability setup, ensuring that your VMs and containers remain highly available even in the event of hardware failures.

1. Downloading Free FortiGate VM

Fortinet offers a free version of FortiGate VM for various hypervisors including VMware, Hyper-V, KVM, and more. Follow these steps to download it:

1. Visit the Fortinet Support Portal:
   • Go to Fortinet Support.
   • Log in or create a new account if you don’t have one.
2. Download the FortiGate VM:
   • Navigate to the “Download” section.
   • Select “VM Images” and choose the appropriate hypervisor (e.g., VMware ESXi, Microsoft Hyper-V, etc.).
   • Download the FortiGate VM package.

2. Deploying FortiGate VM on Your Hypervisor

The deployment process may vary slightly depending on your hypervisor. Below are steps for VMware ESXi:

1. Deploy OVF Template:
   • Open your VMware vSphere Client.
   • Right-click on your desired host or cluster and select “Deploy OVF Template.”
   • Follow the wizard, selecting the downloaded FortiGate VM OVF file.
   • Configure the VM settings (name, datastore, network mapping, etc.).
   • Finish the deployment process.
2. Power On the VM:
   • Once the deployment is complete, power on the FortiGate VM.

3. Initial Configuration

1. Access the FortiGate Console:
   • Use the vSphere Client to open the console of the FortiGate VM.
   • The initial login credentials are usually admin for the username and a blank password.
2. Set the Password:
   • You will be prompted to set a new password for the admin user.
3. Configure the Management Interface:
   • Assign an IP address to the management interface.
   • Example commands:

config system interface
edit port1
set ip 192.168.1.99/24
set allowaccess http https ping ssh
next
end

1. Access the Web Interface:
   • Open a web browser and navigate to https://<management-ip>.
   • Log in with the admin credentials.

4. Basic Setup via Web Interface

1. System Settings:
   • Navigate to System > Settings.
   • Set the hostname, time zone, and DNS servers.
2. Network Configuration:
   • Configure additional interfaces if needed under Network > Interfaces.
   • Create VLANs, set up DHCP, etc.
3. Security Policies:
   • Define security policies to control traffic flow under Policy & Objects > IPv4 Policy.
   • Set source and destination interfaces, addresses, and services.
4. Enable Features:
   • Enable and configure additional features like IPS, Antivirus, Web Filtering, etc., under Security Profiles.

5. Connecting to the Internet

1. WAN Interface Configuration:
   • Configure the WAN interface with the appropriate settings (static IP, DHCP, PPPoE, etc.).
2. Routing:
   • Set up a default route under Network > Static Routes pointing to the WAN gateway.
3. NAT Configuration:
   • Configure NAT settings under Policy & Objects > NAT.

6. Licensing

• The free version of FortiGate VM comes with limited features. For full functionality, you may need to purchase a license and activate it under System > FortiGuard.

VyOS Installation and Configuration Guide

Introduction

VyOS is an open-source network operating system based on Debian GNU/Linux that provides software-based network routing, firewall, and VPN functionality. This guide covers the installation and configuration of VyOS, including setting up OSPF.

Installation of VyOS

1. Download VyOS ISO:

   – Go to the VyOS download page and download the ISO image of the latest stable version.

2. Create a Bootable USB Drive:

   – For Windows: Use Rufus to create a bootable USB drive.

   – For Linux/macOS: Use the `dd` command.

3. Boot from the USB Drive:

   – Insert the USB drive into your server or PC and boot from it. You may need to change the boot order in the BIOS/UEFI settings.

4. Install VyOS:

   – Once booted, you will be presented with the VyOS live environment. Log in with the default credentials:

     Username: vyos
     Password: vyos

   – To start the installation, enter:

     install image

   – Follow the prompts to select the installation disk, partitioning scheme, and other options. You will also set a password for the `vyos` user and create a GRUB bootloader.

5. Reboot:

   – After the installation completes, reboot the system and remove the USB drive. The system will boot into the installed VyOS.

Basic Configuration of VyOS

1. Log In:

   – Log in with the user `vyos` and the password you set during installation.

2. Enter Configuration Mode:

   configure

3. Set Hostname:

   set system host-name my-router
   commit
   save

4. Configure Network Interfaces:

   – Identify the network interfaces using the `show interfaces` command.

   – Configure an interface (e.g., `eth0`) with a static IP address:

     set interfaces ethernet eth0 address ‘192.168.1.1/24’
     commit
     save

5. Configure Default Gateway:

   set protocols static route 0.0.0.0/0 next-hop 192.168.1.254
   commit
   save

6. Set DNS Servers:

   set system name-server 8.8.8.8
   set system name-server 8.8.4.4
   commit
   save

7. Enable SSH:

   set service ssh port 22
   commit
   save

Configuring OSPF

Enable OSPF

To configure OSPF (Open Shortest Path First) on VyOS:

1. Enter Configuration Mode:

   configure

2. Enable OSPF:

   set protocols ospf parameters router-id 1.1.1.1

   Replace `1.1.1.1` with a unique router ID for the OSPF instance.

Configure OSPF on Interfaces

Specify which interfaces will participate in OSPF and their respective areas:

   set protocols ospf area 0 network 192.168.1.0/24
   set protocols ospf area 0 network 192.168.2.0/24

   Replace `192.168.1.0/24` and `192.168.2.0/24` with the actual network addresses of your interfaces.

Adjust OSPF Interface Parameters (Optional)

You can adjust OSPF interface parameters like cost, hello interval, and dead interval:

   set interfaces ethernet eth0 ip ospf cost 10
   set interfaces ethernet eth0 ip ospf hello-interval 10
   set interfaces ethernet eth0 ip ospf dead-interval 40

   Replace `eth0` with your actual interface name.

Commit and Save the Configuration

   commit
   save

Example Configuration for OSPF

Here is an example configuration where two interfaces (`eth0` and `eth1`) participate in OSPF with different network segments.

Configuration for Router 1:

configure
set interfaces ethernet eth0 address ‘192.168.1.1/24’
set interfaces ethernet eth1 address ‘10.1.1.1/24’

set protocols ospf parameters router-id 1.1.1.1
set protocols ospf area 0 network 192.168.1.0/24
set protocols ospf area 0 network 10.1.1.0/24

commit
save

Configuration for Router 2:

configure
set interfaces ethernet eth0 address ‘192.168.1.2/24’
set interfaces ethernet eth1 address ‘10.1.2.1/24’

set protocols ospf parameters router-id 2.2.2.2
set protocols ospf area 0 network 192.168.1.0/24
set protocols ospf area 0 network 10.1.2.0/24

commit
save

Verifying OSPF Configuration

1. Check OSPF Neighbors:

   show ip ospf neighbor

2. Check OSPF Routes:

   show ip route ospf

3. Check OSPF Interface Status:

   show ip ospf interface

Additional OSPF Configurations

Configuring OSPF Authentication

To enhance security, you can configure OSPF authentication on the interfaces:

1. Set Authentication Type and Key:

   set interfaces ethernet eth0 ip ospf authentication message-digest
   set interfaces ethernet eth0 ip ospf message-digest-key 1 md5 ‘yourpassword’

   Replace `yourpassword` with a secure password.

2. Configure OSPF Area Authentication:

   set protocols ospf area 0 authentication message-digest

Configuring OSPF Redistribution

To redistribute routes from other protocols (e.g., BGP) into OSPF:

1. Set Redistribution:

   set protocols ospf redistribute bgp
   commit
   save

Troubleshooting OSPF

1. Check OSPF Process:

   show ip ospf

2. Check OSPF Logs:

   show log

3. Debug OSPF:

   monitor protocol ospf

1. Cluster Setup: Ensure that your Proxmox hosts are part of the same cluster. A Proxmox cluster consists of multiple Proxmox VE servers (nodes) combined to offer high availability and load balancing to virtual machines. Nodes in a cluster share resources such as storage and can migrate VMs between each other.
2. Shared Storage: Live migration requires shared storage accessible by both the source and target hosts. This shared storage can be implemented using technologies like NFS, iSCSI, or Ceph. Shared storage allows the VM’s disk images and configuration files to be accessed by any node in the cluster.
3. Migration Prerequisites: Before initiating a live migration, ensure that the target host has enough resources (CPU, memory, storage) to accommodate the migrating VM. Proxmox will check these prerequisites before allowing the migration to proceed.
4. Initiating Migration: In the Proxmox web interface (or using the Proxmox command-line interface), select the VM you want to migrate and choose the “Migrate” option. Proxmox will guide you through the migration process.
5. Migration Process:
   • Pre-Copy Phase: Proxmox starts by copying the memory pages of the VM from the source host to the target host. This is done iteratively, with the majority of memory pages copied in the initial phase.
   • Stopping Point: At a certain point during the migration, Proxmox determines a stopping point. This is the point at which the VM will be paused briefly to perform a final synchronization of memory pages and state information.
   • Pause and Synchronization: The VM is paused on the source host, and any remaining memory pages and state information are transferred to the target host. This pause is usually very brief, minimizing downtime.
   • Completion: Once the final synchronization is complete, the VM is resumed on the target host. From the perspective of the VM and its users, the migration is seamless, and the VM continues to run without interruption on the target host.
6. Post-Migration: After the migration is complete, the VM is running on the target host. You can verify this in the Proxmox web interface or using the command-line tools. The source host frees up resources previously used by the migrated VM.
7. High Availability (HA): In a Proxmox cluster with HA enabled, if a host fails, VMs running on that host can be automatically migrated to other hosts in the cluster, ensuring minimal downtime.

Overall, Proxmox VM live migration is a powerful feature that enables you to move virtual machines between hosts in a Proxmox cluster with minimal downtime, providing flexibility and high availability for your virtualized environment.