[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Should Qemu monitor be enabled by default



On Thu, Apr 12, 2007 at 09:40:26PM +0100, Christian Limpach wrote:
> On 4/12/07, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:
> >This part of the patch does not look correct:
> >
> >-- a/tools/python/xen/xend/image.py     Thu Apr 12 13:18:08 2007 +0100
> >+++ b/tools/python/xen/xend/image.py    Thu Apr 12 13:21:26 2007 +0100
> >@@ -415,6 +415,8 @@ class HVMImageHandler(ImageHandler):
> >         else:
> >             ret.append('-nographic')
> >
> >+        if int(vmConfig['platform'].get('monitor', 0)) != 0:
> >+            ret.append('-monitor vc')
> >         return ret
> >
> >     def createDeviceModel(self, restore = False):
> >
> >The '-monitor vc' is already the default for QEMU, so both branches of
> >that if end up reducing to the same functional state - the monitor being
> >enabled. You need to explicitly disable the monitor if the config file
> >has monitor=0
> 
> No, the monitor in qemu is off by default, the patch is correct as is.

Is that a recent Xen-specific change to QEMU ? The regular QEMU has always 
had the monitor on by default - and its on by default in Xen 3.0.3/4 :

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

 "-monitor dev
    Redirect the monitor to host device dev (same devices as the serial port). 
    The default device is vc in graphical mode and stdio in non graphical mode."

> >I'm not sure this patch is a good idea long term though. If, as Anthony
> >suggests in previous thread, XenD takes control of the monitor and provides
> >an explicit 'xm monitor' command, then it'll be impossible to also make
> >the monitor also appear on a VC.
> >
> >This also doesn't address the issue that making the monitor appear on a
> >VC is fundamentally a security risk and so can never be enabled in any
> >production environment where you care about integrity of the Dom0 host.
> >I don't see the point in introducing a config file setting which will
> >have to go away once a sustainable 'xm monitor' patch is implemented.
> 
> Why shouldn't both co-exist?  You can have either monitor=pty or
> monitor=vc.  This is how serial ports work already.

What I mean is that if we wanted to implement a 'xm monitor' command,
then XenD would need to launch QEMU with '-monitor pty' (or equivalent)
at which point you'd be unable to also have '-monitor vc' on the same
command line.

> >For the timescales involved in 3.0.5 I think we should instead make sure
> >that 'xm block-configure' works correctly.
> 
> How does it not work correctly?

I've not had any trouble with it myself, but I've not tested it much.
I was refering to the earlier mail in this thread

http://lists.xensource.com/archives/html/xen-devel/2007-04/msg00222.html

where Nishi indicated his motivation for wanting access to the monitor
via a VC was that block-configure wasn't reliable. 

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.