John Levon wrote:
> On Mon, Jun 15, 2009 at 12:11:18PM -0400, Cole Robinson wrote:
>
>>>>> The API user should pass in an nvlist, where a set of the names are
>>>>> defined and known about. The response needs to indicate whether it's a
>>>>> preferred setting ("would like virtio") or a required one.
>>>> I can see doing something like
>>>>
>>>> os_info_set_install_prop(os_info_t info, int prop, char *propval)
>>>>
>>>> So the API user might do:
>>>>
>>>> os_info_set_install_prop(myinfo, OS_INSTALL_VIRT_TYPE, "hvm");
>>>> os_info_set_install_prop(myinfo, OS_INSTALL_ARCH, "x86_64");
>>>> os_info_set_install_prop(myinfo, OS_INSTALL_HV_TYPE, "kvm");
>>> This isn't going to work as we most definitely have more than one value
>>> of all of these settings.
>> 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). 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 and isn't a big priority at the moment. I'm
interested in just reaching parity with the current virtinst osdict
solution for now.
>>> Instead we need to pass in a list of "environments". Each one would
>>> specify a particular combination of the values above (along with a
>>> 'preferred' setting methinks).
>> Maybe we can avoid an explicit 'preferred' concept, and just return a
>> list of supported values to the user. osinfo will put it's 'preferred'
>> choice as the first in the list, but if the user wants to differ, they
>> can choose from the other values in the list.
>
> There may be more than one preferred setting ('kvm or xenpv, but I'd
> avoid xenhvm'). Possibly we need a more nuanced notion.
>
> regards
> john
Thanks,
Cole
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
