VMware Communities
multiverse
Contributor
Contributor

Exceedingly slow startup on Xserve

I just installed Beta 4.1 | 6/21/07 | Build 49528 of Fusion onto a Xserve with (2) Intel Dual Core CPUs and 8 GB of RAM. We are using a pair of 750 GB hardrives that are in RAID 1 configuration. This also has the latest version of OS X and is fully patched.

When I compare the start up performance to a MacBook of lesser specifications, the Xserver is much slower to start Fusion. It takes about 5 seconds on the MacBook and about 60 seconds for the Xserve.

What might be causing this problem? RAID 1 is the main difference between the two systems, except of course that the MacBook has fewer resources.

Reply
0 Kudos
9 Replies
Andreas_Masur
Expert
Expert

Well....I do not have a specific solution to your problem....however, just out of curiosity...why didn't you try it with RC1 instead of an older beta?

Ciao, Andreas

Reply
0 Kudos
multiverse
Contributor
Contributor

We are testing our software on the build I mentioned. We cannot upgrade Fusion in the middle of the test. I would need proof that the cause of this problem is that build before I update. Updating does not guarantee this problem will go away. I wonder if VMWare have tested on the configuration I have described.

Reply
0 Kudos
getwired
Enthusiast
Enthusiast

Well, undoubtedly their response will be to have you update to a more current build - as you're asking them to regress to an older build to help - and the product has changed quite a bit since then... I don't think you can really consider your test fully valid if the product you're running on[/i] isn't current.

Reply
0 Kudos
admin
Immortal
Immortal

Actually, it's reasonable of multiverse to be in the middle of regression testing beta 4.1 and unable to update to the release candidate. You also can't get valid results if you switch versions in the middle of testing. Of course it's better if the tests are done with the RC, but sometimes it's not possible.

multiverse, I don't know anything about our testing, but I don't think an Xserve is part of it (Fusion being aimed at consumers, and most consumers not having an Xserve ...). Is there anything in vmware.log or vmware-vmfusion.log that sounds suspicious? Can you identify any system components as a bottleneck?

Reply
0 Kudos
multiverse
Contributor
Contributor

Addressing the first part of your reply, we ran a test of Fusion, and our compressed schedule became more compressed. Our test proved that Fusion Beta is pretty darn stable. The main reason we prefer Fusion to Parallels is that we can take a Fusion image and put onto any other VMWare implementation, specifically VMWare Server that will live on one of our Dell 1950's. I remember making a similar decision with JSP back in 1999. Testing on beta is common.

The second part of you reply is very apparent when we start talking about complex configurations of the network. I attempted to devise a Kickstart system on Fusion, but it didn't work out because I needed a more controllable network configuration tool. I could have gone underneath and modified configurations by hand, but that is less than optimum since the GUI is likely to overwrite those files. We also ran out of time as I mentioned due to the schedule compression. I really feel that Fusion is a great base for Apple/VMware to develop a more robust and feature-full enterprise or server solution.

I can't even find those logs you mentioned. What path should I be looking for? I used "Find" and everything but those log files.

Reply
0 Kudos
Andreas_Masur
Expert
Expert

I can't even find those logs you mentioned. What

path should I be looking for? I used "Find" and

everything but those log files.

'vmware.log' is located inside your virtual machine package (default: '~/Documents/Virtual Machines'). Use 'Ctrl+Click' and then "Show Package Contents" to look inside the package.

'vmware-vmfusion.log' is located in '~/Library/Logs/VMware Fusion'.

Ciao, Andreas

Reply
0 Kudos
multiverse
Contributor
Contributor

I thought it only fair to come report a problem I was experiencing that directly affected the problem I was reporting in this thread.

For the last hour I have been persuing an OS X hostname issue. The test server is isolated from DNS, and the server itself does not need DNS. Put another way DNS is UNWANTED. For proper HOSTNAME designation, OS X has a requirement for DNS. The solution, of course, is to:

1) Change /etc/hostconfig (HOSTNAME=desiredhostname)

2) Change /etc/hosts (alias desiredhostname to 127.0.0.1)

Fusion starts just fine now.

Reply
0 Kudos
admin
Immortal
Immortal

To make sure I understand, this solved the slow startup problem? If so, were you doing anything to DNS prior to that which might have been responsible for Fusion being slow?

Reply
0 Kudos
multiverse
Contributor
Contributor

Yeah that's a sharp question.

So I put my Xserve onto our network so that I could update OSX. The DHCP gave us a lease that reversed to some dopey out of date subdomain name, such as "defunct server". When I removed the server from the network after the updates were complete, I put the server onto an isolated network that has no DNS. I called Apple support, and was told that "OS X behaves unpredictably without the presence of a DNS server. I suggested that I modify hostconfig and hosts, and I was told "That is an unsupported configuration and I will be unable to help you with that."

My solution works perfectly, of course.

The problem suggests that VMWare's start up, probably at the initialization of the virtual network, has a dependency on OS X's ability to resolve it's own hostname.

Message was edited by:

multiverse

Reply
0 Kudos