What's easiest is probably whatever you're used to, which is to say, once one is used to something, most differences in what's easier vanish. There are a lot of editors like joe, pico, and the like that are easier than vi. But once you've used vi for long enough, you really don't notice.
Consolidation as a one-to-one real-to-virtual migration isn't going to end up being all that much less work. What it saves in some ways it adds in additional complexity. It does reduce physical resources (power, space, cooling, hardware maintenance), and it can add flexibility if you have an extra host and the right sort of setup (migrating virtual clients). It can be great in a development environment if you have enough physical resources, because you can quickly create new virtual clients. In other words, it may not reduce human resources: administrator time, and such. Woe to you however, if you do not have extra physical host(s) to migrate your virtual environments to. Scheduling downtime for hardware maintenance, or dealing with the too-many-eggs-in-one-basket problem if something breaks, is no fun at all. Zones are more efficient than other solutions. And depending on the details of the setup (and _if_ updates go smoothly), they _may_ be less bother to keep up-to-date. Make sure that updates play very nicely with zfs snapshots and clones in whatever version you end up using. The experience over various Solaris 10 updates was that it could be ugly, or it could be very smooth, depending on where one was starting from. If you use zfs, best you don't mix in anything else like VxVM/VxFS, because while it's possible, it's likely to make updates require a lot of additional manual intervention. (System-level software coming from two or more different vendors adds additional pain of its own, too. VxVM/VxFS can be a fine product, but there are a lot of cases where it's just not worth the bother.) Migrating zones is also possible, but _not_ on-the-fly, AFAIK; they have to be halted to be migrated. (LDOMs on a CoolThreads box can come closer; I think they can just be suspended, but that may still be a little less transparent than true on-the-fly migration under something like VMware.) I'm not sure where zone migration stands with OpenSolaris; with more recent updates of Solaris 10 it was possible, but practical only between identical systems (preferably identical hardware, definitely identical OS version and updates). Zone migration might be much quicker if zones were in separate zpools, stored on SAN, with SAN access set up for source and destination system, such that moving the storage was nothing more than zpool export on one system and zpool import on another. Without a SAN (or maybe a NAS), either disks would have to be physically moved or data would have to be copied. Zone migration also includes moving the definition of the zone from one system to another. I'm not sure which storage arrangements make it the easiest to move both definition and storage over together. "Branded" zones can provide an illusion of different OSs (older versions of Solaris, or even partial compatibility with some Linux versions). That's not as flexible as separate VMs, though, nor is the compatibility necessarily 100%. Doing a good job of setting up zones means setting up the resource controls to keep them all using only their proper share of system resources. There are now _mostly_ enough controls that if one does it right, there shouldn't be a problem. But I can still think of ways one zone could impact the system as a whole. It has gotten easier; it used to be that some resource controls had to be set up separately, but now pretty much all the resource controls can be part of the definition of the zone. There are situations where zones are a good choice, but I'm not sure I'd want to draw up a list of guidelines for how to choose zones vs some other alternative. They all have their advantages and disadvantages. Any sort of virtualization takes at _least_ as much planning, understanding, and configuration control as the similar number of non-virtualized systems; probably more, if its flexibility is to be taken advantage of... TANSTAAFL (google for it if you don't know what it means) -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
