Ways to exit from kvm on behalf of the quest system?

Ways to exit from kvm on behalf of the quest system?

[Dimitry Golubovsky]

Hi,

What are possible ways to exit from kvm on behalf of the quest OS
(mainly Linux) when it shuts down?

I use console redirected to serial port (-append console=ttyS0), and
serial port to stdio (-serial stdio), that is, the terminal window
that started kvm becomes guest console, and qemu console seems to be
unavailable. I disable the SDL window as graphics is very slow. So I
see no way to send in a qemu monitor command.

One that works for me is not to disable ACPI, and then if the guest
kernel can use power management, kvm exits on "power off".

Are there other ways to exit from kvm if it is started with -no-acpi?
If kvm is started with -no-acpi then I only see "system halted", but
kvm does not exit.

I use kvm-17 with 2.6.21-ARCH kernel on the host.

Thanks.

PS I need this information to properly document usage scenarios in
kvmadm documentation.

-- 
Dimitry Golubovsky

Anywhere on the Web

-------------------------------------------------------------------------
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/

Re: Ways to exit from kvm on behalf of the quest system?

[Amit Shah]

On Tuesday 31 July 2007 22:26:28 Dimitry Golubovsky wrote:
> I use console redirected to serial port (-append console=ttyS0), and
> serial port to stdio (-serial stdio), that is, the terminal window
> that started kvm becomes guest console, and qemu console seems to be
> unavailable. I disable the SDL window as graphics is very slow. So I
> see no way to send in a qemu monitor command.

From

http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC32

Use Ctrl-a c to switch between the serial console and the monitor (see section 
3.4 Keys).

Amit

-------------------------------------------------------------------------
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/

Re: Ways to exit from kvm on behalf of the quest system?

[Dimitry Golubovsky]

Amit,

On 7/31/07, Amit Shah <amit.shah-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:

> > unavailable. I disable the SDL window as graphics is very slow. So I
> > see no way to send in a qemu monitor command.
>
> From
>
> http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC32
>
> Use Ctrl-a c to switch between the serial console and the monitor (see section
> 3.4 Keys).
>

Thanks. I'll try this. However I am still interested in kvm exit on
behalf of the guest system w/o acpi. I experiment with running KVM in
X window environment (window manager runs on the virtual machine, not
on host). At the moment the guest OS shuts down, console window may
lose focus, and since window manager has already been killed by OS
shutdown, the console window may not be accessible for keyboard input.
To fix this, I patched evilwm (the simpliest window manager
available): when kvm process exits, its parent shell script sends
evilwm a signal, and it restarts. Thus window management will be
restored. But kvm should exit.

In general, it would be a useful option if qemu monitor was accessible
from within the guest OS as some virtual character device where
commands might be written. Unfortunately I couldn't find anything like
this in QEMU documentation.

PS How does the -no-reboot option work?

I never was able to actually _reboot_ an OS in kvm - it just hangs.

Thanks.

-- 
Dimitry Golubovsky

Anywhere on the Web

-------------------------------------------------------------------------
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/

Re: Ways to exit from kvm on behalf of the quest system?

[Avi Kivity]

Dimitry Golubovsky wrote:
> I never was able to actually _reboot_ an OS in kvm - it just hangs.
>
>   

Please follow the usual bug report procedure: what host, what cpu, what 
guest, what kvm, how to reproduce.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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/

Re: Ways to exit from kvm on behalf of the quest system?

[Dimitry Golubovsky]

Avi,

OK, I'll try to summarize that. However I'd also like to make a
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.

Thank you

On 8/1/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> Dimitry Golubovsky wrote:
> > I never was able to actually _reboot_ an OS in kvm - it just hangs.
> >
> >
>
> Please follow the usual bug report procedure: what host, what cpu, what
> guest, what kvm, how to reproduce.
>
>
> --
> error compiling committee.c: too many arguments to function
>
>


-- 
Dimitry Golubovsky

Anywhere on the Web

-------------------------------------------------------------------------
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/

Re: Ways to exit from kvm on behalf of the quest system?

[Avi Kivity]

Dimitry Golubovsky wrote:
> Avi,
>
> OK, I'll try to summarize that. However I'd also like to make a
> 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.
>   

That exists now.  Look up the -monitor option --   you can redirect the 
monitor to a unix domain socket, a tcp socket, a pty, or wherever you like.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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/

Re: Ways to exit from kvm on behalf of the quest system?

[Daniel P. Berrange]

On Wed, Aug 01, 2007 at 12:48:51PM -0400, Dimitry Golubovsky wrote:
> OK, I'll try to summarize that. However I'd also like to make a
> 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.

Unless you whitelist which monitor commands it can run this would be a
significant security hole.  eg a guest could run

   'usb_add disk /some/path'

To get access to arbitrary files & disks from the host.

Dan,
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
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/

Re: Ways to exit from kvm on behalf of the quest system?

[Dimitry Golubovsky]

Daniel,

On 8/1/07, Daniel P. Berrange <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> Unless you whitelist which monitor commands it can run this would be a
> significant security hole.  eg a guest could run
>
>   'usb_add disk /some/path'
>
> To get access to arbitrary files & disks from the host.
>

If we assume that kvm runs under root, yes (and if kvm finds out it
runs under root, it might disable such access to monitor). I have
written a suid wrapper (very simple) that does whatever necessary
under root, and then drops to user privileges, then execs kvm, so
these actions will be limited by Linux multi-user mechanisms as usual.
In my daily practice, I run kvm under my user privileges, and it works
fine.

See the kvmadm project (link on the kvm wiki page "Management tools").

-- 
Dimitry Golubovsky

Anywhere on the Web

-------------------------------------------------------------------------
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/

Re: Ways to exit from kvm on behalf of the quest system?

[Daniel P. Berrange]

On Wed, Aug 01, 2007 at 01:06:22PM -0400, Dimitry Golubovsky wrote:
> Daniel,
> 
> On 8/1/07, Daniel P. Berrange <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> 
> > Unless you whitelist which monitor commands it can run this would be a
> > significant security hole.  eg a guest could run
> >
> >   'usb_add disk /some/path'
> >
> > To get access to arbitrary files & disks from the host.
> >
> 
> If we assume that kvm runs under root, yes (and if kvm finds out it
> runs under root, it might disable such access to monitor). I have
> written a suid wrapper (very simple) that does whatever necessary
> under root, and then drops to user privileges, then execs kvm, so
> these actions will be limited by Linux multi-user mechanisms as usual.
> In my daily practice, I run kvm under my user privileges, and it works
> fine.

It can be a problem even if running as an unprivileged user, since the 
guest can read/write any files owned by that user - for example other 
guest disk images the user may have in their home dir.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
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/

Re: Ways to exit from kvm on behalf of the quest system?

[Anthony Liguori]

Dimitry Golubovsky wrote:
> Avi,
>
> OK, I'll try to summarize that. However I'd also like to make a
> 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.

Regards,

Anthony Liguori

> Thank you
>
> On 8/1/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>   
>> Dimitry Golubovsky wrote:
>>     
>>> I never was able to actually _reboot_ an OS in kvm - it just hangs.
>>>
>>>
>>>       
>> Please follow the usual bug report procedure: what host, what cpu, what
>> guest, what kvm, how to reproduce.
>>
>>
>> --
>> error compiling committee.c: too many arguments to function
>>
>>
>>     
>
>
>   


-------------------------------------------------------------------------
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/

Re: Ways to exit from kvm on behalf of the quest system?

[Dimitry Golubovsky]

Anthony,

On 8/1/07, Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> 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.

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.

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.

-- 
Dimitry Golubovsky

Anywhere on the Web

-------------------------------------------------------------------------
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/

Re: Ways to exit from kvm on behalf of the quest system?

[Anthony Liguori]

Dimitry Golubovsky wrote:
> Anthony,
>
> On 8/1/07, Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> 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/

Re: Ways to exit from kvm on behalf of the quest system?

[Dimitry Golubovsky]

Anthony,

On 8/1/07, Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> wrote:

> Why are you using a setuid wrapper instead of just changing ownership of
> /dev/kvm?

Ownership of /dev/kvm is adjusted to be of group "kvm" (for example)
and all users allowed to use it are in the same group. It is also
necessary to create a tap device (and through unique naming of it
users are prevented from running multiple instances of VMs thus
preventing memory overconsumption). Also it is necessary to connect
tap to bridge. If FS (CAP_NETADMIN) capabilities were available in
Linux by default then qemu process might be made capable of that (and
anyway, when dropping to user privileges, capabilities are masked
away). But they are only in special -mm patches, not in the mainstream
kernel. So these tap/bridge operations require root privileges.

> The power-off thing is a bug.  I was also thinking that it may be
> possible to detect when most guests have halted.

Power-off works for me though.

Thanks.

-- 
Dimitry Golubovsky

Anywhere on the Web

-------------------------------------------------------------------------
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/

Re: Ways to exit from kvm on behalf of the quest system?

[Anthony Liguori]

Dimitry Golubovsky wrote:
> Anthony,
>
> On 8/1/07, Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> wrote:
>
>   
>> Why are you using a setuid wrapper instead of just changing ownership of
>> /dev/kvm?
>>     
>
> Ownership of /dev/kvm is adjusted to be of group "kvm" (for example)
> and all users allowed to use it are in the same group.

Okay, so no root privileges are needed here.

>  It is also
> necessary to create a tap device (and through unique naming of it
> users are prevented from running multiple instances of VMs thus
> preventing memory overconsumption). Also it is necessary to connect
> tap to bridge. If FS (CAP_NETADMIN) capabilities were available in
> Linux by default then qemu process might be made capable of that (and
> anyway, when dropping to user privileges, capabilities are masked
> away). But they are only in special -mm patches, not in the mainstream
> kernel. So these tap/bridge operations require root privileges.
>   

This is one of the reasons the VDE project exists, to delegate 
privileges for tap/bridge devices.

Regards,

Anthony Liguori

>> The power-off thing is a bug.  I was also thinking that it may be
>> possible to detect when most guests have halted.
>>     
>
> Power-off works for me though.
>
> 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/

Re: Ways to exit from kvm on behalf of the quest system?

[Anthony Liguori]

Dimitry Golubovsky wrote:
> Anthony,
>
> On 8/1/07, Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> wrote:
>
>   
>> Why are you using a setuid wrapper instead of just changing ownership of
>> /dev/kvm?
>>     
>
> Ownership of /dev/kvm is adjusted to be of group "kvm" (for example)
> and all users allowed to use it are in the same group. It is also
> necessary to create a tap device (and through unique naming of it
> users are prevented from running multiple instances of VMs thus
> preventing memory overconsumption). Also it is necessary to connect
> tap to bridge. If FS (CAP_NETADMIN) capabilities were available in
> Linux by default then qemu process might be made capable of that (and
> anyway, when dropping to user privileges, capabilities are masked
> away). But they are only in special -mm patches, not in the mainstream
> kernel. So these tap/bridge operations require root privileges.
>
>   
>> The power-off thing is a bug.  I was also thinking that it may be
>> possible to detect when most guests have halted.
>>     
>
> Power-off works for me though.
>   

Note that if your running Linux as a guest, you can issue:

modprobe apm power_off=1

And then when the guest shutdowns, QEMU will exit as expected.  I'm not 
really sure why distros aren't loading apm automatically.

Regards,

Anthony Liguori

> 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/