On Mon, Jun 15, 2009 at 12:51:49PM -0400, Cole Robinson wrote:
The values the user sets are for what kind of guest they are installing at that moment (x86_64 kvm in this case, i686 xen PV in another).
That's backwards, though. I don't care about kvm or xen. I care about installing a particular guest type, and want the library to tell me the best method. To do that it needs to match guest needs against host capabilities, and that implies the above properties need to be multi-valued. There is no one "golden setup" even on a single system and it would be a major mistake to presume there ever will be.
No presumption here. In virt-manager, those above values are chosen by the user (qemu vs. kvm vs. xenner, arch, xenpv vs. xenfv).
We aren't writing libvirtmanager though.
I'm not saying those above API calls would be hard coded, it would be the result of:
./virt-install --connect qemu:///system --arch x86_64 --virt-type kvm --os-variant foobar ...
I hear you that it would be nice if the user could say 'here's the OS I want, here's my host config, DO IT!', and to some degree virt-manager/virt-install already plays that role, but at the osinfo library it can come later
^^^^^^^^^^^^^^^^^
No, you're proposing an API which prevents it, that is, one value per key (one hypervisor type, one arch, etc.). That's precisely my complaint.
By all means make the current /implementation/ throw its hands up if given more than one virtenv[1]. Just don't encode it into the API.
regards john
[1] guest-arch+hypervisor-type+virt-type+... combo