Darren J Moffat wrote: > Artem Kachitchkine wrote: >> The current backend block driver (xdb) allows block devices or raw >> files (using lofi) to be exported to the guest as disks. xdb will >> continue to be present and will co-exist with the block tap driver >> (xpvtap). A guest may contain many disks. These disks can be a mixture >> of block devices using xdb, raw files using xdb, and vmdk, vdi, and/or >> raw files using xpvtap. > > Why keep the existing lofi based with xdb as the default for file based > disks if xpvtab can support this too ? > Is it just because lofi supports compression and encryption and xpvtap > doesn't or is there another reason ? This is the only part that needs to > be answered for me to be happy with the architecture of this case the > rest is futures.
xdb with lofi is still used for cdrom emulation. xpvtap does not handle media exchange today. There is a recent RFE to add in this support to xpvtap in the future. When this, encryption, and possibly compression support are present in xpvtap, it makes sense to re-evaluate lofi support in xdb. > Is xdb likely to be obsoleted in the future ? It's expected that xdb will still be used for block based devices (zvols, raw disks, etc). > I believe VMware has the capability to provide encrypted .vmdk images, > is there a plan/desire for this support to be added to xpvtap in the > future I'm not expecting it to be part of this case just trying to work > of if the architecture of this case can support it, I believe it could > providing we can get the details of how encrypted vmdk images are written. Assuming VMWare provides the details for the encrypted .vmdk image, and customers use it, I would expect us to add support for it. > I would expect that to support encryption with xpvtab vdiskadm > (PSARC/2008/597) would need updating. Yes. > For VirtualBox VDI format there is an open request for adding encryption > support: http://www.virtualbox.org/ticket/1765 Yes, we are aware and interested in this. :-) > Similar comments for compression. We haven't discussed compression internally yet. But all the same comments apply. Once the 1.0 features have been putback, we are going to start prioritizing what functionality to add next. Most, if not all of which, will require follow-up ARC work. Thanks, MRJ
