Re: [RFC] cgroups net_cls controller implementation

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

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]