How to Recover XenServer Physical Volume Structure after Accidental Deletion

This article describes how to recreate a Physical Volume (PV) and restore Logical Volume Manager (LVM) structure in a situation where Shared or Local storage metadata has been damaged or overwritten.

Warning! Perform the instructions at your own risk. It is recommended to raise a case with Citrix Technical Support to confirm the cause of the issue and then perform necessary steps. Do not attempt commands in this article unless you are confident in understanding of the issue and suggested steps.

If a PV information has been accidentally deleted or tempered with, LVM commands such as “lvscan”, “vgscan”, and “pvscan” return incorrect or empty output.

Note: The commands lvscan, vgscan, and pvscan also return empty output if storage is disconnected or XenServer has problems with communicating to the storage device. Ensure that storage is attached and can be accessed from XenServer, by testing reading with hdparm –t /dev/sd<x> or hdparm –t /dev/mapper/<scsi id> for multipathed SRs, before proceeding with the following instructions. Correct output returns the PV associated with block device and corresponding Volume Groups.

For instance, correct output of pvscan command for shared SR (iSCSI or HBA) with multipath enabled would be in the following format.

PV /dev/mapper/<scsi id> VG VG_XenStorage-<SR uuid> lvm2 [<size total/size free>]

Note how the block device appears under /dev/mapper. If multipath is not enabled, PV value would point to a single block device /dev/sd<x>, like in case of the local storage. For example:

PV /dev/sda3 VG XSLocalEXT-fdf91589-39f4-4104-9856-3cb6c606255 lvm2 [457.75 GB / 0 free]

If only /dev/sd<x> device is displayed, you can confirm scsi id of that device by inspecting output of command.

ls –alh /dev/disk/by-id/


For example, if there is an iSCSI device with scsi id of “23237636464633731” and uuid “e79f14b6-055e-a166-42ce-bf535db5f285”, as seen in general tab of the SR in XenCenter, then the pvscan output for this SR is as follows.

PV /dev/mapper/23237636464633731 VG VG_XenStorage-e79f14b6-055e-a166-42ce-bf535db5f285 lvm2 [1.22 TB / 116.00 GB free]

However, when LVM has been tempered with, pvscan command may provide no output for that SR, or another Volume Group (VG_XenStorage-<different uuid>) name will be assigned to the PV on the expected scsi device.

Background

This problem can occur in following or similar cases:
  1. Storage has been accidentally mapped to another XenServer pool and/or PV and VG metadata has been removed or overwritten with new PV and VG information.
  2. LVM metadata has been removed with incorrect pv/vg commands executed on the host.

  3. Storage failure that caused corruption on the LUN affecting LVM metadata.

Related:

Citrix Hypervisor 7.1 CU2 “This host does not appear to have any network interfaces” during fresh install of XenServer 7.1

During the installation of XS 7.1 CU2 NIC driver not installed / does not work.

Installed CH 8.1 and the driver installed out of the box with no issues.

Error Message: “This host does not appear to have any network interfaces. If interfaces are present you may need to load a device driver on the previous screen for them to be detected.”

Integrated NIC 1: QLogic 2x1GE+2x10GE QL41264HMCU CNA

NIC Slot 7: QLogic 10GE 2P QL41112HxCU-DE Adapter

Related:

Citrix Hypervisor 7.1 CU2 “This host does not appear to have any network interfaces” during fresh install of Xenserv 7.1

During the installation of XS 7.1 CU2 NIC driver not installed / does not work.

Installed CH 8.1 and the driver installed out of the box with no issues.

Error Message: “This host does not appear to have any network interfaces. If interfaces are present you may need to load a device driver on the previous screen for them to be detected.”

Integrated NIC 1: QLogic 2x1GE+2x10GE QL41264HMCU CNA

NIC Slot 7: QLogic 10GE 2P QL41112HxCU-DE Adapter

Related:

Google Drive File Stream Detected as Removable Drive

I need a solution

Google Drive File Stream is being detected as removable drive on endpoints. We have a policy to block transfer to USB and since file stream is loaded as a removable drive, any writes to this is being blocked now. We use google drive for business so this is impacting users.

IDE/SCSI Devices have been whitelisted, but unfortunately the file stream is detected as an unknown device in many cases and treated as a removable drive.

Local disk , Network share or AFAC exclusions are not applicable here since this is purely detected as a removable drive. So destination or location based white listing is not working.

Symantec knows about this issue, but doesnt have a solution.

0

Related:

  • No Related Posts

VNXe: What should be the value for parameter reclaim-unit=number in VNXe? (DELL EMC User correctable)

Article Number: 503006 Article Version: 4 Article Type: Break Fix



VNXe2 Series

To reclaim unused storage blocks on a VMFS datastore for a thin-provisioned device, we need to run the below command from Vmware
esxcli storage vmfs unmap –volume-label=volume_label|–volume-uuid=volume_uuid –reclaim-unit=number

Parameter description is as below:

-l|–volume-label=volume_label

The label of the VMFS volume to UNMAP. This is a mandatory argument. If you specify this argument, do not use -u|–volume-

uuid=volume_uuid.
-u|–volume-uuid=volume_uuid

The UUID of the VMFS volume to UNMAP. This is a mandatory argument. If you specify this argument, do not use -l|–volume-label=volume_label.
-n|–reclaim-unit=number

The number of VMFS blocks to UNMAP per iteration.
What should be the value for –reclaim-unit=number in VNXe?

The reclaim-unit=number is an optional argument and if not specified, the command uses a default value of 200.

The default value of 200 for the -n number or –reclaim-unit=number argument is appropriate in most environments, but some array vendors may suggest a larger or smaller value depending on how the array handles the SCSI UNMAP command.

The reclaim-unit=number is specified as per below configuration statistics:

200 MB for 1 MB block VMFS3 / VMFS5

800 MB for 4 MB block VMFS3

1600 MB for 8 MB block VMFS3

VNXe supports VMFS5 format with 1 MB of block size, hence 200 which is the default VMFS blocks to UNMAP is appropriate for VNXe environments.

Hence, you may leave the argument “reclaim-unit=number” as it is, it will by default will take 200 value.



The associated VMware kb is:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2057513

Related:

SEP not login

I need a solution

I have a problem with the Symantec Enpoint Protection product.
The Symantec Endpoint Protection that we have runs within a VM, while for the datastore from symantec our protection endpoint is a different VM.

to connect Symantec Endpoint protection with the datastore we use the ISCSI initiator but the ISCSI Initiator cannot connect between Symantec Endpoint Protection and the datastore, so we have difficulty logging into our SEP console.

Please provide a solution to the problems we are facing, we have great hopes for the support you provide

Regards,

Ibn Rizal

0

Related:

Re: srdf

If you’re using SRDF/S (Synchronous), or SRDF/A (Asynchronous), the replication target devices are consistent, but in WD (Write Disabled) state. That indeed qualifies as read-only, so a host connected to them will identify them, but not much else can be done with the target devices in that state. Especially since they continuously update their data from the source devices. For SRDF/S and SRDF/A only when you failover, or swap, the target devices take a RW (read-write) state.

If you want to operate SRDF where both sides are in RW state and replicate in both directions look into SRDF/Metro. It makes the SCSI personality of both source and target devices look identical to the host(s) when they are in sync, both sides are RW, and writes are replicated in both directions.

Related:

  • No Related Posts

Re: How do I retrieve host LUN ids using Powershell?

Hi RRR,

By powershell do you mean UEMCLI?

The command you are looking for might be:

uemcli -no /stor/prov/luns/lun show -detail

Check the line that reads “Host LUN IDs” and the line above that.

You can filter also for what you need only. Example:

uemcli -no /stor/prov/luns/lun show -filter “ID,Name,LUN access hosts,Host LUN IDs”

Sample output:

ID = sv_xx

Name = Test_LUN

LUN access hosts = Host_13, Host_14, Host_9, Host_10

Host LUN IDs = 7, 7, 7, 7

So from here you get what hosts can see a LUN, along with the Host LUN ID they are mapped with.

If you need to see it the other way around (from the host side, not LUN), then try the host command:

uemcli -no /remote/host show -detail

The filter option can also be used here.

All these outputs are based on Unity OE 4.4.1, so if you are running dated versions, you may not have some options.

Hope this helps.

Andre @ Dell EMC

If this answered your question, please remember to mark this thread as resolved/answered, so it can help other users.

Related:

Re: Inherited a problem I think

So the background:

I started my current position about a year and a half ago. We currently have a VNX5100 which we are migrating away from due to other requirements. I plan on keeping the VNX around for testing purpose though. The previous admin created one RAID5 group of 4.5 TB LUN and a POOL of 10.9 TB as a LUN. I did have to replace a few of the drives about 5 months into my employment. Now the problem is that on the 4.5LUN. These LUNS are attached to my VCenter for VM use.

Skip ahead to last week, and including up to today.

I have migrated a bunch of my smaller VMs from the 4.5 no problem, but now as I get to the last 2 which contain about 1.5 TB each of data on that 4.5 TB LUN, they fail. I get an I/O error. I Had VMware look at the issue and he says its on the storage side and has given me the codes that show up.

“- The errors are on the VNX-4.5TB Storage Aray and have the sense codes 0x0 0x2 0x0 and sense data 0x3 0x11 0x0

– I decoded these scsi sense codes which shows an issue with the storage array medium error.”

I went to look at the LUN itself and check the disks I found that… well just chek out the screen shot

VNX-LUN4.5-Dying.JPG.jpg

I Have got to get the data off of these as both of the VMs that have a VMDK stuck on this LUN have medical data for hundreds of patients. and a database.

Any help appreciated.

Related:

  • No Related Posts

Inherited a problem I think

So the background:

I started my current position about a year and a half ago. We currently have a VNX5100 which we are migrating away from due to other requirements. I plan on keeping the VNX around for testing purpose though. The previous admin created one RAID5 group of 4.5 TB LUN and a POOL of 10.9 TB as a LUN. I did have to replace a few of the drives about 5 months into my employment. Now the problem is that on the 4.5LUN. These LUNS are attached to my VCenter for VM use.

Skip ahead to last week, and including up to today.

I have migrated a bunch of my smaller VMs from the 4.5 no problem, but now as I get to the last 2 which contain about 1.5 TB each of data on that 4.5 TB LUN, they fail. I get an I/O error. I Had VMware look at the issue and he says its on the storage side and has given me the codes that show up.

“- The errors are on the VNX-4.5TB Storage Aray and have the sense codes 0x0 0x2 0x0 and sense data 0x3 0x11 0x0

– I decoded these scsi sense codes which shows an issue with the storage array medium error.”

I went to look at the LUN itself and check the disks I found that… well just chek out the screen shot

VNX-LUN4.5-Dying.JPG.jpg

I Have got to get the data off of these as both of the VMs that have a VMDK stuck on this LUN have medical data for hundreds of patients. and a database.

Any help appreciated.

Related:

  • No Related Posts