On Fri, Jan 16, 2009 at 01:24:53PM +0000, John Levon wrote: > On Fri, Jan 16, 2009 at 10:11:02AM +0000, Daniel P. Berrange wrote: > > > Integrating with host networking meanwhile is a fundamental requirement > > for virtualization for all apps using libvirt, since guests need network > > connectivity, and thus managing NICs should be within scope. > > I don't think that's much of an argument. Plenty of things can be > considered fundamental. My kernel version certainly is, so why isn't > libvirt letting me upgrade that? What about my firewall? Why isn't > libvirt configuring my iSCSI target for me? The kernel version isn't fundamental to the task of provisioning and configuring a guest VM. When deploying a VM there is no general requirement to upgrade the host kernel. When deploying a VM there very much is a requirement to configure physical resources in the host such as storage, and networking. > We should be considering why libvirt is /well-placed/ to configure the > host. I think it should be pretty clear that it's actually not: the > problems around distro differences alone is a good indication. The > proposed API is anaemic enough to not be of much use. The existance of many different impls is exactly the reason for libvirt to have this capability. Libvirt is providing a consistent mgmt API for management of guests and host networking interfaces is as much a part of this as the storage management. Libvirt is providing this capability across virtualization technology. If we did not include the NIC mgmt then apps using libvirt would not only need to write different code for each OS, but also for Xen, VMWare, etc each of have their own APIs for network management which is just not helpful for apps using libvirt. We already have this problem in apps using libvirt needing to cope with different OS networking setups and thus duplicating all this horrible code in every user of libvirt, which is why networking mgmt is a important goal within scope. > This is way beyond carving out the physical system into virtual chunks > and it's a big step towards lib*virt* becoming libmanagement. Not really - it is precisely about carving up / managing physical resources that are related to the guest configuration. It is not about arbitrary OS management - we don't want an API to deploy RPMs, or configure Apache, or any other things related to general OS management. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list