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

Re: [Xen-users] Re: graphically accessing pv guest


  • To: Ted Brenner <griztown@xxxxxxxxx>
  • From: Melody Bliss <melodybliss@xxxxxxxxx>
  • Date: Tue, 1 Mar 2011 21:39:39 -0800
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx, "Fajar A. Nugraha" <list@xxxxxxxxx>
  • Delivery-date: Tue, 01 Mar 2011 21:40:29 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NBvixcOSiSkg21TWXgRuL00hkTY3DmcCFS4gr/pTMj2KD1a/+WaSkma2OGfiWUX8Fx DcbAX9FguEBdm5MJ03XrtMR+5CZQyYoGYLKVZEX/RVI+jCfxdXu7cFnvPISrE8AN8X6V IriaIcgYaMREmm/qckA8DOWTHgqUoJ7VD8VPQ=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

in the shell you're executing "xm vncviewer domainID", you can type

echo $DISPLAY

is it set to anything?

if it looks something like this

bash-3.2$ echo $DISPLAY
:0.0

then your X Windows display is set to localhost. If this is a remote
machine (not your local machine), then this won't work for you. You
need to export the display back to your local machine.

So, starting from my local desktop, connect to the remote (xen dom0)
using "ssh -Y" (for trusted X11 forwarding).

For example, if your remote (dom0) system is called xenhost, use

ssh -Y root@xenhost

This will enable (hopefully if it's allowed) X11 forwarding back to
your desktop over an encrypted ssh session and allow you to do your
"xm vncviewer domID" successfully.

Mel

On Tue, Mar 1, 2011 at 7:30 PM, Melody Bliss <melodybliss@xxxxxxxxx> wrote:
> That's an X Windows error (Can't open display). What is your DISPLAY
> set to? Are you running an X Server?
>
> Mel
>
> On Tue, Mar 1, 2011 at 6:51 PM, Ted Brenner <griztown@xxxxxxxxx> wrote:
>> So I made these changes but now I get the following error after typing in
>> #xm vncviewer domainID
>>
>> invoking  vncviewer 0.0.0.0:1
>> No protocol specified
>> Error: Can't open display: :0.0
>>
>> I'm currently listening on 0.0.0.0 but I've also tried 127.0.0.1 with the
>> same affect.  What would cause this error?
>>
>> On Sun, Feb 27, 2011 at 10:27 PM, Fajar A. Nugraha <list@xxxxxxxxx> wrote:
>>>
>>> On Mon, Feb 28, 2011 at 10:15 AM, Ted Brenner <griztown@xxxxxxxxx> wrote:
>>> > Is it possible that in Xen 4.0+, the 'xenfb.video' should be added to
>>> > the
>>> > kernel line of the /boot/grub/menu.lst file?
>>> >
>>> > On Sun, Feb 27, 2011 at 10:49 AM, Ted Brenner <griztown@xxxxxxxxx>
>>> > wrote:
>>> >>
>>> >> Hi all,
>>> >>
>>> >> I'm trying to expand the screen resolution of my guest when using vnc.
>>> >> It
>>> >> appears I need to use the extra variable in my guest config file and
>>> >> xenfb.
>>> >> I pass it in like this:
>>> >>
>>> >> extra = 'xenfb.video=8,1024,768'
>>> >>
>>> >> I can see this being passed to the kernel when it boots but it doesn't
>>> >> change the vnc screen resolution.
>>>
>>> Thanks for pointing out that parameter.
>>>
>>> There are three parts answer to your question.
>>>
>>> The first part, being how to pass a parameter to kernel. That would
>>> depend on how you boot domU:
>>> - If you use pygrub/pv-grub, then the correct way to pass it would be
>>> to edit domU's grub config file (or some other config file that is
>>> used to generate it, like /etc/default/grub).
>>> - If you use pygrub, you might be able to use "args" to add it without
>>> editing domU's grub config file
>>> - If you use "kernel" and "ramdisk", then the right way to add it is
>>> on "extra" line (which should already contain things like "root=")
>>> You can check with "cat /proc/cmdline" inside domU to see if the
>>> parameter is correctly passed to domU kernel.
>>>
>>> The second part is where to put the parameter:
>>> - If xen vfb support is compiled built-in in domU kernel, then the
>>> only place to pass it is on domU kernel command line, using one oh the
>>> three options mentioned above
>>> - If xen vfb support is built as a module, you can pass it on domU
>>> kernel command line, or by simply creating a .conf file on
>>> /etc/modprobe.d (recommended)
>>>
>>> The third part is what's the correct module name, and what parameter
>>> to pass. In Ubuntu maverick, the module name is xen-fbfront.
>>> $ modinfo xen-fbfront
>>> filename:
>>> /lib/modules/2.6.35-25-generic/kernel/drivers/video/xen-fbfront.ko
>>> alias:          xen:vfb
>>> license:        GPL
>>> description:    Xen virtual framebuffer device frontend
>>> srcversion:     0EB34742ACF8D2559403034
>>> depends:        fb_sys_fops,syscopyarea,sysfillrect,sysimgblt
>>> vermagic:       2.6.35-25-generic SMP mod_unload modversions
>>> parm:           video:Video memory size in MB, width, height in pixels
>>> (default 2,800,600) (array of int)
>>>
>>>
>>> So considering all three parts, if you use Ubuntu maverick and want to
>>> use 1280x1024, you can just create a file like this:
>>> $ cat /etc/modprobe.d/xen-fbfront.conf
>>> options xen-fbfront video=32,1280,1024
>>>
>>> A "depmod -a" and "update-initramfs -u" might be needed afterwards.
>>> After reboot, it should correctly use 1280x1024 resolution.
>>>
>>> I still say you should use things like NX/xrdp/vnc server inside domU
>>> though (my favorite is xrdp). It's smooth, easy to install (apt-get
>>> install xrdp), can allow you to choose different resolution without
>>> having to reboot (just specify the desired resolution and color depth
>>> when you connect), and allows you to have multiple GUI session to the
>>> client (using idfferent user-resolution-depth combination)
>>>
>>> --
>>> Fajar
>>
>>
>>
>> --
>> Ted Brenner
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-users
>>
>
>
>
> --
> Melody Bliss
> Usenix, SAGE and LOPSA Charter Member
> Patron Member of the NRA
>



-- 
Melody Bliss
Usenix, SAGE and LOPSA Charter Member
Patron Member of the NRA

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


 


Rackspace

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