On 27/05/2011, at 11:19 AM, Voytek Eymont wrote: > > On Fri, May 27, 2011 12:13 pm, James Gray wrote: > >> On 27/05/2011, at 11:08 AM, Voytek Eymont wrote: > >> I had a similar problem with a virtual linux server a while back. Turned >> out that presenting it with multiple VCPUs was the culprit. Reducing it >> back to a single VCPU fixed it. As for how I figured that out - I went >> back through the change logs and found that another engineer decided it >> needed more CPU grunt and gave it another VCPU...not long after that we >> started getting random reboots about once every 24-36 hours. Although we >> went through a lot of "what about this, what about that" before we >> thought of checking the VM configuration and hypervisor changes. >> >> My advice would be go back over what has changed on you virtual machine >> AND your hypervisor. Sometimes the most inane changes can lead to odd >> behaviour. > > James, thanks > > I'm very new to this virtual host stuff.... > > all I have access is the virtual host, this what you're suggesting needs > admin of the actual hardware, yes?
Yep. The "hypervisor" is the controlling "shell" that provides management and translation between the physical hardware and the virtual guest. The hypervisor is usually something like VMware's vSphere or ESXi, XEN, or even VirtualBox or Parallels. The latter pair are apps that run on top of an existing OS whereas the the others are operating systems in their own right. If your hosting provider has made changes to the hypervisor and you don't have control of that (which is usually the case) the best bet would be to contact them and ask if they have made any changes coinciding with when you started experiencing problems. Also, you might want to turn up the logging on your Linux server as you might get some clues about what is causing the reboot by messages leading up to it. You might start seeing weird disk/IO/memory/CPU messages then BAM! Server reboots. Obviously, whatever is ACTUALLY causing the reboot wont be logged (the kernel is drooling in the corner by that stage) but clues are gold when you don't have root cause. Good luck :) Cheers, James
smime.p7s
Description: S/MIME cryptographic signature
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
