Hi all, I'm working on host device passthrough. A a problem troubles me: I see in current Kimchi code, when adding a specific SCSI or iSCSI LUN, it is added to the template but not the VM. This is counter-intuitive, because a template is to store the common information for lots of VMs, while a specific LUN should only be used by just one VM. It's OK for DIR, NFS and Logical storage pool being managed by the template, because actually the template allocates a new specific volume for a new VM, so the specific volume goes with the specific VM but not the template. Since we don't define a specific DIR storage volume in the template, why we define a concrete LUN in it? The first problem in the current design is that we can not attach a new LUN to a VM after the VM is created. Another problem is that we mix the "things in common" and "things special" in template, thus we make its responsibility complex. Static and dynamic validations are also mixed in template. The third problem is that if we get 10 LUNs for 10 VMs, the user has to create 10 templates at first, then create 10 VMs from the 10 templates respectively. It's a bit tedious. The fourth problem is that if a LUN is used by a VM, usually it should not be used by other VMs, so it implies that by specifying a LUN in a template, the template should only create just one VM. What's the point to make a template that only produces one VM? It seems a cleaner way is putting SCSI LUN handling code in VM. Firstly, we can assign a SCSI/iSCSI storage pool to the template. When it's time to create a VM from the template, Kimchi lists all the available LUNs in the storage pool and the user can just pick some LUNs. The VM override parameters are suitable to store the LUNs information. It also makes possible to implement some mechanisms to add/remove LUNs after a VM is created, which is a very typical user requirement. The same problem exists in host device passthrough. For a specific device, it should be passthrough to a specific VM but not a template. I'd like to collect some thoughts before my device passthrough patch V2. In which place you'd suggest me to put device passthrough information, template or VM? Thanks for sharing your ideas!

On 04/27/2014 10:38 PM, Zhou Zheng Sheng wrote: > Hi all, > > I'm working on host device passthrough. A a problem troubles me: I see > in current Kimchi code, when adding a specific SCSI or iSCSI LUN, it is > added to the template but not the VM. This is counter-intuitive, because > a template is to store the common information for lots of VMs, while a > specific LUN should only be used by just one VM. It's OK for DIR, NFS > and Logical storage pool being managed by the template, because actually > the template allocates a new specific volume for a new VM, so the > specific volume goes with the specific VM but not the template. Since we > don't define a specific DIR storage volume in the template, why we > define a concrete LUN in it? > > The first problem in the current design is that we can not attach a new > LUN to a VM after the VM is created. > > Another problem is that we mix the "things in common" and "things > special" in template, thus we make its responsibility complex. Static > and dynamic validations are also mixed in template. > > The third problem is that if we get 10 LUNs for 10 VMs, the user has to > create 10 templates at first, then create 10 VMs from the 10 templates > respectively. It's a bit tedious. > > The fourth problem is that if a LUN is used by a VM, usually it should > not be used by other VMs, so it implies that by specifying a LUN in a > template, the template should only create just one VM. What's the point > to make a template that only produces one VM? > > It seems a cleaner way is putting SCSI LUN handling code in VM. Firstly, > we can assign a SCSI/iSCSI storage pool to the template. When it's time > to create a VM from the template, Kimchi lists all the available LUNs in > the storage pool and the user can just pick some LUNs. The VM override > parameters are suitable to store the LUNs information. It also makes > possible to implement some mechanisms to add/remove LUNs after a VM is > created, which is a very typical user requirement. > > The same problem exists in host device passthrough. For a specific > device, it should be passthrough to a specific VM but not a template. > I'd like to collect some thoughts before my device passthrough patch V2. > In which place you'd suggest me to put device passthrough information, > template or VM? Template should NOT include any vm specific information. As I mentioned in the comments of your pci passthrough patch, we need allow user have chance to customize the configuration when creating vm based on template.

> Thanks for sharing your ideas! >

Would anyone share some background information on why we implement LUN in template? I want to know the original author's considerations. I googled this topic in the mail list, didn't get much context information.

on 2014/04/28 21:08, Sheldon wrote: > On 04/28/2014 01:45 PM, Mark Wu wrote: >> On 04/27/2014 10:38 PM, Zhou Zheng Sheng wrote: >>> Hi all, >>> >>> I'm working on host device passthrough. A a problem troubles me: I see >>> in current Kimchi code, when adding a specific SCSI or iSCSI LUN, it is >>> added to the template but not the VM. This is counter-intuitive, because >>> a template is to store the common information for lots of VMs, while a >>> specific LUN should only be used by just one VM. It's OK for DIR, NFS >>> and Logical storage pool being managed by the template, because actually >>> the template allocates a new specific volume for a new VM, so the >>> specific volume goes with the specific VM but not the template. Since we >>> don't define a specific DIR storage volume in the template, why we >>> define a concrete LUN in it? >>> >>> The first problem in the current design is that we can not attach a new >>> LUN to a VM after the VM is created. >>> >>> Another problem is that we mix the "things in common" and "things >>> special" in template, thus we make its responsibility complex. Static >>> and dynamic validations are also mixed in template. >>> >>> The third problem is that if we get 10 LUNs for 10 VMs, the user has to >>> create 10 templates at first, then create 10 VMs from the 10 templates >>> respectively. It's a bit tedious. >>> >>> The fourth problem is that if a LUN is used by a VM, usually it should >>> not be used by other VMs, so it implies that by specifying a LUN in a >>> template, the template should only create just one VM. What's the point >>> to make a template that only produces one VM? >>> >>> It seems a cleaner way is putting SCSI LUN handling code in VM. Firstly, >>> we can assign a SCSI/iSCSI storage pool to the template. When it's time >>> to create a VM from the template, Kimchi lists all the available LUNs in >>> the storage pool and the user can just pick some LUNs. The VM override >>> parameters are suitable to store the LUNs information. It also makes >>> possible to implement some mechanisms to add/remove LUNs after a VM is >>> created, which is a very typical user requirement. >>> >>> The same problem exists in host device passthrough. For a specific >>> device, it should be passthrough to a specific VM but not a template >>> I'd like to collect some thoughts before my device passthrough patch V2. >>> In which place you'd suggest me to put device passthrough information, >>> template or VM? >> Template should NOT include any vm specific information. As I mentioned >> in the comments of your pci passthrough patch, we need allow user have >> chance to customize the configuration when creating vm based on >> template. > ACK