guest video slow

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

guest video slow

Mike Wright
Hi all,

Been running xen since 2.something and now have a situation I've been
chasing for months on end without resolution.

There is a system whose guests' video, whether via ssh -Y or vnc is very
slow. You can see it "paint" the screen every 3/4 second or so.

Host ubuntu (14.04 thru 15.10) guest (started at 14.04, now 16.04).

Prior to a catastrophic crash that took out my internal and external
drives I was running Fedora with 5 fedora guests, each running gnome3
desktops, and was able to have all 5 of them running concurrent video
streams, with a vnc window open to each, in real time with no delay, so
I know xen can easily handle this.

Hardware is 3-core amd phenom, 16g ram, on a gigabyte mobo.
Software is now at xen-4.5 w/ ubuntu-15.10. Kernel is down rev 3.19
because the 4.x kernels don't recognize one of my drives.

It's hard to say it's ubuntu vs. fedora and am guessing it's something
to do with my guest config.  Here's the part re video:

vbf = [
   'sdl=1',
   'vnc=1',
   'vncdisplay=0',
]

I've tried all sorts of variations with these but truth is I'm shooting
in the dark.  As xen has evolved so has its documentation; a lot of it
is undated, much of it is contradictory, most of it is scattered.

Does anybody have any ideas?  Where do I go from here?   Could it be an
ubuntu problem? Does my config make sense?  straw(grasp);

Thanks for any help,
Mike Wright

_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: guest video slow

George Dunlap
On Sun, May 1, 2016 at 5:39 PM, Mike Wright <[hidden email]> wrote:

> Hi all,
>
> Been running xen since 2.something and now have a situation I've been
> chasing for months on end without resolution.
>
> There is a system whose guests' video, whether via ssh -Y or vnc is very
> slow. You can see it "paint" the screen every 3/4 second or so.
>
> Host ubuntu (14.04 thru 15.10) guest (started at 14.04, now 16.04).
>
> Prior to a catastrophic crash that took out my internal and external drives
> I was running Fedora with 5 fedora guests, each running gnome3 desktops, and
> was able to have all 5 of them running concurrent video streams, with a vnc
> window open to each, in real time with no delay, so I know xen can easily
> handle this.
>
> Hardware is 3-core amd phenom, 16g ram, on a gigabyte mobo.
> Software is now at xen-4.5 w/ ubuntu-15.10. Kernel is down rev 3.19 because
> the 4.x kernels don't recognize one of my drives.
>
> It's hard to say it's ubuntu vs. fedora and am guessing it's something to do
> with my guest config.  Here's the part re video:
>
> vbf = [
>   'sdl=1',
>   'vnc=1',
>   'vncdisplay=0',
> ]
>
> I've tried all sorts of variations with these but truth is I'm shooting in
> the dark.  As xen has evolved so has its documentation; a lot of it is
> undated, much of it is contradictory, most of it is scattered.
>
> Does anybody have any ideas?  Where do I go from here?   Could it be an
> ubuntu problem? Does my config make sense?  straw(grasp);

The documentation regarding the vnc and vfb options in xl is indeed
rather poor.  You don't mention what kind of guest you're using, but
the vfb options are, in fact, meant to be PV-only; so if you have an
HVM guest, you should put those options at the top level, like this:

sdl=1
vnc=1
vncdisplay=0

And even for PV, each element in that [ ] makes a new vfb, so the
stanza you have above will create *three* virtual frame buffers, one
with the "sdl=1' option, one with the 'vnc=1' option, and one with the
'vncdisplay=0' option.  If you want one vfb with all those options,
you should write:

vfb = [ 'sdl=1,vnc=1,vncdisplay=0' ]

(I haven't looked at the docs to see if those particular options are
sensible things to set yet.)

On top of that, 'vbf' isn't an option at all, so if that's actually
copy-and-pasted from your guest config, the whole thing will end up
being ignored. :-)

Probably best if you copy and paste your entire guest config file.

What version of Fedora were you using?  Do you know what version of
Xen it was using, and what version of qemu?

Various things that might be different enough to cause this sort of problem:
* Xen version using / recognizing different options to implement the VFB
* QEMU versions.  Xen upstream tarballs include a specific release of
qemu tested with that release, but downstreams typically  try to use
the same qemu binary for multiple purposes (emulation, KVM, &c).
* X server version / drivers
* Differences in config file.  It may be that when you re-generated
your config file you mixed it up a bit.  (For instance, the 'vbf' /
'vbf' thing; or if you accidentally switched from PV to HVM or vice
versa.)
* Differences in default vga adapter and options, if you're running an HVM guest

Hope that gives you some things to look at.

Peace,
 -George

_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: guest video slow

Mike Wright
On 05/03/2016 02:59 AM, George Dunlap wrote:
<snip/>
> Hope that gives you some things to look at.
Thanks George. It does.

All records (and memories) of my fedora setup are long lost.

Guest is PV.  All bridging, etc. is predefined in Dom0.  Not knowingly
using any scripts, virt-, qemu-, etc. Everything is manual via "xl".
Using xen-4.5-amd64 with ubuntu's kernel 3.19.0-16-generic.

### config
name        = 'MIKE'
kernel      = '/etc/xen/VMs/boot/vmlinuz-4.4.0-18-generic'
initrd      = '/etc/xen/VMs/boot/initrd.img-4.4.0-18-generic'
vcpus       = '3'
memory      = '6144'
root        = '/dev/xvda1 ro'
disk        = [
   'phy:/dev/VMs/MIKE,xvda1,w',
   'phy:/dev/VMs/MIKEs,xvda2,w',
]
vif         = [
   'mac=00:16:3E:01:B3:11,bridge=LAN',
   'mac=00:16:3E:09:47:C1,bridge=SND',
]
vbf         = [ 'sdl=1,vnc=1,vncdisplay=0' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

### this process exists; I think it is started by xl when the guest is
created:

/usr/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic
-M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel
/dev/null -pidfile /var/run/qemu-dom0.pid

Since correcting the vbf line it appears to run more smoothly be there
is still some jerkiness.

I looked at the man page for "qemu-system-i386".  How are those options
passed in?  Some of them such as "-nographic" look interesting.

Anything else I can provide?

Thanks,
Mike Wright



_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: guest video slow

George Dunlap
On Wed, May 4, 2016 at 2:02 AM, Mike Wright <[hidden email]> wrote:

> On 05/03/2016 02:59 AM, George Dunlap wrote:
> <snip/>
>>
>> Hope that gives you some things to look at.
>
> Thanks George. It does.
>
> All records (and memories) of my fedora setup are long lost.
>
> Guest is PV.  All bridging, etc. is predefined in Dom0.  Not knowingly using
> any scripts, virt-, qemu-, etc. Everything is manual via "xl". Using
> xen-4.5-amd64 with ubuntu's kernel 3.19.0-16-generic.
>
> ### config
> name        = 'MIKE'
> kernel      = '/etc/xen/VMs/boot/vmlinuz-4.4.0-18-generic'
> initrd      = '/etc/xen/VMs/boot/initrd.img-4.4.0-18-generic'
> vcpus       = '3'
> memory      = '6144'
> root        = '/dev/xvda1 ro'
> disk        = [
>   'phy:/dev/VMs/MIKE,xvda1,w',
>   'phy:/dev/VMs/MIKEs,xvda2,w',
> ]
> vif         = [
>   'mac=00:16:3E:01:B3:11,bridge=LAN',
>   'mac=00:16:3E:09:47:C1,bridge=SND',
> ]
> vbf         = [ 'sdl=1,vnc=1,vncdisplay=0' ]

You still have "vbf" rather than "vfb" here.

> on_poweroff = 'destroy'
> on_reboot   = 'restart'
> on_crash    = 'restart'
>
> ### this process exists; I think it is started by xl when the guest is
> created:
>
> /usr/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M
> xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null
> -pidfile /var/run/qemu-dom0.pid

No -- that process is started on behalf of dom0 during boot.  It's to
help dom0 mount guest filesystems for things like pygrub.

Unfortunately I'm not terribly familiar with the vfb path itself, and
I don't have a lot of time to look into it at the moment. :-/

 -George

_______________________________________________
Xen-users mailing list
[hidden email]
http://lists.xen.org/xen-users