Mac OS X can be picky when it comes to allowing the user
to use physical devices in QEMU. Most mounted volumes
appear to be off limits to QEMU. If an issue is detected,
a message is displayed showing the user how to unmount a
volume. Now QEMU uses both CD and DVD media.
Signed-off-by: John Arbuckl
Max: Did you have in mind something like this?
v2:
- Fix qemu-img from now choking when it gets a partial response.
For convenience, this branch is available at:
https://github.com/jnsnow/qemu.git branch block-allo
Always report full_backing_filename, even if it's the same as
backing_filename. In the next patch, full_backing_filename may be
omitted if it cannot be generated instead of allowing e.g. drive_query
to abort if it runs into this scenario.
The presence or absence of the "full" field becomes useful
If it happens to match the backing path, that was the actual path.
Signed-off-by: John Snow
---
block/qapi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/qapi.c b/block/qapi.c
index 267f147..01569da 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -676,7 +676,9 @@
...But only if we have the backing_filename. It means something Scary
happened and we can't really be quite exactly sure if we can trust the
backing_filename.
Signed-off-by: John Snow
---
qemu-img.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/qemu-img.c b/qemu-img.c
i
For more complex BDS trees that can be created under normal circumstances,
we lose the ability to issue query commands because of our inability to
re-construct the absolute filename.
Instead, omit this field when it is a problem and present as much information
as we can.
This will change the expe
On 12/10/2015 10:27 PM, Eric Blake wrote:
> On my machine, './check -qcow2 028' was failing about 80% of the
> time, due to a race in how many times the repeated attempts
> to run 'info block-jobs' could occur before the job was done,
> showing up as a failure of fewer '(qemu) ' prompts than in t
On 12/11/2015 04:40 PM, Programmingkid wrote:
> I guess the commit message is a little out of date. How about this:
>
> Mac OS X can be picky when it comes to allowing the user
> to use physical devices in QEMU. Most mounted volumes
> appear to be off limits to QEMU. If an issue is detected,
> a
On Dec 11, 2015, at 5:00 PM, Jeff Cody wrote:
> On Thu, Dec 10, 2015 at 09:39:51AM -0500, Programmingkid wrote:
>> https://patchwork.ozlabs.org/patch/550295/
>>
>> Mac OS X can be picky when it comes to allowing the user
>> to use physical devices in QEMU. Most mounted volumes
>> appear to be of
On Thu, Dec 10, 2015 at 09:39:51AM -0500, Programmingkid wrote:
> https://patchwork.ozlabs.org/patch/550295/
>
> Mac OS X can be picky when it comes to allowing the user
> to use physical devices in QEMU. Most mounted volumes
> appear to be off limits to QEMU. If an issue is detected,
> a message
On 11 December 2015 at 15:43, Max Reitz wrote:
> On 2015-12-11 at 16:40, Peter Maydell wrote:
>>
>> On 11 December 2015 at 15:30, Eric Blake wrote:
>>>
>>> On 12/11/2015 08:23 AM, Max Reitz wrote:
SQMP
-blockdev-remove-medium
+x-blockdev-remove-medium
---
On 2015-12-11 at 16:40, Peter Maydell wrote:
On 11 December 2015 at 15:30, Eric Blake wrote:
On 12/11/2015 08:23 AM, Max Reitz wrote:
SQMP
-blockdev-remove-medium
+x-blockdev-remove-medium
--
Formatting nit, but not worth holding this up (as it is really our last
cha
On 11 December 2015 at 15:30, Eric Blake wrote:
> On 12/11/2015 08:23 AM, Max Reitz wrote:
>>
>> SQMP
>> -blockdev-remove-medium
>> +x-blockdev-remove-medium
>> --
>
> Formatting nit, but not worth holding this up (as it is really our last
> chance to get it in 2.5 before bak
While in the long term we want throttling to be its own block filter
BDS, in the short term we want it to be part of the BB instead of a BDS;
even in the long term we may want legacy throttling to be automatically
tied to the BB.
blockdev-insert-medium and blockdev-remove-medium do not retain
thro
On 12/11/2015 08:23 AM, Max Reitz wrote:
> While in the long term we want throttling to be its own block filter
> BDS, in the short term we want it to be part of the BB instead of a BDS;
> even in the long term we may want legacy throttling to be automatically
> tied to the BB.
>
> blockdev-insert
Hello Peter,
After having talked about the current status of the block layer today,
Markus, Kevin and me agreed to mark the newly introduced QMP commands
blockdev-insert-medium and blockdev-remove-medium experimental after
all (due to possible interference of its current status with future
designs
A server can respond different to both methods, or can block one of the two.
Signed-off-by: Boris Schrijver
Reviewed-by: John Snow
---
V2: Impovements over V1:
- Don't check for CURLE_WRITE_ERROR, on success CURLE_OK will be returned.
- Use CURLOPT_CUSTOMREQUEST instead of CURLOPT_HTTPGET.
---
[adding qemu-devel; per http://wiki.qemu.org/Contribute/SubmitAPatch,
ALL patches must include qemu-devel, even if they are also copying other
sublists]
On 12/11/2015 01:40 AM, Boris Schrijver wrote:
> A server can respond different to both methods, or can block one of the two.
>
> Signed-off-by:
On 11 December 2015 at 03:27, Eric Blake wrote:
> On my machine, './check -qcow2 028' was failing about 80% of the time,
> due to a race in how many times the repeated attempts to run 'info
> block-jobs' could occur before the job was done, showing up as a
> failure of fewer '(qemu) ' prompts than
On 11/12/2015 00:53, Eric Blake wrote:
> We have two different JSON visitors in the tree; and having both
> named 'qjson.h' can cause include confusion. Rename the qapi
> version.
>
> Kill trailing whitespace in the renamed tests/check-qobject-json.c
> to keep checkpatch.pl happy.
>
> Signed-o
A server can respond different to both methods, or can block one of the two.
Signed-off-by: Boris Schrijver
Reviewed-by: John Snow
---
V2: Impovements over V1:
- Don't check for CURLE_WRITE_ERROR, on success CURLE_OK will be returned.
- Use CURLOPT_CUSTOMREQUEST instead of CURLOPT_HTTPGET.
---
21 matches
Mail list logo
