How to Change NTP Source on XenServer:
1. At the XenServer console, select Network and Management Interface. If using SSH to connect to your XenServer or using XenCenter Console (tab), type xsconsole to access the following configuration:
2. Select Network Time (NTP).
3. Type in the password for the root user account.
4. Select Add an NTP Server (Optionally, select Remove All NTP Servers, then proceed to add new NTP servers).
5. Enter the IP address of the NTP server. (Hint: If not currently known, you can use nslookup on the Windows command line to get the IP address of your NTP server.)
6. Once the new time server has been accepted, validate that NTP is running by exiting to the XenServer command line, by selecting Quit in the xsconsole.
7. Verify the Network Time Protocol (NTP) is running on your XenServer, by using service ntpd status.
8. Ensure the new time source is accessible by cycling the network time protocol daemon, using service ntpd restart.
If there are errors, see if the time server is accessible using the ping command. Ping the server and ensure you have network connectivity and TCP port 123 open. If ping fails, there is a networking problem outside the XenServer that must be addressed.
Advanced
To synchronize the hardware clock using the Network Time Protocol daemon, the following file, /etc/sysconfig/ntpd must be edited. Change the following line:
– from –
SYNC_HWCLOCK=no
– to –
SYNC_HWCLOCK=yes
XenServer 5.6 with XenCenter 5.6 is not showing the “Used Memory”:
1. At the XenServer console, select Network and Management Interface. If using SSH to connect to your XenServer or using XenCenter Console (tab), type xsconsole to access the following configuration:
2. Select Network Time (NTP).
3. Type in the password for the root user account.
4. Select Add an NTP Server (Optionally, select Remove All NTP Servers, then proceed to add new NTP servers).
5. Enter the IP address of the NTP server. (Hint: If not currently known, you can use nslookup on the Windows command line to get the IP address of your NTP server.)
6. Once the new time server has been accepted, validate that NTP is running by exiting to the XenServer command line, by selecting Quit in the xsconsole.
7. Verify the Network Time Protocol (NTP) is running on your XenServer, by using service ntpd status.
8. Ensure the new time source is accessible by cycling the network time protocol daemon, using service ntpd restart.
If there are errors, see if the time server is accessible using the ping command. Ping the server and ensure you have network connectivity and TCP port 123 open. If ping fails, there is a networking problem outside the XenServer that must be addressed.
Advanced
To synchronize the hardware clock using the Network Time Protocol daemon, the following file, /etc/sysconfig/ntpd must be edited. Change the following line:
– from –
SYNC_HWCLOCK=no
– to –
SYNC_HWCLOCK=yes
Backing up metadata of pooled installations
In a pool scenario, the master host provides an authoritative database which is synchronously mirrored by all the slave hosts in the pool. This provides a degree of built-in redundancy to a pool; the master can be replaced by any slave since each of them has an accurate version of the pool database.
Please refer to the XenServer Administrator’s Guide for more information on how to transition a slave into becoming a master host.
This level of protection may not be sufficient; for example, if your shared storage containing the VM data is backed up in multiple sites, but your local server storage (containing the pool metadata) is not. To fully recreate a pool given just a set of shared storage, you must first backup the xe pool-dump-database against the master host, and archive this file.
# xe pool-dump database file-name= /raja/backups/my_backup
To subsequently restore this backup on a brand new set of hosts
- Install a fresh set of XenServer hosts from the installation media, or via PXE.
- Use the xe pool-restore-database on the host designated to be the new master.
- Run the xe host-forget command on the new master to remove the old slave machines.
- Use the xe pool-join command on the slave hosts to connect them to the new cluster.
Note:
Removing a xenserver host from a pool will delete all the user data on local HDD of that host.
Hotplug vCPUs to a VM in Xenserver:
To hotplug vCPUs to a VM in Xenserver, check whether updated xenserver tools are installed in the VM and then use the following command,
vm-vcpu-hotplug new-vcpus=<new_vcpu_count> uuid=<uuid of the VM>
You can dynamically adjust the number of VCPUs available to a running paravirtual Linux VM within the number bounded by the parameter VCPUs-max.
Windows VMs always run with the number of VCPUs set to VCPUs-max and must be rebooted to change this value.
Note:
To find ‘your_vms_uuid’, you can use:
xe vm-list name-label=VMname
No Sound in windows VMs on Xenserver
To enable sound for windows VMs on Xenserver, the following settings have to be changed:
- Go to control panel > administrative tools > terminal services > terminal services configuration, enter the “rdp-tcp” properties where you set various parameters of the RDP role offered by the TS.
- Go to the “Client settings” tab and UNTICK audio. By default, “ticked” options mean “disable”. So, remove the “disable” tick from audio, log off, re-logon and voila!
- Enable ‘Windows audio’ service in services.msc
- Enable audio in mstsc setting while connecting from client.
OR
- Go to the sound control panel (Start-> (Settings->) Control Panel-> Sounds and Audio Devices)
- Select Audio tab.
- Select Microsoft RDP Audio Driver for the default playback device, if not already specified.
- Check the “Use only default devices” checkbox at the bottom of the dialog.
- Click the Voice tab.
- Select Microsoft RDP Audio Driver for the default playback device, if not already specified.
- Save settings by clicking on OK button.
How to stop a hanged VM on Xenserver?
One of my development server was not accessible. It’s a VM under Xenserver and trying to fix things through XenCenter was quite a deadend. The console was not accessible from XenCenter, there was only a blank white screen. When the VM was being forced to shutdown, it gave an error message
“Another operation involving the object is currently in progress class: VM“.
There’s some discussion and proposed solution from on internet. Here’s quote from one of the post that finally fix it for me (you need to login to server’s shell to execute the below command):
1 – Type “xe vm-list” to get the uuid of the VM that is hung
2 – Type “list_domains” to list the domain uuid’s so you can determine the domain # of the VM above by matching the uuids from this output with the uuid for your VM from the previous command.
3 – Type “/opt/xensource/debug/destroy_domain -domid XX” where XX is the domain number from the previous command
4 – Type “xe vm-reboot uuid=XXXX –force” where XXXX is the uuid from the first vm-list command for your VM. (name-label may work but didn’t work this time for me so I used the uuid)
Internal error: Failure(“The ballooning daemon is not running”)
If you’re finding issues starting VM’s on your Citrix XenServers due to ballooning issues as mentioned below:
$ xe vm-start name-label=vmname
The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem.
message: Failure(“The ballooning daemon is not running”)
Then try this command then restart VM to find it working.
$ xe-toolstack-restart
Service XAPI is unresponsive:
Step 1: First, you need to find out process PID (process id)
Use ps command or pidof command to find out process ID (PID). Syntax:
Or
service xapi status will also give the output
Step #2: kill process using PID (process id)
Above command tell you PID xapi process. Now kill process using this PID:
# kill <pid>
OR
# kill -9 <PID>
Where,
- -9 is special Kill signal, which will kill the process.
To recover a pool from a failed pool Master:
To check whether pool master pool master has failed:
If you’ve tried to connect to the pool from the Xencenter console, and if it fails – then your pool master is down.
Verify this by connecting to the xenserver host using putty and issue a command like “xe host-list” to see if you get a response.
If you get an error message like ““Cannot perform operation as the host is running in emergency mode” – then your Pool master is almost certainly down.
Solution:
Step 1:
Try restarting the toolstack using this command
Service xapi restart
Step 2:
Try rebooting the Pool master to bring it online.
Step 3:
Now the member XenServer hosts will accept only the pool-emergency commands, because the members try to reconnect for sixty seconds and then each member puts itself into emergency mode. So we are telling the pool members where the pool master is
xe pool-emergency-reset-master master-address=<new_master_hostname>
Note:
This command instructs a slave member XenServer host to reset its master address to the new value and attempt to connect to it. This command should not be run on master hosts.
And then force the failed pool master to reboot as a pool master using the following command.
xe pool-emergency-transition-to-master uuid=<host_uuid>
If the master comes back up at this point, it re-establishes communication with its members, the members leave emergency mode, and operation returns to normal.
However if the master is really dead, choose one of the remaining members and run the command on any member server:
xe pool-emergency-transition-to-master uuid=<host_uuid>
Note:
This command instructs a member XenServer host to become the pool master. This command is only accepted by the XenServer host if it has transitioned to emergency mode, meaning it is a member of a pool whose master has disappeared from the network and could not be contacted for some number of retries.
Note that this command may cause the password of the host to reset if it has been modified since joining the pool.
Once it has become the master, issue the below command and the members will now point to the new pool master:
xe pool-recover-slaves
Note:
This command instructs the pool master to try and reset the master address of all members currently running in emergency mode.
To recover VMs from Failed pool master:
1). First you have to figure out which server in the environment has failed. To do this, you’ll want to run the command,
xe host-list params=uuid,name-label,host-metrics-live
Any servers that come back with “host-metrics-live = false” have failed. Take note of the UUID of any failed servers
2) Then try to restart the service for the failed host by executing this command on the failed host using Putty
service xapi restart
3) Second, you must determine which VM’s were running on that failed server. You can do this by running the command,
xe vm-list is-control-domain=false resident-on=UUID_of_failed_vm
4) Once you’ve determined which VM’s were running, you need to reset their power state in order to get them to move onto another server. To do this, run the command,
xe vm-reset-powerstate resident-on= UUID_of_failed_vm –force –multiple
You should see the VM’s in question now show up as halted in the Xencenter console. Restart each of the VM’s, and they should now boot up onto surviving pool member servers.
Note:
To do this, the VMs should be in shared storage.
To recover VMs from Failed Xenserver host:
1). First you have to figure out which server in the environment has failed. To do this, you’ll want to run the command,
xe host-list params=uuid,name-label,host-metrics-live
Any servers that come back with “host-metrics-live = false” have failed. Take note of the UUID of any failed servers
2) Then try to restart the service for the failed host by executing this command on the failed host using Putty
service xapi restart
3) Second, you must determine which VM’s were running on that failed server. You can do this by running the command,
xe vm-list is-control-domain=false resident-on=UUID_of_failed_vm
4) Once you’ve determined which VM’s were running, you need to reset their power state in order to get them to move onto another server. To do this, run the command,
xe vm-reset-powerstate resident-on= UUID_of_failed_vm –force –multiple
You should see the VM’s in question now show up as halted in the Xencenter console. Restart each of the VM’s, and they should now boot up onto surviving pool member servers.
Note:
To do this, the VMs should be in shared storage.
- ← Previous
- 1
- 2
- 3
- Next →
sysadmino 