[libvirt] CGROUPS network classID setting in domain

D. Herrendoerfer d.herrendoerfer at herrendoerfer.name
Wed Dec 1 15:32:57 UTC 2010


Hi,

I went ahead and added what was needed to work the network
controller - that was easy.

The basic way it works is beautifully simple - if there is a cgroup
net_cls controller, then the qemu_driver will initialize it and add
a default classid.

With this approach modelling traffic is relatively easy across
more than one interface, but restricted when several VMs communicate
over one interface.

The changes I made so far don't require changes to domain xml, and they
will only work on linux hosts with cgroups enabled.

If there are no objections to the design itself I'd post the patches  
soon.

Regards,

Dirk

On Nov 22, 2010, at 8:23 PM, D. Herrendoerfer wrote:

>
> On Nov 22, 2010, at 2:21 PM, Daniel P. Berrange wrote:
>
>> On Thu, Nov 18, 2010 at 04:22:49PM +0100, D. Herrendoerfer wrote:
>>> Hello,
>>>
>>> I'm looking into the possibility of putting a network(tc) classID  
>>> into
>>> to the domain description and adding it into a (possibly) mounted
>>> cgroup directory upon launch of a VM.
>>>
>>> Has anyone before looked into this ?
>>> I've seen this mentioned in an abstract by Daniel B.
>>>
>>> I imagine a classid entry to look somewhat like:
>>>
>>> <domain type='qemu'>
>>> <name > foo</name>
>>> <uuid>3e3fce45-4f53-4fa7-bb32-11f34168b82b </uuid>
>>> ...
>>> <classid>0x1234</classid>
>>>
>>> ...
>>>
>>> Thoughts ?
>>
>> This isn't a very nice approach to modelling network controls
>> for a guest. The use of 'tc' for controlling networking is
>> a Linux specific implementation detail, that is not at all
>> applicable to any other platform. A bare classid on its own
>> also has zero semantic value - this is akin to configuring
>> guest disks by using an inode number in the XML instead of
>> the file path.
>>
>
> Agreed, but ..
>
>> Any networking controls really need a higher level XML
>> description of the conceptual policy that is being applied
>> to the network traffic, that is independant of any single
>> implementation mechanism. Internally libvirt would create
>> TC classids itself per VM, and map those to cgroups.
>>
>
> .. I don't really want to use libvirt for a "one-shot" configuration
> of the network policy, but rather manage a group of classid
> settings and simply have the ability to classify a VM to a group.
> This management is specific to a host, not a single VM.
> Therefore it would be a great benefit if libvirt would simply
> set a classid for a running VM, and let the network admin tool
> figure out the traffic shaping.
>
>
>> Regards,
>> Daniel
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list




More information about the libvir-list mailing list