On Wed, Dec 08, 2010 at 01:08:36PM +0100, D. Herrendoerfer wrote: > I disagree. The concept of QoS is not pertinent to a single VM > description; > it is a constrainment of the Host. Libvirt vor example has no concept > of multiple VLAN distribution on a single machine and is dependent > on other tools to provide them. > True network QoS (802.1p) on the other hand is, in linux, bound to a > specific VLAN > interface, and having a single VM try to modify these settings will > affect all users of that VLAN. > > Using cgroups in this context is a wonderful way of managing bandwidth > between groups of VMs, to make sure one cannot stave-out the other, but > again - this is a Host Where the network settings need to be configured & applied can vary depending on what network settings you're trying to manage. There's been no description of what the design goals or required network controls are, so it is impossible to say where they must be configured in libvirt. Even if there are settings which are not applicable for the VM configuration, there are other existing areas of libvirt where they can be applied, and scope for adding further APIs if no existing functionality is sufficient. As an example, in VMWare they have a 'Virtual Switch' which then has a number of 'Port Groups'. A VM NIC is associated with a port group. Network QoS is configured against the port groups. I could easily envisage such a model being something should have in the libvirt API and build for QEMU, potentially backed up by cgroups+tc. Cgroups could even be the wrong approach if we want a VM to have multiple NICs, each with a different policy, since cgroups control the VM as a whole, not individual VM NICs. Starting from "We need to let admins set the 'tc' classid" is wrong approach to dealing with this in libvirt. We need to start from a consideration of what general capabilities & concepts we want to represent & model in the XML/APIs. Then consider how these concepts could be mapped to the platforms or hypervisors libvirt wants to support. Directly exposing 'tc' as an implementation to the end administrator or app developer is at odds with the libvirt goals. Regards, Daniel -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list