BSD · FreeBSD 11 · KVM · QEMU · Virtual Machines · Virtualization

Installing Qemu on FreeBSD 11

Installation

QEMU is a hypervisor, that can emulate many number of architectures.Some of the architectures include:

  • i386
  • x86_64
  • Alpha
  • Arm
  • MIPS
  • MIPS64
  • PPC
  • PPC64
  • Sparc
  • Sparc64

In this article lets look at, how to install QEMU on FreeBSD 11. By default, QEMU on FreeBSD supports the following architectures.

  • i386
  • x86_64

Continue reading “Installing Qemu on FreeBSD 11”

Advertisements
BSD · FreeBSD · FreeBSD 10.0 · QEMU · Virtualization

Installing Qemu on FreeBSD 10

Installation

QEMU is a hypervisor, that can emulate many number of architectures.Some of the architectures include:

  • i386
  • x86_64
  • Alpha
  • Arm
  • MIPS
  • MIPS64
  • PPC
  • PPC64
  • Sparc
  • Sparc64

In this article lets look at, how to install QEMU on FreeBSD 10. By default, QEMU on FreeBSD supports the following architectures.

 

  • i386
  • x86_64

Continue reading “Installing Qemu on FreeBSD 10”

KVM · Virtualization

KVM – Kernel Virtual Machine

According to Wikipedia, KVM(Kernel Based Virtual Machine) is a  virtualization infrastructure for the Linux kernel that turns it into a hypervisor. In simple words KVM is a kernel module that provides the Linux Kernel, the capability to act as a hypervisor.

KVM support was added to Linux kernel in the version 2.6.20 in February 2007.

Requirements for KVM:

  1. Hardware virtualization extension
  2. Linux Kernel 2.6.20 and above( If you are using Linux as the host OS)
  3. Disk space according to drive size of guest OS
  4. Free Memory according to memory size of guest OS

Continue reading “KVM – Kernel Virtual Machine”

Cloud · Linux Distribution · nova · OpenSSH · OpenStack · sshd · Ubuntu · Virtualization

Enable password authentication on cloud images

The cloud images bundled by various linux distributions have password authentication disabled by default for security reasons. The only possible way to login to an instance launched using one of these images is by specifying a security key during boot and using the key to ssh. Often you would want to enable password authentication like say to login through VNC console for debugging. This post will take you through the steps involved for enabling password authentication.
Continue reading “Enable password authentication on cloud images”

Cloud · Grizzly · Havana · IceHouse · Netfilter · Netlink · Network Management · Networking · Neutron · Open source · Open vSwitch · OpenFlow · OpenStack · OpenStack architecture · Quantum · Software Defined Networking · Virtualization

L3 connectivity using neutron-l3-agent

The neutron l3 agent is responsible for providing service for routing, natting, security-group rules and floatingip allocation. This purpose of this post is to document its working principles and also to enable users to effectively debug their Openstack cloud(most problems occur due to user mis configuration). The l3 agent offers these services from the network node and relies on neutron-openvswitch-agent to provide l2 connectivity to the instances running on compute nodes. This post assumes that the readers are aware of how l2 connectivity is achieved using ‘openvswitch’ mechanism driver. Continue reading “L3 connectivity using neutron-l3-agent”

Cloud · Linux Distribution · LXC · Netfilter · Netlink · Network Management · Networking · Open source · Open vSwitch · OpenFlow · OpenStack · Virtualization

A bite of virtual linux networking

In this post we shall be discussing about various network components and their corresponding Linux virtual counterparts.

Bridges

Switches basically provide the following functionality

  1. Mac learning: As switch receive packets on their interface they map the interface id/port number to the source mac address of the all packets received on that interface. This is used later while forwarding.
  2. Forwarding: Switches do not see a packet past the l2 headers. The have to perform a simple logic before sending out a packet received on one interface, to other interfaces.
    1. If the destination is broadcast/multi-cast, forward on all ports except the ingress port.
    2. If the destination of a packet is mapped to any interface send the packet out that interface alone.
    3. If the destination is non of the above, forward on all ports belonging to the packet’s VLAN, except the ingress port.
  3. VLAN Isolation: Packets are assorted according to their VLAN. A switch’s port can be either configured as trunk port(Belongs to all VLANs) or as an access port for a particular VLAN. The rules therefore are simple.
    1. Packets appearing on trunk ports should be tagged unless they belong to vlan 1(native vlan). The tag identifies the packet’s vlan in this case.
    2. Packets appearing on access ports should not be tagged unless they want to be dropped. The port configuration(access ports always belong to a VLAN) identifies the packet in this case

    The assorted packets then pass through the forwarding phase, which determine to which port they would be sent to. Packets going out trunk ports will be tagged and those going out access ports will not be tagged. The forwarding logic guarantees that a packet belonging to a VLAN shall never trespass another VLAN.

Continue reading “A bite of virtual linux networking”

Cloud · IceHouse · Network Management · Neutron · Open source · Open vSwitch · OpenStack · Virtualization

L2 connectivity in OpenStack using OpenvSwitch mechanism driver

L2 connectivity is the most basic requirement in a network. All cloud platforms allow users to create subnets. Subnets are L2 segments to which the servers attach their interfaces to and start sending and receiving traffic. Servers on the same L2 segment can reach each other directly. They only need to resolve the destination MAC address using ARP. In the world of networking this service is provided by your access switch.

Continue reading “L2 connectivity in OpenStack using OpenvSwitch mechanism driver”