On Wed, 2013-01-02 at 00:53 -0800, Robert Dinse wrote:

Friday, I moved our servers to a new co-lo facility and ran into an interesting problem with virtual machines.

 I did an orderly shutdown of the CentOS 6.3 host, and it in turn suspends

all the guests. It took about an hour and a half to move and fire up the host.

 The guests, being suspended, were then an hour and a half behind and it

seems ntpd does not want to correct more than 1000 seconds of error so it would not automatically adjust the clocks.

 I tried the -g argument which is supposed to override the 1000 second

limit

It is not supposed: from 'man ntpd': <QUOTE> The -g option overrides this check and the clock will be set to the server time regardless of the chip time. However, and to protect against broken hardware, such as when the CMOS battery fails or the clock counter becomes defective, once the clock has been set, an error greater than 1000s will cause ntpd to exit anyway. </QUOTE>

So after initial time set ntpd would enforce it's 1000s limit anyway.

More, it would take too much time for ntpd to synchronize an hour difference.

but it did not. I ended up having to manually set the clocks close enough for ntpd to correct.

 Since there is no hardware clock for the virtual machines to use when they

boot, it seems that shutdown and reboot of the virtual machines probably would not have avoided this.

IHMO it would help. There is some emulated hardware clock for a virtual machine but Linux doesn't use it except for bootup. Otherwize virtual machine won't get correct time at all. There's the 'hwclock' application mentioned in init scripts which synchronizes Linux clock to hardware (hwclock --hctosys) on bootup and does reverse on shutdown (hwclock --systohc). Obviously in the virtual environment the last command would be ignored :-).

 Any suggestions for addressing this particular scenerio other than having

to manually set a bunch of clocks?

Reboot. Or manually stop ntpd and do 'ntpdate'. Or you could manually try hwclock --hctosys. I'd like to know if it would succeed.

On Wed, Jan 2, 2013 at 3:53 AM, Robert Dinse nanook@eskimo.com wrote:

 Friday, I moved our servers to a new co-lo facility and ran into an

interesting problem with virtual machines.

 I did an orderly shutdown of the CentOS 6.3 host, and it in turn suspends

all the guests. It took about an hour and a half to move and fire up the host.

Suspends? Or shuts down? There's a big difference, and I don't think you'd have seen this problem with the gu4ests shutdown.

 The guests, being suspended, were then an hour and a half behind and it

seems ntpd does not want to correct more than 1000 seconds of error so it would not automatically adjust the clocks.

ntpd is sometimes too smart for its own good. However, "rdate -s time.mit.edu" or other rdate server works very well and doesn't have the problems with not being able to run "ntpdate" while the ntpd is running.

On Wed, Jan 2, 2013 at 3:53 AM, Robert Dinse nanook@eskimo.com wrote:

 Friday, I moved our servers to a new co-lo facility and ran into an

interesting problem with virtual machines.

 I did an orderly shutdown of the CentOS 6.3 host, and it in turn

suspends all the guests. It took about an hour and a half to move and fire up the host.

By default VMs suspend when the host node is shutdown. You can change this behavior in /etc/sysconfig/libvirt-guests

By shutting down the VMs you don't have to wait for the in-memory data to be dumped to disk, nor do you have to wait for it to be copied back from disk and into memory on boot.

 The guests, being suspended, were then an hour and a half behind and

it seems ntpd does not want to correct more than 1000 seconds of error so it would not automatically adjust the clocks.

At my place of employment we noticed the same thing during maintenance, the VMs had their clocks all out of whack.

 I tried the -g argument which is supposed to override the 1000 second

limit but it did not. I ended up having to manually set the clocks close enough for ntpd to correct.

I believe we had manually correct the clocks as well on ours, but it's been months since then.

 Since there is no hardware clock for the virtual machines to use when

they boot, it seems that shutdown and reboot of the virtual machines probably would not have avoided this.

 Any suggestions for addressing this particular scenerio other than

having to manually set a bunch of clocks?

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874 .

---

CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt

Updated HV and guest to CentOS 5.9 and 6.3. HV: 2.6.18-348.1.1.el5xen Guest: 2.6.32-279.19.1.el6.x86_64

But still memory missing, free -m: 781

Am 02.01.2013 13:02, schrieb Nico Kadel-Garcia:

On Wed, Jan 2, 2013 at 3:29 AM, sg@cyon.ch wrote:

...

Hi,

I'm running CentOS 6.2 x86_64 as xen guest on a CentOS 5.7 dom0. The host is running 2.6.18-274.7.1.el5xen, the guest 2.6.32-220.2.1.el6.x86_64.

Memory for domU is set to 1024 MB and "xm list" shows these 1024 MB. But "free -m" on the guest system shows only 652 MB. When I set up a CentOS 5.x guest with 1024 MB "free -m" shoes 1024 MB.

Anyone else seeing this? Any ideas on how to fix it?

Start out by doing all the updates to both the Hyperviisor and the guest. There have been ongoing improvements to kernels, and to libvirt, and ongoing security updates for numerous packages. You should realy be at CentOS 6.3 and CentOS5.8, respectively: CentOS 6.2 and CentOS 5.7 aren't even available on the main download mirrors, anymore. _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt