alacrityvm-users

[Alacrityvm-users] AlacrityVM and cgroups

[Rolando M. <rol...@gm...>]

Hi,
will the AlacrityVM architecture bypass the cgroups resource
reservations? (like cpuset, networking, etc)

Thanks,
Rolando

Re: [Alacrityvm-users] AlacrityVM and cgroups

[Gregory H. <gre...@gm...>]

Rolando Martins wrote:
> Hi,
> will the AlacrityVM architecture bypass the cgroups resource
> reservations? (like cpuset, networking, etc)


Hi Rolando,

There are no plans to do anything like that.  As it stands right now, it
should integrate seemlessly with cgroups et. al.

Are you asking because you would be concerned it we did?  Or are you
asking because you would like to see this feature added?

Regards,
-Greg

Re: [Alacrityvm-users] AlacrityVM and cgroups

[Rolando M. <rol...@gm...>]

Hi Greg,
thanks for the quick answer. I was asking because I was concern about
a possible bypass.
Being integrated with cgroups, we could maintain resources
reservations across VM's, and other system services.

Thanks,
Rolando


On Tue, Aug 4, 2009 at 12:47 PM, Gregory
Haskins<gre...@gm...> wrote:
> Rolando Martins wrote:
>> Hi,
>> will the AlacrityVM architecture bypass the cgroups resource
>> reservations? (like cpuset, networking, etc)
>
>
> Hi Rolando,
>
> There are no plans to do anything like that.  As it stands right now, it
> should integrate seemlessly with cgroups et. al.
>
> Are you asking because you would be concerned it we did?  Or are you
> asking because you would like to see this feature added?
>
> Regards,
> -Greg
>
>
>

Re: [Alacrityvm-users] AlacrityVM and cgroups

[Gregory H. <gre...@gm...>]

Rolando Martins wrote:
> Hi Greg,
> thanks for the quick answer. I was asking because I was concern about
> a possible bypass.

Ah, I see.

> Being integrated with cgroups, we could maintain resources
> reservations across VM's, and other system services.

Yes, this should work fine I believe.

Note: Since the device modules live in the kernel, I suppose that
someone could possibly craft a module that does alter other kernel
subsystems such as cgroups.  However, this isn't unique to vbus per se
(any host kernel module would have the same access), and the admittance
of such a module is completely under the control of the host
administrator.  In addition, the module in question would have to
explicitly expose any hooks to the guest in order to allow the guest to
have any semblance of control over that facet of its operation.

That said, I am not really sure how or why someone would try to bypass
cgroups.  I certainly have no intention of developing such a module
myself, and I do not believe it would be very easy as a pure LKM since
the scheduler is not directly exposed.


> 
> On Tue, Aug 4, 2009 at 12:47 PM, Gregory
> Haskins<gre...@gm...> wrote:
>>
>> There are no plans to do anything like that.  As it stands right now, it
>> should integrate seemlessly with cgroups et. al.

Or seamlessly, even. ;)

/me grumbles at my own poor spelling.

Regards,
-Greg