There is someone that switched from kvm to xen? If yes what are the motivations? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 02/10/2011 05:31 PM, Mauro wrote:> There is someone that switched from kvm to xen? > If yes what are the motivations?I play with both, but I claim expertise in neither. I''ve found KVM good on stand-alone boxes (ie: my main laptop''s VMs are KVM). On dedicated VM servers though, I prefer Xen''s dom0/domU model and networking. I would not fault anyone for using either. -- Digimer E-Mail: digimer@alteeve.com AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 10 February 2011 22:36, Digimer <linux@alteeve.com> wrote:> On 02/10/2011 05:31 PM, Mauro wrote: >> There is someone that switched from kvm to xen? >> If yes what are the motivations? > > I play with both, but I claim expertise in neither. > > I''ve found KVM good on stand-alone boxes (ie: my main laptop''s VMs are > KVM). On dedicated VM servers though, I prefer Xen''s dom0/domU model and > networking. > > I would not fault anyone for using either.I''m very undecided if use xen or kvm.> > -- > Digimer > E-Mail: digimer@alteeve.com > AN!Whitepapers: http://alteeve.com > Node Assassin: http://nodeassassin.org >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Thu, 10 Feb 2011, Mauro wrote:> There is someone that switched from kvm to xen? > If yes what are the motivations? > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >I run a lot of both. In my production servers I have a multi-master mysql database of fairly small size (a few MB) that runs on Xen and has run fine for years. I tried to clone this setup in the cloud on KVM. The same load from the web frontent, KVM load spikes to 67 and DB freezes up. Xen in the cloud runs at load of 5 or 6, quite acceptable. KVM as shipped with RHEL6 is supposed to be better but I haven''t tried it yet. But where KVM seems to fall down the most is on complex heavy disk I/O tasks. If it is just block read and writes things are fine. KVM is also not very good as a Lustre server. (but it is impossible to run Lustre servers on Xen at all due to incompatible kernel patching.) Steve Timm -- ------------------------------------------------------------------ Steven C. Timm, Ph.D (630) 840-8525 timm@fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Group Leader. Lead of FermiCloud project. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 10 February 2011 22:42, Steven Timm <timm@fnal.gov> wrote:> On Thu, 10 Feb 2011, Mauro wrote: > >> There is someone that switched from kvm to xen? >> If yes what are the motivations? >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users >> > > > I run a lot of both. > In my production servers I have a multi-master mysql database > of fairly small size (a few MB) that runs on Xen and > has run fine for years. > > I tried to clone this setup in the cloud on KVM. The same > load from the web frontent, KVM load spikes to 67 and DB freezes > up. Xen in the cloud runs at load of 5 or 6, quite acceptable. > > KVM as shipped with RHEL6 is supposed to be better but I haven''t tried > it yet. But where KVM seems to fall down the most is on complex > heavy disk I/O tasks. If it is just block read and writes > things are fine. KVM is also not very good as a Lustre server. > (but it is impossible to run Lustre servers on Xen at all due > to incompatible kernel patching.)I''ve used xen for years and I like it, but the fact that it''s not included in linux kernel makes me doubt whether it can be supported for a long time. Here is a similar discussion on kvm list: http://www.spinics.net/lists/kvm/msg50060.html _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 02/11/2011 03:09 AM, Mauro wrote:> I''ve used xen for years and I like it, but the fact that it''s not > included in linux kernel makes me doubt whether it can be supported > for a long time.As of 2.6.37, Xen dom0 support has been accepted by Linus into the mainline kernel. They are now working to test and move all of the patches into place and are hoping dom0 support will be native in Fedora 15 or 16. The Xen community is working hard to ensure that Xen/dom0 support will be available for CentOS 6 via the EPEL repositories. -- Digimer E-Mail: digimer@alteeve.com AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
.> The Xen community is working hard to ensure that Xen/dom0 support will > be available for CentOS 6 via the EPEL repositories.Now this has just made my weekend! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 2/10/2011 5:31 PM, Mauro wrote:> There is someone that switched from kvm to xen? > If yes what are the motivations?I tried KVM for a while before settling on Xen. Either is probably okay. I like the idea of a type 1 hypervisor better than a type 2 (Xen is a type 1, KVM is a type 2). It''s probably not a huge concern for most uses but I like the idea that a type 1 is not inside another kernel but is running directly on the hardware. As long as some distros commit to providing tested Xen support I think all is good there. I personally found openSUSE to be a pretty good dom0 platform in terms of seamless updates, etc. I''m sure there are others. -- Steve Sapovits steves06@comcast.net _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 11 February 2011 17:01, Digimer <linux@alteeve.com> wrote:> On 02/11/2011 03:09 AM, Mauro wrote: >> I''ve used xen for years and I like it, but the fact that it''s not >> included in linux kernel makes me doubt whether it can be supported >> for a long time. > > As of 2.6.37, Xen dom0 support has been accepted by Linus into the > mainline kernel. They are now working to test and move all of the > patches into place and are hoping dom0 support will be native in Fedora > 15 or 16. > > The Xen community is working hard to ensure that Xen/dom0 support will > be available for CentOS 6 via the EPEL repositories.I hope not only for CenOS but for Debian too. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, Feb 11, 2011 at 12:24 PM, Steve Sapovits <steves06@comcast.net> wrote:> (Xen is a type 1, KVM is a type 2)that''s not exact since KVM doesn''t run ''on top of'' the Linux kernel; it''s part of the Linux kernel. as such, it has the same ''bare metal'' access to hardware as the rest of the kernel or the Xen hypervisor. IMHO, the main difference is that Xen has its own scheduler and arbitration logic, while KVM reuses existing Linux code. pro: it can be tuned to the specific case of handling VMs. con: a little duplication of code -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, 11 Feb 2011, Javier Guerra Giraldez wrote:> On Fri, Feb 11, 2011 at 12:24 PM, Steve Sapovits <steves06@comcast.net> wrote: >> (Xen is a type 1, KVM is a type 2) > > that''s not exact since KVM doesn''t run ''on top of'' the Linux kernel; > it''s part of the Linux kernel. as such, it has the same ''bare metal'' > access to hardware as the rest of the kernel or the Xen hypervisor. > > IMHO, the main difference is that Xen has its own scheduler and > arbitration logic, while KVM reuses existing Linux code. pro: it can > be tuned to the specific case of handling VMs. con: a little > duplication of codeI second this. I have used KVM extensively and find it is very stable and useful in case we are running a dissimlar OS (like windows and SunOS). KVM is really good in a lot of respects (for eg:- in case of USB if you want to send a raw USB device to the guest machine). I have found KVM very stable. As Javier told, KVM is _not_ running on top of kernel. It is a totaly different sub-system and gives near-baremetal performance if properly configured with virtio drivers. Almost everything which can be done on Xen can be done on KVM (but IMO vice-versa is not totally true).> > -- > Javier > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 12 February 2011 22:45, Bhasker C V <bhasker@unixindia.com> wrote:> > On Fri, 11 Feb 2011, Javier Guerra Giraldez wrote: > >> On Fri, Feb 11, 2011 at 12:24 PM, Steve Sapovits <steves06@comcast.net> >> wrote: >>> >>> (Xen is a type 1, KVM is a type 2) >> >> that''s not exact since KVM doesn''t run ''on top of'' the Linux kernel; >> it''s part of the Linux kernel. as such, it has the same ''bare metal'' >> access to hardware as the rest of the kernel or the Xen hypervisor. >> >> IMHO, the main difference is that Xen has its own scheduler and >> arbitration logic, while KVM reuses existing Linux code. pro: it can >> be tuned to the specific case of handling VMs. con: a little >> duplication of code > > I second this. I have used KVM extensively and find it is very stable and > useful in case we are running a dissimlar OS (like windows and SunOS). KVM > is really good in a lot of respects (for eg:- in case of USB if you want > to send a raw USB device to the guest machine). I have found KVM very > stable. As Javier told, KVM is _not_ running on top of kernel. It is a > totaly different sub-system and gives near-baremetal performance if properly > configured with virtio drivers. > > Almost everything which can be done on Xen can be done on KVM (but IMO > vice-versa is not totally true).Do you use xen or kvm on your productions servers? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sat, 12 Feb 2011, Mauro wrote:> On 12 February 2011 22:45, Bhasker C V <bhasker@unixindia.com> wrote: >> >> On Fri, 11 Feb 2011, Javier Guerra Giraldez wrote: >> >>> On Fri, Feb 11, 2011 at 12:24 PM, Steve Sapovits <steves06@comcast.net> >>> wrote: >>>> >>>> (Xen is a type 1, KVM is a type 2) >>> >>> that''s not exact since KVM doesn''t run ''on top of'' the Linux kernel; >>> it''s part of the Linux kernel. as such, it has the same ''bare metal'' >>> access to hardware as the rest of the kernel or the Xen hypervisor. >>> >>> IMHO, the main difference is that Xen has its own scheduler and >>> arbitration logic, while KVM reuses existing Linux code. pro: it can >>> be tuned to the specific case of handling VMs. con: a little >>> duplication of code >> >> I second this. I have used KVM extensively and find it is very stable and >> useful in case we are running a dissimlar OS (like windows and SunOS). KVM >> is really good in a lot of respects (for eg:- in case of USB if you want >> to send a raw USB device to the guest machine). I have found KVM very >> stable. As Javier told, KVM is _not_ running on top of kernel. It is a >> totaly different sub-system and gives near-baremetal performance if properly >> configured with virtio drivers. >> >> Almost everything which can be done on Xen can be done on KVM (but IMO >> vice-versa is not totally true). > > Do you use xen or kvm on your productions servers?I use KVM. They are running Debian (very light one only having the base and the KVM support) and on top of this with RAW LVs I am running windows on KVM. These windows machines are using certain USB devices (direct access passthrough) and they are quite happy for a long time. I must say that I was a bit lazy to bring up the usb passthrough on xen which i had problems with.> > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 2/12/2011 5:45 PM, Bhasker C V wrote:> that''s not exact since KVM doesn''t run ''on top of'' the Linux kernel; > it''s part of the Linux kernel. as such, it has the same ''bare metal'' > access to hardware as the rest of the kernel or the Xen hypervisor.One differing factor is paravirtualization. To clarify my comments regarding KVM: I meant it runs *in* the kernel. So, yes -- when accessing hardware without paravirtualization, making a Linux kernel call versus making a Xen hypervisor/micorkernel call is probably half a dozen of one/6 of the other. However, when running paravirtualized guests, the dedicated nature of the Xen approach can offer better performance. Here''s a good paper on the subject: http://iopscience.iop.org/1742-6596/219/4/042005/pdf/1742-6596_219_4_042005.pdf KVM has more limited paravirtualization -- only specific network and IO drivers I believe (someone can clarify this perhaps). Does it matter? Probably not for most people. I''ve considered using KVM again and may use it on another box at some point. Theoretically, the separation of the VMs in a dedicated hypervisor like Xen *should* also offer better security: The assumption being that the more general purpose Linux kernel is more susceptible to security attacks than the specific purpose Xen kernel. I have, however, seen nothing that indicates any real world issues in the security area. -- Steve Sapovits steves06@comcast.net _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, Feb 13, 2011 at 3:22 PM, Steve Sapovits <steves06@comcast.net> wrote:>> that''s not exact since KVM doesn''t run ''on top of'' the Linux kernel; >> it''s part of the Linux kernel. as such, it has the same ''bare metal'' >> access to hardware as the rest of the kernel or the Xen hypervisor. > > One differing factor is paravirtualization. To clarify my comments > regarding KVM: I meant it runs *in* the kernel. So, yes -- when > accessing hardware without paravirtualization, making a Linux kernel > call versus making a Xen hypervisor/micorkernel call is probably half > a dozen of one/6 of the other. However, when running paravirtualized > guests, the dedicated nature of the Xen approach can offer better > performance. Here''s a good paper on the subject:Just to clarify, my comment was about the characterization of KVM as a type 2 hypervisor. it''s not. now, about the paravirtualization / full virtualization, that''s a totally different issue. Definitely Xen does offer a complete mode of operation that''s simply inexistent on KVM. The pros/cons of each mode is open for discussion, and changes one way or the other not only for different uses, but also changes with processor generations. first-gen full-virtualization was noticeably slower, second-gen made the difference much smaller, and there''s hints of new optimizations that could swing the performance advantage again far toward paravirtualization.... or maybe the other way. In any case, offering both options is a good thing :-) but i think it''s not about a KVM vs. Xen debate. And my specific comment was defintely not about Xen at all. just to say: KVM is type 1. no matter what drivers you use, which parts of the VM are emulated, which are virtualized and which are paravirtualized, it''s always type 1 -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, Feb 11, 2011 at 10:34:47PM -0500, Javier Guerra Giraldez wrote:> On Fri, Feb 11, 2011 at 12:24 PM, Steve Sapovits <steves06@comcast.net> wrote: > > (Xen is a type 1, KVM is a type 2) > > that''s not exact since KVM doesn''t run ''on top of'' the Linux kernel; > it''s part of the Linux kernel. as such, it has the same ''bare metal'' > access to hardware as the rest of the kernel or the Xen hypervisor.Unless my understanding is wrong, this is not true. The QEMU process still needs to run, and still does runs code on behalf of the VM; yes, CPU is not emulated, memory access is direct, but IIRC even my paravirt drivers, some stuff still goes through QEMU/kvm.> IMHO, the main difference is that Xen has its own scheduler and > arbitration logic, while KVM reuses existing Linux code. pro: it can > be tuned to the specific case of handling VMs. con: a little > duplication of codeA strace on the qemu process shows that it does lots of stuff, so I don''t think the situation is as simple as you describe it. Corrections welcome. Regards, iustin _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 2/13/2011 6:45 PM, Javier Guerra Giraldez wrote:> Just to clarify, my comment was about the characterization of KVM as a > type 2 hypervisor. it''s not.Maybe it''s a 1.5? 8-) I''ve seen the debate over whether it''s a type 1 or type 2. It''s not 100% clear, at least to me. It used to be that any VM platform that ran as an extension to an existing OS was considered a type 2. But, in the hardware access view of things, I can see how KVM would be considered a type 1. I think we can agree that KVM is not a traditional type 1 or type 2. We can probably also agree that the type 1/type 2 distinction in of itself doesn''t matter if the platform does what you need it to do. In my mind, I always felt if I used the hosting Linux OS to only run VM''s then KVM isn''t much different than Xen. But if I were to take the hosting OS and do a lot more with it -- desktop, etc. -- it starts to feel less like a type 1. Now you''ve got me thinking about playing with KVM again. It''s been a few years ... -- Steve Sapovits steves06@comcast.net _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, Feb 13, 2011 at 7:02 PM, Iustin Pop <iusty@k1024.org> wrote:> The QEMU process > still needs to run, and still does runs code on behalf of the VM; yes, > CPU is not emulated, memory access is direct, but IIRC even my paravirt > drivers, some stuff still goes through QEMU/kvm.just the same stuff that goes through Dom0 daemons -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, Feb 13, 2011 at 7:08 PM, Steve Sapovits <steves06@comcast.net> wrote:> I think we can agree that KVM is not a traditional type 1 or type 2. > We can probably also agree that the type 1/type 2 distinction in of > itself doesn''t matter if the platform does what you need it to do.wholeheartedly agree. in fact, i think the type 1 / type 2 is a very insignificant distinction in any case. some more easily virtualizable CPUs allow for very efficient and powerful type2 VMs (MacOnLinux was _very_ nice on PowerPC macs)> Now you''ve got me thinking about playing with KVM again. It''s been > a few years ...please don''t think i''m advocating KVM over Xen. the reasons to choose one or the other (or something else) are very complex and situation-specific. said that, on workstations it''s my first choice (specially on Ubuntu, using libvirt-manager, setup is quick and painless) -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 2/13/2011 7:58 PM, Javier Guerra Giraldez wrote:> please don''t think i''m advocating KVM over Xen. the reasons to choose > one or the other (or something else) are very complex and > situation-specific. said that, on workstations it''s my first choice > (specially on Ubuntu, using libvirt-manager, setup is quick and > painless)No, I was thinking more for my own education. I''m a consultant so my use of Xen is two-fold: to use for my own business needs, but also to learn something about Xen. It can''t hurt to also learn more about KVM. I''ve been looking ahead to a need for another VM box sometime this year. Maybe I''ll make that one KVM-based. -- Steve Sapovits steves06@comcast.net _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
In the discussion of whether KVM is a type 1 or type 2 hypervisor, it is important to remember that KVM, by allowing driver code to be moved into the address space of the hypervisor, is violating one key tenets of having hypervisors in the first place. Driver code is notoriously buggy and by allowing it to share the address space of the hypervisor you have greatly expanded the vulnerability and attack surface for the most important part of your system. KVM has dramatically increased the chances of catastrophic system failure by violating one of the fundamental architectural principles that has guided the design of hypervisors since IBM originated the original concepts in the '60's. If reliability, availability and security are important to you, then Xen is a much better choice from an architectural standpoint. Phil Winterfield> > On 2/13/2011 6:45 PM, Javier Guerra Giraldez wrote: > > > Just to clarify, my comment was about the characterization of KVM as > a > > type 2 hypervisor. it's not. > > Maybe it's a 1.5? 8-) I've seen the debate over whether it's a > type 1 or type 2. It's not 100% clear, at least to me. It used > to be that any VM platform that ran as an extension to an existing > OS was considered a type 2. But, in the hardware access view of > things, I can see how KVM would be considered a type 1. > > I think we can agree that KVM is not a traditional type 1 or type 2. > We can probably also agree that the type 1/type 2 distinction in of > itself doesn't matter if the platform does what you need it to do. > > In my mind, I always felt if I used the hosting Linux OS to only run > VM's then KVM isn't much different than Xen. But if I were to take > the hosting OS and do a lot more with it -- desktop, etc. -- it starts > to feel less like a type 1. > > Now you've got me thinking about playing with KVM again. It's been > a few years ... >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, Feb 13, 2011 at 07:50:35PM -0500, Javier Guerra Giraldez wrote:> On Sun, Feb 13, 2011 at 7:02 PM, Iustin Pop <iusty@k1024.org> wrote: > > The QEMU process > > still needs to run, and still does runs code on behalf of the VM; yes, > > CPU is not emulated, memory access is direct, but IIRC even my paravirt > > drivers, some stuff still goes through QEMU/kvm. > > just the same stuff that goes through Dom0 daemonsNo, not at all. You can kill all dom0 daemons, and Xen VMs still run. We used to rely on this in old Xen versions where xend sometimes got stuck. What the dom0 daemons are used for is setting up the VM, afterwards they are not running it. Yes, the drivers in dom0 respond to I/O requests, but this is different. regards, iustin _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Feb 15, 2011 at 6:51 PM, Iustin Pop <iusty@k1024.org> wrote:> On Sun, Feb 13, 2011 at 07:50:35PM -0500, Javier Guerra Giraldez wrote: >> On Sun, Feb 13, 2011 at 7:02 PM, Iustin Pop <iusty@k1024.org> wrote: >> > The QEMU process >> > still needs to run, and still does runs code on behalf of the VM; yes, >> > CPU is not emulated, memory access is direct, but IIRC even my paravirt >> > drivers, some stuff still goes through QEMU/kvm. >> >> just the same stuff that goes through Dom0 daemons > > No, not at all. You can kill all dom0 daemons, and Xen VMs still run. We > used to rely on this in old Xen versions where xend sometimes got stuck. > What the dom0 daemons are used for is setting up the VM, afterwards they > are not running it. Yes, the drivers in dom0 respond to I/O requests, > but this is different.i think you''re missing some important points about KVM execution architecture (although i fear it''s becoming off-topic). a KVM process has several threads: one for qemu, one or more for IO, and one for each virtualized CPU. the last ones are switched to the virtualization mode and run ''guest'' code. all the guest OS is run on these threads, only when there''s a mode-exit trap, the VM thread(s) is suspended by the kernel and the qemu thread receives a signal. exactly the same as on HVM Xen DomU''s, when there''s a mode-exit trap, the hypervisor switches contexts and signals the Dom0 daemons. the fact that there''s no way to keep the VM while killing/restarting qemu is just because they''re threads in a single process. there''s no ''code run in behalf of the VM'' by qemu beyond hardware emulation. again, just like Dom0 daemons. the pros/cons of each architecture are (once again) debatable in importance: Xen is (in theory) more resilient to bugs; KVM gets (in theory) less context switches per I/O -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, Feb 13, 2011 at 07:50:35PM -0500, Javier Guerra Giraldez wrote:> On Sun, Feb 13, 2011 at 7:02 PM, Iustin Pop <iusty@k1024.org> wrote: > > The QEMU process > > still needs to run, and still does runs code on behalf of the VM; yes, > > CPU is not emulated, memory access is direct, but IIRC even my paravirt > > drivers, some stuff still goes through QEMU/kvm. > > just the same stuff that goes through Dom0 daemons >Not necessarily dom0 daemons.. Xen has stubdomains, where you can run the qemu on a separate lightweight domain. Or you can use Xen "driver domains" to run specific drivers in another domain (not in dom0). -- Pasi _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users