HP vPars and Integrity Virtual Machines V6.1 Administrator Guide
A vswitch of the same name, connected to the same network must be available on the source and
target VSP servers. The hpvmmigrate command does connectivity checking before migration.
You can use the hpvmmigrate -w option to bypass the vswitch connectivity checks, but only use
-w if you are certain that the source and target vswitches are connected to the same subnet.
Otherwise, your guest will lose network connectivity after migrating.
For online migration, in addition to sharing the same LAN segment for normal guest connectivity,
the VSPs should be connected with a private 1 GbE (or faster) network for efficient VSP–to-VSP
communications and for secure guest memory transfer. Using NTP for time synchronization is
strongly recommended on all VSPs and guests to maintain consistent time accuracy.
12.3.1 Using Network Time Protocol (NTP) in Integrity VM environments
Using NTP in Integrity VM environments is recommended to keep time-of-day clocks in sync and
correct. Use xntpd on HP-UX to synchronize time use NTP.
NTP Configuration on a VSP
On each VSP, NTP should be configured just as it would be on any typical (non-virtual) system. In
/etc/ntp.conf, specify a drift file and one or more high quality time servers:
driftfile /etc/ntp.drift
server <A-HIGH-QUALITY-TIME-SERVER> prefer # a preferred time source
server <ANOTHER-HIGH-QUALITY-TIME-SERVER> # a backup time source
server <YET-ANOTHER-HIGH-QUALITY-TIME-SERVER>
The local clock should also be configured as a fall back if necessary:
server 127.127.1.0 # use local clock as backup
fudge 127.127.1.0 stratum 10 # show poor quality
If you have a group of VSPs that you would like to synchronize, you can add "peer" references in
the /etc/ntp.conf file for each of those associated VSPs, so they will do mutual synchronization:
peer <AN-ASSOCIATED-VM-HOST>
peer <ANOTHER-ASSOCIATED-VM-HOST>
peer <YET-ANOTHER-ASSOCIATED-VM-HOST>
After configuring the VSP's /etc/ntp.conf file, assuming the NTP is already enabled, (that is,
the XNTPD variable in /etc/rc.config.d/netdaemons is set to 1, as in export XNTPD-1),
you can execute /sbin/init.d/xntpd start to restart xntpd on the HP-UX VSP.
NTP Configuration on a VM Guest
Because NTP was not designed to run inside a virtual machine, using NTP on VM guests requires
special configuration to be stable. Using a typical default NTP configuration on a VM guest might
result in NTP instability and failure to synchronize, or in apparent lost time on the guest. To avoid
these virtualization related NTP issues, each VM guest should get its time directly from the VSP.
Also, VM guests should not serve time to any other systems.
You can monitor NTP status by using the ntpq -p command and noting the offset and the
disp values. Ideally both values will be well under 100. For information about how to check NTP
stability, see the HP-UX Internet Services Administrators Guide.
You can improve time stability on VM guests by tuning NTP to poll more frequently for time
corrections. The default NTP values for the minpoll and maxpoll intervals are 6 (64 seconds)
and 10 (1024 seconds) respectively. NTP adjusts the current polling interval depending on network
quality and delays. A VM guest uses a virtual LAN that can cause NTP to set the polling value
incorrectly. To help mitigate this issue use the minpoll and maxpoll directives in the ntp.conf
file to change the polling intervals.
Start with minpoll at 4 (16 seconds) and maxpoll at 6 (64 seconds) and then reduce maxpoll
towards 4 if necessary to force shorter polling intervals. HP recommends that a VM guest never
be allowed to deliver time (allow guests to be a time consumers). Because a VM guest never delivers
time, you do not need to configure the local clock (server 127.127.1.0) or an ntp.drift file.
So, the ntp.conf file on a VM guest should be as simple as the single line:
206 Migrating virtual machines and vPars