and it’s not that i don’t understand the benefits from a user perspective – it’s more than i don’t think users properly appreciate the costs.

Ian: i’m inclined to agree. i’ll have more to say after i talk to rPath, and i don’t think it’s an unsolvable problem, but i do believe that this approach is going to create significant issues.

Dick: well, i think the appliance vendors would instead say that the point is that the drivers actually aren’t necessary in guest OSs b/c that’s already handled by the host. whether or not you buy that is a matter of where you fall on appliances.

the system management point here is an interesting one, however.

Each appstack effectively needs it’s own drivers, network stack etc – some of this can be pushed down into the hv, but then that starts to look like a kernel again…

Not that this is automatically bad thing, but it certainly says something about the sorry state of system management if this is saner than the status quo.

I think this is going to be a large problem personally.
especially when it to security upgrades, and even knowing what your threat is.

If appliance manufacturers could come up with a standard way of configuring and maintaining their appliances (physical or virtual) so operations staff can truly treat them like a black boxes It would be a big step forward.
but for now, I (or a admin) still needs to have a in-depth knowledge of all the working parts inside a appliance, and the diversity that appliances bring will be devastating when it comes to time to maintain a system of them.

At Zimbra we choose to build both our software appliance and virtual appliance based on rPath Linux. They provide a toolset(rBuilder/Conary) that allow you to extract the minimum required set of dependencies for your custom Linux distribution and application stack. The advantages of this for an application like Zimbra with a *thick* stack (40+ OSS dependencies) is that we eliminate many of the variables that come with installing on a traditional Linux distro – port conflicts, dependency problems, conflicting applications, SELinux/iptables/ipchain problems, etc. Basically you get a clean install base and can fully automate most of the install. So in your 1-6 above much of this load in our case is still on rPath since they are Linux OS experts and stand behind it. Since you’ve got a minimum Linux distro there is less to support. Updates for both the Linux stack and the application stack(Zimbra) are delivered from the Zimbra updates server. So the update story is even better than what we have for the traditional OS’s. rPath Linux is mirrored from rPath and the Zimbra bits come from our internal build machines. To the end appliance it only sees and manages a single update connection. This single point of OS+application updates prevents a mis-match between OS and application bits. Still not convinced that an appliance virtual or software are not the right solution. You can try our 1st vmware appliance beta for yourself here:

http://www.zimbra.com/vmware/