[libvirt] CGROUPS network classID setting in domain
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
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
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
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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (2)
-
D. Herrendoerfer -
Daniel P. Berrange