From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWVmN-0004Cn-59 for qemu-devel@nongnu.org; Mon, 31 Aug 2015 16:34:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWVm1-0000mR-F2 for qemu-devel@nongnu.org; Mon, 31 Aug 2015 16:34:10 -0400 Received: from mail-qg0-x233.google.com ([2607:f8b0:400d:c04::233]:34418) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWVm1-0000m9-5B for qemu-devel@nongnu.org; Mon, 31 Aug 2015 16:33:49 -0400 Received: by qgtt94 with SMTP id t94so22540281qgt.1 for ; Mon, 31 Aug 2015 13:33:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Programmingkid In-Reply-To: <55E4B86E.6090007@redhat.com> Date: Mon, 31 Aug 2015 16:33:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <63FAA579-CD4E-455C-BE7D-30B79A8F7174@gmail.com> References: <55E1D289.9000202@redhat.com> <55E1E03A.6060002@redhat.com> <89185148-279E-402F-8AC2-76FA97A1FD43@gmail.com> <55E4B86E.6090007@redhat.com> Subject: Re: [Qemu-devel] Mount image file feature List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Peter Maydell , qemu-devel qemu-devel On Aug 31, 2015, at 4:26 PM, Max Reitz wrote: > On 31.08.2015 22:13, Programmingkid wrote: >>=20 >> On Aug 29, 2015, at 12:39 PM, Max Reitz wrote: >>=20 >>> On 29.08.2015 17:57, Programmingkid wrote: >>>>=20 >>>> On Aug 29, 2015, at 11:40 AM, Max Reitz wrote: >>>>=20 >>>>> 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. >>>>>>=20 >>>>>> Would you be open to accepting such a feature? >>>>>=20 >>>>> 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. >>>>=20 >>>> Isn't Libvirt only available on Linux? This mount image file = feature would >>>> only be on Mac OS X. >>>=20 >>> 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). >>>=20 >>>> Mac OS X users don't have all the fancy GUI wrappers >>>> for QEMU :( >>>=20 >>> Good thing most GNU/Linux distributions are free. ;-) >>>=20 >>> (sorry, could not resist) >>>=20 >>>> Mac OS X is a second-class citizen in the QEMU world... >>>=20 >>> Might have to do something with most (?) of it being non-free and = Apple >>> not caring enough about KVM. >>>=20 >>> (And without KVM, people in turn don't care enough about OS X as a = qemu >>> host.) >>>=20 >>> ((But all of that is pretty biased speculation, of course.)) >>>=20 >>>>> 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=85 >>>>=20 >>>> That is because of several reasons. One being maintainers not = wanting to >>>> advance the GUI because they feel another program should be QEMU's=20= >>>> 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. >>>=20 >>> 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. >>>=20 >>> I guess you'll better talk to Markus about this. :-) >>>=20 >>> Quote: "We should've stayed out of the GUI business." >>>=20 >>> = (http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg03049.html) >>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>=20 >>> Having to deal with ugly legacy cruft from time to time, I don't = know >>> whether "What works, works" is always appropriate. >>>=20 >>>> I just wish there were an easy way to share files between the host = and the guest. >>>=20 >>> 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=85 >>>=20 >>> =3D=3D=3D >>>=20 >>> 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: >>>=20 >>> 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).* >>>=20 >>> 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. >>>=20 >>> Then you'd whitelist usb-storage-insert-file (or however it is = named), >>> give it some nice alias and you'd be done. >>>=20 >>> While this would be much work I feel like this would actually be the >>> nicest solution. >>>=20 >>> 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. >>>=20 >>> Max >>>=20 >>>=20 >>> *Actually you'd probably want a generic insert-storage-file which = takes >>> the kind of storage device to add as a parameter. >>=20 >> I thought about using add_init_drive() found in device-hotplug.c,=20 >> but it is private. Too bad. It looked perfect. =20 >>=20 >> https://wiki.ubuntu.com/QemuDiskHotplug#Hotplug_USB_Disk >> This page say talks about how to do it. This is what it said to do: >>=20 >> drive_add 0 if=3Dnone,id=3Dusbdisk1,file=3D/tmp/test.img >>=20 >> Then >>=20 >> device_add usb-storage,id=3Dusbdisk1,drive=3Dusbdisk1 >>=20 >> 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? >=20 > That was the "if that works" part. ;-) >=20 > The following works for me: >=20 > $ echo foo > bar > $ x86_64-softmmu/qemu-system-x86_64 -qmp stdio -usb -cdrom > ~/tmp/archlinux-2015.07.01-dual.iso -enable-kvm -m 512 > {"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2}, > "package": ""}, "capabilities": []}} > {'execute': 'qmp_capabilities'} > {"return": {}} > {'execute': 'blockdev-add', 'arguments': {'options': {'id': = 'usb-image', > 'driver': 'raw', 'file': {'driver': 'file', 'filename': 'bar'}}}} >=20 > {"return": {}} > {'execute': 'device_add', 'arguments': {'driver': 'usb-storage', 'id': > 'usb-disk', 'drive': 'usb-image'}} > {"return": {}} >=20 > In the VM, before device_add: > # cat /dev/sda > cat: /dev/sda: No such file or directory >=20 > After device_add: > # cat /dev/sda > foo Is there a function that the GUI could call to send all of the JSON code = as the argument to execute.=20 > Unplugging the device can be done with device_del; but there is no > blockdev-del yet, so the image file will remain lingering. If the user decided to use the same image file again, would that be = possible? What about handle_hmp_command() in monitor.c. Would it be ok to send commands to execute?=