|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH 0 of 6] dm-userspace xen integration
CL> Has this been posted to the devicemapper list? I think someone
CL> mentioned it had been, could you post a reference to any follow-up
CL> discussion?
It has been posted to dm-devel, and through a few on-list and (mostly)
off-list mails, the maintainer has expressed interest in getting this
pushed into device-mapper proper soon.
CL> Is there clear indication that this will be picked up by
CL> devicemapper because
Yes. An older version is already in his staging tree, and the latest
version has been sent to him.
CL> I don't think we'll want to have to maintain this in-tree forever.
I strongly agree.
CL> This needs to be changed to fail gracefully if the auto* tools are
CL> not installed. Is the use of auto* tools absolutely necessary?
Since xm-test was accepted with the use of autotools, we did not see
any reason why this wouldn't.
CL> Could we checkin the generated files as well?
I suppose, if that's what you want. It will result in some relatively
large patches of apparent garbage every time we make a change to the
build system.
CL> Is this there because libdevmapper doesn't support this yet? Is
CL> there any version of libdevmapper which supports this yet?
The libdevmapper changes are also being pushed to the device-mapper
maintainer. For now, we are just compiling those directly into cowd
to avoid forcing people to patch their libdevmapper.
CL> Does this work for qemu domains? If so how, if not, what are your
CL> plans to make it work for qemu domains?
I don't see why it would not work. It just exports a block device, so
if a qemu domain can use an LVM or a partition, then this will work.
I can get access to an HVM machine and verify.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@xxxxxxxxxx
pgpimwM71zyye.pgp
Description: PGP signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|