Red Hat Bugzilla – Bug 868425
RFE: RAM backed storage pool
Last modified: 2016-04-26 12:02:37 EDT
As systems are coming with more and more ram, it is desirable to create ram storage for use with short lived guests.
In my use case I use guests to do repeated install testing, where persistence between host reboots is unneeded. However speed is needed, and as I have an over abundance of ram in my host I'd like to allocate some of it to be the storage for these one-shot guests.
Currently I'm using scsi_debug to create a scsi device out of a chunk of ram, then creating LVM on that scsi device and giving the device to libvirt. I have to make sure this gets setup before the libvirt daemon starts so that the pool is available for use. It would be nice to make this kind of setup (not necessarily scsi_debug) a supported path, complete with UI to create such a storage pool that would get managed at daemon start time.
You and Osier should talk about exactly what you're doing and how to implement it.
Does tmpfs fit the requirements? Then it could just be a <pool type='filesystem'/> with <source device='tmpfs'/> or something like that.
(In reply to comment #2)
> Does tmpfs fit the requirements? Then it could just be a <pool
> type='filesystem'/> with <source device='tmpfs'/> or something like that.
tmpfs might work. I don't know the performance differences between scsi_debug direct, LVM on top of scsi_debug, or qcow like images on top of tmpfs.
One thing that libvirt would have to do is recreate the setup each start up. It's not enough to just make the tmpfs pool, it would need to recreate any image files on top of it.
People can do this manually with host tmpfs mounts... I think that's sufficient without needing to add native libvirt support