On 01/11/2019 01:40 AM, Bruce Ferrell wrote:
> How does it respond if you log into the account running the VM process and
> run:
>
> VBoxSDL --startvm <vm name> --separate
02:12 valkyrie:~/tmp> VBoxSDL --startvm Win7Pro_32bit --separate
Oracle VM VirtualBox SDL GUI version 6.0.0
(C) 2005-2018 Oracle Corporation
All rights reserved.
VM is already running.
Oh my God, that is cool... I have 2 views of the same Win7 guest on two
different desktops in KDE -- but oh my God are they slow. I started the same
dir command and it has been running for a full minute and just got to the
w's... But switching back and forth between desktops, the VBoxSDL window and
the normal --headless window were both executing the dir command and both
updating (just very slowly)
(I just closed the SDL window)
>
> Best if it's already running detachable, but...
>
> Most "modern" systems try to stop me from doing remote X displays so I usually
> do ssh -X to do this type of thing.
I start the guest headless, then use:
VBoxManage controlvm "Win7Pro_32bit" setvideomodehint 1440 864 32
to set the resolution I want.
Then I use rdesktop-1.8.3 to access the guests from KDE. It has always worked
fantastically, and continues to work well for the Archlinux and OpenSuSE
guests I have, it's just the Win7 guest that is falling flat.
>
> And just out of curiosity, if you ssh -X into the "virtualbox" account, how is
> the response trying to start virtualbox as a remote X application?
I always have a ssh -X terminal up to the host (that's how I start the guest).
UUgh!!!
Starting VirtualBox as a remote X app crawls. I run a number of apps this
way, and the VirtualBox window pops right up, ---> but populating the
VirtualBox window with the guest details is very, very slow. The right side of
the window where the guest details go to a good 10-15 seconds just to populate
(it does show the updating image of the running Win7 guest)
In the past when I have accessed the VirtualBox console to make changes,
etc.., it has never taken so long to read the guest details -- God I hope this
isn't a GTK3 thing...
I just use a short shell script to start the guest. For the Win7 guest, the
script calls:
VBoxManage startvm Win7Pro_32bit --type headless
(the script itself is simply a short case statement, I have the whole thing
aliased to vsvm -- non-creatively for "VBoxManage startvm")
#!/bin/sh
case "$1" in
"-w" )
exec VBoxManage startvm Win7Pro_32bit --type headless;;
"-l" )
exec VBoxManage startvm leap_15 --type headless;;
* )
exec VBoxManage startvm arch_1_64 --type headless;;
esac
I don't know what is going on, but something is totally out of whack. When I
had the VBoxSDL window up on my laptop, it effected the entire desktop meaning
it was like the back and forth to the VBoxSDL window was blocking waiting on
some kind of read/write over the network (where you would think only
non-blocking I/O would be in play)
If you don't mind, what would be the best way to try a strace the Win7 guest
operation? strace the start of the headless session (via ssh) and leave it
running on the host while I access the guest with rdesktop? (of all the
millions of things I have done regularly on a Linux box for the past 20 years
-- strace isn't one if them... :)
--
David C. Rankin, J.D.,P.E.
_______________________________________________
VBox-users-community mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/vbox-users-community
_______________________________________________
Unsubscribe:
mailto:[email protected]?subject=unsubscribe
