From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Ways to exit from kvm on behalf of the quest system? Date: Wed, 01 Aug 2007 16:28:02 -0500 Message-ID: <46B0FAE2.4090906@codemonkey.ws> References: <200708010047.36600.amit.shah@qumranet.com> <46B0B779.5050407@qumranet.com> <46B0CCC3.6010308@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Dimitry Golubovsky Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Dimitry Golubovsky wrote: > Anthony, > > On 8/1/07, Anthony Liguori wrote: > > >>> feature request: a virtual character device (sort of a virtual serial >>> line) that the guest OS might use to communicate with the QEMU >>> monitor. That might solve many problems. >>> >>> >> Can you provide the use-case you're looking to address with this? As >> Dan mentioned, this would be pretty hairy from a security perspective >> since the guest could do things it's not supposed to be able to do but >> if you've got something specific in mind, there might be another way to >> achieve the same results without compromising security. >> > > I am working on the project named "kvmadm" which is aimed to giving > users private VMs instead of shell accounts on the host. > > This first of all means that VMs run under privileges of users who > started them (there is a suid wrapper that does the root work). > Secondly, users are limited in kvm options they are able to supply > (mainly to name disk image files and kernel file to boot from - by the > means of the same wrapper). Thirdly, power of users to harm the system > is same as if they had regular shell accounts on the host that runs > their VMs. > Why are you using a setuid wrapper instead of just changing ownership of /dev/kvm? > Possible use case for the feature I am proposing: > > When guest OS completes shutdown, there should be a clear signal to > kvm to exit. One possibility is power-off via ACPI which works, but > there may be problems with acpi (some sources recommend to turn it > off; personally I personally encountered instability and hangups when > booting a guest with rtc and acpi enabled together, so I can boot > either with -no-acpi or with -no-rtc, works fine). Another possibility > would be sending a monitor command via proposed channel to exit kvm. > The power-off thing is a bug. I was also thinking that it may be possible to detect when most guests have halted. Regards, Anthony Liguori > It may not always be possible to enter such command manually: earlier > in this thread I described the situation when the guest OS runs a X > window manager, and it is killed during shutdown, the console window > may become unaccessible for keyboard input. In the kvmadm wiki, I > described the way to switch between host's and guest's window > managers, but kvm process must exit in order for this to work as it is > not possible to know from outside if the guest OS shut down. > > Thanks. > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/