Let's say you have a base server running several KVM guests. Now with regards to disk I/O caching, it would seem that the base server would cache the I/O in its memory, but wouldn't the guest also cache the same I/O in its memory pool also? If so, wouldn't this waste memory if the disk contents are cached twice? If this is the case, then what would be a good way to tune this behavior (i.e., either cache everything from the base server, or cache nothing from the base and only from withing the guests)? The only way I can think of is to allocate the guests with less memory that you normally would, set the swappiness parameter in the guests to 0 (so process memory doesn't get swapped out in favor of disk caching), so there is no extra memory in the guests that they can use for cache. This would then force all caching to happen in the base server. Or, is this an issue that is somehow solved automatically by KVM?
At my current job, we distribute a product based on a Linux server with multiple VMs defined (using KVM / libvirt). We are planning to expose limited ports to the customer's network, and use iptables to direct inbound traffic to the appropriate internal VM. My question: is there a class of private subnets that I can use for the internal host-only network that is least likely to conflict with a client IP subnet? Specifically, if I choose a /24 out of any of the RFC-1918 defined private subnets (such as 192.168.x.x), there is a chance of conflicting with a customer-used range.
I noticed that several current VM implementations default to 192.168.122.x -- is this due to an RFC that I'm not familiar with, and therefore this is a safe range to use (that most network admins would avoid)? Or did the various VM vendors just pick that range randomly? I guess I'm looking for an IP range that is more private than the existing private (RFC1918) addresses.
The only other thought I had was to use one of the "Test Net" IP ranges reserved for documentation purposes (RFC 5737). Note, that I'm not worried about a customer's network blocking these IPs, as this is only internal to our server (packets get NATted before leaving the box). However this does seem more unorthodox than just sticking with the default 192.168.122.x/24 subnet.