Re: [CentOS-virt] xen dom0/domU network speed
Hi, > > Is anyone experiencing same network slowdown? > > Or could it be just some configuration issue on my side? > > What do you get on the same hardware running a non-Xen kernel? What > does the test look like? You also have to consider that Ethernet is not > 100% efficient. The same hw without Xen can handle several 1Gbps (tested with 2) simultaneous streams (doesn't matter whether in- or out-going). I think this is really Xen (vif-eth) speed issue which may or may not be possible to optimize, as there is really a lot of additional packet copying in the dom0 (and also domU is applicable). So my question is more like - is there anyone who can get 1Gbps throuput on domU (or Dom0) eth0 under Xen? Or do I have to assign the network card HW directly to the dom0/domU where I need full network speed? Thanks, [EMAIL PROTECTED] + ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] i386 VM on x86_64 host in Xen
Karanbir, - "Karanbir Singh" <[EMAIL PROTECTED]> wrote: > the fact that openvz kernel does not boot my machine, takes it > completely out of the working category. Not booting would be a problem. :) The only OpenVZ kernel I've had trouble booting was one where they added Xen support (so you can use both Xen and OpenVZ on the same host). I don't mean to associate Xen with the boot problem... the machine got stuck on USB detection and wouldn't get past that. If you remember any of the details, it would be interesting to report the boot failure to the bug tracking system... but unless you were willing to do followup, it would just be another ticket that doesn't have the possibility of being resolved. > Also, none of the HA tools work for me under openvz. Here's a wiki page on using DRDB and heartbeat... although I've not done it myself. http://wiki.openvz.org/HA_cluster_with_DRBD_and_Heartbeat For high availability, I just migrate my VPSes from one physical host to another periodically... and have good backups. I know that isn't real HA but it is suitable for my needs. I'm guessing that HA isn't a feature used by more than a single digit percentage of Xen users... but I really have no data one way or another. Again, it's an area where if you need HA, then OpenVZ might not be for you. > Neither is it capable of running selinux, which is another show stopped. I'm one of those people who have yet to take the time to learn SELinux... and unfortunately, I think there are a lot of us out there. I'm not sure if there is a technical reason why SELinux and OpenVZ are incompatible. I've asked questions from people who should know... and the answer I get is that the main reason SELinux support is not available with OpenVZ is because of the same reason some other projects say it has to be turned off... simply because they don't want to have to deal with all of the troubleshooting involved with its use. That's a bad excuse but it seems to be pretty common. The vast majority of Linux distros don't support SELinux anyway... and for users of those, it isn't an issue. >> There are uses where Xen is much better suited and OpenVZ isn't even >> a viable option. [...] > Sure, thats what my point was. But my point also went on to say that > aprt from high density hosting, I am yet to find a role where openvz > was a better fit. I am open to hearing about your use cases :D Your argument is like saying everyone should drive a large SUV because it has 4-wheel drive and it holds a lot of passengers... and it has a large gas tank. I didn't flesh that argument out very well... but my point is that not everyone wants or needs 4-wheel drive or a lot of passengers... or a large gas tank. And OS Virtualization gets more miles per gallon. :) I could just as easily say that a physical machine is a much better solution than Xen because you can do more with a physical machine than you can a virtual machine... but I'm guessing you see the fault with that argument. > sure, but again, only in high desity hosting solutions. I am yet to > see a openvz deployment outside that. The vast majority of people I talk to on a daily basis are using OpenVZ in situations other than high density hosting solutions. This would include myself. :) The common misperception is that OpenVZ or OS Virtualization is only good for high density web hosting. While that is an area where it definitely excels in, it isn't the only thing it is good for. > Depends on the client setup, lots of people seem to rely on the amazon I think that Amazon makes up the largest percentage of Xen deployments. I hope they are giving back to the community. > btw, whats wrong with virsh ? you seem to be happy using cli tools for Nothing. I'd like to learn more about it... especially if and when it supports OpenVZ. :) > right, so your ideas on Xen are mostly based on the lack of awareness. [...] > You can quite easily control and tweak runtime resources with Xen, > that was one of the main selling points for it in the first place. I'll grant that. Please point me to a web page that talks about the tweakable resource parameters of Xen. All I am aware of are memory and number of CPUs. Hey, I'm here to learn... that's why I signed up for this mailing list. > Most people who do high density hosting can achieve similar results / > density without really needing a userspace vm model. eg. I know that > $LargestHostingISP in .de is presently looking at howto educate the > users that they might actually get a better deal with almost all the > same resource access using shared hosting rather than VPS's running > UML/Virtuzzo/Xen etc. Lets see how that pans out. At the moment, the > idea and selling point of VPS's is that its a buzzword. You mean service level virtual hosting (ie Apache VirtualHosting) rather than using virtualization? That might be true... but there are drawbacks to that. I mean, you can't give someon
Re: [CentOS-virt] i386 VM on x86_64 host in Xen
Scott Dowdle wrote: Karanbir, - "Karanbir Singh" <[EMAIL PROTECTED]> wrote: apart from mass scale hosting solutions, I am yet to see a role where openvz actually provided a better all around VM solution than Xen. Depends on your definition of better. One that works (for example the discussion you are having now about problems running i386 guests on x86_64 hosts) might fall into that. :) the fact that openvz kernel does not boot my machine, takes it completely out of the working category. Neither is it capable of running selinux, which is another show stopped. Also, none of the HA tools work for me under openvz. They have a long way to go. There are uses where Xen is much better suited and OpenVZ isn't even a viable option. Sure, thats what my point was. But my point also went on to say that aprt from high density hosting, I am yet to find a role where openvz was a better fit. I am open to hearing about your use cases :D Even the management tools and the developer support behind Xen far out weights that on openvz. I'm not sure what you mean by that. OpenVZ comes from Virtuozzo which has been out over 6 years now and has been deployed by thousands (if not tens of thousands) of deployments. sure, but again, only in high desity hosting solutions. I am yet to see a openvz deployment outside that. So far as management tools go, I wondering what management tools you use for Xen. The only one I've really tried was Virtual Machine Manager and prior to the most recent release in 5.1, it couldn't even START a virtual machine. I've tested out XenSource's management solution and while it has a few more features that Virtual Machine Manager, there still isn't much there. Depends on the client setup, lots of people seem to rely on the amazon xen tools these days, along with Enomalism stuff. btw, whats wrong with virsh ? you seem to be happy using cli tools for openvz, why not try the same sort of stuff on Xen as well ? Besides, I have never really used GUI pointty/clickity tools on such machines ( I think you get the idea that I am not in the hosting business :D ) Given the 20ish resource parameters provided by OpenVZ and the vzctl command where all of those resources can be dynamically changed... and looking at /proc/user_beancounters on the hn or guests is the most direct way to monitor them... those rudimentary cli tools seem more up to the task than the current crop of GUI tools I see for Xen. Although perhaps I'm just ignorant of additional management programs that are out there... and I look forward to you informing me. right, so your ideas on Xen are mostly based on the lack of awareness. You can quite easily control and tweak runtime resources with Xen, that was one of the main selling points for it in the first place. And for those mass hosting solutions, a bit of security minded setups would remove the need to have this sort of a virtual userspace virtualising anyway. I'm not really sure what you mean, please clarify. Most people who do high density hosting can achieve similar results / density without really needing a userspace vm model. eg. I know that $LargestHostingISP in .de is presently looking at howto educate the users that they might actually get a better deal with almost all the same resource access using shared hosting rather than VPS's running UML/Virtuzzo/Xen etc. Lets see how that pans out. At the moment, the idea and selling point of VPS's is that its a buzzword. -- Karanbir Singh : http://www.karan.org/ : [EMAIL PROTECTED] ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] i386 VM on x86_64 host in Xen
On Tue, 2007-12-11 at 11:27 -0500, Scott Dowdle wrote: > There are uses where Xen is much better suited and OpenVZ isn't even a > viable option. But there are other cases where OpenVZ is a better fit > especially with regards to density and scalability. OpenVZ is also > very attractive in those situations where you want to isolate a single > or a small number of services... although the vast majority if my > deployments have a full set of services. Yes. It's good not to underestimate OS-level virtualization. Many people used chroot to isolate certain processes. OS-level virtualization provides better isolation and control, at only little extra cost. Operating systems that provide binary compatibility for other systems (like the BSDs or Solaris) can also use OS-level virtualization to emulate a complete enviroment that resembles the emulated system. The downside of most (if not virtually all) current OS-level virtualization on Linux is that they do not have proper support for SELinux. I suppose that things get more interesting in that respect when container features are integrated in the mainline kernel. -- Daniel ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] i386 VM on x86_64 host in Xen
Karanbir, - "Karanbir Singh" <[EMAIL PROTECTED]> wrote: > apart from mass scale hosting solutions, I am yet to see a role where > openvz actually provided a better all around VM solution than Xen. Depends on your definition of better. One that works (for example the discussion you are having now about problems running i386 guests on x86_64 hosts) might fall into that. :) But seriously, it's all about meeting the needs of the users... and there is a large variety of virtualization needs out there... and not a single, one size fits all best solution. I'm not trying to badmouth Xen and I'd appreciate it if people didn't badmouth other solutions either. There are uses where Xen is much better suited and OpenVZ isn't even a viable option. But there are other cases where OpenVZ is a better fit especially with regards to density and scalability. OpenVZ is also very attractive in those situations where you want to isolate a single or a small number of services... although the vast majority if my deployments have a full set of services. > Even the management tools and the developer support behind Xen far out > weights that on openvz. I'm not sure what you mean by that. OpenVZ comes from Virtuozzo which has been out over 6 years now and has been deployed by thousands (if not tens of thousands) of deployments. The OpenVZ developers (along with a few from IBM and Google mostly) are currently working on getting "control group" features in the mainline kernel... and that is expected to happen between now and the next 12-18 months. Who knows how the mainline implementation will differ from the stock OpenVZ? So far as management tools go, I wondering what management tools you use for Xen. The only one I've really tried was Virtual Machine Manager and prior to the most recent release in 5.1, it couldn't even START a virtual machine. I've tested out XenSource's management solution and while it has a few more features that Virtual Machine Manager, there still isn't much there. Given the 20ish resource parameters provided by OpenVZ and the vzctl command where all of those resources can be dynamically changed... and looking at /proc/user_beancounters on the hn or guests is the most direct way to monitor them... those rudimentary cli tools seem more up to the task than the current crop of GUI tools I see for Xen. Although perhaps I'm just ignorant of additional management programs that are out there... and I look forward to you informing me. The good thing is Red Hat has taken a virtualization agnostic approach with their tools and with some additional development work, they could support OpenVZ too. I believe someone added OpenVZ support to libvirt this past summer but I don't know how complete it was nor if it got integrated into upstream or not. > And for those mass hosting solutions, a bit of security minded setups would > remove the need > to have this sort of a virtual userspace virtualising anyway. I'm not really sure what you mean, please clarify. TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] i386 VM on x86_64 host in Xen
Christopher, - "Christopher G. Stach II" <[EMAIL PROTECTED]> wrote: > It would really suck to have 3795 "virtual machines" die all at the > same time from a single kernel panic. Yes, absolutely it would. I use the OpenVZ kernels that are based on the RHEL4 and RHEL5 kernels and I haven't had any problems with them... just like I haven't had any problems with the stock RHEL4 and RHEL5 kernels... nor CentOS kernels. I usually end up rebooting host node machines because of kernel upgrades... so my machines don't get a chance to have longish uptimes... but on one remote colocation machine I have for hobby stuff... it currently has an uptime of 106 days. It has 7 VPSes on it and they are fairly fat as they all run a full set of services. I know I've been running that machine for close to 2 years now... and if I remember correctly it started out with CentOS 4.0. I've upgraded to each release (on the host node and the VPSes) and am currently at CentOS 4.5. I look foward forward to 4.6. Here's what they look like (ip addresses and hostnames obscured): [EMAIL PROTECTED] ~]# vzlist VEID NPROC STATUS IP_ADDR HOSTNAME 101 53runningxx.xx.xx.xxvps101.localdomain 102 44runningxx.xx.xx.xxvps102.localdomain 103 44runningxx.xx.xx.xxvps103.localdomain 104 32runningxx.xx.xx.xxvps104.localdomain 105322 runningxx.xx.xx.xxvps105.localdomain 106 32runningxx.xx.xx.xxvps106.localdomain 107 29runningxx.xx.xx.xxvps107.localdomain Looking at the number of processes, can you tell which VPS is running Zimbra? :) 6 of the 7 VPSes are CentOS and the remaining 1 is Debian. Speaking of uptimes, I have a "legacy" machine at work running Linux-VServer on a 2.4.x series kernel. It had the longest uptime of any machine I've had... and was well over 400 days... when a power outage that outlasted its UPS took it down. That particular machine runs three VPSes that are mail relay/frontends and they get pounded... so that uptime is notable. So, my experience has been that physical failures and power failures (although pretty rare) are more common that kernel panics that take down all of my virtual machines. TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Network Problem after update 3.0 -> 3.1: blkback
I respond to myself: Before in xen 3.0 this was okay: vif = [ 'mac=aa:dd:rr:ee:ss:11', 'mac=aa:dd:rr:ee:ss:22, bridge=xenbr1'] The first vif was implicitly attached to bridge 0 (xenbr0). BUT now in 3.1 this doesn't work anymore, you must explicitly give the "bridge=xenbr0" argument: vif = [ 'mac=aa:dd:rr:ee:ss:11, bridge=xenbr0', 'mac=aa:dd:rr:ee:ss:22, bridge=xenbr1'] beware... kfx wrote: Hello, I have a big problem: Dom0 is centos5.1, domU are centos5.1. My setup is really simple, the only thing is that I give 3 nics to the domU so I use a modified network script (which has worked since january... since fedora 6): " #!/bin/sh dir=$(dirname "$0") "$dir/network-bridge" "$@" vifnum=0 "$dir/network-bridge" "$@" vifnum=1 "$dir/network-bridge" "$@" vifnum=2 " So I have updated my xen dom0 from 3.0.3-rc5-8.1.15.el5 to 3.1.0-53.1.4.el5 (and kernel-xen 2.6.18-8.1.15.el5xen to 2.6.18-53.1.4.el5xen) and now my domU cant access the network. The interfaces are good in the domU, all seems to be ok but there are no connectivity at all (no arp entries). This message shows up on the dom0 each time I launch a domU: blkback: ring-ref 9, event-channel 7, protocol 1 (x86_64-abi) Do someone know what is happening ? this is very embarrassing after a simple upgrade... Hopefully I have another identical server (Centos 5.0 with 5.1 domUs) which is still in 3.0 but I cant stay not updated. Thanks for any help. xm info: host : host.foo.com release: 2.6.18-53.1.4.el5xen version: #1 SMP Fri Nov 30 01:21:23 EST 2007 machine: x86_64 nr_cpus: 4 nr_nodes : 1 sockets_per_node : 2 cores_per_socket : 1 threads_per_core : 2 cpu_mhz: 2992 hw_caps: bfebfbff:20100800::0180:641d total_memory : 4095 free_memory: 3246 xen_major : 3 xen_minor : 1 xen_extra : .0-53.1.4.el5 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : unavailable cc_compiler: gcc version 4.1.2 20070626 (Red Hat 4.1.2-14) cc_compile_by : mockbuild cc_compile_domain : cc_compile_date: Fri Nov 30 00:37:12 EST 2007 xend_config_format : 2 ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
