|
Hi Anthony,
Thanks for taking the time to read, and thanks for the feedback: The spec clearly has a way to go, and will benefit a lot from a wider reading and comments like yours. My comments inline:
> Overall, I'm rather keen on this concept. A format for describing a
> virtual machine such that it's easy to deploy as an appliance. I think
> what you've come up with is quite good as a first cut but I'm slightly
> concerned that it's a tad over specific. In general, I think this is
> bound to happen anytime you try to specify first before implementing and
> having users.
Well put. There is a bit of a chicken-egg problem with specifying this sort of thing, and I'm sure that it shows through in the current draft. We've done the best we can with the knowledge that we have and the set of appliances that we can anticipate.
I'm sure that there are aspects of the spec that are over-specific (disk names, for instance), in that they target xen/linux/x86 too much. We are very keen to iron these out. I think there are other aspects, like multi-vm network config, that may benefit from a more specific coverage.
> So before I get into specifics, what are the plans moving forward? I
> think if we approached this as a guideline and attempted to build a
> system for Xen that worked with these OVA packages, it would be a good
> way to validate the spec (which could then be finalized). Thoughts?
I think this is exactly what we imagine as the next step.
> I'm a little confused as to whether the intention is to build images
> that will run on any hypervisor or that run on a specific hypervisor.
> If it is the later (which it seems to be), then what is the value in
> standardizing since there is no compatibility?
The intention is the former. Our motivation was that "open" specs like VMDK are not sufficient as a transport vehicle: they don't let you configure/specialize the appliance, etc etc... hopefully the document does a reasonable job of articulating this. So the intention is certainly that the format accommodate other VMMs -- so the Xen-isms that are there all need a bit of development. We're hoping that the end product of the OVA process is a well-designed transport format that anyone can use; what they do in terms of juggling the bits into a specific run-time format is completely up to them.
> This brings me to the vbd description for Xen. device="sda1" is a
> concerning example as we shouldn't be using things other than xvd for
> paravirt domains. This brings up a practical question of whether these
> sort of things should be insulted from the developer to begin with?
> Thoughts?
Hopefully we can come up with a reasonable way of naming devices that everyone can be happy with. Suggestions are more than welcome. ;)
> I think the property system is a noble attempt at solving a pretty hard
> problem. However, I don't think it will be sufficient for very long.
> Users are going to want GUIs and I suspect that means we need to think a
> little harder about this problem.
Ewan will have more to say on this -- the property approach was intended to support GUIs while still being reasonably scriptable/automatable. If we want to support greater forms of prettiness/graphic design then this will need to be built out -- maybe that's not for the first rev of the spec though. ;)
> The script stuff is a little odd. The script gets it's own VM? With
> Perl? Seriously? ;-)
The bottom-line thing that we are desperately trying to avoid is the VMM equivalent of dll hell. OVA tries to represent an installable package that can be rigorously isolated, and that imposes a _minimum_ of shared config state on the VMM/tools. A one-off VM for running customization scripts seems perfectly reasonable to me, if we've got these VMs, we may as well use them, no?
> The security stuff is interesting but I don't know enough about whether
> that will be acceptable to vendors. Have you gotten an initial reaction
> yet?
The (very limited) initial reaction that I have seen has been good, but I agree that there are details to add. More specific comments here would be excellent.
> The rendevous section was a little odd too. I think it presupposes that
> each VM is going to have one network device (which is a bad
> assumption). Also, putting IPs in XenStore seems like a bad idea.
> There are so many ways to do network identification, why reinvent the wheel?
I agree that the rendezvous stuff is kind of strange. Having a more complete way to specify network topologies within appliances would be very good and if anyone can suggest established approaches we'd be happy to look at them. The spec certainly isn't meant to assume a limit of one NIC per VM.
Bear in mind that the use of xenstore described here is just to pass a bunch of config-time data to the VM for its scripts to use for customization. Nobody is suggesting that these be incorporated into split driver configs (for instance). Also, in many cases it's quite possible that these would just specify hostnames (or less) and let you defer to DHCP -- however, it seemed to make quite a bit of sense to allow an appliance the configuration option of sharing a local virtual subnet and assigning static non-forwarded IPs. Among other things this sort of config is nice for migration.
Thanks a lot for the feedback -- if you want to start working through some specific solutions to point-by-point concerns, that would be excellent. We can also start to talk in more detail about building a couple of more real prototypes and associated tool support.
best,
a.
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home