Felipe Alfaro Solana

From How to improve disk I/O performances with VMware Workstation 5:

Memory trimming

Workstation checks which part of the guest OS virtual memory is not used and allocates it back to the host OS. This permits to have more concurrent virtual machines running but everytime the guest OS asks back for its memory it suffers a performance degradation.

So, if you have enough free RAM for all planned concurrent VMs, be sure to disable memory trimming for guest OSes adding the following line to the virtual machine configuration (.vmx) file:

MemTrimRate=0

Page sharing

VMware uses a page sharing technique to allow guest memory pages with identical contents to be stored as a single copy-on-write page. Page sharing decreases host memory usage, but consumes system resources, potentially including I/O bandwidth.

You may want to avoid this overhead for guests for which host memory is plentiful and I/O latency is important. To disable page sharing, add the following line to the virtual machine configuration (.vmx) file:

sched.mem.pshare.enable=FALSE option

Xen implements paravirtualization to allow for software partitioning.

Xen is an hypervisor that allows running several partitions, called “domains”. Each domain is totally independent, virtualized and solated by the Xen hypervisor, which controls access to the hardware and shares the physical resources among all running domains.

There are two domain classes:

1. Privileged domain: has some limited access to the hardware, and is used to provide for virtual driver support for all the non-privileged domains. There can only be one privileged domain running on a machine at any time and its called “domain0″.

   For example, the privileged domain has access to the video frame buffer and can run an accelerated X server, and has limited access to real devices, like eth0, hda, and so on.

2. Unprivileged domain: has no direct hardware access, and all the I/O operations are virtualized by using virtual devices, like the virtual block device or virtual network device, which are in turn hooked to the privileged domain. There can be as many unprivileged domains as system resources allow for.

   Unprivileged domains don’t have a video frame buffer and, thus, all GUI support must get implented using software like VNCserver or FreeNX, then remotely controlling the session from another domain or machine.

Xen selects a random hardware MAC address if not specifically told to use a particular one. This causes problems with networking since the MAC address for the domain virtual interface (called vif) changes between domain reboots and switches and computers keep the corresponding entry on their ARP caches for a few minutes.

Let be A a virtual unprivileged domain running under Xen’s control. After A has started, any other domain or real machine, will be unable to talk to A until the moment A forces an ARP cache update by sending out a packet (for example, an ICMP packet).

I see two solutions to this problem:

1. When domain A starts, it initiates an ARP cache refresh of other domains or machines.

   This can be achieved by sending a gratuitious ARP cache on interface wakeup, which not every Linux distribution does, or send some ICMP echo request packets to force sending ARP requests. This can be easily implemented in init scripts.

2. Forcing domain A to use a fixed MAC address.

   This can be achieved by using the following line in A domain configuration file:

   vif = [ 'mac = XX:XX:XX:XX:XX:XX' ]

   The latter solution is the easiest and, usually, the preferred one.

   NOTE: This also covered in the Xen FAQ.