From: Rolando M. <rol...@gm...> - 2009-08-04 10:01:38
|
Hi, will the AlacrityVM architecture bypass the cgroups resource reservations? (like cpuset, networking, etc) Thanks, Rolando |
From: Gregory H. <gre...@gm...> - 2009-08-04 11:47:53
Attachments:
signature.asc
|
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 |
From: Rolando M. <rol...@gm...> - 2009-08-04 11:54:24
|
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 > > > |
From: Gregory H. <gre...@gm...> - 2009-08-04 12:07:06
Attachments:
signature.asc
|
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 |