Just an FYI, with the latest XCP-NG (updated last night to 8.2.1), the sr-create step no longer seems to generate the UUID, says it is missing when you execute that line. I’ll play with it more when I have a chance.
I deleted the sym links to see if order of operations was important, but didn’t seem to matter.
Maybe because these servers are in a pool, but it wanted to know which host (by UUID) these were going to be attached to. host-uuid= long string of numbers and letters copied from the the host tab in XO completed the task.
Installed XCP-ng over Leap which was used as my KVM Server having,
[19:01 xcp-ng mnt]# blkid | grep "crypto_LUKS"
/dev/sda1: UUID="1cc46889-d49b-4772-8eaa-bb03497b74f5" TYPE="crypto_LUKS"
/dev/sdc1: UUID="fb1244ce-8054-4fd8-b182-cd5d19a849ea" TYPE="crypto_LUKS"
/dev/sdd1: UUID="9ef7c851-f6e3-4edb-883f-8fa66d588248" TYPE="crypto_LUKS"
/dev/sde1: UUID="b65abff0-4540-40ab-bf9b-16ae762c8614" TYPE="crypto_LUKS"
/dev/sdf1: UUID="d38cd9cf-b76f-4d08-87f6-2fa63153423f" TYPE="crypto_LUKS"
and was hoping to mount them so I can move the vm’s before making these dev’s into SR’s. But, I get this message,
[19:03 xcp-ng mnt]# cryptsetup luksOpen /dev/sde1 encrypted_sde1
Unsupported LUKS version 2.
So, I’ve created a Leap VM and want to attached these drives, instead of creating a new folder, can I use either the folder
that are already created by the host and,
xe sr-create name-label=Leap_Drives type=udev content-type=disk device-config:location=/dev/disk/by-uuid
Well this work without xcp-ng erasing the disks?
UPDATE:
Well, I just did this as instructed
ln -s /dev/sda /srv/leap-drives/sda
ln -s /dev/sdc /srv/leap-drives/sdc
ln -s /dev/sdd /srv/leap-drives/sdd
ln -s /dev/sde /srv/leap-drives/sde
ln -s /dev/sdf /srv/leap-drives/sdf
xe sr-create name-label=“Leap Drives” name-description=”Leap Lab KVM SR” type=udev content-type=disk device-config:location=/srv/leap-drives
and was able to attached the disks to the Leap VM and mount them as expected, now I can move the vm’s and wipe these disks to be used for SR’s… 
or
leave as is 
, because this is my Leap Test Lab Server. Any drawbacks for this type of setup?
This is pretty interesting, but do these passed through drives have any access to SMART data in the VM? Can they be hot attached and detached from a running VM, or do they require a VM reboot?
Hello all,
I am trying Disk Passthrough on XCP-NG host.
The first XCP-NG host successfully passthrough the physical RAID 5 disk.
THe secound XCP-NG attach the disk, but the log showing VM_MISSING_PV_DRIVERS:
So I tried the convert to PV, but the log showing INTERNAL_ERROR(xenopsd internal error: Domain.Could_not_read_file(“”)) , that I can’t start the VM.
Please help.
Super cool idea.
I thought this was my perfect alternative to overcome a server that doesn’t support PCI passthrough. So I tried this, it all executed fine without reporting errors.
But when I do “sr-scan” the SR shows no drive, while I do confirm that the location contains proper symlinks. It seems that XCP-ng 8.3 refuses to show these drives.
What gives? Any idea? I’m stuck at finding a way to pass drives to my VM.
I have not tested to see if this method still works in version 8.3
Apparently someone else encountered the issue, and opened a bug on Github.
Apparently 8.2.1 should still work, so that would be my workaround. I’ll be testing it in the next few days.
As a heads up. I’ve since confirmed that this trick works in 8.2.1 (LTS) but is broken in 8.3
Please watch GitHub issue 666 if this matters to you.
Also of interesting note, it only works if the symlink point to /dev/sd*. If you try to link to any other locations, XCP-ng is unable to pick up the drives correctly. They will get miss-identified and with a size of 0 Bytes.
From my observation, the SR seems to read the symlink instead of following it, as if it was using the readlink command. Hence why it doesn’t work by-id.
