I can think of some reasons for a non-native file service that is instead built into QEMU:
a) One interface to all clients outside of QEMU. Lowers the learning curve for dealing with different enviroments; at least for some raw file access they are all accessible in the same way. You can lower configuration close to zero-config, just as was done with user mode networking. This allows to control the complexity of the configuration, as opposed to Samba, Windows, NFS, issues in each particular circumstance. Don't underestimate the value of expedience. c) Vintage OSes where being networked is atypical or for which network compatibility with QEMU is currently problematic like old versions of DOS d) Non-desktop emulation of non-networked embedded devices. e) Scripts to be used across farms of QEMU virtual machines will have more commonalities even across different OSes. The event and content of a file popping up on a machine in a given directory is a very basic form of inter-process communication common in business operations. Having one way that always or almost always works with QEMU virtual machines will be good for QEMU strategically. Look at VmWare... purchased recently by EMC corporation. Their product line is currently geared toward packing multiple 'virtual servers" onto beefy real servers. -- John. _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
