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
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
