On 1/11/19 12:45 AM, David C. Rankin wrote:
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... :)
Starting from the last question:
strace VBoxManage startvm...
I tend to just watch stuff flow by, but you may want to save the output so
you'll need to do redirects to capture it or you can start the VM and do
ps -efw | grep vbox
vbox 21127 13705 26 2018 ? 4-19:58:40
/usr/lib/virtualbox/VBoxHeadless --comment win7-2 --startvm
8e8dd73e-315a-45cf-a4c7-3ca38ade0dfc --vrde config
strace -p <pid of the vm process>
strace -p 21127 1> trace.out 2>> trace.out
to attach to the running process and collect a trace of what it's up to.
It's a crude, blunt example, but I tend to find things this way. Cruse and
blunt is usually enough.
The strace man pages will let you refine it.
sysdig is MUCH finer grained but a lot of pain to get running sometimes
You of course know you can use grep et al to do a slice n' dice of what you
collect.
in the ps above, the parent process to VBoxHeadless is 13705. The just happens
to be
vbox 13705 1 0 2018 ? 01:32:07 /usr/lib/virtualbox/VBoxSVC
--auto-shutdown
We might want to trace that too
The fact the VBoxSDL shows slow too implies it's not a thing of
rdesktop/network. If it hadn't I'd suggest a tcpdump capture.
tracing VBoxSDL requires starting it, locating it's pid and running strace as
root on that pid
Going back the running the virtualbox GUI and having that come up slow.
I had that happen in the past. I exported the Win 7 VM to an OVA and then deleted it. Surprise! virtualbox came up fast. Import the OVA and virtualbox got slow again. the GUI
slowness was specific to the VM.
I rebuilt the VM from scratch and the problem went away for a long time.
I store my windows data files on a samba share. My windows NIC is bridged to an internal NIC on the host that samba uses just in general for my house. so I move data around a lot
less and rebuilds don't hit my data... Much.
There is a lot to collect and look at.
_______________________________________________
VBox-users-community mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/vbox-users-community
_______________________________________________
Unsubscribe:
mailto:[email protected]?subject=unsubscribe
