10:49 p.m.
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(a)linux.vnet.ibm.com
Telephone: 86-10-82454397