[Qemu-devel] Mount image file feature

[Qemu-devel] Mount image file feature

[G 3]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 556 bytes --]

Re: [Qemu-devel] Mount image file feature

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

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.

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…

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.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

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. Mac OS X users don't have all the fancy GUI wrappers
for QEMU :( 

Mac OS X is a second-class citizen in the QEMU world...

> 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.

> 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. 

I just wish there were an easy way to share files between the host and the guest. 

Re: [Qemu-devel] Mount image file feature

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 5315 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

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).

If making QEMU more user-friendly is a crime, I plead guilty!

I'm not a Linux user. I am a proud Macintosh user. We Mac users
like our software easy to use. I know this goes against the Linux
way of life. That is why this patch would only work on Mac OS X. 
This will keep QEMU on Linux hard to use... just the way you guys
like it.

> 
>> 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)

....lolz

But on the other hand, you get what you pay for.

> 
>> 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.

Fact, Apple has made an hypervisor API available as of Mac OS 10.10, so who
knows. Maybe in the future someone will implement KVM support on Mac OS X.

Fact, Apple now gives away Mac OS X for free. Yes I know, it is only for Apple-only
hardware still. 

> 
> (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.))

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.

We can have both. Command-line options are there that can turn on or off the GUI. 
Example: --disable-gtk.

Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing stuff like
freezing and restoring a session would be awesome and a real time saver.

> 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)

That is totally fine for the Linux users. If they want to use the command-line only, 
let them. They are only hurting themselves :)

> 
>>> 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.

Public API's are what I will try to use. 

> 
>> 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…

Probably wouldn't work, but who knows. If the emulated network card did work on
Mac OS X, then maybe ftp sharing would be possible. Then again QEMU does
have that USB network card. That might work. 

> 
> ===
> 
> 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 will have to examine this information more, but thank you very much for helping.
Who knows, maybe someone might port this feature to GTK. 

Re: [Qemu-devel] Mount image file feature

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 9721 bytes --]

On 29.08.2015 19:36, Programmingkid wrote:
> 
> 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).
> 
> If making QEMU more user-friendly is a crime, I plead guilty!

Yes, in some people's eyes it is a crime because they say qemu should
rather be machine-friendly. User-friendliness is always expensive,
difficult to maintain, and a neverending source of complaints.

So while it is always a nice thing to have, it comes at a hefty price.

> I'm not a Linux user. I am a proud Macintosh user. We Mac users
> like our software easy to use. I know this goes against the Linux
> way of life. That is why this patch would only work on Mac OS X. 
> This will keep QEMU on Linux hard to use... just the way you guys
> like it.

Erm, well, I think I won't reply to that other than *cough* virt-manager
*cough*.

>>> 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)
> 
> ....lolz
> 
> But on the other hand, you get what you pay for.

Working qemu/KVM with a nice management layer on top of it?

>>> 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.
> 
> Fact, Apple has made an hypervisor API available as of Mac OS 10.10, so who
> knows. Maybe in the future someone will implement KVM support on Mac OS X.

As far as I know, someone even managed to create a proof-of-concept
implementation of KVM for Windows. Of course it's possible, but it isn't
there yet, and I was just explaining a possible reason why there aren't
(which I'm assuming from what you told me) any nice user-friendly and
feature-rich qemu management tools for OS X.

> Fact, Apple now gives away Mac OS X for free. Yes I know, it is only for Apple-only
> hardware still.

Then you know it's not free.

Also, here I meant "free" as in "freedom", not "free" as in "beer". I
don't know how much of OS X is free software. I know the kernel is, but
most of the things above it aren't, as far as I remember. So that's why
I don't know whether it would actually be reasonably possible for anyone
outside Apple to develop a supported KVM host module.

>> (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.))
> 
> Of course...

Yep, since this is a well-tested flamewar topic, of course it is.

My point wasn't to make OS X look bad. My point was to explain why OS X
is a second-class citizen in the qemu world, and I feel like there is a
very good reason for it, and that simply is missing KVM support.

Another reason is probably that most of the active qemu developers are
paid to focus on Linux-related things.

>>>> 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.
> 
> We can have both. Command-line options are there that can turn on or off the GUI. 
> Example: --disable-gtk.
> 
> Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing stuff like
> freezing and restoring a session would be awesome and a real time saver.

Might be trivially possible with the things I described, since there is
HMP's savevm/loadvm.

On the other hand, I don't think you'll find (m)any friends for making
qemu's GUI as feature-rich as VBox's. There have long been
"non-invasive" GUIs for managing qemu VMs (such as qtemu), so this isn't
some recent development.

Maybe I can get you interested in writing a management application for
OS X? I do not think that would be more difficult than plugging these
features directly into qemu, and I think everyone would like that idea.
As an OS X user, there shouldn't be any visible difference; and all
non-OS-X users would not have any reason to complain.

Because, as much as you may think this is worthless to hear, what you
are describing is exactly what virt-manager offers.

>> 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)
> 
> That is totally fine for the Linux users. If they want to use the command-line only, 
> let them. They are only hurting themselves :)

Again, that is not necessarily true. For VMs where I want to get stuff
done, I use libvirt and virt-manager.

Max

>>>> 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.
> 
> Public API's are what I will try to use. 
> 
>>
>>> 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…
> 
> Probably wouldn't work, but who knows. If the emulated network card did work on
> Mac OS X, then maybe ftp sharing would be possible. Then again QEMU does
> have that USB network card. That might work. 
> 
>>
>> ===
>>
>> 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 will have to examine this information more, but thank you very much for helping.
> Who knows, maybe someone might port this feature to GTK. 
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Mount image file feature

[MagicCat Software]

On Aug 29, 2015, at 2:01 PM, Max Reitz wrote:

> On 29.08.2015 19:36, Programmingkid wrote:
>> 
>> 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).
>> 
>> If making QEMU more user-friendly is a crime, I plead guilty!
> 
> Yes, in some people's eyes it is a crime because they say qemu should
> rather be machine-friendly.

These people have the mentality of terminator robots. 

> User-friendliness is always expensive,
> difficult to maintain, and a neverending source of complaints.

Really? It has been months since Peter Maydell implemented my GUI patches
for the cocoa interface, and I haven't seen a complaint about it yet.

> So while it is always a nice thing to have, it comes at a hefty price.

If programmers follow good programming practices, the code should be
pretty much maintenance free. But I do understand that public API's do
change over time. 

> 
>> I'm not a Linux user. I am a proud Macintosh user. We Mac users
>> like our software easy to use. I know this goes against the Linux
>> way of life. That is why this patch would only work on Mac OS X. 
>> This will keep QEMU on Linux hard to use... just the way you guys
>> like it.
> 
> Erm, well, I think I won't reply to that other than *cough* virt-manager
> *cough*.

Linux exclusive probably.

> 
>>>> 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)
>> 
>> ....lolz
>> 
>> But on the other hand, you get what you pay for.
> 
> Working qemu/KVM with a nice management layer on top of it?

Linux has a few advantages.

> 
>>>> 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.
>> 
>> Fact, Apple has made an hypervisor API available as of Mac OS 10.10, so who
>> knows. Maybe in the future someone will implement KVM support on Mac OS X.
> 
> As far as I know, someone even managed to create a proof-of-concept
> implementation of KVM for Windows. Of course it's possible, but it isn't
> there yet, and I was just explaining a possible reason why there aren't
> (which I'm assuming from what you told me) any nice user-friendly and
> feature-rich qemu management tools for OS X.
> 
>> Fact, Apple now gives away Mac OS X for free. Yes I know, it is only for Apple-only
>> hardware still.
> 
> Then you know it's not free.

Point.

> 
> Also, here I meant "free" as in "freedom", not "free" as in "beer". I
> don't know how much of OS X is free software. I know the kernel is, but
> most of the things above it aren't, as far as I remember. So that's why
> I don't know whether it would actually be reasonably possible for anyone
> outside Apple to develop a supported KVM host module.
> 
>>> (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.))
>> 
>> Of course...
> 
> Yep, since this is a well-tested flamewar topic, of course it is.
> 
> My point wasn't to make OS X look bad. My point was to explain why OS X
> is a second-class citizen in the qemu world, and I feel like there is a
> very good reason for it, and that simply is missing KVM support.
> 
> Another reason is probably that most of the active qemu developers are
> paid to focus on Linux-related things.
> 
>>>>> 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.
>> 
>> We can have both. Command-line options are there that can turn on or off the GUI. 
>> Example: --disable-gtk.
>> 
>> Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing stuff like
>> freezing and restoring a session would be awesome and a real time saver.
> 
> Might be trivially possible with the things I described, since there is
> HMP's savevm/loadvm.

It is just a few patches away from working well.

> On the other hand, I don't think you'll find (m)any friends for making
> qemu's GUI as feature-rich as VBox's. There have long been
> "non-invasive" GUIs for managing qemu VMs (such as qtemu), so this isn't
> some recent development.

Probably true. 

> 
> Maybe I can get you interested in writing a management application for
> OS X? I do not think that would be more difficult than plugging these
> features directly into qemu, and I think everyone would like that idea.
> As an OS X user, there shouldn't be any visible difference; and all
> non-OS-X users would not have any reason to complain.

Part of making QEMU easier for the user is not having to install more software.
If everything came with in one package, that would be a blessing. 

> Because, as much as you may think this is worthless to hear, what you
> are describing is exactly what virt-manager offers.

Maybe someone might port Virt-manager to other platforms. Shouldn't be too
difficult. It probably uses multi-platform libraries like GTK.

> 
>>> 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)
>> 
>> That is totally fine for the Linux users. If they want to use the command-line only, 
>> let them. They are only hurting themselves :)
> 
> Again, that is not necessarily true. For VMs where I want to get stuff
> done, I use libvirt and virt-manager.
> 
> Max
> 
>>>>> 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.
>> 
>> Public API's are what I will try to use. 
>> 
>>> 
>>>> 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…
>> 
>> Probably wouldn't work, but who knows. If the emulated network card did work on
>> Mac OS X, then maybe ftp sharing would be possible. Then again QEMU does
>> have that USB network card. That might work. 
>> 
>>> 
>>> ===
>>> 
>>> 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 will have to examine this information more, but thank you very much for helping.
>> Who knows, maybe someone might port this feature to GTK. 
>> 
> 
> 

Re: [Qemu-devel] Mount image file feature

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 5388 bytes --]

On 29.08.2015 20:34, MagicCat Software wrote:
> 
> On Aug 29, 2015, at 2:01 PM, Max Reitz wrote:
> 
>> On 29.08.2015 19:36, Programmingkid wrote:
>>>
>>> On Aug 29, 2015, at 12:39 PM, Max Reitz wrote:

[snip]

>>> If making QEMU more user-friendly is a crime, I plead guilty!
>>
>> Yes, in some people's eyes it is a crime because they say qemu should
>> rather be machine-friendly.
> 
> These people have the mentality of terminator robots.

Just want to add that by "machine-friendly" I meant "friendly to an
upper management layer who will be really, really nice to the user".

>> User-friendliness is always expensive,
>> difficult to maintain, and a neverending source of complaints.
> 
> Really? It has been months since Peter Maydell implemented my GUI patches
> for the cocoa interface, and I haven't seen a complaint about it yet.

By definition, a user interface is something the user interacts with.
People are prone to complain about things they interact with which
aren't to their exact liking.

What I mean to say is that humans are more complex than machines. It's
much more difficult to please a human than to please libvirt. I guess.

> 
>> So while it is always a nice thing to have, it comes at a hefty price.
> 
> If programmers follow good programming practices, the code should be
> pretty much maintenance free.

[citation needed]

> But I do understand that public API's do
> change over time. 
> 
>>
>>> I'm not a Linux user. I am a proud Macintosh user. We Mac users
>>> like our software easy to use. I know this goes against the Linux
>>> way of life. That is why this patch would only work on Mac OS X. 
>>> This will keep QEMU on Linux hard to use... just the way you guys
>>> like it.
>>
>> Erm, well, I think I won't reply to that other than *cough* virt-manager
>> *cough*.
> 
> Linux exclusive probably.

Your point?

You said applications on Linux are generally more difficult to use than
comparable applications on OS X, by design. I said "Well, there's
virt-manager." You say it's available only on Linux. So how does that
make qemu on Linux more difficult to use than on OS X?

>>>>> 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)
>>>
>>> ....lolz
>>>
>>> But on the other hand, you get what you pay for.
>>
>> Working qemu/KVM with a nice management layer on top of it?
> 
> Linux has a few advantages.

Which don't really matter here, because this thread should really not be
about which OS is better (which is a rather pointless question and even
more so on the qemu mailing list).

The point why I brought up libvirt and virt-manager is simply that those
tools do exactly what you want qemu to do. The ratio of how much GUI
work we do and how much work we do to have qemu interact nicely with
libvirt shows to me very clearly that our current direction is to
separate the frontend (libvirt + GUI) from the backend (qemu).

It's a pity that libvirt is not available for OS X, but in my humble
opinion that's libvirt's fault and not qemu's. Putting features into
qemu we apparently decided to leave to libvirt and any management
application on top of it doesn't seem quite right.

[snip]

>>> Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing stuff like
>>> freezing and restoring a session would be awesome and a real time saver.
>>
>> Might be trivially possible with the things I described, since there is
>> HMP's savevm/loadvm.
> 
> It is just a few patches away from working well.
> 
>> On the other hand, I don't think you'll find (m)any friends for making
>> qemu's GUI as feature-rich as VBox's. There have long been
>> "non-invasive" GUIs for managing qemu VMs (such as qtemu), so this isn't
>> some recent development.
> 
> Probably true. 
> 
>>
>> Maybe I can get you interested in writing a management application for
>> OS X? I do not think that would be more difficult than plugging these
>> features directly into qemu, and I think everyone would like that idea.
>> As an OS X user, there shouldn't be any visible difference; and all
>> non-OS-X users would not have any reason to complain.
> 
> Part of making QEMU easier for the user is not having to install more software.
> If everything came with in one package, that would be a blessing.

I don't know how installing software works under OS X, but as far as I
can recall, it was pretty similar to most Linux distributions in that
there are package managers. So you'd install the frontend your heart
desires and it'd pull in qemu as a dependency. Sometimes package
managers support optional dependencies, too. So one of qemu's optional
dependencies might be your frontend. Alternatively, your frontend could
just be part of the qemu package.

Other than that, the difficulty of having to install two packages
instead of one doesn't quite strike me as a good argument.

>> Because, as much as you may think this is worthless to hear, what you
>> are describing is exactly what virt-manager offers.
> 
> Maybe someone might port Virt-manager to other platforms. Shouldn't be too
> difficult. It probably uses multi-platform libraries like GTK.

The thing is that it works on top of libvirt.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Mount image file feature

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

On 29.08.2015 20:34, MagicCat Software wrote:
> 
> On Aug 29, 2015, at 2:01 PM, Max Reitz wrote:

[snip]

>> User-friendliness is always expensive,
>> difficult to maintain, and a neverending source of complaints.
> 
> Really? It has been months since Peter Maydell implemented my GUI patches
> for the cocoa interface, and I haven't seen a complaint about it yet.

I just looked into it, and without having an OS X to test it on I have a
few things to complain about:

(1) 'change' always uses 'raw' as the format, but the selector
apparently offers you the full range of image formats
(supportedImageFileTypes).

(2) I think it should be possible to add block devices with removable
media at runtime (I didn't try, though), and also remove them. The
current code doesn't account for that.

(3) supportedImageFileTypes is static. The list might change at any time
and the likelihood of people adding or removing formats there when
adding/removing them to/from the block layer itself is pretty low. Also,
the list depends on compile and (in the future at least) maybe even
runtime options. For instance, it's missing vdi, vhd (vpc), and vhdx.
vhdx in turn can be disabled at compile time.

(4) NSBeep()? Is that necessary? Won't the alert itself be audible if so
desired by the user?

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Aug 29, 2015, at 3:34 PM, Max Reitz wrote:

> On 29.08.2015 20:34, MagicCat Software wrote:
>> 
>> On Aug 29, 2015, at 2:01 PM, Max Reitz wrote:
>> 
>>> On 29.08.2015 19:36, Programmingkid wrote:
>>>> 
>>>> On Aug 29, 2015, at 12:39 PM, Max Reitz wrote:
> 
> [snip]
> 
>>>> If making QEMU more user-friendly is a crime, I plead guilty!
>>> 
>>> Yes, in some people's eyes it is a crime because they say qemu should
>>> rather be machine-friendly.
>> 
>> These people have the mentality of terminator robots.
> 
> Just want to add that by "machine-friendly" I meant "friendly to an
> upper management layer who will be really, really nice to the user".
> 
>>> User-friendliness is always expensive,
>>> difficult to maintain, and a neverending source of complaints.
>> 
>> Really? It has been months since Peter Maydell implemented my GUI patches
>> for the cocoa interface, and I haven't seen a complaint about it yet.
> 
> By definition, a user interface is something the user interacts with.
> People are prone to complain about things they interact with which
> aren't to their exact liking.

But that doesn't mean we just give up. I think this means we should challenge
ourselves to be better.

> 
> What I mean to say is that humans are more complex than machines. It's
> much more difficult to please a human than to please libvirt. I guess.
> 
>> 
>>> So while it is always a nice thing to have, it comes at a hefty price.
>> 
>> If programmers follow good programming practices, the code should be
>> pretty much maintenance free.
> 
> [citation needed]
> 
>> But I do understand that public API's do
>> change over time. 
>> 
>>> 
>>>> I'm not a Linux user. I am a proud Macintosh user. We Mac users
>>>> like our software easy to use. I know this goes against the Linux
>>>> way of life. That is why this patch would only work on Mac OS X. 
>>>> This will keep QEMU on Linux hard to use... just the way you guys
>>>> like it.
>>> 
>>> Erm, well, I think I won't reply to that other than *cough* virt-manager
>>> *cough*.
>> 
>> Linux exclusive probably.
> 
> Your point?
> 
> You said applications on Linux are generally more difficult to use than
> comparable applications on OS X, by design. I said "Well, there's
> virt-manager." You say it's available only on Linux. So how does that
> make qemu on Linux more difficult to use than on OS X?

It doesn't make QEMU more difficult to use on Linux. I was just saying this
virt-manager sounds like a good program to have, but isn't available to
Mac OS X users. 

> 
>>>>>> 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)
>>>> 
>>>> ....lolz
>>>> 
>>>> But on the other hand, you get what you pay for.
>>> 
>>> Working qemu/KVM with a nice management layer on top of it?
>> 
>> Linux has a few advantages.
> 
> Which don't really matter here, because this thread should really not be
> about which OS is better (which is a rather pointless question and even
> more so on the qemu mailing list).
> 
> The point why I brought up libvirt and virt-manager is simply that those
> tools do exactly what you want qemu to do. The ratio of how much GUI
> work we do and how much work we do to have qemu interact nicely with
> libvirt shows to me very clearly that our current direction is to
> separate the frontend (libvirt + GUI) from the backend (qemu).

This philosophy doesn't have to be universal. There might be Linux
users who don't want to use virt-manager but who still want a
nice GUI to use. Lets give the user the power to decide what
GUI to use.

> 
> It's a pity that libvirt is not available for OS X, but in my humble
> opinion that's libvirt's fault and not qemu's. Putting features into
> qemu we apparently decided to leave to libvirt and any management
> application on top of it doesn't seem quite right.

It doesn't seem quite right to the GTK-Linux people, but it perfectly ok with the
cocoa-Macintosh people. Who wouldn't like the idea of making QEMU more
user-friendly. Right now in order to move files between guest and host, the user
has to depend on using an image file as a hard drive. That means shutting down
and restarting the guest a lot. Not fun. The feature I propose would make rebooting
the guest a thing of the past. QEMU would be a lot more robust.

> 
> [snip]
> 
>>>> Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing stuff like
>>>> freezing and restoring a session would be awesome and a real time saver.
>>> 
>>> Might be trivially possible with the things I described, since there is
>>> HMP's savevm/loadvm.
>> 
>> It is just a few patches away from working well.
>> 
>>> On the other hand, I don't think you'll find (m)any friends for making
>>> qemu's GUI as feature-rich as VBox's. There have long been
>>> "non-invasive" GUIs for managing qemu VMs (such as qtemu), so this isn't
>>> some recent development.
>> 
>> Probably true. 
>> 
>>> 
>>> Maybe I can get you interested in writing a management application for
>>> OS X? I do not think that would be more difficult than plugging these
>>> features directly into qemu, and I think everyone would like that idea.
>>> As an OS X user, there shouldn't be any visible difference; and all
>>> non-OS-X users would not have any reason to complain.
>> 
>> Part of making QEMU easier for the user is not having to install more software.
>> If everything came with in one package, that would be a blessing.
> 
> I don't know how installing software works under OS X, but as far as I
> can recall, it was pretty similar to most Linux distributions in that
> there are package managers. So you'd install the frontend your heart
> desires and it'd pull in qemu as a dependency. Sometimes package
> managers support optional dependencies, too. So one of qemu's optional
> dependencies might be your frontend. Alternatively, your frontend could
> just be part of the qemu package.

Installing software on Mac OS X is done by simply using a .dmg file and
the default installer application. The user just pushes the install button and
that's it.

> 
> Other than that, the difficulty of having to install two packages
> instead of one doesn't quite strike me as a good argument.

Less stuff to have to install means less of a headache for the user.

> 
>>> Because, as much as you may think this is worthless to hear, what you
>>> are describing is exactly what virt-manager offers.
>> 
>> Maybe someone might port Virt-manager to other platforms. Shouldn't be too
>> difficult. It probably uses multi-platform libraries like GTK.
> 
> The thing is that it works on top of libvirt.

Oh. Then it would be harder to port Virt-manager.

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Aug 29, 2015, at 3:52 PM, Max Reitz wrote:

> On 29.08.2015 20:34, MagicCat Software wrote:
>> 
>> On Aug 29, 2015, at 2:01 PM, Max Reitz wrote:
> 
> [snip]
> 
>>> User-friendliness is always expensive,
>>> difficult to maintain, and a neverending source of complaints.
>> 
>> Really? It has been months since Peter Maydell implemented my GUI patches
>> for the cocoa interface, and I haven't seen a complaint about it yet.
> 
> I just looked into it, and without having an OS X to test it on I have a
> few things to complain about:
> 
> (1) 'change' always uses 'raw' as the format, but the selector
> apparently offers you the full range of image formats
> (supportedImageFileTypes).

So far it has worked out just fine. Doesn't QEMU detect the format itself?
If I didn't use raw, what would I use? Is the file extension also the format type?

> (2) I think it should be possible to add block devices with removable
> media at runtime (I didn't try, though), and also remove them. The
> current code doesn't account for that.

I think block devices should be used also. I use to have a menu item called "Use real CDROM" in the 
machine menu. I will bring it back soon. 

QEMU booting up a real hard drive partition? Definitely!

> (3) supportedImageFileTypes is static. The list might change at any time
> and the likelihood of people adding or removing formats there when
> adding/removing them to/from the block layer itself is pretty low. Also,
> the list depends on compile and (in the future at least) maybe even
> runtime options. For instance, it's missing vdi, vhd (vpc), and vhdx.
> vhdx in turn can be disabled at compile time.

I have no problem adding these missing file types.

> 
> (4) NSBeep()? Is that necessary? Won't the alert itself be audible if so
> desired by the user?


Well, alert boxes don't make a sound when they show up. I just wanted to make
sure I caught the user's attention. To answer your question, we don't need NSBeep().

Re: [Qemu-devel] Mount image file feature

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

On 08/29/2015 11:36 AM, Programmingkid wrote:

>>
>>> 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.
> 
> Fact, Apple has made an hypervisor API available as of Mac OS 10.10, so who
> knows. Maybe in the future someone will implement KVM support on Mac OS X.
> 
> Fact, Apple now gives away Mac OS X for free. Yes I know, it is only for Apple-only
> hardware still. 

No monetary cost is not the same as free.  Where can I get the source
code without being forced to agree to a non-free license, or forced to
buy particular hardware?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] Mount image file feature

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

On 08/29/2015 01:34 PM, Max Reitz wrote:

>>> Erm, well, I think I won't reply to that other than *cough* virt-manager
>>> *cough*.
>>
>> Linux exclusive probably.
> 
> Your point?
> 
> You said applications on Linux are generally more difficult to use than
> comparable applications on OS X, by design. I said "Well, there's
> virt-manager." You say it's available only on Linux. So how does that
> make qemu on Linux more difficult to use than on OS X?

virt-manager is designed to be cross-platform compatible, and it IS
ported to Windows. If the port to Mac OS doesn't already work out of the
box, then I'm sure the virt-manager community would love patches.  And
THAT is the gui app of choice for dealing with VMs in a cross-platform
manager, since virt-manager IS a gui.  But this is not the virt-manager
mailing list.  Here, in the lower-level qemu, we focus on providing the
machine-friendly knobs, so that higher-level apps like libvirt, and on
top of that virt-manager, can expose a nice gui that uses those knobs.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] Mount image file feature

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

On 08/29/2015 02:18 PM, Programmingkid wrote:

>>
>> (1) 'change' always uses 'raw' as the format, but the selector
>> apparently offers you the full range of image formats
>> (supportedImageFileTypes).
> 
> So far it has worked out just fine. Doesn't QEMU detect the format itself?

You DON'T want to rely on qemu detecting the format itself.  That is a
CVE waiting to happen.  If you hand a raw disk to the guest, and the
guest writes particular metadata to resemble some other format, and then
qemu probes that other format, you have allowed the guest to take over
the host.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Aug 29, 2015, at 7:12 PM, Eric Blake wrote:

> On 08/29/2015 02:18 PM, Programmingkid wrote:
> 
>>> 
>>> (1) 'change' always uses 'raw' as the format, but the selector
>>> apparently offers you the full range of image formats
>>> (supportedImageFileTypes).
>> 
>> So far it has worked out just fine. Doesn't QEMU detect the format itself?
> 
> You DON'T want to rely on qemu detecting the format itself.  That is a
> CVE waiting to happen.  If you hand a raw disk to the guest, and the
> guest writes particular metadata to resemble some other format, and then
> qemu probes that other format, you have allowed the guest to take over
> the host.

What is the answer? How do we know what to use in place of "raw"?

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Aug 29, 2015, at 7:10 PM, Eric Blake wrote:

> On 08/29/2015 01:34 PM, Max Reitz wrote:
> 
>>>> Erm, well, I think I won't reply to that other than *cough* virt-manager
>>>> *cough*.
>>> 
>>> Linux exclusive probably.
>> 
>> Your point?
>> 
>> You said applications on Linux are generally more difficult to use than
>> comparable applications on OS X, by design. I said "Well, there's
>> virt-manager." You say it's available only on Linux. So how does that
>> make qemu on Linux more difficult to use than on OS X?
> 
> virt-manager is designed to be cross-platform compatible, and it IS
> ported to Windows. If the port to Mac OS doesn't already work out of the
> box, then I'm sure the virt-manager community would love patches.  And
> THAT is the gui app of choice for dealing with VMs in a cross-platform
> manager, since virt-manager IS a gui.  But this is not the virt-manager
> mailing list.  Here, in the lower-level qemu, we focus on providing the
> machine-friendly knobs, so that higher-level apps like libvirt, and on
> top of that virt-manager, can expose a nice gui that uses those knobs.

I just tried using Virt-manager in Mac OS X. It definitely appears to be Linux only. 
The source code doesn't even have a configure script. Sorry.

I do wish it worked on Mac OS X.

Re: [Qemu-devel] Mount image file feature

[MagicCat Software]

On Aug 29, 2015, at 7:04 PM, Eric Blake wrote:

> On 08/29/2015 11:36 AM, Programmingkid wrote:
> 
>>> 
>>>> 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.
>> 
>> Fact, Apple has made an hypervisor API available as of Mac OS 10.10, so who
>> knows. Maybe in the future someone will implement KVM support on Mac OS X.
>> 
>> Fact, Apple now gives away Mac OS X for free. Yes I know, it is only for Apple-only
>> hardware still. 
> 
> No monetary cost is not the same as free.  Where can I get the source
> code without being forced to agree to a non-free license, or forced to
> buy particular hardware?

Apple employees need to eat also. :)

Re: [Qemu-devel] Mount image file feature

[Paolo Bonzini]

On 29/08/2015 18:39, Max Reitz wrote:
>> 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.))

I don't think it's speculation.  The Win32 port can be developed with
cross-compilers and Wine.  Mac OS X cannot.  KVM is not particularly
important factor in the picture.

Paolo

Re: [Qemu-devel] Mount image file feature

[Paolo Bonzini]

On 29/08/2015 19:36, Programmingkid wrote:
> > > 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.
> 
> Fact, Apple has made an hypervisor API available as of Mac OS 10.10, so who
> knows. Maybe in the future someone will implement KVM support on Mac OS X.

Yes, that's nice.

I'm all for better Mac OS X support, and personally I think that
implementing a virt-manager-like GUI for Mac OS X is fine.  But it's a
large work, and you shouldn't be surprised if few people can help you,
if doing so requires spending a thousand euros/dollars for a new computer.

Paolo

Re: [Qemu-devel] Mount image file feature

[Paolo Bonzini]

On 30/08/2015 02:02, Programmingkid wrote:
>> > virt-manager is designed to be cross-platform compatible, and it IS
>> > ported to Windows. If the port to Mac OS doesn't already work out of the
>> > box, then I'm sure the virt-manager community would love patches.  And
>> > THAT is the gui app of choice for dealing with VMs in a cross-platform
>> > manager, since virt-manager IS a gui.  But this is not the virt-manager
>> > mailing list.  Here, in the lower-level qemu, we focus on providing the
>> > machine-friendly knobs, so that higher-level apps like libvirt, and on
>> > top of that virt-manager, can expose a nice gui that uses those knobs.
> I just tried using Virt-manager in Mac OS X. It definitely appears to be Linux only. 
> The source code doesn't even have a configure script. Sorry.

That doesn't matter.  It's written in Python, it doesn't need a
configure script.

I think virt-manager might work on Mac OS X, but only to connect to
virtual machines running remotely on a Linux machine.  virt-manager
relies on libvirtd running on the same machine as the guest, and
libvirtd is definitely Linux only.

Paolo

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Aug 30, 2015, at 2:47 AM, Paolo Bonzini wrote:

> 
> 
> On 29/08/2015 19:36, Programmingkid wrote:
>>>> 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.
>> 
>> Fact, Apple has made an hypervisor API available as of Mac OS 10.10, so who
>> knows. Maybe in the future someone will implement KVM support on Mac OS X.
> 
> Yes, that's nice.
> 
> I'm all for better Mac OS X support, and personally I think that
> implementing a virt-manager-like GUI for Mac OS X is fine.  But it's a
> large work, and you shouldn't be surprised if few people can help you,
> if doing so requires spending a thousand euros/dollars for a new computer.

It looks like Virt-Manager is out of the question. So going back to the original 
topic, can this "Mount Image File" feature be added to the cocoa interface?

Re: [Qemu-devel] Mount image file feature

[Markus Armbruster]

Programmingkid <magiccatsoftware@gmail.com> writes:

> 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).
>
> If making QEMU more user-friendly is a crime, I plead guilty!
>
> I'm not a Linux user. I am a proud Macintosh user. We Mac users
> like our software easy to use. I know this goes against the Linux
> way of life. That is why this patch would only work on Mac OS X. 
> This will keep QEMU on Linux hard to use... just the way you guys
> like it.

I think you've used up your "speculation on what Linux users like" quota
on this list for 2015.  Now let's get back on topic.

[More snipped...]

>>>> 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.
>
> We can have both. Command-line options are there that can turn on or
> off the GUI.
> Example: --disable-gtk.
>
> Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing stuff like
> freezing and restoring a session would be awesome and a real time saver.
>
>> 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)
>
> That is totally fine for the Linux users. If they want to use the
> command-line only,
> let them. They are only hurting themselves :)

You're attacking a strawman.  Nobody is arguing against having a nice
GUI.  My argument is that one application trying to do everything tends
to result in the application doing most of it badly.

Case in point: QEMU tries to be the low-level user space plumbing for
virtualization, and machine emulation, and GUI.  Even just the first two
create tension by having different requirements, but at least they take
quite similar kinds of expertise.  GUI is a quite different business.

I think we should focus on what really, really needs to be done in QEMU.
GUI can and should be layered on top.

I'm not going to oppose improvements to the built-in GUI just because of
my opinion on the wisdom of having a built-in GUI.  I am, however, quite
critical of such efforts distracting us from our core job.

Patches to improve the GUI that don't touch non-GUI code: hash it out
with the relevant maintainer.  Balancing distraction against utility is
his job, not mine.

Non-GUI patches you want for GUI work that can stand on their own as
contributions to our core job: sounds useful, thanks!

Non-GUI patches that don't contribute to our core job: rejecting small
and simple ones is probably more distraction than taking them, but I'd
advise against big ones.  The relevant maintainers may have different
opinions, of course, and they decide.


[...]

Re: [Qemu-devel] Mount image file feature

[Markus Armbruster]

MagicCat Software <magiccatsoftware@gmail.com> writes:

> On Aug 29, 2015, at 7:04 PM, Eric Blake wrote:
>
>> On 08/29/2015 11:36 AM, Programmingkid wrote:
>> 
>>>> 
>>>>> 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.
>>> 
>>> Fact, Apple has made an hypervisor API available as of Mac OS 10.10, so who
>>> knows. Maybe in the future someone will implement KVM support on Mac OS X.
>>> 
>>> Fact, Apple now gives away Mac OS X for free. Yes I know, it is
>>> only for Apple-only
>>> hardware still. 
>> 
>> No monetary cost is not the same as free.  Where can I get the source
>> code without being forced to agree to a non-free license, or forced to
>> buy particular hardware?
>
> Apple employees need to eat also. :)

I'm a Red Hat employee, and my diet is just fine, thank you.

That said, y'all welcome to discuss business models, the philosophy of
free software, inhowfar $corporation contributes to society, or whether
a corporation has any obligations beyond making its shareholders money,
but *please* don't do it on this list.

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Aug 31, 2015, at 3:52 AM, Markus Armbruster wrote:

> Programmingkid <magiccatsoftware@gmail.com> writes:
> 
>> 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).
>> 
>> If making QEMU more user-friendly is a crime, I plead guilty!
>> 
>> I'm not a Linux user. I am a proud Macintosh user. We Mac users
>> like our software easy to use. I know this goes against the Linux
>> way of life. That is why this patch would only work on Mac OS X. 
>> This will keep QEMU on Linux hard to use... just the way you guys
>> like it.
> 
> I think you've used up your "speculation on what Linux users like" quota
> on this list for 2015.  Now let's get back on topic.
> 
> [More snipped...]
> 
>>>>> 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.
>> 
>> We can have both. Command-line options are there that can turn on or
>> off the GUI.
>> Example: --disable-gtk.
>> 
>> Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing stuff like
>> freezing and restoring a session would be awesome and a real time saver.
>> 
>>> 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)
>> 
>> That is totally fine for the Linux users. If they want to use the
>> command-line only,
>> let them. They are only hurting themselves :)
> 
> You're attacking a strawman.

I think the word attack is a little strong. We were just having a little informal
conversation. Sorry if the Linux jokes weren't so funny.

>  Nobody is arguing against having a nice
> GUI.  My argument is that one application trying to do everything tends
> to result in the application doing most of it badly.

That's what you believe? Are you saying if we do add a few features to the GUI
it automatically becomes bad? Isn't that kind of pessimistic? Is all hope gone?

Running Virt-manager on Mac OS X isn't currently possible. So my only choice is to advance
the GUI. This feature would making transferring files from and to the guest actually easy
to do. That sounds like a good idea. This patch would only affect Mac OS X users, so Linux
users won't notice a difference. No harm done to them.

Re: [Qemu-devel] Mount image file feature

[Markus Armbruster]

Programmingkid <programmingkidx@gmail.com> writes:

> On Aug 31, 2015, at 3:52 AM, Markus Armbruster wrote:
>
>> Programmingkid <magiccatsoftware@gmail.com> writes:
>> 
>>> 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).
>>> 
>>> If making QEMU more user-friendly is a crime, I plead guilty!
>>> 
>>> I'm not a Linux user. I am a proud Macintosh user. We Mac users
>>> like our software easy to use. I know this goes against the Linux
>>> way of life. That is why this patch would only work on Mac OS X. 
>>> This will keep QEMU on Linux hard to use... just the way you guys
>>> like it.
>> 
>> I think you've used up your "speculation on what Linux users like" quota
>> on this list for 2015.  Now let's get back on topic.
>> 
>> [More snipped...]
>> 
>>>>>> 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.
>>> 
>>> We can have both. Command-line options are there that can turn on or
>>> off the GUI.
>>> Example: --disable-gtk.
>>> 
>>> Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing stuff like
>>> freezing and restoring a session would be awesome and a real time saver.
>>> 
>>>> 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)
>>> 
>>> That is totally fine for the Linux users. If they want to use the
>>> command-line only,
>>> let them. They are only hurting themselves :)
>> 
>> You're attacking a strawman.
>
> I think the word attack is a little strong. We were just having a
> little informal
> conversation.

We're having a technical argument.  Such arguments can occasionally get
a little heated, but that's fine, we don't mean each other harm :)

>               Sorry if the Linux jokes weren't so funny.

No offense taken.

>>  Nobody is arguing against having a nice
>> GUI.  My argument is that one application trying to do everything tends
>> to result in the application doing most of it badly.
>
> That's what you believe? Are you saying if we do add a few features to the GUI
> it automatically becomes bad? Isn't that kind of pessimistic? Is all hope gone?

I think we QEMU developers have our hands full with our core mission,
and saddling ourselves with GUI development on top risks failure.

You're welcome to prove me wrong.

> Running Virt-manager on Mac OS X isn't currently possible. So my only
> choice is to advance
> the GUI.

Very rarely something is your only choice.

You could work on libvirt and virt-manager under Mac OS X.  A quick grep
shows #ifdef __APPLE__ in libvirt sources, which suggests it already
runs there.

You could write your own GUI layered on top of QEMU.

>          This feature would making transferring files from and to the
> guest actually easy
> to do. That sounds like a good idea.

Plumbing for easy file sharing is part of our core job.  I think Max
pointed you to the work being done by Stefan (NFS over AF_VSOCK).  A
less capable, but more portable alternative could be USB MTP.

>                                      This patch would only affect Mac
> OS X users, so Linux
> users won't notice a difference. No harm done to them.

There's always the opportunity cost.

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Aug 31, 2015, at 12:26 PM, Markus Armbruster wrote:

> Programmingkid <programmingkidx@gmail.com> writes:
> 
>> On Aug 31, 2015, at 3:52 AM, Markus Armbruster wrote:
>> 
>>> Programmingkid <magiccatsoftware@gmail.com> writes:
>>> 
>>>> 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).
>>>> 
>>>> If making QEMU more user-friendly is a crime, I plead guilty!
>>>> 
>>>> I'm not a Linux user. I am a proud Macintosh user. We Mac users
>>>> like our software easy to use. I know this goes against the Linux
>>>> way of life. That is why this patch would only work on Mac OS X. 
>>>> This will keep QEMU on Linux hard to use... just the way you guys
>>>> like it.
>>> 
>>> I think you've used up your "speculation on what Linux users like" quota
>>> on this list for 2015.  Now let's get back on topic.
>>> 
>>> [More snipped...]
>>> 
>>>>>>> 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.
>>>> 
>>>> We can have both. Command-line options are there that can turn on or
>>>> off the GUI.
>>>> Example: --disable-gtk.
>>>> 
>>>> Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing stuff like
>>>> freezing and restoring a session would be awesome and a real time saver.
>>>> 
>>>>> 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)
>>>> 
>>>> That is totally fine for the Linux users. If they want to use the
>>>> command-line only,
>>>> let them. They are only hurting themselves :)
>>> 
>>> You're attacking a strawman.
>> 
>> I think the word attack is a little strong. We were just having a
>> little informal
>> conversation.
> 
> We're having a technical argument.  Such arguments can occasionally get
> a little heated, but that's fine, we don't mean each other harm :)
> 
>>              Sorry if the Linux jokes weren't so funny.
> 
> No offense taken.
> 
>>> Nobody is arguing against having a nice
>>> GUI.  My argument is that one application trying to do everything tends
>>> to result in the application doing most of it badly.
>> 
>> That's what you believe? Are you saying if we do add a few features to the GUI
>> it automatically becomes bad? Isn't that kind of pessimistic? Is all hope gone?
> 
> I think we QEMU developers have our hands full with our core mission,
> and saddling ourselves with GUI development on top risks failure.
> 
> You're welcome to prove me wrong.
> 
>> Running Virt-manager on Mac OS X isn't currently possible. So my only
>> choice is to advance
>> the GUI.
> 
> Very rarely something is your only choice.
> 
> You could work on libvirt and virt-manager under Mac OS X.  A quick grep
> shows #ifdef __APPLE__ in libvirt sources, which suggests it already
> runs there.
> 
> You could write your own GUI layered on top of QEMU.

I honestly don't know very much about this libvirt, but it will take a lot
of work and effort to make it run on Mac OS X. 


> 
>>         This feature would making transferring files from and to the
>> guest actually easy
>> to do. That sounds like a good idea.
> 
> Plumbing for easy file sharing is part of our core job.  I think Max
> pointed you to the work being done by Stefan (NFS over AF_VSOCK).  A
> less capable, but more portable alternative could be USB MTP.

I was told about this feature. Someone said it wouldn't work on Mac OS X.

> 
>>                                     This patch would only affect Mac
>> OS X users, so Linux
>> users won't notice a difference. No harm done to them.
> 
> There's always the opportunity cost.

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

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?

Re: [Qemu-devel] Mount image file feature

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 7167 bytes --]

On 31.08.2015 22:13, Programmingkid wrote:
> 
> 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?

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Aug 31, 2015, at 4:26 PM, Max Reitz wrote:

> On 31.08.2015 22:13, Programmingkid wrote:
>> 
>> 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?
> 
> 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

Is there a function that the GUI could call to send all of the JSON code as the
argument to execute. 

> 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?

Re: [Qemu-devel] Mount image file feature

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]

On 31.08.2015 22:33, Programmingkid wrote:
> 
> On Aug 31, 2015, at 4:26 PM, Max Reitz wrote:

[snip]

>> 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
> 
> Is there a function that the GUI could call to send all of the JSON code as the
> argument to execute.

If you put the GUI outside of qemu, it's very simple, obviously, since
you then just need to send it to whichever interface you chose to be
used for QMP.

(Yes, I'm still strongly encouraging you to write a separate GUI. The
only part that I suppose to be more difficult than when putting
everything into qemu itself is integrating the guest output into your
GUI. Ideally you'd probably either use VNC or qxl/spice for that, but
for the start I personally would just use SDL (it does work on OS X,
too, doesn't it?) so you get a bare window which is only the guest
output, and then put the VM controls into a separate window.)

The nice thing about a GUI outside of qemu, besides looking preferable
design-wise to me, is that you can configure the VM offline, too.


For the GUI inside of qemu: Well, there is handle_qmp_command(), but it
doesn't look like it's intended to be used directly. Judging from
monitor.c, you'd want to set up a JSON parser, call
json_message_parser_init(parser, handle_hmp_command); and then use
json_message_parser_feed() to send commands.

So the GUI inside of qemu would probably want to continue to call qmp_*
directly, i.e. qmp_blockdev_add() and qmp_device_add().

>> 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?

Yes, but you'd have to keep track of the ID you gave it. If you call
blockdev-add again, qemu will happily open it anew and then it'll be
open twice.

> What about handle_hmp_command() in monitor.c. Would it be ok to
> send commands to execute?

Depends on you definition of "ok". As long as it works, well, it'll
work. But HMP is intended for human use, that's where the H comes from.
It's also not as powerful as QMP, e.g. there's not blockdev-add.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Sep 2, 2015, at 10:31 AM, Max Reitz wrote:

> On 31.08.2015 22:33, Programmingkid wrote:
>> 
>> On Aug 31, 2015, at 4:26 PM, Max Reitz wrote:
> 
> [snip]
> 
>>> 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
>> 
>> Is there a function that the GUI could call to send all of the JSON code as the
>> argument to execute.
> 
> If you put the GUI outside of qemu, it's very simple, obviously, since
> you then just need to send it to whichever interface you chose to be
> used for QMP.
> 
> (Yes, I'm still strongly encouraging you to write a separate GUI. The
> only part that I suppose to be more difficult than when putting
> everything into qemu itself is integrating the guest output into your
> GUI. Ideally you'd probably either use VNC or qxl/spice for that, but
> for the start I personally would just use SDL (it does work on OS X,
> too, doesn't it?)

Yes it does.

> so you get a bare window which is only the guest
> output, and then put the VM controls into a separate window.)
> 
> The nice thing about a GUI outside of qemu, besides looking preferable
> design-wise to me, is that you can configure the VM offline, too.
> 
> 
> For the GUI inside of qemu: Well, there is handle_qmp_command(), but it
> doesn't look like it's intended to be used directly. Judging from
> monitor.c, you'd want to set up a JSON parser, call
> json_message_parser_init(parser, handle_hmp_command); and then use
> json_message_parser_feed() to send commands.

Wow, that is a bit overwhelming. I really like what my patch does. It just sends a 
command to the monitor as if the user typed it up. Very simple, easy, and effective.
I will never have to look for some poorly documented function again!


> So the GUI inside of qemu would probably want to continue to call qmp_*
> directly, i.e. qmp_blockdev_add() and qmp_device_add().
> 
>>> 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?
> 
> Yes, but you'd have to keep track of the ID you gave it. If you call
> blockdev-add again, qemu will happily open it anew and then it'll be
> open twice.

I just call drive_del then device_del. So far so good. I have mounted
and unmounted the same image file several times without problem.

> 
>> What about handle_hmp_command() in monitor.c. Would it be ok to
>> send commands to execute?
> 
> Depends on you definition of "ok". As long as it works, well, it'll
> work. But HMP is intended for human use, that's where the H comes from.
> It's also not as powerful as QMP, e.g. there's not blockdev-add.
> 
> Max

Thanks for the help.

Re: [Qemu-devel] Mount image file feature

[Markus Armbruster]

Max Reitz <mreitz@redhat.com> writes:

> On 31.08.2015 22:33, Programmingkid wrote:
>> 
>> On Aug 31, 2015, at 4:26 PM, Max Reitz wrote:
>
> [snip]
>
>>> 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
>> 
>> Is there a function that the GUI could call to send all of the JSON
>> code as the
>> argument to execute.
>
> If you put the GUI outside of qemu, it's very simple, obviously, since
> you then just need to send it to whichever interface you chose to be
> used for QMP.
>
> (Yes, I'm still strongly encouraging you to write a separate GUI. The
> only part that I suppose to be more difficult than when putting
> everything into qemu itself is integrating the guest output into your
> GUI. Ideally you'd probably either use VNC or qxl/spice for that, but
> for the start I personally would just use SDL (it does work on OS X,
> too, doesn't it?) so you get a bare window which is only the guest
> output, and then put the VM controls into a separate window.)
>
> The nice thing about a GUI outside of qemu, besides looking preferable
> design-wise to me, is that you can configure the VM offline, too.

All good points.

> For the GUI inside of qemu: Well, there is handle_qmp_command(), but it
> doesn't look like it's intended to be used directly. Judging from
> monitor.c, you'd want to set up a JSON parser, call
> json_message_parser_init(parser, handle_hmp_command); and then use
> json_message_parser_feed() to send commands.

No, use the proper internal interface: the C functions implementing the
QMP commands.

> So the GUI inside of qemu would probably want to continue to call qmp_*
> directly, i.e. qmp_blockdev_add() and qmp_device_add().

Yes, those are two of them.

>>> 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?
>
> Yes, but you'd have to keep track of the ID you gave it. If you call
> blockdev-add again, qemu will happily open it anew and then it'll be
> open twice.
>
>> What about handle_hmp_command() in monitor.c. Would it be ok to
>> send commands to execute?
>
> Depends on you definition of "ok". As long as it works, well, it'll
> work. But HMP is intended for human use, that's where the H comes from.
> It's also not as powerful as QMP, e.g. there's not blockdev-add.

Using handle_hmp_command() as internal interface goes through multiple
layers of formatting and parsing just to call a C function you could've
just as well called directly.

Thus, calling handle_hmp_command() from for any purpose other than
handling QMP command "human-monitor-command" or testing it is
inappropriate.

Re: [Qemu-devel] Mount image file feature

[Markus Armbruster]

Programmingkid <programmingkidx@gmail.com> writes:

> On Sep 2, 2015, at 10:31 AM, Max Reitz wrote:
>
>> On 31.08.2015 22:33, Programmingkid wrote:
>>> 
>>> On Aug 31, 2015, at 4:26 PM, Max Reitz wrote:
>> 
>> [snip]
>> 
>>>> 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
>>> 
>>> Is there a function that the GUI could call to send all of the JSON
>>> code as the
>>> argument to execute.
>> 
>> If you put the GUI outside of qemu, it's very simple, obviously, since
>> you then just need to send it to whichever interface you chose to be
>> used for QMP.
>> 
>> (Yes, I'm still strongly encouraging you to write a separate GUI. The
>> only part that I suppose to be more difficult than when putting
>> everything into qemu itself is integrating the guest output into your
>> GUI. Ideally you'd probably either use VNC or qxl/spice for that, but
>> for the start I personally would just use SDL (it does work on OS X,
>> too, doesn't it?)
>
> Yes it does.
>
>> so you get a bare window which is only the guest
>> output, and then put the VM controls into a separate window.)
>> 
>> The nice thing about a GUI outside of qemu, besides looking preferable
>> design-wise to me, is that you can configure the VM offline, too.
>> 
>> 
>> For the GUI inside of qemu: Well, there is handle_qmp_command(), but it
>> doesn't look like it's intended to be used directly. Judging from
>> monitor.c, you'd want to set up a JSON parser, call
>> json_message_parser_init(parser, handle_hmp_command); and then use
>> json_message_parser_feed() to send commands.
>
> Wow, that is a bit overwhelming. I really like what my patch does. It
> just sends a
> command to the monitor as if the user typed it up. Very simple, easy,
> and effective.
> I will never have to look for some poorly documented function again!

On the flip side, you'll never get a patch abusing handle_hmp_command()
or handle_qmp_command() as internal interface committed.

>> So the GUI inside of qemu would probably want to continue to call qmp_*
>> directly, i.e. qmp_blockdev_add() and qmp_device_add().
>> 
>>>> 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?
>> 
>> Yes, but you'd have to keep track of the ID you gave it. If you call
>> blockdev-add again, qemu will happily open it anew and then it'll be
>> open twice.
>
> I just call drive_del then device_del. So far so good. I have mounted
> and unmounted the same image file several times without problem.

Wrong order, trap for the unwary.  Let me paste my standard advice:

    drive_del is nasty.  Its purpose is to revoke access to an image
    even when the guest refuses to cooperate.  To the guest, this looks
    like hardware failure.

    If you drive_del before device_del, even a perfectly well-behaved
    guest guest is exposed to a terminally broken device between
    drive_del and completion of unplug.

    Always try a device_del first, and only if that does not complete
    within reasonable time, and you absolutely must revoke access to the
    image, then whack it over the head with drive_del.

Copied from
http://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00116.html

I hope we can eventually replace and deprecate drive_del with something
that where the obvious use is the correct one.

[...]

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Sep 3, 2015, at 5:46 AM, Markus Armbruster wrote:

> Programmingkid <programmingkidx@gmail.com> writes:
> 
>> On Sep 2, 2015, at 10:31 AM, Max Reitz wrote:
>> 
>>> On 31.08.2015 22:33, Programmingkid wrote:
>>>> 
>>>> On Aug 31, 2015, at 4:26 PM, Max Reitz wrote:
>>> 
>>> [snip]
>>> 
>>>>> 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
>>>> 
>>>> Is there a function that the GUI could call to send all of the JSON
>>>> code as the
>>>> argument to execute.
>>> 
>>> If you put the GUI outside of qemu, it's very simple, obviously, since
>>> you then just need to send it to whichever interface you chose to be
>>> used for QMP.
>>> 
>>> (Yes, I'm still strongly encouraging you to write a separate GUI. The
>>> only part that I suppose to be more difficult than when putting
>>> everything into qemu itself is integrating the guest output into your
>>> GUI. Ideally you'd probably either use VNC or qxl/spice for that, but
>>> for the start I personally would just use SDL (it does work on OS X,
>>> too, doesn't it?)
>> 
>> Yes it does.
>> 
>>> so you get a bare window which is only the guest
>>> output, and then put the VM controls into a separate window.)
>>> 
>>> The nice thing about a GUI outside of qemu, besides looking preferable
>>> design-wise to me, is that you can configure the VM offline, too.
>>> 
>>> 
>>> For the GUI inside of qemu: Well, there is handle_qmp_command(), but it
>>> doesn't look like it's intended to be used directly. Judging from
>>> monitor.c, you'd want to set up a JSON parser, call
>>> json_message_parser_init(parser, handle_hmp_command); and then use
>>> json_message_parser_feed() to send commands.
>> 
>> Wow, that is a bit overwhelming. I really like what my patch does. It
>> just sends a
>> command to the monitor as if the user typed it up. Very simple, easy,
>> and effective.
>> I will never have to look for some poorly documented function again!
> 
> On the flip side, you'll never get a patch abusing handle_hmp_command()
> or handle_qmp_command() as internal interface committed.
> 
>>> So the GUI inside of qemu would probably want to continue to call qmp_*
>>> directly, i.e. qmp_blockdev_add() and qmp_device_add().
>>> 
>>>>> 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?
>>> 
>>> Yes, but you'd have to keep track of the ID you gave it. If you call
>>> blockdev-add again, qemu will happily open it anew and then it'll be
>>> open twice.
>> 
>> I just call drive_del then device_del. So far so good. I have mounted
>> and unmounted the same image file several times without problem.
> 
> Wrong order, trap for the unwary.  Let me paste my standard advice:
> 
>    drive_del is nasty.  Its purpose is to revoke access to an image
>    even when the guest refuses to cooperate.  To the guest, this looks
>    like hardware failure. 

Has the device been probably ejected from the guest first?

> 
>    If you drive_del before device_del, even a perfectly well-behaved
>    guest guest is exposed to a terminally broken device between
>    drive_del and completion of unplug.
> 
>    Always try a device_del first, and only if that does not complete
>    within reasonable time, and you absolutely must revoke access to the
>    image, then whack it over the head with drive_del.

I guess I could use "device_del" only. I just thought it made sense to use
"drive_del" when I used the "drive_add" command.

> 
> Copied from
> http://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00116.html
> 
> I hope we can eventually replace and deprecate drive_del with something
> that where the obvious use is the correct one.

I haven't noticed any problems so far. When I use "drive_del", the "info block" 
command says it is gone. That is good. Then I do a "device_del". "info usb" shows
the device gone. Maybe any problems with "drive_del" you might have had in the 
past have been fixed. Have you tried it out lately? I did extensive testing of my patch
using Debian Linux as a guest. Never heard it complain. 

Re: [Qemu-devel] Mount image file feature

[Markus Armbruster]

Programmingkid <programmingkidx@gmail.com> writes:

> On Sep 3, 2015, at 5:46 AM, Markus Armbruster wrote:
>
>> Programmingkid <programmingkidx@gmail.com> writes:
>> 
>>> On Sep 2, 2015, at 10:31 AM, Max Reitz wrote:
>>> 
>>>> On 31.08.2015 22:33, Programmingkid wrote:
>>>>> 
>>>>> On Aug 31, 2015, at 4:26 PM, Max Reitz wrote:
>>>> 
>>>> [snip]
>>>> 
>>>>>> 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
>>>>> 
>>>>> Is there a function that the GUI could call to send all of the JSON
>>>>> code as the
>>>>> argument to execute.
>>>> 
>>>> If you put the GUI outside of qemu, it's very simple, obviously, since
>>>> you then just need to send it to whichever interface you chose to be
>>>> used for QMP.
>>>> 
>>>> (Yes, I'm still strongly encouraging you to write a separate GUI. The
>>>> only part that I suppose to be more difficult than when putting
>>>> everything into qemu itself is integrating the guest output into your
>>>> GUI. Ideally you'd probably either use VNC or qxl/spice for that, but
>>>> for the start I personally would just use SDL (it does work on OS X,
>>>> too, doesn't it?)
>>> 
>>> Yes it does.
>>> 
>>>> so you get a bare window which is only the guest
>>>> output, and then put the VM controls into a separate window.)
>>>> 
>>>> The nice thing about a GUI outside of qemu, besides looking preferable
>>>> design-wise to me, is that you can configure the VM offline, too.
>>>> 
>>>> 
>>>> For the GUI inside of qemu: Well, there is handle_qmp_command(), but it
>>>> doesn't look like it's intended to be used directly. Judging from
>>>> monitor.c, you'd want to set up a JSON parser, call
>>>> json_message_parser_init(parser, handle_hmp_command); and then use
>>>> json_message_parser_feed() to send commands.
>>> 
>>> Wow, that is a bit overwhelming. I really like what my patch does. It
>>> just sends a
>>> command to the monitor as if the user typed it up. Very simple, easy,
>>> and effective.
>>> I will never have to look for some poorly documented function again!
>> 
>> On the flip side, you'll never get a patch abusing handle_hmp_command()
>> or handle_qmp_command() as internal interface committed.
>> 
>>>> So the GUI inside of qemu would probably want to continue to call qmp_*
>>>> directly, i.e. qmp_blockdev_add() and qmp_device_add().
>>>> 
>>>>>> 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?
>>>> 
>>>> Yes, but you'd have to keep track of the ID you gave it. If you call
>>>> blockdev-add again, qemu will happily open it anew and then it'll be
>>>> open twice.
>>> 
>>> I just call drive_del then device_del. So far so good. I have mounted
>>> and unmounted the same image file several times without problem.
>> 
>> Wrong order, trap for the unwary.  Let me paste my standard advice:
>> 
>>    drive_del is nasty.  Its purpose is to revoke access to an image
>>    even when the guest refuses to cooperate.  To the guest, this looks
>>    like hardware failure. 
>
> Has the device been probably ejected from the guest first?

For a PCI device (such as virtio-blk-pci), device_del merely asks the
guest politely to relinquish the device.  As soon as it complies, the
device gets unplugged.

What if it doesn't?  Buggy, maliciously, or simply incapable of ACPI.
You sometimes still a surefire way to revoke its access to an image
anyway.  That way is the (badly named!) drive_del.

>>    If you drive_del before device_del, even a perfectly well-behaved
>>    guest guest is exposed to a terminally broken device between
>>    drive_del and completion of unplug.
>> 
>>    Always try a device_del first, and only if that does not complete
>>    within reasonable time, and you absolutely must revoke access to the
>>    image, then whack it over the head with drive_del.
>
> I guess I could use "device_del" only. I just thought it made sense to use
> "drive_del" when I used the "drive_add" command.

Did I mention "badly named"?

>> Copied from
>> http://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00116.html
>> 
>> I hope we can eventually replace and deprecate drive_del with something
>> that where the obvious use is the correct one.
>
> I haven't noticed any problems so far. When I use "drive_del", the "info block" 
> command says it is gone. That is good. Then I do a "device_del". "info
> usb" shows
> the device gone. Maybe any problems with "drive_del" you might have had in the 
> past have been fixed. Have you tried it out lately? I did extensive
> testing of my patch
> using Debian Linux as a guest. Never heard it complain. 

Read again:

    If you drive_del before device_del, even a perfectly well-behaved
    guest guest is exposed to a terminally broken device between
    drive_del and completion of unplug.

This is a race condition.  If the guest doesn't look between drive_del
and device_del, nothing bad happens.  If it does, it sees a dead device.

Dijkstra's old adage "testing shows the presence, not the absence of
bugs" applies to race conditions most forcefully.

Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Sep 3, 2015, at 12:26 PM, Markus Armbruster wrote:

> Programmingkid <programmingkidx@gmail.com> writes:
> 
>> On Sep 3, 2015, at 5:46 AM, Markus Armbruster wrote:
>> 
>>> Programmingkid <programmingkidx@gmail.com> writes:
>>> 
>>>> On Sep 2, 2015, at 10:31 AM, Max Reitz wrote:
>>>> 
>>>>> On 31.08.2015 22:33, Programmingkid wrote:
>>>>>> 
>>>>>> On Aug 31, 2015, at 4:26 PM, Max Reitz wrote:
>>>>> 
>>>>> [snip]
>>>>> 
>>>>>>> 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
>>>>>> 
>>>>>> Is there a function that the GUI could call to send all of the JSON
>>>>>> code as the
>>>>>> argument to execute.
>>>>> 
>>>>> If you put the GUI outside of qemu, it's very simple, obviously, since
>>>>> you then just need to send it to whichever interface you chose to be
>>>>> used for QMP.
>>>>> 
>>>>> (Yes, I'm still strongly encouraging you to write a separate GUI. The
>>>>> only part that I suppose to be more difficult than when putting
>>>>> everything into qemu itself is integrating the guest output into your
>>>>> GUI. Ideally you'd probably either use VNC or qxl/spice for that, but
>>>>> for the start I personally would just use SDL (it does work on OS X,
>>>>> too, doesn't it?)
>>>> 
>>>> Yes it does.
>>>> 
>>>>> so you get a bare window which is only the guest
>>>>> output, and then put the VM controls into a separate window.)
>>>>> 
>>>>> The nice thing about a GUI outside of qemu, besides looking preferable
>>>>> design-wise to me, is that you can configure the VM offline, too.
>>>>> 
>>>>> 
>>>>> For the GUI inside of qemu: Well, there is handle_qmp_command(), but it
>>>>> doesn't look like it's intended to be used directly. Judging from
>>>>> monitor.c, you'd want to set up a JSON parser, call
>>>>> json_message_parser_init(parser, handle_hmp_command); and then use
>>>>> json_message_parser_feed() to send commands.
>>>> 
>>>> Wow, that is a bit overwhelming. I really like what my patch does. It
>>>> just sends a
>>>> command to the monitor as if the user typed it up. Very simple, easy,
>>>> and effective.
>>>> I will never have to look for some poorly documented function again!
>>> 
>>> On the flip side, you'll never get a patch abusing handle_hmp_command()
>>> or handle_qmp_command() as internal interface committed.
>>> 
>>>>> So the GUI inside of qemu would probably want to continue to call qmp_*
>>>>> directly, i.e. qmp_blockdev_add() and qmp_device_add().
>>>>> 
>>>>>>> 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?
>>>>> 
>>>>> Yes, but you'd have to keep track of the ID you gave it. If you call
>>>>> blockdev-add again, qemu will happily open it anew and then it'll be
>>>>> open twice.
>>>> 
>>>> I just call drive_del then device_del. So far so good. I have mounted
>>>> and unmounted the same image file several times without problem.
>>> 
>>> Wrong order, trap for the unwary.  Let me paste my standard advice:
>>> 
>>>   drive_del is nasty.  Its purpose is to revoke access to an image
>>>   even when the guest refuses to cooperate.  To the guest, this looks
>>>   like hardware failure. 
>> 
>> Has the device been probably ejected from the guest first?
> 
> For a PCI device (such as virtio-blk-pci), device_del merely asks the
> guest politely to relinquish the device.  As soon as it complies, the
> device gets unplugged.
> 
> What if it doesn't?  Buggy, maliciously, or simply incapable of ACPI.
> You sometimes still a surefire way to revoke its access to an image
> anyway.  That way is the (badly named!) drive_del.
> 
>>>   If you drive_del before device_del, even a perfectly well-behaved
>>>   guest guest is exposed to a terminally broken device between
>>>   drive_del and completion of unplug.
>>> 
>>>   Always try a device_del first, and only if that does not complete
>>>   within reasonable time, and you absolutely must revoke access to the
>>>   image, then whack it over the head with drive_del.
>> 
>> I guess I could use "device_del" only. I just thought it made sense to use
>> "drive_del" when I used the "drive_add" command.
> 
> Did I mention "badly named"?
> 
>>> Copied from
>>> http://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00116.html
>>> 
>>> I hope we can eventually replace and deprecate drive_del with something
>>> that where the obvious use is the correct one.
>> 
>> I haven't noticed any problems so far. When I use "drive_del", the "info block" 
>> command says it is gone. That is good. Then I do a "device_del". "info
>> usb" shows
>> the device gone. Maybe any problems with "drive_del" you might have had in the 
>> past have been fixed. Have you tried it out lately? I did extensive
>> testing of my patch
>> using Debian Linux as a guest. Never heard it complain. 
> 
> Read again:
> 
>    If you drive_del before device_del, even a perfectly well-behaved
>    guest guest is exposed to a terminally broken device between
>    drive_del and completion of unplug.
> 
> This is a race condition.  If the guest doesn't look between drive_del
> and device_del, nothing bad happens.  If it does, it sees a dead device.
> 
> Dijkstra's old adage "testing shows the presence, not the absence of
> bugs" applies to race conditions most forcefully.

Ok. There is no problem removing drive_del. It does seem that using
device_del is good enough. An "info block" after a device_del command
proves this. 

Hopefully Peter Maydell will tell me his comments on the patch soon. Then I will 
make a version 2 of the patch without the drive_del command.

Thank you for input.