Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
Kristian Erik Hermansen wrote: > Cool idea, and please let us know if you implement it and the result > works. But I feel compelled to also point you to vmware's vmotion > product :-) > Looking quickly at Vmotion it seems that Vmotion starts out requiring a box to serve up disks I am only being medium ambitious here. I want to have two identical servers that can stand in for each other with no single points of failure. Put some central disk server in the mix and I start to want two of them in case one dies. The cost of minimal hardware of a completely redundant system goes up by thousands. (Also, Vmware always ignores the resumes I send them. If they don't like me, I am not so enthusiastic about them.) A point on motivation: Upgrading software. Say the host OS needs an upgrade, or the virtualization software itself has a new revision. Those are cases where the whole world might really be happier with a reboot of the guest. Vmotion seems to be a load balancing feature. Trying a live migration for an upgrade seems greedy. In those cases I think it is reasonable to reboot the guest OS. Yes, you can't do many reboots and still do "five-nines", but people who think they have that reliability are usually fooling themselves. A little scheduled downtime is usually something that can be arranged, and a system that assumes a reboot is occasionally allowed can be so much simplier--and simplicity breeds reliability. -kb, the Kent who is coming around to thinking Virtualbox is pretty damn cool. P.S. It is still annoying that only one copy of Virtualbox can be installed at once on a host machine. Qemu doesn't have that limitation...though in the most recent copy of Qemu that I have tried dereferencing a -1 kills the entire guest OS. Yes, really. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list [hidden email] http://lists.blu.org/mailman/listinfo/discuss
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |