9:22 a.m.
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 ?
Best regards,
D. Herrendoerfer
7:21 a.m.
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.
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.
Regards,
Daniel
1:23 p.m.
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
9:32 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
5135
days inactive
5148
days old
3 comments
2 participants
participants (2)
-
D. Herrendoerfer -
Daniel P. Berrange