Rethink the Relationship of Template and VM
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! -- Thanks and best regards! Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
CCing the the developers who have talked to me on this topic, and the maintainer. on 2014.04/27 22:38, 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?
Thanks for sharing your ideas!
-- Thanks and best regards! Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
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!
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 Thanks for sharing your ideas!
-- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
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
On 04/29/2014 10:42 AM, Zhou Zheng Sheng wrote:
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. Aline, any comments?
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
-- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
Hi, I talked to Rodrigo. He did send a patch series to implement LUN in VM, but the patches are not applied. It seems there are some reasons to implement LUN in template. I list the reasons below as well as my opinion. (1) It's rare to install a VM on LUN. There wouldn't be a case to install 10 VMs on 10 LUNs, instead, once a VM is created, it should be cloned. So creating "one VM -> one template -> one LUN" relationship for each LUN is not that tedious. If the above reason was correct, we should have never implemented iSCSI/SCSI storage pool. When the user wants to use this style of creating-cloning VMs, the user just creates a logical storage pool over the LUNs, and creates and clones VMs from the logical storage pool. That's exactly what a logical storage pool for. Then all the things to do to support iSCSI/SCSI is just to scan all the LUNs and import them to a logical storage pool. Moreover, putting a particular LUN in a template is actually preventing the user from cloning a VM. The user has to clone the template firstly, then creates a new VM from the new template. This is even more tedious. (2) We have two roles, user and admin. The admin creates the template and the user creates VM from the template. If the LUN is configured by the user upon VM creation, the user may mistakenly use the other user's LUN and step each other's feet. So the privilege of managing LUNs should only be available to admin. This is also not a valid reason. If there are two admins, one admin can also mistakenly use another admin's LUN when configuring the template. I think instead of offering all detected LUNs to use upon VM creation, Kimchi should track all the LUNs currently used by all the VMs and only present the free LUNs to the user/admin. Alone with my reasons in the previous mail below, I think LUN handling should be moved to VM. If there is any other reason to put a specific LUN in template, please reply this mail and let's discuss. on 2014/04/27 22:38, 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?
Thanks for sharing your ideas!
-- Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
participants (3)
-
Mark Wu -
Sheldon -
Zhou Zheng Sheng