[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[fedora-virt] Re: [et-mgmt-tools] RFC: libosinfo: Library for virt OS/distro metadata 3



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]