On Fri, Jul 2, 2010 at 10:55 PM, Emmanuel Noobadmin <centos.admin@xxxxxxxxx> wrote: > This is a concern since I plan to put storage on the network and the > most heavy load the client has is basically the email server due to > the volume plus inline antivirus and anti-spam scanning to be done on > those emails. Admittedly, they won't be seeing as much emails as say a > webhost but most of their emails come with relatively large > attachments. if by 'put storage on the network' you mean using a block-level protocol (iSCSI, FCoE, AoE, NBD, DRBD...), then you should by all means initiate on the host OS (Dom0 in Xen) and present to the VM as if it were local storage. it's far faster and more stable that way. in that case, storage wouldn't add to the VM's network load, which might or might not make those (old) scenarios irrelevant > 2. Security > Some sites point out that KVM VM runs in userspace as threads. So a > compromised guest OS would then give intruder access to the system as > well as other VMs. in any case, if your base OS (host on KVM, Dom0 on Xen) is compromised, it's game over. also, KVM is not 'userspace threads', they're processes as far as the scheduler is concerned, and their ram mapping is managed as a separate process space. no more no less separation than usual among processes on a server. of course, the guest processes are isolated inside that VM and there's no way out of there (unless there's a security bug, which are few and far between given the hardware-assisted virtualization) in any case, yes; Xen does have more maturity on big hosting deployments. but most third parties are betting on KVM for the future. the biggest examples are Redhat, Canonical, libvirt (which is sponsored by redhat), and Eucalyptus (which reimplements amazon's EC2 with either Xen or KVM, focusing on the last) so the gap is closing. regarding performance, KVM is still somewhat behind; but the design is cleaner and more scalable (don't believe too much on 'type 1 vs type 2' hype, most people invoking that don' really understand the issues). the evolving virtio backends have a lot of promise, and periodically there are proof of concept tests that blow out of the water everything else. and finally, even if right now the 'best' deployment on Xen definitely outperforms KVM by a measurable margin; when things are not optimal Xen degrades a lot quicker than KVM. in part because the Xen core scheduler is far from the maturity of Linux kernel's scheduler. -- Javier -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
