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 visio
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 may
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 us
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
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 w
* 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 portabl
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 14:00,
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 imp
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 exampl
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 t
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 UEFI
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 management
* 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 c
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, the
* 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
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 does
* 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 re
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 r
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 quite
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 that for q35
> > guests using EFI as well as aa
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 wel
* 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 hi
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 parit
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 ea
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, al
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 beca
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
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 publi
* 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 UUID
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 co
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 e
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 larger
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]) a
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 ne
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 file stores the whole
> VM. This is exactly what I
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 conta
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 should
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 fi
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
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 think.
* Daniel P. Berrangé (berra...@redhat.com) 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
* 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 tar
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:
>> On
* 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 qcow2
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 distri
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 13:32:
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 q
* 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 W
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. Thi
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 12:3
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: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 Wed, 6 Jun 2018 13:02:53 +0200
> Max Reitz wrot
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 t
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 13:02:
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 beca
On Wed, Jun 06, 2018 at 12:48:17PM +0100, 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
> > > i
* 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 w
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 is
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 or
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 12:14
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 or have an archive. If you have an archive
> > you
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 wrote:
> On Tue, 29 May 2018 12:14:15 +0200
>
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 dat
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 08:44
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 Ri
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 Re
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 dupl
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 Richard W.M. Jones geschrieben:
> On Mon, Ma
* 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:
> >
> >
> >
> >> T
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
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 typ
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 (mre...@redhat.com)
* 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 severa
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. Thi
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 M
1 - 100 of 154 matches
Mail list logo