Re: [libvirt] Release of libvirt-0.4.6

2008-09-29 Thread Gerd Hoffmann
Stefan de Konink wrote: - From your position; is there currently anything in the pipeline so Xen users soon can work without XenD (aka the big memoryleak)? I have patches for qemu creating xen domains directly in my queue of stuff to be merged upstream. Right now (patches) qemu handles the

Re: [libvirt] Re: Overriding vnetN with the target element in xml configuration not working

2008-09-29 Thread Daniel P. Berrange
On Sat, Sep 27, 2008 at 02:58:14AM +0200, Ahmed Medhat wrote: Ok, so its kinda creepy now, it works with change the device name to anything but vnetN. vnetNNN is an automatically generated device name pattern. We explicitly ignore any requested target dev with that naming pattern because

[libvirt] [PATCH] openvz: swap source bridge=... with target dev=...

2008-09-29 Thread Anton Protopopov
2008/9/29 Evgeniy V. Sokolov [EMAIL PROTECTED] This behaviour contradicts with description found in docs (in which source tag specify interface in host, not in container). I think, the previous bridge must be specified as interface type='bridge' mac

Re: [libvirt] [PATCH] fix creating of openvz bridge device

2008-09-29 Thread Anton Protopopov
P.S. Are someone going to implement interface type='bridge' ... source bridge=... ... /interface part of openvz driver? :) I plan to implement it in a month. It will be fine if you are ready to develop the feature. How we can save, say, a name of a

Re: [libvirt] Release of libvirt-0.4.6

2008-09-29 Thread Stefan de Konink
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Gerd Hoffmann schreef: Stefan de Konink wrote: - From your position; is there currently anything in the pipeline so Xen users soon can work without XenD (aka the big memoryleak)? I have patches for qemu creating xen domains directly in my

Re: [libvirt] [PATCH] openvz: swap source bridge=... with target dev=...

2008-09-29 Thread Evgeniy Sokolov
2008/9/29 Evgeniy V. Sokolov [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] This behaviour contradicts with description found in docs (in which source tag specify interface in host, not in container). I think, the previous bridge must be

Re: [libvirt] [PATCH] openvz: swap source bridge=... with target dev=...

2008-09-29 Thread Daniel P. Berrange
On Mon, Sep 29, 2008 at 04:11:39PM +0400, Evgeniy Sokolov wrote: 2008/9/29 Evgeniy V. Sokolov [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] This behaviour contradicts with description found in docs (in which source tag specify interface in host, not in

[libvirt] [PATCH 1 of 2] Add internal cgroup manipulation functions

2008-09-29 Thread Dan Smith
This patch adds src/cgroup.{c,h} with support for creating and manipulating cgroups. It's quite naive at the moment, but should provide something to work with to move forward with resource controls. All groups created with the internal API are forced under $mount/libvirt/ to keep everything

Re: [libvirt] [PATCH] Fix 1 char device for qemu VM

2008-09-29 Thread Cole Robinson
Cole Robinson wrote: Trying to start a qemu guest with more than 1 character device (serial or parallel, doesn't count for console) always times out. There was an error in the code that would strip the pty path qemu spits out, which confused the parsing after being called more than twice.

[libvirt] [PATCH 2 of 2] Use cgroup functions to set resource limits on LXC domains

2008-09-29 Thread Dan Smith
This patch adds code to the controller to set up a cgroup called libvirt/lxc/$name, set the memory limit, and restrict devices. It also adds bits to lxc_driver to properly clean up the cgroup on domain death. If virCgroupHaveSupport() says that no support is available, then we just allow the

Re: [libvirt] [PATCH 0 of 2] [RFC] Add cgroup manipulation and LXC driver support

2008-09-29 Thread Balbir Singh
Dan Smith wrote: This patch set adds basic cgroup support to the LXC driver. It consists of a small internal cgroup manipulation API, as well as changes to the driver itself to utilize the support. Currently, we just set a memory limit and the allowed devices list. The cgroup.{c,h}