Jump to content
Welcome to our new Citrix community!
  • 0

The SR operation cannot be performed because a device underlying the SR is in use by the host


phil godfrin

Question

Created a new SR thus:

[root@xenhost ~]# xe sr-create content-type="localSR" host-uuid=78633ea8-74ad-4986-9688-86865eeac2ce type=lvm device-config:device=/dev/sdc8 shared=true name-label="Disk 01 (/dev/sdc8)"
a15bd05a-2b9b-bebd-a7a6-b3f4a77878e7

And then tried a second one:

[root@xenhost ~]# xe sr-create content-type="localSR" host-uuid=78633ea8-74ad-4986-9688-86865eeac2ce type=lvm device-config:device=/dev/sdc9 shared=true name-label="Disk 02 (/dev/sdc9)"
The SR operation cannot be performed because a device underlying the SR is in use by the host.
[root@xenhost ~]#

And the fdisk:

[root@xenhost ~]# fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 523 4194304 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 523 1045 4194304 83 Linux
/dev/sda3 1045 9729 69759553 8e Linux LVM

Disk /dev/sdc: 160.0 GB, 160000000000 bytes
255 heads, 63 sectors/track, 19452 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 1 5100 40960000 83 Linux
/dev/sdc2 5100 19453 115288064 5 Extended
/dev/sdc5 5100 7650 20480000 83 Linux
/dev/sdc6 7650 10199 20480000 83 Linux
/dev/sdc7 10200 12749 20480000 83 Linux
/dev/sdc8 12749 14024 10240000 83 Linux
/dev/sdc9 14024 15299 10240000 83 Linux
/dev/sdc10 15299 16574 10240000 83 Linux
/dev/sdc11 16574 17849 10240000 83 Linux
/dev/sdc12 17849 19124 10240000 83 Linux

Any thoughts?
pg

Link to comment

15 answers to this question

Recommended Posts

  • 2

I had this same issue "The SR operation cannot be performed because a device underlying the SR is in use by the host."

The problem with the SCSI device is in the device mapper, so removes it.

 

To solve it: 

Goes to your Xenserver and run: 

 

dmsetup ls 

 

#dmsetup ls
VG_XenStorage--e39bbb44--d3f5--96e4--b036--061bc4c22d3f-MGT     (253:0)
3690b11c0002a4aff000035095c489531       (253:2)
3690b11c0002a499700002d235c3d796d       (253:1)

 

Then remove it!

 dmsetup remove 3690b11c0002a4aff000035095c489531

 

That's it, try to add the disk again! Do it in all of your xenserver

  • Like 2
Link to comment
  • 0

I believe it's because your devices overlap. You have:

/dev/sdc8 12749 14024 10240000 83 Linux
/dev/sdc9 14024 15299 10240000 83 Linux

It should instead be something like this:

/dev/sdc8 12749 14024 10240000 83 Linux
/dev/sdc9 14025 15300 10240000 83 Linux
/dev/sdc10 15301 16576 10240000 83 Linux
etc.

so block 14024 doesn't get mapped to both. Looks like all the drives
from /dev/sdc6 on up need to be redone.

--Tobias

Link to comment
  • 0

This may be the case but it is unlikely.

Fox example these devices appear to overlap but that is not the case.

Device Boot Start End Blocks Id System
/dev/sda1 * 1 523 4194304 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 523 1045 4194304 83 Linux
/dev/sda3 1045 17849 134983453 8e Linux LVM

[root@XSMarco ~]# fdisk -lu

Disk /dev/sda: 146.8 GB, 146815733760 bytes
255 heads, 63 sectors/track, 17849 cylinders, total 286749480 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 63 8388670 4194304 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 8388671 16777278 4194304 83 Linux
/dev/sda3 16777279 286744184 134983453 8e Linux LVM

I would make sure the device is not plugged into dom0 or mounted.

Link to comment
  • 0

OK - so I tried to sr-create on non-contiguous partitions, to test the theory of overlapping - no change:

[root@xenhost ~]# xe sr-create host-uuid=78633ea8-74ad-4986-9688-86865eeac2ce type=lvm device-config-device=/dev/sdc8 shared=false name-label="Disk 01 (/dev/sdc8)"
a5876848-69b1-f864-2da9-16334c28db29

[root@xenhost ~]# xe sr-create host-uuid=78633ea8-74ad-4986-9688-86865eeac2ce type=lvm device-config-device=/dev/sdc10 shared=false name-label="Disk 02 (/dev/sdc10)"
The SR operation cannot be performed because a device underlying the SR is in use by the host.

results of sr-scan:

[root@xenhost ~]# xe sr-list
uuid ( RO) : a5876848-69b1-f864-2da9-16334c28db29
name-label ( RW): Disk 01 (/dev/sdc8)
name-description ( RW):
host ( RO): xenhost
type ( RO): lvm
content-type ( RO):

uuid ( RO) : 5e957bd1-dc3b-abeb-fec0-a76b92c4be33
name-label ( RW): Local storage
name-description ( RW):
host ( RO): xenhost
type ( RO): lvm
content-type ( RO): user

uuid ( RO) : 3a681f3d-e323-e766-ff91-38ad829cca06
name-label ( RW): DVD drives
name-description ( RW): Physical DVD drives
host ( RO): xenhost
type ( RO): udev
content-type ( RO): iso

uuid ( RO) : 1bd96d03-f056-a2c6-37c8-f9a064504110
name-label ( RW): XenServer Tools
name-description ( RW): XenServer Tools ISOs
host ( RO): xenhost
type ( RO): iso
content-type ( RO): iso

uuid ( RO) : 7ec8f03e-3314-9de7-d2d2-4cb7fcb893ff
name-label ( RW): Removable storage
name-description ( RW):
host ( RO): xenhost
type ( RO): udev
content-type ( RO): disk

[root@xenhost ~]# xe sr-scan uuid=a5876848-69b1-f864-2da9-16334c28db29
[root@xenhost ~]#

Link to comment
  • 0

Yes I did see that article, it does not apply. I did try creating 4 primary partitions, same error.

I agree - if you are creating an sr on a partition that should appear as a single disk. I suspect this has something to do with the way LVM and disk parts work.

It would seem to me that a citrix tech should know the answer to this. Especially since it's not clearly documented...

Link to comment
  • 0

This is not a RAID device but a single spindle. This is my fdisk:

Disk /dev/sdc: 160.0 GB, 160000000000 bytes
255 heads, 63 sectors/track, 19452 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 1 5100 40960000 83 Linux
/dev/sdc2 5100 19453 115288064 5 Extended
/dev/sdc5 5100 7650 20480000 83 Linux
/dev/sdc6 7650 10199 20480000 83 Linux
/dev/sdc7 10200 12749 20480000 83 Linux
/dev/sdc8 12749 14024 10240000 83 Linux
/dev/sdc9 14024 15299 10240000 83 Linux
/dev/sdc10 15299 16574 10240000 83 Linux
/dev/sdc11 16574 17849 10240000 83 Linux
/dev/sdc12 17849 19124 10240000 83 Linux

Link to comment
  • 0

I have experienced the same problem, but mine resulted from a fault after upgrading from xs 5.6 to xs 5.6 SP2. So I had to rebuild the the local storage repository.

From the partition table it looks like there could be possibly more than one partition that is being used for storage.

What I discovered was that if you already have one partition on the same disk (eg /dev/sda5) that has been registered as a storage repository with Xen, you could not add a second SR if it is from the same disk (eg /dev/sda6). That is, assume that /dev/sda5 has a name-label called "SR1-sda5", you cannot use xe sr-create to create another SR called "SR1-sda6". The problem does not occur if the partitions are on two separate drives.

Here is how I got around this:

1. unplug all storage repositories on the same hard drive (eg SR1-sda5**)
use xe pbd-list to determine the pbd uuid that binds the storage of SR1-sda5 to the host
then pbd-unplug the device eg.

xe pbd-unplug uuid=4f918e9d-76d7-61c8-1819-49898c62de83

2. forget the storage repository, note the uuid of "SR1-sda5"
xe sr-forget uuid=8479be36-3511-51ee-b48c-731bc9111b86 (uuid of sda5 - remember this SR uuid for later steps)

CAUTION: using SR-forget will remove all the meta-data for the storage so your XenCenter GUI will show NO descriptions of any virtual disks/templates stored on the system. Backup first the server first! Although sr-forget doesn't destroy the data, just the configuration, it can be painful to try and rename/re-attach virtual storage disks manually. So take note of your VHDs which are attached to the SR. I used XenCenter for this, rather than trying to figure it out via the cli

3. create your new storage repository for sda6


xe sr-create name-label="SR1-sda6" host-uuid=f0dd8879-5c99-9988-b478-928051e63d2b type=lvm shared=false device-config:config=/dev/sda6

*4. re-introduce the original SR1-sda5:* .......
xe sr-probe type=lvm device-config:device=/dev/sda5 (check your uuid)
xe sr-introduce name-label="SR-sda5" type=lvm uuid=8479be36-3511-51ee-b48c-731bc9111b86 (uuid of sda5 from (i))

5. Introduce the block devices with pbd-create & pbd-plug
The previous step will re-introduce the SR to the XenServer but no VHDs will be recognised until you plug the device back in with:

xe pbd-create host-uuid=f0dd8879-5c99-9988-b478-928051e63d2b type=lvm shared=false
device-config:config=/dev/sda6 sr-uuid= 8479be36-3511-51ee-b48c-731bc9111b86

Write down the pbd uuid created from the above xe pbd-create, then plug the device back in.

xe pbd-plug uuid=301c2a8f-ef2b-b303-9230-bbd61358120f

Your VHDs should now be available.

If for some reason it xe pbd-create issues an error such as "A PBD already exists connecting the SR to the host", use xe pbd-list to determine the pbd uuid, and simply use the xe pbd-plug command.

7. Use XenCenter to label your VHDs

Edited by: Chinh Toquale on Jul 4, 2011 1:43 AM

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...