Am 06.06.2018 um 16:55 hat Michael S. Tsirkin geschrieben:
> On Wed, Jun 06, 2018 at 10:42:33AM -0300, Eduardo Habkost wrote:
> > > If we want a grand vision where a single file stores the whole VM, why
> > > not invest the work and make it right from the start?
> >
> > We don't want a grand
On Wed, Jun 06, 2018 at 01:32:47PM +0200, Max Reitz wrote:
> ext2?
I wrote an nbdkit plugin for ext2/ext3/ext4 last week.
https://github.com/libguestfs/nbdkit/tree/master/plugins/ext2
It uses libext2fs from e2fsprogs and I think there are some lessons
for anyone who wants to use ext2 to store
On Mon, 11 Jun 2018 05:06:53 +0300
"Michael S. Tsirkin" wrote:
> On Sat, Jun 09, 2018 at 11:34:03PM +0200, Max Reitz wrote:
> > Dave was saying that the worst thing about the whole q35 thing is
> > that users download an image and have no idea why it isn't
> > working. Figuring that out
On Sat, Jun 09, 2018 at 11:34:03PM +0200, Max Reitz wrote:
> qemu would be very easy to use if it didn't offer any configuration
> options. The problem is that is offers a huge load of configuration
> options and it is not reasonable to expect every user to know all of them.
Right but once one
On 2018-06-07 23:43, Michael S. Tsirkin wrote:
> On Wed, Jun 06, 2018 at 07:06:27PM +0200, Max Reitz wrote:
[...]
>> Er, yeah, OK. But it was my understanding that we decided that we have
>> a management layer on top of qemu to make things simple.
>
> Who's we?
Everyone I'm usually talking to
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Fri, Jun 08, 2018 at 09:21:30AM +0100, Dr. David Alan Gilbert wrote:
> > * Laszlo Ersek (ler...@redhat.com) wrote:
> > > On 06/07/18 12:54, Andrea Bolognani wrote:
> > > > On Thu, 2018-06-07 at 11:36 +0100, Daniel P. Berrangé wrote:
> > > >>
On Fri, Jun 08, 2018 at 09:21:30AM +0100, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (ler...@redhat.com) wrote:
> > On 06/07/18 12:54, Andrea Bolognani wrote:
> > > On Thu, 2018-06-07 at 11:36 +0100, Daniel P. Berrangé wrote:
> > >> On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones
* Laszlo Ersek (ler...@redhat.com) wrote:
> On 06/07/18 12:54, Andrea Bolognani wrote:
> > On Thu, 2018-06-07 at 11:36 +0100, Daniel P. Berrangé wrote:
> >> On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones wrote:
> >>> Another problem which Laszlo mentioned is the varstore isn't
On Wed, Jun 06, 2018 at 07:06:27PM +0200, Max Reitz wrote:
> On 2018-06-06 17:09, Michael S. Tsirkin wrote:
> > On Wed, Jun 06, 2018 at 04:51:39PM +0200, Max Reitz wrote:
> >> On 2018-06-06 16:31, Dr. David Alan Gilbert wrote:
> >>> * Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06
On Thu, Jun 07, 2018 at 12:54:33PM +0200, Andrea Bolognani wrote:
> On Thu, 2018-06-07 at 11:36 +0100, Daniel P. Berrangé wrote:
> > On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones wrote:
> > > Another problem which Laszlo mentioned is the varstore isn't portable
> > > between UEFI
On Thu, Jun 07, 2018 at 11:36:20AM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones wrote:
> > On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote:
> > > Something that I haven't seen mentioned in the thread - and this
> > > looks like as
Hi,
> > I could be wrong, but I feel like it's significantly less likely
> > that a random QEMU binary won't like a random EFI ROM than it is
> > for a random EFI ROM to not like a random EFI NVRAM.
>
> True, but it's not that rare to find SeaBIOS+qemu version problems;
Hmm? Any recent
On 06/07/18 12:51, Andrea Bolognani wrote:
> On Thu, 2018-06-07 at 11:32 +0100, Richard W.M. Jones wrote:
>> On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote:
>>> Something that I haven't seen mentioned in the thread - and this
>>> looks like as good a point as any to jump in - is
On 06/07/18 12:54, Andrea Bolognani wrote:
> On Thu, 2018-06-07 at 11:36 +0100, Daniel P. Berrangé wrote:
>> On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones wrote:
>>> Another problem which Laszlo mentioned is the varstore isn't portable
>>> between UEFI implementations, or if the
On Wed, Jun 06, 2018 at 03:36:53PM -0300, Eduardo Habkost wrote:
> On Wed, Jun 06, 2018 at 08:33:39PM +0200, Michal Suchánek wrote:
> [...]
> > Lastly we are missing a developer of a management layer committed to
> > support such appliances.
>
> This is important. Without developers of
* Andrea Bolognani (abolo...@redhat.com) wrote:
> On Thu, 2018-06-07 at 15:45 +0100, Dr. David Alan Gilbert wrote:
> > * Andrea Bolognani (abolo...@redhat.com) wrote:
> > > On Thu, 2018-06-07 at 14:49 +0100, Dr. David Alan Gilbert wrote:
> > > > Including the nvram and efi makes me nervous; but I
On Thu, 2018-06-07 at 15:45 +0100, Dr. David Alan Gilbert wrote:
> * Andrea Bolognani (abolo...@redhat.com) wrote:
> > On Thu, 2018-06-07 at 14:49 +0100, Dr. David Alan Gilbert wrote:
> > > Including the nvram and efi makes me nervous; but I can see why together
> > > they might work. However,
* Andrea Bolognani (abolo...@redhat.com) wrote:
> On Thu, 2018-06-07 at 14:49 +0100, Dr. David Alan Gilbert wrote:
> > Including the nvram and efi makes me nervous; but I can see why together
> > they might work. However, there's no guarantee that EFI has been tested
> > with the QEMU it's used
On Thu, 2018-06-07 at 14:49 +0100, Dr. David Alan Gilbert wrote:
> Including the nvram and efi makes me nervous; but I can see why together
> they might work. However, there's no guarantee that EFI has been tested
> with the QEMU it's used on and ... that could be trouble.
If the QEMU binary
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Thu, Jun 07, 2018 at 01:17:24PM +0200, Andrea Bolognani wrote:
> > On Thu, 2018-06-07 at 11:22 +0100, Daniel P. Berrangé wrote:
> > > On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote:
> > > > While hints might be considered a
On Thu, Jun 07, 2018 at 01:17:24PM +0200, Andrea Bolognani wrote:
> On Thu, 2018-06-07 at 11:22 +0100, Daniel P. Berrangé wrote:
> > On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote:
> > > While hints might be considered a reasonable fit for qcow2, I think
> > > it's pretty hard to
On Wed, 2018-06-06 at 17:32 +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 06, 2018 at 10:36:20AM -0500, Eric Blake wrote:
> > But for the new config to be useful, you have to modify at least one tool in
> > the path. At which point, it is just as easy to say: "libvirt is now smart
> > enough to
On Thu, 2018-06-07 at 11:36 +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones wrote:
> > Another problem which Laszlo mentioned is the varstore isn't portable
> > between UEFI implementations, or if the UEFI is compiled with
> > different options. You
On Thu, 2018-06-07 at 11:22 +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote:
> > While hints might be considered a reasonable fit for qcow2, I think
> > it's pretty hard to argue for embedding the NVRAM file in there,
> > which to me signals
On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones wrote:
> On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote:
> > Something that I haven't seen mentioned in the thread - and this
> > looks like as good a point as any to jump in - is that for q35
> > guests using EFI as
* Richard W.M. Jones (rjo...@redhat.com) wrote:
> On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote:
> > Something that I haven't seen mentioned in the thread - and this
> > looks like as good a point as any to jump in - is that for q35
> > guests using EFI as well as aarch64 guests
On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote:
> Something that I haven't seen mentioned in the thread - and this
> looks like as good a point as any to jump in - is that for q35
> guests using EFI as well as aarch64 guests the "one click import"
> experience requires not only
On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote:
> On Wed, 2018-06-06 at 17:32 +0100, Daniel P. Berrangé wrote:
> > On Wed, Jun 06, 2018 at 10:36:20AM -0500, Eric Blake wrote:
> > > But for the new config to be useful, you have to modify at least one tool
> > > in
> > > the path.
Hi,
> our actual qcow2v3 improvements, so no one ended up switching to that. So,
> to some extent, various high-level consumers still have the notion that
> 'raw' files are better/safer/faster than 'qcow2' files because of an
> anecdote from years ago, even if we have since fixed the speed
On 06/06/2018 09:57 AM, Eric Blake wrote:
On 06/06/2018 09:43 AM, Michael S. Tsirkin wrote:
On Wed, Jun 06, 2018 at 01:02:53PM +0200, Max Reitz wrote:
Yeah, but why make qcow2 that format? That's what I completely fail to
understand.
Because why not? It's cheap to add it there and is much
On Wed, Jun 06, 2018 at 08:33:39PM +0200, Michal Suchánek wrote:
[...]
> Lastly we are missing a developer of a management layer committed to
> support such appliances.
This is important. Without developers of management tools
willing to help specify the requirements and implement the
feature,
On Wed, 6 Jun 2018 20:02:54 +0200
Max Reitz wrote:
> On 2018-06-06 17:25, Michal Suchánek wrote:
> > On Wed, 6 Jun 2018 16:55:08 +0200
> > Max Reitz wrote:
> >
> >> On 2018-06-06 16:41, Dr. David Alan Gilbert wrote:
> >>> * Max Reitz (mre...@redhat.com) wrote:
> >> Users using a whole
On 2018-06-06 18:10, Eduardo Habkost wrote:
> On Wed, Jun 06, 2018 at 04:17:14PM +0200, Max Reitz wrote:
>> On 2018-06-06 15:45, Michal Suchánek wrote:
[...]
>>> I understand that for some use cases simplifying the distribution of
>>> VMs as much as possible is quite important.
>>
>> I don't
On 2018-06-06 17:25, Michal Suchánek wrote:
> On Wed, 6 Jun 2018 16:55:08 +0200
> Max Reitz wrote:
>
>> On 2018-06-06 16:41, Dr. David Alan Gilbert wrote:
>>> * Max Reitz (mre...@redhat.com) wrote:
>>
>> [...]
>>
So why is it so dangerous to connect a disk you just downloaded to
e.g.
On 2018-06-06 17:05, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
>> On 2018-06-06 16:31, Dr. David Alan Gilbert wrote:
>>> * Max Reitz (mre...@redhat.com) wrote:
On 2018-06-06 14:00, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
>>
On 2018-06-06 17:09, Michael S. Tsirkin wrote:
> On Wed, Jun 06, 2018 at 04:51:39PM +0200, Max Reitz wrote:
>> On 2018-06-06 16:31, Dr. David Alan Gilbert wrote:
>>> * Max Reitz (mre...@redhat.com) wrote:
On 2018-06-06 14:00, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com)
On 06/06/2018 11:11 AM, Michal Suchánek wrote:
The reason why storing the config inside the qcow2 file is you have one
self-contained file that can be updated by qemu itself.
So you take an image file, point your management console to it, boot
it, change something on it, shut it down, and
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Jun 06, 2018 at 10:36:20AM -0500, Eric Blake wrote:
> > On 06/06/2018 10:05 AM, Dr. David Alan Gilbert wrote:
> >
> > > > If that's the issue, add a UUID to qcow2 files and reference it from the
> > > > config file.
> > >
> > > Is a
On Wed, Jun 06, 2018 at 10:36:20AM -0500, Eric Blake wrote:
> On 06/06/2018 10:05 AM, Dr. David Alan Gilbert wrote:
>
> > > If that's the issue, add a UUID to qcow2 files and reference it from the
> > > config file.
> >
> > Is a UUID a small string :-)
>
> Even better, it's something that you
On Wed, 6 Jun 2018 10:36:20 -0500
Eric Blake wrote:
> On 06/06/2018 10:05 AM, Dr. David Alan Gilbert wrote:
>
> >
> >>> We should make this EASY for users.
> >>
> >> To me, having a simple config file they can edit manually certainly
> >> seems simpler than having to use specific tools to
On Wed, Jun 06, 2018 at 04:17:14PM +0200, Max Reitz wrote:
> On 2018-06-06 15:45, Michal Suchánek wrote:
> > On Wed, 6 Jun 2018 15:14:03 +0200
> > Max Reitz wrote:
> >
> >> On 2018-06-06 14:13, Michal Suchánek wrote:
> >>> On Wed, 6 Jun 2018 13:52:35 +0200
> >>> Max Reitz wrote:
> >>>
>
On 06/06/2018 10:05 AM, Dr. David Alan Gilbert wrote:
If that's the issue, add a UUID to qcow2 files and reference it from the
config file.
Is a UUID a small string :-)
Even better, it's something that you could stick directly in the qcow2
header (and which therefore cannot grow to a
On Wed, 6 Jun 2018 16:55:08 +0200
Max Reitz wrote:
> On 2018-06-06 16:41, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
>
> [...]
>
> >> So why is it so dangerous to connect a disk you just downloaded to
> >> e.g. the wrong machine type? I assumed it just wouldn't
On Wed, Jun 06, 2018 at 04:51:39PM +0200, Max Reitz wrote:
> On 2018-06-06 16:31, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 14:00, Dr. David Alan Gilbert wrote:
> >>> * Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 13:14, Dr. David Alan
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 16:31, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 14:00, Dr. David Alan Gilbert wrote:
> >>> * Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 13:14, Dr. David Alan Gilbert wrote:
>
On 2018-06-06 16:46, Michael S. Tsirkin wrote:
> On Wed, Jun 06, 2018 at 01:44:02PM +0200, Max Reitz wrote:
>> Because it's a hack, right. Storing binary data in a qcow2 file,
>> completely ignoring it in qemu (and being completely unusable to any
>> potential other users of the qcow2 format[1])
On 2018-06-06 16:43, Michael S. Tsirkin wrote:
> On Wed, Jun 06, 2018 at 01:02:53PM +0200, Max Reitz wrote:
>> Yeah, but why make qcow2 that format? That's what I completely fail to
>> understand.
>
> Because why not? It's cheap to add it there and is much easier
> than teaching people about a
On 06/06/2018 09:43 AM, Michael S. Tsirkin wrote:
On Wed, Jun 06, 2018 at 01:02:53PM +0200, Max Reitz wrote:
Yeah, but why make qcow2 that format? That's what I completely fail to
understand.
Because why not? It's cheap to add it there and is much easier
than teaching people about a new
On 2018-06-06 16:41, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
[...]
>> So why is it so dangerous to connect a disk you just downloaded to e.g.
>> the wrong machine type? I assumed it just wouldn't work and you'd try
>> again, until you realized that maybe you
On 2018-06-06 16:55, Michael S. Tsirkin wrote:
> On Wed, Jun 06, 2018 at 10:42:33AM -0300, Eduardo Habkost wrote:
>>> If we want a grand vision where a single file stores the whole VM, why
>>> not invest the work and make it right from the start?
>>
>> We don't want a grand vision where a single
On 2018-06-06 16:31, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
>> On 2018-06-06 14:00, Dr. David Alan Gilbert wrote:
>>> * Max Reitz (mre...@redhat.com) wrote:
On 2018-06-06 13:14, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
>>
On Wed, Jun 06, 2018 at 01:44:02PM +0200, Max Reitz wrote:
> Because it's a hack, right. Storing binary data in a qcow2 file,
> completely ignoring it in qemu (and being completely unusable to any
> potential other users of the qcow2 format[1]) and only interpreting it
> somewhere up the stack is
On Wed, Jun 06, 2018 at 01:02:53PM +0200, Max Reitz wrote:
> Yeah, but why make qcow2 that format? That's what I completely fail to
> understand.
Because why not? It's cheap to add it there and is much easier
than teaching people about a new container format.
Eric Blake put it very well I
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 16:02, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 14:16, Dr. David Alan Gilbert wrote:
> >>> * Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 13:37, Dr. David Alan Gilbert wrote:
>
On Wed, Jun 06, 2018 at 03:31:35PM +0100, Dr. David Alan Gilbert wrote:
> > Not in this case because it'd still be a flat qcow2 file in a simple tar
> > archive.
> >
> > But you're right if we had a more complex format (like chunks stored in
> > a tar file).
>
> My only problem with using the
On 2018-06-06 16:02, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
>> On 2018-06-06 14:16, Dr. David Alan Gilbert wrote:
>>> * Max Reitz (mre...@redhat.com) wrote:
On 2018-06-06 13:37, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
>>
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 14:00, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 13:14, Dr. David Alan Gilbert wrote:
> >>> * Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
>
On Wed, Jun 06, 2018 at 12:40:35PM +0100, Richard W.M. Jones wrote:
> I started off a long reply here, but I think you're right. If we
> cannot make people decide on and use a proper disk image + metadata
> container, then it's also unlikely we'll get them to add sensible
> metadata to their
On Wed, Jun 06, 2018 at 11:14:32AM -0300, Eduardo Habkost wrote:
> On Wed, Jun 06, 2018 at 02:50:10PM +0100, Daniel P. Berrangé wrote:
> > On Wed, Jun 06, 2018 at 03:45:10PM +0200, Michal Suchánek wrote:
> > >
> > > I think that *if* we want an 'appliance' format that stores a whole VM
> > > in a
On 2018-06-06 16:14, Eduardo Habkost wrote:
> On Wed, Jun 06, 2018 at 02:50:10PM +0100, Daniel P. Berrangé wrote:
>> On Wed, Jun 06, 2018 at 03:45:10PM +0200, Michal Suchánek wrote:
>>>
>>> I think that *if* we want an 'appliance' format that stores a whole VM
>>> in a single file to ease VM
On 2018-06-06 15:45, Michal Suchánek wrote:
> On Wed, 6 Jun 2018 15:14:03 +0200
> Max Reitz wrote:
>
>> On 2018-06-06 14:13, Michal Suchánek wrote:
>>> On Wed, 6 Jun 2018 13:52:35 +0200
>>> Max Reitz wrote:
>>>
On 2018-06-06 13:43, Michal Suchánek wrote:
> On Wed, 6 Jun 2018
On Wed, Jun 06, 2018 at 02:50:10PM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 06, 2018 at 03:45:10PM +0200, Michal Suchánek wrote:
> >
> > I think that *if* we want an 'appliance' format that stores a whole VM
> > in a single file to ease VM distribution then the logical place to look
> > in
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 14:16, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 13:37, Dr. David Alan Gilbert wrote:
> >>> * Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 13:19, Michal Suchánek wrote:
> > On
On Wed, Jun 06, 2018 at 03:45:10PM +0200, Michal Suchánek wrote:
>
> I think that *if* we want an 'appliance' format that stores a whole VM
> in a single file to ease VM distribution then the logical place to look
> in qemu is qcow. The reason have been explained at length.
I rather disagree.
On Wed, 6 Jun 2018 15:14:03 +0200
Max Reitz wrote:
> On 2018-06-06 14:13, Michal Suchánek wrote:
> > On Wed, 6 Jun 2018 13:52:35 +0200
> > Max Reitz wrote:
> >
> >> On 2018-06-06 13:43, Michal Suchánek wrote:
> >>> On Wed, 6 Jun 2018 13:32:47 +0200
> >>> Max Reitz wrote:
> >>>
>
On Wed, Jun 06, 2018 at 01:44:02PM +0200, Max Reitz wrote:
> On 2018-06-06 13:37, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 13:19, Michal Suchánek wrote:
> >>> On Wed, 6 Jun 2018 13:02:53 +0200
> >>> Max Reitz wrote:
> >>>
> On 2018-06-06
On Wed, Jun 06, 2018 at 10:44:20AM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > On Tue, Jun 05, 2018 at 10:21:59AM +0100, Dr. David Alan Gilbert wrote:
> > >
> > >
> > > This seems to have fizzled out because of a lack of a concrete proposal;
> > > so
On 2018-06-06 14:03, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
>> On Wed, Jun 06, 2018 at 12:42:28PM +0100, Richard W.M. Jones wrote:
>>> On Wed, Jun 06, 2018 at 12:14:07PM +0100, Dr. David Alan Gilbert wrote:
The problem with having a separate file is
On 2018-06-06 14:13, Michal Suchánek wrote:
> On Wed, 6 Jun 2018 13:52:35 +0200
> Max Reitz wrote:
>
>> On 2018-06-06 13:43, Michal Suchánek wrote:
>>> On Wed, 6 Jun 2018 13:32:47 +0200
>>> Max Reitz wrote:
>>>
On 2018-06-06 13:19, Michal Suchánek wrote:
> On Wed, 6 Jun 2018
On 2018-06-06 14:00, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
>> On 2018-06-06 13:14, Dr. David Alan Gilbert wrote:
>>> * Max Reitz (mre...@redhat.com) wrote:
On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
>
>
> This seems to have fizzled out
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 13:37, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-06 13:19, Michal Suchánek wrote:
> >>> On Wed, 6 Jun 2018 13:02:53 +0200
> >>> Max Reitz wrote:
> >>>
> On 2018-06-06 12:32, Michal Suchánek
On Wed, 6 Jun 2018 13:52:35 +0200
Max Reitz wrote:
> On 2018-06-06 13:43, Michal Suchánek wrote:
> > On Wed, 6 Jun 2018 13:32:47 +0200
> > Max Reitz wrote:
> >
> >> On 2018-06-06 13:19, Michal Suchánek wrote:
> >>> On Wed, 6 Jun 2018 13:02:53 +0200
> >>> Max Reitz wrote:
> >>>
>
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Jun 06, 2018 at 12:42:28PM +0100, Richard W.M. Jones wrote:
> > On Wed, Jun 06, 2018 at 12:14:07PM +0100, Dr. David Alan Gilbert wrote:
> > > The problem with having a separate file is that you either have to copy
> > > it around with the
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 13:14, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
> >>>
> >>>
> >>> This seems to have fizzled out because of a lack of a concrete proposal;
> >>> so here
On 2018-06-06 13:48, Daniel P. Berrangé wrote:
> On Wed, Jun 06, 2018 at 12:42:28PM +0100, Richard W.M. Jones wrote:
>> On Wed, Jun 06, 2018 at 12:14:07PM +0100, Dr. David Alan Gilbert wrote:
>>> The problem with having a separate file is that you either have to copy
>>> it around with the image
On 2018-06-06 13:43, Michal Suchánek wrote:
> On Wed, 6 Jun 2018 13:32:47 +0200
> Max Reitz wrote:
>
>> On 2018-06-06 13:19, Michal Suchánek wrote:
>>> On Wed, 6 Jun 2018 13:02:53 +0200
>>> Max Reitz wrote:
>>>
On 2018-06-06 12:32, Michal Suchánek wrote:
> On Tue, 29 May 2018
On Wed, 6 Jun 2018 13:32:47 +0200
Max Reitz wrote:
> On 2018-06-06 13:19, Michal Suchánek wrote:
> > On Wed, 6 Jun 2018 13:02:53 +0200
> > Max Reitz wrote:
> >
> >> On 2018-06-06 12:32, Michal Suchánek wrote:
> >>> On Tue, 29 May 2018 12:14:15 +0200
> >>> Max Reitz wrote:
> >>>
>
On Wed, Jun 06, 2018 at 12:14:07PM +0100, Dr. David Alan Gilbert wrote:
> The problem with having a separate file is that you either have to copy
> it around with the image or have an archive. If you have an archive
> you have to have an unpacking step which then copies, potentially a lot
> of
On Wed, Jun 06, 2018 at 01:02:53PM +0200, Max Reitz wrote:
> (I'm wondering if we could write a block driver that could provide such
> a chunk allocation transparently to qcow2... Note that a qcow2 file
> does not need to be continuous, so you could in theory indeed store the
> qcow2 file and its
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-06 13:19, Michal Suchánek wrote:
> > On Wed, 6 Jun 2018 13:02:53 +0200
> > Max Reitz wrote:
> >
> >> On 2018-06-06 12:32, Michal Suchánek wrote:
> >>> On Tue, 29 May 2018 12:14:15 +0200
> >>> Max Reitz wrote:
> >>>
> On 2018-05-29
On 2018-06-06 13:19, Michal Suchánek wrote:
> On Wed, 6 Jun 2018 13:02:53 +0200
> Max Reitz wrote:
>
>> On 2018-06-06 12:32, Michal Suchánek wrote:
>>> On Tue, 29 May 2018 12:14:15 +0200
>>> Max Reitz wrote:
>>>
On 2018-05-29 08:44, Kevin Wolf wrote:
> Am 28.05.2018 um 23:25 hat
On 2018-06-06 13:14, Dr. David Alan Gilbert wrote:
> * Max Reitz (mre...@redhat.com) wrote:
>> On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
>>>
>>>
>>> This seems to have fizzled out because of a lack of a concrete proposal;
>>> so here is one based on a reply to Max's post:
>>>
>>> * Max
On Wed, Jun 06, 2018 at 13:02:56 +0200, Max Reitz wrote:
> On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
[...]
> > (I would suggest in layer2 that the keys are sorted, but
> > that's a pain to do in some json creators)
> >c) Forcing the registry of keys might avoid silly
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
> >
> >
> > This seems to have fizzled out because of a lack of a concrete proposal;
> > so here is one based on a reply to Max's post:
> >
> > * Max Reitz (mre...@redhat.com) wrote:
> >
> >
> >
> >>
On 2018-06-06 12:32, Michal Suchánek wrote:
> On Tue, 29 May 2018 12:14:15 +0200
> Max Reitz wrote:
>
>> On 2018-05-29 08:44, Kevin Wolf wrote:
>>> Am 28.05.2018 um 23:25 hat Richard W.M. Jones geschrieben:
On Mon, May 28, 2018 at 10:20:54PM +0100, Richard W.M. Jones
wrote:
>
On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:
>
>
> This seems to have fizzled out because of a lack of a concrete proposal;
> so here is one based on a reply to Max's post:
>
> * Max Reitz (mre...@redhat.com) wrote:
>
>
>
>> The original problem was that you need to supply a machine
On Tue, 29 May 2018 12:14:15 +0200
Max Reitz wrote:
> On 2018-05-29 08:44, Kevin Wolf wrote:
> > Am 28.05.2018 um 23:25 hat Richard W.M. Jones geschrieben:
> >> On Mon, May 28, 2018 at 10:20:54PM +0100, Richard W.M. Jones
> >> wrote:
> >>> On Mon, May 28, 2018 at 08:38:33PM +0200, Kevin Wolf
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Tue, Jun 05, 2018 at 10:21:59AM +0100, Dr. David Alan Gilbert wrote:
> >
> >
> > This seems to have fizzled out because of a lack of a concrete proposal;
> > so here is one based on a reply to Max's post:
> >
> > * Max Reitz
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Tue, Jun 05, 2018 at 03:09:17PM -0500, Eric Blake wrote:
> > On 06/05/2018 02:58 PM, Richard W.M. Jones wrote:
> > > > Binary blobs can always be base64 encoded for representation within
> > > > a valid JSON UTF-8 string (and we already have
Hi,
> Based on this proposal for layer 2, it looks like you expect the
> number of keys used on layer 1 to become large.
>
> I would prefer a solution that expects a very small set of keys
> for layer 0+1, and point to other specifications of how the blob
> can be interpreted for each key.
Hi,
> By binary I actually meant binary. The idea is you could
> store things like PNG images in them (for icons).
Guess if we go that route we also want store a mine-type for each entry.
cheers,
Gerd
On Wed, 23 May 2018 18:35:31 +0200
Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Wed, May 23, 2018 at 01:19:46PM +0200, Markus Armbruster wrote:
> >> Eduardo Habkost writes:
> >>
> >> > On Mon, May 21, 2018 at 07:44:40PM +0100, Daniel P. Berrangé
> >> > wrote:
> >> >> On
On Tue, Jun 05, 2018 at 03:46:45PM -0500, Eric Blake wrote:
> On 06/05/2018 03:28 PM, Michael S. Tsirkin wrote:
> > On Tue, Jun 05, 2018 at 03:09:17PM -0500, Eric Blake wrote:
> > > On 06/05/2018 02:58 PM, Richard W.M. Jones wrote:
> > > > > Binary blobs can always be base64 encoded for
On 06/05/2018 03:28 PM, Michael S. Tsirkin wrote:
On Tue, Jun 05, 2018 at 03:09:17PM -0500, Eric Blake wrote:
On 06/05/2018 02:58 PM, Richard W.M. Jones wrote:
Binary blobs can always be base64 encoded for representation within
a valid JSON UTF-8 string (and we already have several QMP
On Tue, Jun 05, 2018 at 03:09:17PM -0500, Eric Blake wrote:
> On 06/05/2018 02:58 PM, Richard W.M. Jones wrote:
> > > Binary blobs can always be base64 encoded for representation within
> > > a valid JSON UTF-8 string (and we already have several QMP
> > > interfaces that utilize base64 encoding
On 06/05/2018 02:58 PM, Richard W.M. Jones wrote:
Binary blobs can always be base64 encoded for representation within
a valid JSON UTF-8 string (and we already have several QMP
interfaces that utilize base64 encoding to pass through what is
otherwise invalid UTF-8). It does inflate things
On Tue, Jun 05, 2018 at 02:54:07PM -0500, Eric Blake wrote:
> On 06/05/2018 02:47 PM, Michael S. Tsirkin wrote:
>
> > > > Layer 1:
> > > > The string shall always be a JSON 'object'; i.e. of the form
> > > > { "something": ... , "more": ... }
> > > >
> > > > The key strings shall be
On Tue, Jun 05, 2018 at 02:54:07PM -0500, Eric Blake wrote:
> On 06/05/2018 02:47 PM, Michael S. Tsirkin wrote:
>
> >>>Layer 1:
> >>>The string shall always be a JSON 'object'; i.e. of the form
> >>> { "something": ... , "more": ... }
> >>>
> >>>The key strings shall be non-null and
On 06/05/2018 02:47 PM, Michael S. Tsirkin wrote:
Layer 1:
The string shall always be a JSON 'object'; i.e. of the form
{ "something": ... , "more": ... }
The key strings shall be non-null and non-empty and shall
be unique.
I think it would be simpler if layer 0 simply
On Tue, Jun 05, 2018 at 04:03:24PM -0300, Eduardo Habkost wrote:
> On Tue, Jun 05, 2018 at 10:21:59AM +0100, Dr. David Alan Gilbert wrote:
> >
> >
> > This seems to have fizzled out because of a lack of a concrete proposal;
> > so here is one based on a reply to Max's post:
> >
> > * Max Reitz
1 - 100 of 146 matches
Mail list logo
