LN_TARGET = "SYSTEM" not cloning image to system DS

[Pimplek]

Description
When creating new persistent VMs from a template, I want the VM image to sit on a NFS mount in the system datastore which I select when creating the new VM (via sunstone).

By default when using datastores with TM_MAD=shared, this is not the case. From what I see:

#   ln_target : determines how the persistent images will be cloned when
#               a new VM is instantiated.
#       NONE: The image will be linked and no more storage capacity will be used
#       SELF: The image will be cloned in the Images datastore
#       SYSTEM: The image will be cloned in the System datastore

LN_TARGET = "SYSTEM" looks to be what I want. I created a new TM_MAD called "shared2" with that setting, but the results are the same as with the default "shared" (LN_TARGET = "NONE")

To Reproduce
Add a new TM_MAD section with LN_TARGET = "SYSTEM" in oned.conf:

TM_MAD_CONF = [
    NAME = "shared2", LN_TARGET = "SYSTEM", CLONE_TARGET = "SYSTEM", SHARED = "YES",
    DS_MIGRATE = "YES", TM_MAD_SYSTEM = "ssh", LN_TARGET_SSH = "SYSTEM",
    CLONE_TARGET_SSH = "SYSTEM", DISK_TYPE_SSH = "FILE"
]

Also modify:

TM_MAD = [
    EXECUTABLE = "one_tm",
#    ARGUMENTS = "-t 15 -d dummy,lvm,shared,fs_lvm,qcow2,ssh,ceph,dev,vcenter,iscsi_libvirt"
    ARGUMENTS = "-t 15 -d dummy,lvm,shared,shared2,fs_lvm,qcow2,ssh,ceph,dev,vcenter,iscsi_libvirt"
]

Restart opennebula, and create a new system and image datastore:

# onedatastore show 129
DATASTORE 129 INFORMATION                                                       
ID             : 129                 
NAME           : nfs-test-img        
USER           : oneadmin            
GROUP          : oneadmin            
CLUSTERS       : 0                   
TYPE           : IMAGE               
DS_MAD         : fs                  
TM_MAD         : shared2             
BASE PATH      : /var/lib/one//datastores/129
DISK_TYPE      : FILE                
STATE          : READY               

DATASTORE CAPACITY                                                              
TOTAL:         : 271.2G              
FREE:          : 244.5G              
USED:          : 12.9G               
LIMIT:         : -                   

PERMISSIONS                                                                     
OWNER          : um-                 
GROUP          : u--                 
OTHER          : ---                 

DATASTORE TEMPLATE                                                              
ALLOW_ORPHANS="NO"
CLONE_TARGET="SYSTEM"
CLONE_TARGET_SSH="SYSTEM"
COMPATIBLE_SYS_DS="130"
DISK_TYPE="FILE"
DISK_TYPE_SSH="FILE"
DS_MAD="fs"
LN_TARGET="SYSTEM"
LN_TARGET_SSH="SYSTEM"
RESTRICTED_DIRS="/"
SAFE_DIRS="/var/tmp"
TM_MAD="shared2"
TM_MAD_SYSTEM="ssh"
TYPE="IMAGE_DS"


# onedatastore show 130
DATASTORE 130 INFORMATION                                                       
ID             : 130                 
NAME           : nfs-test-sys        
USER           : oneadmin            
GROUP          : oneadmin            
CLUSTERS       : 0                   
TYPE           : SYSTEM              
DS_MAD         : -                   
TM_MAD         : shared2             
BASE PATH      : /var/lib/one//datastores/130
DISK_TYPE      : FILE                
STATE          : READY               

DATASTORE CAPACITY                                                              
TOTAL:         : 271.2G              
FREE:          : 244.5G              
USED:          : 12.9G               
LIMIT:         : -                   

PERMISSIONS                                                                     
OWNER          : um-                 
GROUP          : u--                 
OTHER          : ---                 

DATASTORE TEMPLATE                                                              
ALLOW_ORPHANS="NO"
DISK_TYPE="FILE"
DS_MIGRATE="YES"
RESTRICTED_DIRS="/"
SAFE_DIRS="/var/tmp"
SHARED="YES"
TM_MAD="shared2"
TYPE="SYSTEM_DS"

Next, create a VM from any template via sunstone. Select the "nfs-test-sys" DS before hitting "create".
The VM disk file (disk.0 ) is created in the selected system datastore, but the file itself is a symlink to a clone of the VM disk image from the template. When that image from the template is cloned, it's cloned to the same image datastore where the source image (from the template) resides.

# ls -alRh /var/lib/one/datastores/{129,130}
/var/lib/one/datastores/129:
total 8.0K
drwxr-xr-x  2 oneadmin oneadmin 4.0K Apr  7 02:51 .
drwxrwxr-x 30 oneadmin oneadmin 4.0K Apr  7 02:52 ..

/var/lib/one/datastores/130:
total 12K
drwxr-xr-x  3 oneadmin oneadmin 4.0K Apr  7 03:02 .
drwxrwxr-x 30 oneadmin oneadmin 4.0K Apr  7 02:52 ..
drwxrwxr-x  2 oneadmin oneadmin 4.0K Apr  7 03:02 61

/var/lib/one/datastores/130/61:
total 380K
drwxrwxr-x 2 oneadmin oneadmin 4.0K Apr  7 03:02 .
drwxr-xr-x 3 oneadmin oneadmin 4.0K Apr  7 03:02 ..
-rw-rw-r-- 1 oneadmin oneadmin  866 Apr  7 03:02 deployment.0
lrwxrwxrwx 1 oneadmin oneadmin   60 Apr  7 03:02 disk.0 -> /var/lib/one/datastores/124/49e461d5d41160d14d1320dfb80f3d01
-rw-r--r-- 1 oneadmin oneadmin 364K Apr  7 03:02 disk.1

As shown above, the new VM disk is a symlink to a image file in a completely different image datasource.

The same stands for datasources with TM_MAD=qcow2. The COMPATIBLE_SYS_DS="130" setting also has no effect.

Expected behavior
The disk image file from the template is cloned to the selected system datastore, and the running VM uses that same cloned file.

Details

• Affected Component: Storage
• Hypervisor: KVM
• Version: 5.6.1

Additional context
The reason for doing this is because we want to use multiple NFS mounts to even out the IO load for running VMs. It would be very practical if we can select the DS (and with it the NFS mount) directly when creating a new VM.

Is this a bug or am I doing something wrong?

Progress Status

• Branch created
• Code committed to development branch
• Testing - QA
• Documentation
• Release notes - resolved issues, compatibility, known issues
• Code committed to upstream release/hotfix branches
• Documentation committed to upstream release/hotfix branches

[rsmontero]

Sorry for the confusion those attributes do not change the behavior of the driver. They describe the behavior of the driver. They exists so oned knows how the driver is going to deal with persistent images, or system datastores. This way, oned can compute quotas, disk usage and the like.

See #2791 for additional discussions on this matter. Closing as duplicate for this one.

BTW, TM shared uses links on the NFS mount for persistent images. If you want to actually copy the images you can use the ssh mode, and mount in the datastore dir the NFS share....