Xen devel - Jul 2008 - qemu-dm exit(1) for invalid option ''-vncviewer'' -- Xen #18023

qemu.log:
domid: 3
qemu: the number of cpus is 1
/usr/lib64/xen/bin/qemu-dm: invalid option -- ''-vncviewer''

As QEMU_REMOTE is used for ioemu by default, regression was introduced
accordingly. 
Looks xm/xend is still passing ''-vncviewer'' to qemu-dm, which
causes
qemu-dm exit(1), and HVM guest creation is failed. 


-- haicheng

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

Keir Fraser writes ("FW: [Xen-devel] qemu-dm exit(1) for invalid option
''-vncviewer'' -- Xen #18023"):
> Conversation: qemu-dm exit(1) for invalid option
''-vncviewer'' -- Xen #18023
> Subject: [Xen-devel] qemu-dm exit(1) for invalid option
''-vncviewer'' -- Xen
> #18023
This option works (worked) by passing the caller''s display and
xauthority through xm and xend to qemu.  qemu then connects to it
later.  This is a very remarkable way of going about things.  Its
security properties are problematic from several points of view.

I had assumed that because it was so strange no-one would be using it,
so I deliberately dropped that change.  Evidently I was wrong.  If
this is a feature that is seriously used then I could reinstate it but
I think it should come with a health warning.

A better place to implement this would be xm or some higher level
tool, I think, but that wouldn''t be sensible at this stage of the
release cycle.
> Looks xm/xend is still passing ''-vncviewer'' to qemu-dm,
which causes
> qemu-dm exit(1), and HVM guest creation is failed.
For now, if you turn off the vncviewer option it will work.  If there
is demand I''ll look into cross-porting this feature (on Monday,
probably).

Ian.

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

On Fri, Jul 11, 2008 at 11:39:13AM +0100, Ian Jackson
wrote:
> Keir Fraser writes ("FW: [Xen-devel] qemu-dm exit(1) for invalid
option ''-vncviewer'' -- Xen #18023"):
> > Conversation: qemu-dm exit(1) for invalid option
''-vncviewer'' -- Xen #18023
> > Subject: [Xen-devel] qemu-dm exit(1) for invalid option
''-vncviewer'' -- Xen
> > #18023
> 
> This option works (worked) by passing the caller''s display and
> xauthority through xm and xend to qemu.  qemu then connects to it
> later.  This is a very remarkable way of going about things.  Its
> security properties are problematic from several points of view.
> 
> I had assumed that because it was so strange no-one would be using it,
> so I deliberately dropped that change.  Evidently I was wrong.  If
> this is a feature that is seriously used then I could reinstate it but
> I think it should come with a health warning.
I think it should be killed - its easy todo it in the ''xm''
client code,
after all xm already knows how to spawn ''xm console'' for text
mode
display - this is just same use case in graphical mode.
> A better place to implement this would be xm or some higher level
> tool, I think, but that wouldn''t be sensible at this stage of the
> release cycle.
xm already seems to have some kind of vncviewer support, though its
running it in listen mode, rather than connect mode. 

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

On Fri, Jul 11, 2008 at 11:46:42AM +0100, Daniel P. Berrange wrote:
> > This option works (worked) by passing the caller''s display
and
> > xauthority through xm and xend to qemu.  qemu then connects to it
> > later.  This is a very remarkable way of going about things.  Its
> > security properties are problematic from several points of view.
> > 
> > I had assumed that because it was so strange no-one would be using it,
> > so I deliberately dropped that change.  Evidently I was wrong.  If
> > this is a feature that is seriously used then I could reinstate it but
> > I think it should come with a health warning.
What might be useful is allowing "wait" mode for VNC like you can with
telnet serial console. I''m suspecting that''s the only reason
you would
ever want -vncviewer (to catch the BIOS screen).
> I think it should be killed - its easy todo it in the
''xm'' client code,
> after all xm already knows how to spawn ''xm console'' for
text mode
> display - this is just same use case in graphical mode.
Heck, then can we kill SDL, which does exactly the same thing, but in
xend?

I must admit when I discovered this, I blanched.

john

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

On Fri, Jul 11, 2008 at 04:27:36PM +0100, John Levon
wrote:
> On Fri, Jul 11, 2008 at 11:46:42AM +0100, Daniel P. Berrange wrote:
> 
> > > This option works (worked) by passing the caller''s
display and
> > > xauthority through xm and xend to qemu.  qemu then connects to it
> > > later.  This is a very remarkable way of going about things.  Its
> > > security properties are problematic from several points of view.
> > > 
> > > I had assumed that because it was so strange no-one would be
using it,
> > > so I deliberately dropped that change.  Evidently I was wrong. 
If
> > > this is a feature that is seriously used then I could reinstate
it but
> > > I think it should come with a health warning.
> 
> What might be useful is allowing "wait" mode for VNC like you can
with
> telnet serial console. I''m suspecting that''s the only
reason you would
> ever want -vncviewer (to catch the BIOS screen).
If we launched it from ''xm'', I''d xm would have to
wait on xenstore for
the VNC port number to be written, at which point it can immediately
launch vncviewer. We do this in virt-install and its quick  enough to
catch the BIOS screen.
> 
> > I think it should be killed - its easy todo it in the
''xm'' client code,
> > after all xm already knows how to spawn ''xm console''
for text mode
> > display - this is just same use case in graphical mode.
> 
> Heck, then can we kill SDL, which does exactly the same thing, but in
> xend?
It''d get my vote - a consistent source of pain & bug reports, but
quite
a few people seem to like this so I doubt its viable  to kill SDL :-(

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

On Fri, Jul 11, 2008 at 04:34:42PM +0100, Daniel P. Berrange wrote:
> > > > I had assumed that because it was so strange no-one would be
using it,
> > > > so I deliberately dropped that change.  Evidently I was
wrong.  If
> > > > this is a feature that is seriously used then I could
reinstate it but
> > > > I think it should come with a health warning.
> > 
> > What might be useful is allowing "wait" mode for VNC like
you can with
> > telnet serial console. I''m suspecting that''s the
only reason you would
> > ever want -vncviewer (to catch the BIOS screen).
> 
> If we launched it from ''xm'', I''d xm would have
to wait on xenstore for
> the VNC port number to be written, at which point it can immediately
> launch vncviewer. We do this in virt-install and its quick  enough to
> catch the BIOS screen.
I was thinking more about the case when DISPLAY isn''t set by the
virt-install user at all.
> > > I think it should be killed - its easy todo it in the
''xm'' client code,
> > > after all xm already knows how to spawn ''xm
console'' for text mode
> > > display - this is just same use case in graphical mode.
> > 
> > Heck, then can we kill SDL, which does exactly the same thing, but in
> > xend?
> 
> It''d get my vote - a consistent source of pain & bug reports,
but quite
> a few people seem to like this so I doubt its viable  to kill SDL :-(
What do they want it for?

regards
john

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

On Fri, Jul 11, 2008 at 4:41 PM, John Levon <levon@movementarian.org>
wrote:
> On Fri, Jul 11, 2008 at 04:34:42PM +0100, Daniel P. Berrange wrote:
>
> > > > > I had assumed that because it was so strange no-one
would be using
> it,
> > > > > so I deliberately dropped that change.  Evidently I was
wrong.  If
> > > > > this is a feature that is seriously used then I could
reinstate it
> but
> > > > > I think it should come with a health warning.
> > >
> > > What might be useful is allowing "wait" mode for VNC
like you can with
> > > telnet serial console. I''m suspecting that''s
the only reason you would
> > > ever want -vncviewer (to catch the BIOS screen).
> >
> > If we launched it from ''xm'', I''d xm would
have to wait on xenstore for
> > the VNC port number to be written, at which point it can immediately
> > launch vncviewer. We do this in virt-install and its quick  enough to
> > catch the BIOS screen.
>
> I was thinking more about the case when DISPLAY isn''t set by the
> virt-install user at all.
>
> > > > I think it should be killed - its easy todo it in the
''xm'' client
> code,
> > > > after all xm already knows how to spawn ''xm
console'' for text mode
> > > > display - this is just same use case in graphical mode.
> > >
> > > Heck, then can we kill SDL, which does exactly the same thing,
but in
> > > xend?
> >
> > It''d get my vote - a consistent source of pain & bug
reports, but quite
> > a few people seem to like this so I doubt its viable  to kill SDL :-(
>
> What do they want it for?
>
> regards
> john
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
It may be something as simple as proper mouse tracking, which tends to be
atrocious with vnc, but work perfectly with SDL.


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

On Fri, Jul 11, 2008 at 05:30:12PM +0100, Trolle Selander wrote:
> It may be something as simple as proper mouse tracking, which tends to be
> atrocious with vnc, but work perfectly with SDL.
It works fine with VNC and the usb tablet option enabled, which pretty
much every OS supports (unless you''re hellbent on running Solaris 9, I
suppose).

regards
john

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

Personally, I''ve never gotten the usb mouse/tablet support to work
right
with anything except Windows guests. This tends not to be much of an issue
with Linux, but as someone who has spent quite a bit of time working with
legacy OSs under Xen, I can tell you it definitely does not work with OS/2,
and there are probably "exotic" OSs out there that people are using or
tinkering with that have the same issue. Just to be clear, I''m not
really
protesting the removal of SDL, I''m just giving one example of why some
people may still be using it over vnc.

Cheers,
Trolle

On Fri, Jul 11, 2008 at 5:35 PM, John Levon <levon@movementarian.org>
wrote:
> On Fri, Jul 11, 2008 at 05:30:12PM +0100, Trolle Selander wrote:
>
> > It may be something as simple as proper mouse tracking, which tends to
be
> > atrocious with vnc, but work perfectly with SDL.
>
> It works fine with VNC and the usb tablet option enabled, which pretty
> much every OS supports (unless you''re hellbent on running Solaris
9, I
> suppose).
>
> regards
> john
>

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

Trolle Selander, le Fri 11 Jul 2008 17:55:26 +0100, a écrit
:
> Personally, I''ve never gotten the usb mouse/tablet support to work
right with
> anything except Windows guests. This tends not to be much of an issue with
> Linux,
On linux you just need to peek the USB tablet input device in
/dev/input/*, to trigger qemu''s switch to USB tablet events.

Samuel

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