The operating system can no longer decide which processes are to be performed exactly when, because the virtualization application can stop or delay the execution of the entire virtualized system.

The operating system can no longer access the network card or storage hardware directly, but must access a virtualization software component. In order to do this, it is necessary to switch between guest and host multiple times. This not only reduces the maximum possible output, but also increases latency.

If the hard drives are not installed locally on the virtualization server, but are connected via a SAN, for example, the transfer latency via SAN is added. However, very different latency times can be observed on different SAN systems. Systems based on iSCSI tend to have high latency. Fibre Channel or FCoE systems (Fibre Channel over Ethernet) tend to have better latency. Additional layers such as storage virtualization can add further latency.

Most tasks of an Intra2net system are typically limited by the latency of hard drive access and not by drive output or lack of CPU performance. This point can therefore significantly impair the performance of an Intra2net system.

We recommend compensating for this by using faster hard drives (15,000 RPM) or solid state drives.

Furthermore, we do not recommend configuring the virtual disk for the Intra2net system as a dynamically growing / allocated drive, but to assign and allocate it completely from the beginning. If the disk only grows on demand, it costs performance for write accesses. Also, additional administrative information is required, which must be retrieved before access and then possibly adjusted. With classic hard drives, additional repositioning of the read/write heads is required due to the uneven distribution of the blocks.

If the Intra2net system is used as a router and firewall and thus establishes a connection to the Internet, it comes into direct contact with network packets from the Internet. The Intra2net system is designed to handle non-standard compliant or even malicious packets correctly. Any detected gaps in the drivers or functions are promptly closed through regular updates.

If the Intra2net system is operated as a virtual machine and its network cards are managed via the regular network functions of a virtualization system, the virtualization system is exposed to these packets unfiltered. This usually applies to the network card drivers and the virtual switch.

Virtualization systems are typically not designed to be firewalls. For this reason, driver updates for network cards and virtual switches are not considered to be critical and are therefore distributed and installed less frequently. This ultimately increases the risk of interference or attacks.

Therefore, we strongly advise against connecting network cards directly to the Internet via regular network functions of the virtualization system (typically virtual switches).

Instead, we recommend handing over the respective network cards as complete PCI devices to the virtual machine. The Intra2net system controls the hardware directly via PCI access and the virtualization solution does not come into contact with these network packets in any case.

Caution

Note that this function is not offered by all virtualization systems and is only available with support of the hardware (Intel VT-d or AMD-Vi in processor and chipset as well as appropriate description tables in the BIOS). Therefore, check compatibility from the planning stage. In addition, when passing through complete PCI devices, live migration of the VM is usually no longer possible. Therefore, a VM must be shut down before migrating to new hardware.

Alternatively, it is possible to use an additional hardware firewall, or install the Intra2net system not as a virtual machine, but on dedicated hardware.