XP conversion to VM machine fails to auto-resize

[jdow]

I have several working virtual machines. I converted an existing XP machine to a virtual machine. I use it for writing software for myself as entertainment. (At 70 years old I can afford to entertain myself and have strange habits, I guess. A life? What's that?)

I have the extensions (in the VBOX host) and add-ons (guest machines) installed on all the machines, Linux, XP 32 *2, Win 7 32, and so forth. It's a way to explore and learn. The second XP machine is converted from a former development machine before I retired. It's running fine except that after 4 migration attempts doing things in different orders I still cannot get the system to decide it likes the HOST-G or View menu auto-resize (grayed).

Does anybody have any suggestions? If so I'd certainly be interested. I want to turn that former development machine into a 64 bit Linux monster running virtual machines for old installations so I can answer peoples questions if they call and ask me, "How in heck did you do it?"

{^_^}

[mpack]

You need to install the Guest Additions before any of the fancier host integration features will work. See chapter 4.

Post a VM log file if you need to continue this discussion. For details see Minimum information needed for assistance.

[jdow]

I am aware of this. They are installed - and reinstalled - and re-re-installed. On this particular virtual machine the resizing doesn't work. The embedded feature does not work. Apparently all the other features work. Certainly the additional mouse features work.

One additional bit of information MIGHT be significant. This machine, before conversion, was host to a brief VirtualBox install before I installed VB on my current Win7 host. I have removed the VB install immediately after booting the virtualized machine the first time. Is it possible that is the source of the problem.

Note that I have several virtual machines running with the additions all working properly. Only this one client machine is being recalcitrant.

{^_^}

[jdow]

Sorry about the delay - it took awhile to figure out that a log with an internal date of March 26th applied to the current day. I consider that to be a bug. But I guess you guys don't. Misleading logs are more fun, I suppose.

{^_^}

[Perryg]

You need to post the guests log file.

Right click on the guest in the VBox main manager and then left click on show log. Save and post as an attachment.

[jdow]

This is what I get when I right click in the affected guest and ask for the log.

{^_^}

[mpack]

4GB RAM is overkill for a XP guest, or any other 32bit guest. 2GB is way more than XP needs, and won't bring us close to the 64bit threshold.

Also, giving all your cores to the guest is not a good idea, it results in very poor performance. For an XP guest I would start at one or two cores and leave it there unless I am running apps that are capable of using additional cores. Extra cores don't automatically make a guest go faster.

You still have the GAs ISO mounted, I would unmount that. However I can confirm that the GAs are installed.

Your VM seems to have a rather odd folder structure: no VDI in the VM folder, two VHDs outside it - in different locations. This is an error prone structure, and when you do have an error your helpers will not be assuming this layout.

Let's fix the above and then see where we are.

[Jose-28]

I Will try too

[jdow]

4GB RAM is overkill for a XP guest, or any other 32bit guest. 2GB is way more than XP needs, and won't bring us close to the 64bit threshold.

The actual original box has 24 gig in it preparatory to making it a 64 bit Linux machine.

Also, giving all your cores to the guest is not a good idea, it results in very poor performance. For an XP guest I would start at one or two cores and leave it there unless I am running apps that are capable of using additional cores. Extra cores don't automatically make a guest go faster.

I am only giving it 8 of the machine's 16 cores. The host machine is still quite usable. (No stutters in the pair of Software Defined Radios I keep running for background music and monitoring purposes.)

You still have the GAs ISO mounted, I would unmount that. However I can confirm that the GAs are installed.

THAT should make a difference? It doesn't bother the other machines. They are quite happy, even the Haiku vm I brought up as a lark. (Of course I didn't try the additions there.) I've been fiddling with VirtualBox for over two years now.

Your VM seems to have a rather odd folder structure: no VDI in the VM folder, two VHDs outside it - in different locations. This is an error prone structure, and when you do have an error your helpers will not be assuming this layout.

The directory structure works fine for the other machines. The moved machine images are on their own drive at the moment because it's rather large and the host machine's native disks are rather full.

Let's fix the above and then see where we are.

No room to fix it. I can place the C drive on the same disk and folder as all other the images; but, that does not help. There absolutely is no room to place everything on the C drive. So that's out of the question. And evidence at hand suggests that's not a problem. I am attaching a log from another XP 32 client I have. (Presuming that the show log thing actually works.)

{^_^}

[jdow]

mpack wrote:You still have the GAs ISO mounted, I would unmount that. However I can confirm that the GAs are installed.



I wrote: THAT should make a difference? It doesn't bother the other machines. They are quite happy, even the Haiku vm I brought up as a lark. (Of course I didn't try the additions there.) I've been fiddling with VirtualBox for over two years now.

And, in point of fact, it does not make a diference. I tried it again. I rebooted and saw no difference.

I also retried placing the C drive image in the same place as the others and did not mount the other two drives with no perceptible difference. So that eliminates directory structure as a basic problem. Otherwise it would affect SL6, Fedora, or Windows (XP and 7 32 bits) installs I have.

The memory size allocated should be a non-issue. It's there. I have lots of ram to play in. So I made it 4 G. I figure to reduce it to something saner once it's happy.

And I repeat, I am only giving the VM half the CPU cores I have available. I was trying to make it look as much like it looked in the past. That's another thing I'll tune once the main problems are solved.

I would rather like the auto-resize to work.

{^_^}

[mpack]

At no point did I say that GAs ISO made a difference. It was merely one of several notes I made while viewing your log.

You seem to have contradicted everything I said, from a position of massive ignorance, and then come back to do it again, so I think from now on I'll leave you to come up with your own guidance since you seem to be happier with it. Hey, I've only been running VBox XP VMs for 6 years, so what do I know.

Parting gift :

00:00:01.975570 Logical host processors: 16 present, 16 max, 16 online, online mask: 000000000000ffff
00:00:01.976416 Physical host cores: 8

The difference between cores and threads has been discussed enough times already on these forums.

[jdow]

How so - I have 16 processor cores on this dual XEON 5620 machine. That is as declared by TaskManager and Device Manager. So what the heck is your insulting me all about? I am telling you the flat out truth.

At least I have some notion of basic troubleshooting. There's something about 55 years of experience troubleshooting and 45 years as a professional engineer that trains one to that discipline. I have attempted to bisect the problem. None of the details you fastened upon survive the basic tests.

Are you telling me that VIrtualBox is shoddy enough code that the directory structure SOMETIMES matters? Is that it? The directory structure works for one 32 bit XP machine, several Linux machines, and a Win7 32 bit machine, and fails for a second XP 32 bit machine. If it's fussy enough over directory structure that this is a common occurrence maybe I should try something else a little more professional or simply maintain a collection of real machines. I'm trying to be eco friendly and cut down on electricity use. But, if that can't be done, so be it. I'll just spread the word to friends that VirtualBox is a pathetic toy.

{+_+}

[Martin]

Task Manager and Device Manager show you the logical cores or threads.
For virtualization only the physical cores count in almost all cases. Your Xeon 5620 CPUs are quadcore so you only have eight cores available, even when Windows "thinks" it has sixteen.

[loukingjr]

With all your troubleshooting experience one would think you would know that you have two processors, eight cores and 16 threads. Be that as it may, logic would dictate since you have multiple guests running in VirtualBox and only one guest that is giving you problems, what could the issue be, VirtualBox or the one guest? hmmm, let me think.

[jdow]

Task Manager and Device Manager show you the logical cores or threads.
For virtualization only the physical cores count in almost all cases. Your Xeon 5620 CPUs are quadcore so you only have eight cores available, even when Windows "thinks" it has sixteen.

With all your troubleshooting experience one would think you would know that you have two processors, eight cores and 16 threads. Be that as it may, logic would dictate since you have multiple guests running in VirtualBox and only one guest that is giving you problems, what could the issue be, VirtualBox or the one guest? hmmm, let me think.

Well, then, podnah, VirtualBox has a serious bug. It declares 16 CPUs and is green through 8. The machine performance on both host and client supports this as both remain nicely responsive.

Now what?

Now, I do have multiple guests hosted on this machine. I only have this one host running at the time I am testing it. I do have some other CPU hungry tasks running on it - software defined radio code, for example. It doesn't skip a beat despite using as much as 20% of the machine itself.

This machine was originally constructed to support live broadcast HD video with multi-layered effects and keying. It's seriously hypertrophied. (Actually both were. I rescued them from the trash rather than waste such magnificent beasts. Project demands kept requiring ever more processor to accommodate it. I learned of a surprising number of bottlenecks that can and usually do exist within such large systems when doing that video work. Now I use them for other software testing and development. In some cases dual CPU packages can slow you down rather than speed you up due to the way the packages communicate with each other - modulo the system's internal firmware.)

{^_^}