> -----Original Message----- > From: George Dunlap [mailto:[email protected]] > Sent: 10 August 2015 10:33 > To: Dave Scott; Anil Madhavapeddy > Cc: Martin Lucina; rumpkernel-users; Felipe Franciosi > Subject: Re: Eliminating the need for qemu for file images on Xen unikernels > > One disadvantage of blktap is that at the moment (as I understand it) it > relies > on a kernel module, even if you're not primarily using the in-kernel datapath. > Felipe seemed to think that this was mainly to have a central place to > allocate > minor numbers for the device node; but that still it would take some massive > re-architecting to get the code to work without it.
That's absolutely correct. Tapdisk3 (which is the userspace daemon) requires the kernel blktap driver to be loaded, even if you are using it in the datapath. By design, a tapdisk server is quite flexible and a single daemon can be used to serve a group of VMs, a group of VBDs (e.g. one VM with many disks) or a single virtual disk. In XenServer, we use one tapdisk3 process per virtual disk. Internally, a tapdisk_server+blktap_minor mapping is what you associate with a virtual disk (hence the need for the kernel driver). As George said, it could be modified to function without a minor. And yeah, that would require massive re-architecting. Cheers, Felipe
