On 12/12/2022 9:55 AM, Christoph Hellwig wrote:
On Sun, Dec 11, 2022 at 01:39:37PM +0200, Max Gurtovoy wrote:
1. Need to define a concept of a "virtual subsystem". A primary controller
will be able to create a virtual subsystem. Inside this subsystem the
primary controller will be the master ("the controlling") of the migration
process. It will also be able to add secondary controllers to this virtual
subsystem and assign "virtual controller ID" to it.
something like:
- nvme virtual_subsys_create --dev=/dev/nvme1 --virtual_nqn="my_v_nqn_1"
--dev_vcid = 1
- nvme virtual_subsys_add --dev=/dev/nvme1 --virtual_nqn="my_v_nqn_1"
--secondary_dev=/dev/nvme2 --secondary_dev_vcid=20
Yes. Note that there is a bit more state than just the NQN. You also
need at least a serial number, and also probably a different vendor
ID (the PCI vendor ID that is also mirror in Identify Controller and
the IEEE OUI), and new unique namespace identifier.
Yes for sure there is more bits we should consider.
I wanted to describe the high level.
I think that we can maybe say the when a secondary function is moved to
a virtual subsystem its feature set of the virtual ctrl is narrowed to
mandatory NVMe features set.
And we'll provide an API to set/extend it's feature set to a maximum of
the feature set that the original ctrl of the secondary function had.
Then the sys admin will configure the virtual ctrl in both src/dst hosts.
The high level idea is to have a programmable way to set the features of
a virtual controller inside a virtual subsystem that is also programmable.
