Tag Archives: xenserver

How To Increase Space on an iSCSI XenServer LUN

When increasing the size of iSCSI SR, this change is not reflected by default within XenServer.  To resolve this, follow the procedure outlined here.  I am including one minor change to original article CTX126473 (addition of your host-uuid in step 3):


Note: This procedure does not cover any activities that must be performed on the storage array itself. Consult the storage array documentation for information on modifying the size of a LUN. Also, the LUN size modifications must be completed prior to performing the instructions below. Note also that this example applies to a XenServer iSCSI Storage Repository only.

Note: UUIDs for Master XenServer and target SR can also be found within XenCenter – command line for this is not necessarily required to obtain these.


Identify the SR Universally Unique Identifier (UUID)

#xe sr-list type=lvmoiscsi name-label=<Name of your SR> –minimal


Identify the device this SR is using:

#pvs | grep <UUID from step 1>


Identify the iSCSI target name to rescan:

#xe pbd-param-get uuid=$(xe pbd-list sr-uuid={UUID from step 1} –minimal host-uuid={master UUID}) param-name=device-config param-key=targetIQN


Extract the content of the image

# iscsiadm -m node –targetname < targetIQN from step 3> -R


Update the Physical Volume size:

# pvresize /dev/<device from step 2>


Update the SR size:

#xe sr-scan uuid=<UUID from step 1>







Attempt to Boot PVS Target with BDM ISO Results in “No ARP Reply”

I recently ran into a problem booting a provisioned XenApp target using Provisioning Services 6.1. The target was set to boot a maintenance version of a known good vDisk. The resulting error was “No ARP Reply”.


This target was using a BDM .iso boot configuration, running under XenServer 6.02, and we were using Provisioning Server 6.1 with all latest available hotfixes.

If this same target was set to boot a Production/Testing version of the image, it would boot fine. At first it seemed the obvious problem was that there was a problem with the associated .avhd, but this exact problem was able to be replicated using another target device, and another .vhd image altogether.

It appears this may be a bug in the Provisioning Server 6.x product, but this problem can be worked around by adding the following registry entry on all your Provisioning Servers:

HKLM\Software\Citrix\ProvisioningServices\SkipBootMenu [DWORD]

Value Behavior

  • 0 Not Defined, normal behavior (default)
  • 1 Don’t send a boot menu to device. Automatically pick the first item that would been on menu and act as if it was the only version assigned, ignoring the device type.
This will eliminate the boot menu altogether, so may only be a usable workaround if this menu is not required in your environment.

Citrix also states that another client worked around this by using PXE instead of BDM.



Reconciling XenServer VM with Exact Disk File in XenServer


You are deleting XenServer VMs and notice that the attached disk name is the same for various VMs, and want to ensure that you are deleting only that VMs disk, and this disk is not being used by other VMs.

How can you verify the exact disk file connected to a certain VM?



If you want to double-check this link, you can do a "xe vm-list" and using the UUID of the VM in question, run the following command:

xe vbd-list vm-uuid=<uuid of vm>

This will show you all VDIs associated with that VM, as well as their name labels.

If you change the name-label (can be done via XenCenter, for instance) you can then also see which is associated with which particular VM by its label as an added check.



Virtual Machine in XenServer Will Not Shut Down or Start; Stuck/Frozen Starting/Stopping


If you’ve worked with XenServer for any length of time, you have no doubt experienced having a VM turn “orange” or “amber” or otherwise become unmanageable.  Here are couple of similar problem scenarios and solutions that might help.


Problem Scenario #1:

You notice that a VM has numerous lifecycle events on a XenServer.  It has continuously attempted to shutdown, but remains in the green/on state.  The VM will not display a console, or POST information.   Manual shutdowns in XenCenter do not work (Shutdown or Force Shutdown).


You may have success trying some of these ideas, or it may take a combination of these to obtain control of the stuck VM.

  1. Start by trying an ‘xe-toolstack-restart’ on the pool master server.   This is the easiest fix, and will work a majority of the time.   You will lose connection to your pool momentarily.  If this doesn't work, go onto the next steps listed below.
  2. If this is a XenDesktop hosted VM, put the VM in maintenance mode, if you cannot force a Start/Shutdown from the DDC
  3. From the XenServer console, try the following command to force a shutdown:  ‘xe vm-shutdown –force vm=VMNAME’.  If VM does not shutdown with this command, proceed to next step
  4. In XenCenter, once the above two items are done, attempt to "Reboot" the VM. It may restart now.

Related Issue:

I experienced a similar issue where all members were down in a XenServer pool, but the pool Master remained up and functional.  The 'toolstack' processes were not running on pool members. An ‘xe-toolstack-restart’ was required on each pool member XenServer before the server would appear functional and participate in the XenServer Pool.


Problem Scenario #2:

This is the most common scenario you will see.  A virtual machine will go into an “amber” or “orange” state and you are unable to shutdown, reboot, or even forcefully reset the VM.



  1. Find the UUID of the hung VM.
    You can do this via the command line with ‘xe vm-list’ or via XenCenter.
  2. Find the Domain ID of the hung VM.
    Run ‘list_domains’ from the command line, and match the UUID with the ID number



    id |                                 uuid |  state
    0  | 2fe455fe-3185-4abc-bff6-a3e9a04680b0 |    R
    47 | 267227f3-a59e-dafe-b183-82210cf51ec4 |    B
    59 | 298817fb-8a3e-7501-11e0-045a8aa860ff |    B
    60 | 46e3d5aa-2f02-dfdc-b053-9a8ac56ec5d1 |    B
    61 | 16cf3204-eb17-5a12-e8d0-c72087bda690 |    B
    62 | 1f9053b5-c6ca-40bb-504e-3017c37e7281 |    H
    63 | ddaec491-097a-e271-362b-f2f985e26e4a |    R
    65 | 55f3b225-4f65-d1ea-aa19-add44c5acce7 |    B
    66 | 7adef6fd-9171-5426-b333-6fb1b57b8e60 |    B H
    67 | 6046dc13-f70b-8398-56fb-069c22440a7c |    B
    68 | f201cd94-a501-00c2-d21e-8c2f03ea167b |    B H

  3. Run destroy_domain on the Domain ID.


    # /opt/xensource/debug/destroy_domain -domid 62

  4. The VM will still show itself as running, so now, we need to reboot it.


    # xe vm-reboot name-label='name of the VM' –force

  5. The VM is now rebooted, and you can bring it up as if you had just pulled the plug.  That is, check for some disk corruption, etc.






XenServer NIC Status Shows "Disconnected" in XenCenter Despite Known Physically Active/Connected State


When viewing a XenCenter host's NICs in the NIC tab, you may notice that some network interface cards display themselves as "Disconnected". You believe these interfaces are indeed connected to the physical network.  What to do?


1) Double check physical network connection, ensure physical connection/link at the switch level – ensure this is not a bad patch cable, or physical cabling issue

2) You can easily view Ethernet interfaces in XSconsole to verify which interfaces are listed as "disconnected" eg. "eth4", "eth1", etc.

3) At the XenServer command shell, run 'xe pif-list' to display a list of pifs and see if the related "eth" interfaces are listed as connected=false.

4) Obtain the UUID from the above output and run the following command 'xe pif-plug uuid=<UUID>' (inserting the UUID you have obtained from the above list).  You may find several entries for the above interfaces – try each one until the pif-plug works. This should forcefully re-attach the interface.  Once done, check back in XenCenter and you should see the Ethernet interface correctly reporting as "Connected".