From: CSights <cs...@fa...> - 2007-08-24 13:06:04
|
Hi Robert, I agree with your KVM(lguest,Xen...) / openmosix idea. Some userland tools that rae needed are: the daemon which detects CPU load and accordingly starts, stops and moves VMs. The other major tool would be some automated facility for packaging up the VM. Also, does anybody know how kernel "containers" might be used to openMosix's advantage. I've heard these are supposed to be light-weight VMs, but that is about it. C. |
From: Deadpan110 <dea...@gm...> - 2007-08-24 15:26:32
|
Hi all, I agree totally, openMosix is primarilary for load balancing non IO dependant processes... even though oM is currently going through a transitional period, this _should_ still remain the main goals of oM. Virtualization may be obtained via use of virtual systems all using oM, but ignoring that fact and trying to make oM more for virtual use would defeat the end use of oM itself... It has been a while since my last posting to the oM mailing lists and it is unfortunate that Moshe wants to abandon oM like rats from a sinking ship... each to their own... I still see a use for the original ideas behind mosix... oM friendly programming proves this (even in the days of super fast SMP processing). 'It seems wasteful for one person to wash dishes and then pretend he has more arms, than just to get 10 people to wash the same amount of dishes' Martin On 24/08/07, g4sra <g4...@ya...> wrote: > > I have bit my tongue long enough. openMosix never did have, does not, > (and as far as I can predict the future) ever will, have anything to do > with Virtualization (even though that may have been the original > motivation). Those knowledgeable on KVM should read up on openMosix, and > you will understand why I say what I do. Any tools written to be > compatible with both openMosix and KVM will be nothing more than a > bodged compromise, if you want to run that type of software, talk to Bill. > > If you insist on buzzword usage, change "Virtualization" to "Virtual", > as a simplistic (and incorrect) view, openMosix provides the capability > of having "Virtual CPU's". This persistent lumping in of openMosix with > Virtualization does nothing but confuse newcomers and cloud the real > openMosix issues. (Somebody demo me standard XP sitting on a straight > openMosix kernel and I will eat my words :>). > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > openMosix-general mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openmosix-general > |
From: <ta...@sn...> - 2007-08-24 16:08:48
|
On Fri, Aug 24, 2007 at 08:26:30AM -0700, Deadpan110 wrote: > 'It seems wasteful for one person to wash dishes and then pretend he has > more arms, than just to get 10 people to wash the same amount of dishes' unless you're paying per person to wash those dishes ;) -- Vincent Hanquez |
From: David B. <brodbd@u.washington.edu> - 2007-08-24 16:21:51
|
On Aug 24, 2007, at 9:09 AM, Tony Travis wrote: > g4sra wrote: >> I have bit my tongue long enough. openMosix never did have, does not, >> (and as far as I can predict the future) ever will, have anything >> to do >> with Virtualization (even though that may have been the original >> motivation). > > Hmm... [donning my best flame-proof underpants] I thought openMosix > was > actually the inverse of 'virtualisation'? I was going to say that, too. Virtualization usually means making one machine look like a bunch of smaller machines, so you can run multiple operating systems or isolate different applications from each other. OpenMosix tries to make a bunch of small machines look like one big one. It certainly doesn't provide isolation; one rogue program can (and sometimes does) bring down the whole cluster. David Brodbeck Information Technology Specialist 3 Computational Linguistics University of Washington |
From: <ta...@sn...> - 2007-08-24 18:26:52
|
On Fri, Aug 24, 2007 at 09:21:32AM -0700, David Brodbeck wrote: > I was going to say that, too. Virtualization usually means making one > machine look like a bunch of smaller machines, Virtualising *host* yes, but virtualisation can be broader. > so you can run multiple > operating systems or isolate different applications from each other. > OpenMosix tries to make a bunch of small machines look like one big one. Well not really, since it's not a SSI. it's actually virtualising processes. > It certainly doesn't provide isolation; one rogue program can (and > sometimes does) bring down the whole cluster. virtualise != isolation. you can virtualise without isolation (a bit crappy but possible) Cheers, -- Vincent Hanquez |
From: g4sra <g4...@ya...> - 2007-08-24 16:36:17
|
David Brodbeck wrote: > > On Aug 24, 2007, at 9:09 AM, Tony Travis wrote: > >> g4sra wrote: >>> I have bit my tongue long enough. openMosix never did have, does not, >>> (and as far as I can predict the future) ever will, have anything to do >>> with Virtualization (even though that may have been the original >>> motivation). >> >> Hmm... [donning my best flame-proof underpants] I thought openMosix was >> actually the inverse of 'virtualisation'? > > I was going to say that, too. Virtualization usually means making one > machine look like a bunch of smaller machines, so you can run multiple > operating systems or isolate different applications from each other. > OpenMosix tries to make a bunch of small machines look like one big > one. It certainly doesn't provide isolation; one rogue program can > (and sometimes does) bring down the whole cluster. > Both hit the nail on the head, what openMosix obviously needs is it's own buzzword that means "inverse of virtualisation" (much prefer the English spelling, but then I would :>). Suggestions to the mailing list..... How about "Invualisation" :>) |
From: Wes W. <wes...@gm...> - 2007-08-24 16:38:57
|
openMosicks.... Experiense the Sensation of Devirtualisation No z's allowed... On 8/24/07, g4sra <g4...@ya...> wrote: > > David Brodbeck wrote: > > > > On Aug 24, 2007, at 9:09 AM, Tony Travis wrote: > > > >> g4sra wrote: > >>> I have bit my tongue long enough. openMosix never did have, does not, > >>> (and as far as I can predict the future) ever will, have anything to > do > >>> with Virtualization (even though that may have been the original > >>> motivation). > >> > >> Hmm... [donning my best flame-proof underpants] I thought openMosix was > >> actually the inverse of 'virtualisation'? > > > > I was going to say that, too. Virtualization usually means making one > > machine look like a bunch of smaller machines, so you can run multiple > > operating systems or isolate different applications from each other. > > OpenMosix tries to make a bunch of small machines look like one big > > one. It certainly doesn't provide isolation; one rogue program can > > (and sometimes does) bring down the whole cluster. > > > Both hit the nail on the head, what openMosix obviously needs is it's > own buzzword that means "inverse of virtualisation" (much prefer the > English spelling, but then I would :>). Suggestions to the mailing > list..... > > How about "Invualisation" :>) > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > openMosix-general mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openmosix-general > -- Wes Wagner |
From: CSights <cs...@fa...> - 2007-08-24 18:59:59
|
Hi All, I think people may have missed the point regarding using KVM (et al.). I believe the point was not to make openMosix a virtualization, but to use virtualization in order to implement openMosix. openMosix is about moving CPU intensive programs to "real" CPUs. openMosix 2.4 does this by migrating processes from one computer to another. Alternatively, a VM would be created for each process of interest. Then one could migrate an entire VM, containing the CPU intensive process of interest, to other computers. "Migrating a VM" http://kvm.qumranet.com/kvmwiki/Migration The one advantage migrating a VM would have over the 2.4 openMosix is that there is no "head-node" single point of failure. Another is that one could snapshot the VM for recovery in case of power failure. Shared memory (within the VM) and all types of threads would be automatically supported. The main disadvantage (at least how I currently imagine it) is that openMosix would be less transparent and more like XGrid or Condor. One would have to package up the processes in a VM, then start the VM and let it migrate. If this could be automated so that it looks like one is just executing a command then this would be a very nice implementation. Another disadvantage might be the memory footprint of the VM. This could probably be small though if it were the size of Linux on embedded devices. To repeat, no we're not playing buzzword bingo, we're simply suggesting another way of distributing CPU intensive programs between real CPUs. C. |
From: Daniel 'F. L. <did...@go...> - 2007-08-25 21:25:58
|
I think everyone here has made valid points. to play devil's advocate to my friend Martin (deadpan110@gmail - see his post for a passionate view about oM and virtual hosts): If virtualised hosts could also benefit from the asymetric multi-processing that occurs with an oM cluster (with the entire vm bouncing back and forth between nodes to acheive maximum processing capability), then oM needn't be the inverse of virtualisation of hosts. Instead of making a group of machines appear to be one single entity, you can make a group of disperate hosts appear to be one entity with multiple virtualhosts. In this mannar we would be following the trend in virtualising hosts, while still keeping our approach of expansion capability. Instead of having to commission a series of new super powerful hosts to support the ever increasing swathe of virtual hosts, it would be possible to add COTS hardware into a cluster and provision new virtual hosts without needing to set up advanced routing as, to the world, the systems appear to be one logical unit. This would allow a cluster of COTS hardware to appear to be a single MainFrame-esque unit but, instead of being one ungainly mass of circuitry that is custom-designed for the job, you have yourself a completely scalable infrastructure that can grow to meet ever demanding tasks. you would also not have to replace the entire mainframe in one-fell-swoop just to increase your capacity, instead replacing older subsystems (a single x86/64 machine) and upgrading little by little. -- Regards, The HoneyMonster aka Daniel Llewellyn |
From: g4sra <g4...@ya...> - 2007-08-24 14:10:56
|
I have bit my tongue long enough. openMosix never did have, does not, (and as far as I can predict the future) ever will, have anything to do with Virtualization (even though that may have been the original motivation). Those knowledgeable on KVM should read up on openMosix, and you will understand why I say what I do. Any tools written to be compatible with both openMosix and KVM will be nothing more than a bodged compromise, if you want to run that type of software, talk to Bill. If you insist on buzzword usage, change "Virtualization" to "Virtual", as a simplistic (and incorrect) view, openMosix provides the capability of having "Virtual CPU's". This persistent lumping in of openMosix with Virtualization does nothing but confuse newcomers and cloud the real openMosix issues. (Somebody demo me standard XP sitting on a straight openMosix kernel and I will eat my words :>). |
From: Tony T. <aj...@rr...> - 2007-08-24 16:10:04
|
g4sra wrote: > I have bit my tongue long enough. openMosix never did have, does not, > (and as far as I can predict the future) ever will, have anything to do > with Virtualization (even though that may have been the original > motivation). Hmm... [donning my best flame-proof underpants] I thought openMosix was actually the inverse of 'virtualisation'? In my naive interpretation, openMosix does what SMP does but uses a slower interconnect. Migration of processes between openMosix nodes is analagous to migration of processes between SMP processors. In that respect, I can understand why Moshe said the advent of (very) cheap SMP systems makes it less attractive to spend time building and supporting openMosix clusters with 'small' numbers of uniprocessor PC's. However, I've built a 92-node COTS Beowulf for a fraction of the cost of a 'large' SMP computer and I think there is still a lot of life left in openMosix. I, for one, will continue using openMosix unless the project fragments into internecine disputes about 'what' openMosix is. I guess the MOSIX2 developers are smiling to themselves about all this, and getting on with their already credible 2.6 kernel and x86_64 support. I'd use MOSIX2 now if it was GPL, but that's why we've got openMosix... > Those knowledgeable on KVM should read up on openMosix, and > you will understand why I say what I do. Any tools written to be > compatible with both openMosix and KVM will be nothing more than a > bodged compromise, if you want to run that type of software, talk to Bill. 100% agree! > If you insist on buzzword usage, change "Virtualization" to "Virtual", > as a simplistic (and incorrect) view, openMosix provides the capability > of having "Virtual CPU's". This persistent lumping in of openMosix with > Virtualization does nothing but confuse newcomers and cloud the real > openMosix issues. (Somebody demo me standard XP sitting on a straight > openMosix kernel and I will eat my words :>). Hey, we all use 'virtual' machines - The physical address space on most 'real' systems is not linear. It just looks that way to the CPU because of 'virtualisation', and it's the microcode that makes the CPU look like an x86/x86_64 etc. What bothers me is more fundamental: The shift away from 'distributed' computing to traditional 'centralised' computing. Virtualisation is a step back into the dark ages of mainframe computing where one BIG machine is made to look like lots of little ones, and the data centre dictate to the users what they are allowed to do and when, with their 0.001% of available 'mill' time and 0.001%MB of disk quota :-( I'd rather have my own collection of little machines thank you, which I can add to and scale the solution to the task. I can also avoid having to make the case for my share of massive expenditure on centralised resources that can't be incrementally upgraded. I use openMosix because it gives me freedom, in the GNU sense, to do the job I want to and to do the job cost-effectively. My experience of openMosix has been excellent. Tony. -- Dr. A.J.Travis, | mailto:aj...@rr... Rowett Research Institute, | http://www.rri.sari.ac.uk/~ajt Greenburn Road, Bucksburn, | phone:+44 (0)1224 712751 Aberdeen AB21 9SB, Scotland, UK. | fax:+44 (0)1224 716687 |