RE: Eliminating the need for qemu for file images on Xen unikernels
- From: Felipe Franciosi <felipe.franciosi@xxxxxxxxxx>
- To: George Dunlap <George.Dunlap@xxxxxxxxxx>, Dave Scott <Dave.Scott@xxxxxxxxxx>, Anil Madhavapeddy <anil@xxxxxxxxxx>
- Date: Mon, 10 Aug 2015 10:55:28 +0000
-----Original Message-----
From: George Dunlap [mailto:george.dunlap@xxxxxxxxxx]
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
Other related posts:
