search

ktrace / pxmx-ctld

ProxMox plugin for FreeBSD/ctld iSCSI target as backend
MIT License
2 stars 1 forks source link

Moving VM disk from one storage to another creates wrong config file entry and don't delete it from source config #5

Open IronDusts opened 7 months ago

IronDusts commented 7 months ago

Setup

Storage1:

target iqn.storage1.lan:storage1 {
     auth-group no-authentication
     portal-group pg0
     lun 0 {
           path /dev/zvol/iscsi/vm-101-disk-0
     }
}

Storage2: 

target iqn.storage2.lan:storage2 {
    auth-group no-authentication
    portal-group pg0
}

After moving the storage I somehow expected:

Storage1:

target iqn.storage1.lan:storage1 {
     auth-group no-authentication
     portal-group pg0

}

Storage2: 

target iqn.storage2.lan:storage2 {
    auth-group no-authentication
    portal-group pg0
     lun 0 {
           path /dev/zvol/iscsi/vm-101-disk-0
     }
}

What I actually got was:

Storage1:

target iqn.storage1.lan:storage1 {
     auth-group no-authentication
     portal-group pg0
}
iqn.storage2.lan:storage2 {                       ### <<<--- Note missing "Target" at the beginning 
     lun 0 {
           path /dev/zvol/disk_d/vm-101-disk-0
     }
}

Storage2: 

target iqn.storage1.lan:storage1 {
     auth-group no-authentication
     portal-group pg0
     lun 0 {
           path /dev/zvol/iscsi/vm-101-disk-0
     }
}

iqn.storage2.lan:storage2 {                       ### <<<--- Note missing "Target" at the beginning  even thou it was correct before

     lun 0 {
          path /dev/zvol/disk_d/vm-101-disk-0
    }
}

Some observations:

  1. For some reason the storage1 target configuration is being copied to the storage2 ctl.conf
  2. The word "Target is missing"
  3. The storage2 configuration has copied the target configuration from storage1 having the word "target" but then it's own config misses the "target" word
  4. The storage1 don't delete the LUN section after migration
  5. All target configurations have the LUN inside everywhere
  6. ZFS volumes, LUN mappings in the runtime config are being correctly handled. However one ctld restart with this messed up configs may cause a disaster.
  7. Haven't tested how all good runtime LUN mappings and zvols after migration but messed up ctl.conf files will affect attempt for second migration e.g. what data will be taken from configs and what from LUN mappings and what will it result in
  8. Deleting VM with it's disks will fail after a migration happened probably due to messed up ctl.conf files