From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWVew-000251-K1 for qemu-devel@nongnu.org; Mon, 31 Aug 2015 16:26:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWVes-0005RH-HK for qemu-devel@nongnu.org; Mon, 31 Aug 2015 16:26:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWVes-0005RC-6m for qemu-devel@nongnu.org; Mon, 31 Aug 2015 16:26:26 -0400 References: <55E1D289.9000202@redhat.com> <55E1E03A.6060002@redhat.com> <89185148-279E-402F-8AC2-76FA97A1FD43@gmail.com> From: Max Reitz Message-ID: <55E4B86E.6090007@redhat.com> Date: Mon, 31 Aug 2015 22:26:22 +0200 MIME-Version: 1.0 In-Reply-To: <89185148-279E-402F-8AC2-76FA97A1FD43@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TeaFHCVmFWuskLAMsJp4OfHEBD7AoFldV" Subject: Re: [Qemu-devel] Mount image file feature List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid Cc: Peter Maydell , qemu-devel qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TeaFHCVmFWuskLAMsJp4OfHEBD7AoFldV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: >>> >>> 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 "Mo= unt >>>>> 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 mounte= d >>>>> 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 managem= ent >>>> layer. For instance using virt-manager, this can be achived as follo= ws: >>>> 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 Appl= e >> not caring enough about KVM. >> >> (And without KVM, people in turn don't care enough about OS X as a qem= u >> 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 has= n't >>>> worked out too well so far=85 >>> >>> 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 o= ff. >> >> Another is that some people simply feel that qemu should focus on bein= g >> 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 fo= r >> 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= =2E So >>>> then qemu would use its own management interfaces to execute the >>>> operation, which seems a bit strange to me, further hinting at the f= act >>>> 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 th= is 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 an= d 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=85 >> >> =3D=3D=3D >> >> OK, if you really want to implement it, I'm certainly not the right on= e >> to stop you, so here is how I'd do it: >> >> My "BlockBackend and media" series rewrites the "change" HMP/QMP comma= nd >> to be a macro, basically, that actually executes four lower-level QMP >> commands. So this means we have a precedent of "macro" QMP commands, a= nd >> 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 whiteli= st >> of commands. Each parameter would have to be requested through some GU= I >> 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 take= s >> 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? That was the "if that works" part. ;-) The following works for me: $ 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'}}}} {"return": {}} {'execute': 'device_add', 'arguments': {'driver': 'usb-storage', 'id': 'usb-disk', 'drive': 'usb-image'}} {"return": {}} In the VM, before device_add: # cat /dev/sda cat: /dev/sda: No such file or directory After device_add: # cat /dev/sda foo Unplugging the device can be done with device_del; but there is no blockdev-del yet, so the image file will remain lingering. Max --TeaFHCVmFWuskLAMsJp4OfHEBD7AoFldV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV5LhuAAoJEDuxQgLoOKytUGQIAJUm2G+7i0J4KpOlvbcUouYp gRkbP8HLScIEn8LvC1VyW91YZs/cApuz9KatNi+43AB0GGckU6txQkMUbg3bPRic lyBd42ovyqk6L/JOt8Mx293gZwZXz1THOcyZjoXOe5fJiD04hx0wu0/Sl1LKAwS9 Bm0QjZNsKJ7Aa7N1ZgLK6RHQxZ1ybsiZtK8y0eTTLvFKJeIMeP6rmw8c19riu30W Wd7rxrO8n8PD6xZa2TfoLxpYUuUoqLeMwuubLbrzMB5l6SuUvju06O7N4sJ1c9ou txIUOAK5xbgGMgz/f12QrrZysTPU70qHqfJGqlPmE4b9dsnmHN1ZsUiY7wHCloY= =Ga08 -----END PGP SIGNATURE----- --TeaFHCVmFWuskLAMsJp4OfHEBD7AoFldV--