Mark Johnson writes: > James Carlson wrote: > > Would vdiskadm be a useful addition to the system if blktap never > > integrates? (What would it do?) > > By itself, vdiskadm wouldn't be overly useful today. > You would be able to create/snapshot vmdk and vdi files. > But nothing would write to them.
That makes it sound like vdiskadm is actually dependent on delivery of blktap. > In the near future, you will be able to convert a vmdk or > vdi files to a zvol, or zvol to vmdk or vdi file.. > That would be useful outside of blktap. But that is > *not* covered by this fast track. > > Having them separate is based on forward look assumptions > that it will be used by other code outside of xVM-Xen. > I can see how assumptions like that can get out of hand too.. Yes; it makes it a little less clear what we're actually approving. :-/ > We can certainly see that point.. We don't have any issues > with combining the two cases if asked to. We would just need > a little guidance on what we would need to do to move forward > with that. I can live with it the way it is, as long as these two are the whole project as it stands today. (Otherwise, I'd want to see something that documents the whole project.) > >>>> 4.3. Interfaces > >>> What about the VMWare native and Virtual Box native disk file formats? > >> Yes, I will add this in. I'll wait to hear back about the merge > >> before sending out an update. > > > > OK. I'm mostly curious about the stability level of those formats. > > vmdk and vdi file formats are Uncommitted. How does this versioning work? How do the Virtual Box people know to work with us if they need to create a new disk image format? Do we know or constrain their plans? If VMWare chooses to create a new file format (perhaps just to spite Sun and xVM), does something here have to track the changes? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
