On Aug 29, 2015, at 12:39 PM, Max Reitz wrote: > On 29.08.2015 17:57, Programmingkid wrote: >> >> On Aug 29, 2015, at 11:40 AM, Max Reitz wrote: >> >>> On 27.08.2015 03:05, G 3 wrote: >>>> I want to share files between my host and guest computer. A feature I >>>> want to add would be a new menu item in the Machine menu called "Mount >>>> Image File...". When the user selects it, a file open dialog box >>>> displays. The user can then select the image file with the file he wants >>>> to use. After pushing the OK button, the image file would be mounted >>>> like a USB flash drive. This menu item would only show up if there is >>>> usb support in the guest machine. >>>> >>>> Would you be open to accepting such a feature? >>> >>> Generally I'd expect this to be functionality exposed by the management >>> layer. For instance using virt-manager, this can be achived as follows: >>> Switch to "Details", then click "Add Hardware", choose "Storage" and >>> "USB" as the "Bus type". Choose the image, click "Finish", done. >> >> Isn't Libvirt only available on Linux? This mount image file feature would >> only be on Mac OS X. > > I'm not sure whether that sounds like a good idea, because then people > using bare qemu on Linux would complain that it isn't available with > Gtk. So if this was to be implemented, it would have to implemented > cross-platform (or at least in a way so it can be used cross-platform > later on). > >> Mac OS X users don't have all the fancy GUI wrappers >> for QEMU :( > > Good thing most GNU/Linux distributions are free. ;-) > > (sorry, could not resist) > >> Mac OS X is a second-class citizen in the QEMU world... > > Might have to do something with most (?) of it being non-free and Apple > not caring enough about KVM. > > (And without KVM, people in turn don't care enough about OS X as a qemu > host.) > > ((But all of that is pretty biased speculation, of course.)) > >>> The main problem I see with adding this functionality to qemu itself >>> would be having to get even further into the GUI business, which hasn't >>> worked out too well so far… >> >> That is because of several reasons. One being maintainers not wanting to >> advance the GUI because they feel another program should be QEMU's >> GUI. I'm sure there are plenty of good ideas that would advance QEMU's >> GUI. These ideas just need to be accepted into QEMU rather than put off. > > Another is that some people simply feel that qemu should focus on being > a backend than having to mess with frontend work, too. See the recent > discussion on the Gtk code setting the locale and thus breaking QMP for > an example why they have a point. > > I guess you'll better talk to Markus about this. :-) > > Quote: "We should've stayed out of the GUI business." > > (http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg03049.html) > >>> If we didn't care about that, than we'd have to think about the >>> implementation. Internally, we'd probably call QMP's blockdev-add to >>> open the image file, and then QMP's device_add to add the USB device. So >>> then qemu would use its own management interfaces to execute the >>> operation, which seems a bit strange to me, further hinting at the fact >>> that we probably should leave this to the management layer. >> >> What works does, and it isn't always as nice looking >> as we want it. I am sure we will use some kind of API to implement this >> feature. > > Having to deal with ugly legacy cruft from time to time, I don't know > whether "What works, works" is always appropriate. > >> I just wish there were an easy way to share files between the host and the >> guest. > > I don't think using emulated USB storage is the right way to do this, > though. Stefan is working on file sharing using NFS over virtio-vsock, > which seems more appropriate. But then again I don't whether > virtio-vsock will work with an OS X host… > > === > > OK, if you really want to implement it, I'm certainly not the right one > to stop you, so here is how I'd do it: > > My "BlockBackend and media" series rewrites the "change" HMP/QMP command > to be a macro, basically, that actually executes four lower-level QMP > commands. So this means we have a precedent of "macro" QMP commands, and > this could be extended. So you could add a "macro" QMP command > "usb-storage-insert-file" or something which executes blockdev-add + > device_add (if that works).* > > Then, if I felt really fancy, I'd add some layer which allows > generically executing QMP commands through the GUI, based on a whitelist > of commands. Each parameter would have to be requested through some GUI > interface, for instance, filenames would be queried through an > appropriate dialog. Ideally, this would be GUI-agnostic, but this may > not be reasonably possible. > > Then you'd whitelist usb-storage-insert-file (or however it is named), > give it some nice alias and you'd be done. > > While this would be much work I feel like this would actually be the > nicest solution. > > This is just a very rough outline, though, and since it somehow goes > against everything qemu's GUI was used for so far (just the most basic > things, basically nothing about controlling the VM except for > Pause/Shutdown/Reboot) I have no idea how it would be received. > > Max > > > *Actually you'd probably want a generic insert-storage-file which takes > the kind of storage device to add as a parameter.
I thought about using add_init_drive() found in device-hotplug.c, but it is private. Too bad. It looked perfect. https://wiki.ubuntu.com/QemuDiskHotplug#Hotplug_USB_Disk This page say talks about how to do it. This is what it said to do: drive_add 0 if=none,id=usbdisk1,file=/tmp/test.img Then device_add usb-storage,id=usbdisk1,drive=usbdisk1 I wasn't able to follow what you said. Do you think you could send me an example of how you think I should do the mounting of the image file?
