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

John Levon levon at movementarian.org
Mon Jun 15 17:56:03 UTC 2009

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

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.


[1] guest-arch+hypervisor-type+virt-type+... combo

More information about the Fedora-virt mailing list