On Wed, Jun 23, 2010 at 10:08:06PM -0400, ian geiser wrote: > Greetings, I have been working on adding the ability to expose local file > systems to a remote instance of qemu. I have decided that since there is > already a connection from the client to the VM with the RFB protocol that I > want to extend that. I have spent some time researching the current > approaches that VNC uses to transfer files between the client and the host > and > none of them seem to offer a solution I like. The NFS approach is too > cumbersome at this point, and transferring entire files to the host before > they > are accessed is also prohibitive. So I started on the following approach: > > http://www.geiseri.com/sharedfolderspec/sharedfolderspec.html
This is great work - sharing from a local VNC client to remote QEMU instance is a frequently requested feature ! > This approach is a bit different in the way that the server initiates all > file > access, and it accesses data from the client on demand. This is done via a > block based approach so only the desired data is read from the client's file > system. Also I tried to make the messages mesh well with the API's of > Microsoft's file system driver and the FUSE file system driver. The goal > being > that the VNC session would expose these shares as part of the local file > system. Since the implementation I am working against on qemu only supports > the vfat file systems I have mirrored most of the behavior against that. The > only casualties so far have been symbolic links, special files (sockets, > devices, etc), user ids and group ids. For 99% of the applications out there > this should not be an issue. Please someone correct me if I am mistaken > though. My main use case is to share my local USB key with my VM. When you say you want to share the local USB key with the VM, I assume you want the guest OS to access the files on the local client USB key, rather than the remote virt host OS accessing the files ? If this is true then I think that you might want to look at the plan9fs virtio driver that was recently merged into QEMU, instead of vfat. The QEMU community broadly considers vfat a gross hack with no future ahead of it, so I fear you might find it hard to convince them to consider a VNC extension that meshes with the vfat driver. Your RFB proposal does look like it could mesh with the virtio plan9fs driver backends though. Currently that driver has a backend impl that maps to the host filesystem, but it looks like it would be possible to provide a driver that maps over to your VNC extension, if you defined specs for a few more file operations. The hw/file-op-9p.h file in QEMU defines all the ops needed for p9fs support. The other approach to your use case would be to expose the local USB key as a block device over VNC instead of a filesystem. Then, the guest OS itself would be responsible for interpreting the filesystem operations and the VNC extension would only need provide a generic random access, bulk data transfer capability. The obvious downside of this idea though is that if you wanted to allow write access, you could only give the USB key device to one guest at a time, nor be able to access it from your local client OS ie no concurrent write access. So I think your idea has merit, even though its alot more work to implement. > I am looking for feedback from other VNC implementors to see if they are > willing to entertain this extension. It would be nice if there was a way to > share client data with the host similar to how Microsoft does it with their > terminal services. (For those of you who have worked with the RDP protocol > this is going to look eerily familiar) > > I think this might compete with some VNC server vendor's paid offerings, but > it > would be nice to have a common way to do this. I hope they do not feel > threatened and consider this extension as an option. That's not a concern for people on this list! This mailing list started precisely because too many vendors were building undocumented, closed VNC extensions with no effort on standardization / interoperability between impls. Reusable, open specifications are always welcomed here :-) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
