Avi Kivity <avi@xxxxxxxxxx> writes: > On 08/27/2012 02:27 PM, Michael Wolf wrote: >> On Mon, 2012-08-27 at 13:31 -0700, Avi Kivity wrote: >> > On 08/27/2012 01:23 PM, Michael Wolf wrote: >> > > > >> > > > How would a guest know what its entitlement is? >> > > > >> > > > >> > > >> > > Currently the Admin/management tool setting up the guests will put it on >> > > the qemu commandline. From this it is passed via an ioctl to the host. >> > > The guest will get the value from the host via a hypercall. >> > > >> > > In the future the host could try and do some of it automatically in some >> > > cases. >> > >> > Seems to me it's a meaningless value for the guest. Suppose it is >> > migrated to a host that is more powerful, and as a result its relative >> > entitlement is reduced. The value needs to be adjusted. >> >> This is why I chose to manage the value from the sysctl interface rather >> than just have it stored as a value in /proc. Whatever tool was used to >> migrate the vm could hopefully adjust the sysctl value on the guest. > > We usually try to avoid this type of coupling. What if the guest is > rebooting while this is happening? What if it's not running Linux at > all? The guest shouldn't need to know it's entitlement. Or at least, it's up to a management tool to report that in a way that's meaningful for the guest. For instance, with a hosting provider, you may have 3 service levels (small, medium, large). How you present whether the guest is small, medium, or large to the guest is up to the hosting provider. > >> > >> > This is best taken care of from the host side. >> >> Not sure what you are getting at here. If you are running in a cloud >> environment, you purchase a VM with the understanding that you are >> getting certain resources. As this type of user I don't believe you >> have any access to the host to see this type of information. So the >> user still wouldnt have a way to confirm that they are receiving what >> they should be in the way of processor resources. >> >> Would you please elaborate a little more on this? > > I meant not reporting this time as steal time. But that cripples steal > time reporting. > > Looks like for each quanta we need to report how much real time has > passed, how much the guest was actually using, and how much the guest > was not using due to overcommit (with the reminder being unallocated > time). The guest could then present it any way it wanted to. What I had previously suggested what splitting entitlement loss out of steal time and reporting it as a separate metric (but not reporting a fixed notion of entitlement). You're missing the entitlement loss bit above. But you need to call out entitlement loss in order to report idle time correctly. I think changing steal time (as this patch does) is wrong. Regards, Anthony Liguori > > -- > I have a truly marvellous patch that fixes the bug which this > signature is too narrow to contain. > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
