[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v7 16/18] xen: automatically create XenBlockDevice-s



> -----Original Message-----
> From: Anthony PERARD [mailto:anthony.perard@xxxxxxxxxx]
> Sent: 08 January 2019 13:28
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: 'Kevin Wolf' <kwolf@xxxxxxxxxx>; qemu-devel@xxxxxxxxxx; qemu-
> block@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx; Max Reitz
> <mreitz@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>
> Subject: Re: [PATCH v7 16/18] xen: automatically create XenBlockDevice-s
> 
> On Tue, Jan 08, 2019 at 01:07:49PM +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Kevin Wolf [mailto:kwolf@xxxxxxxxxx]
> > > Sent: 08 January 2019 12:53
> > > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> > > Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>; qemu-devel@xxxxxxxxxx;
> > > qemu-block@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx; Max Reitz
> > > <mreitz@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > Subject: Re: [PATCH v7 16/18] xen: automatically create
> XenBlockDevice-s
> > >
> > > Am 04.01.2019 um 17:40 hat Paul Durrant geschrieben:
> > > > > -----Original Message-----
> > > > > From: Anthony PERARD [mailto:anthony.perard@xxxxxxxxxx]
> > > > > Sent: 04 January 2019 16:31
> > > > > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> > > > > Cc: qemu-devel@xxxxxxxxxx; qemu-block@xxxxxxxxxx; xen-
> > > > > devel@xxxxxxxxxxxxxxxxxxxx; Kevin Wolf <kwolf@xxxxxxxxxx>; Max
> Reitz
> > > > > <mreitz@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > > > Subject: Re: [PATCH v7 16/18] xen: automatically create
> > > XenBlockDevice-s
> > > > >
> > > > > Almost done, there is one thing left which I believe is an issue.
> > > > > Whenever I attach a raw file to QEMU, it print:
> > > > >     qemu-system-i386: warning: Opening a block device as a file
> using
> > > the
> > > > > 'file' driver is deprecated
> > > >
> > > > Oh, I'd not noticed that... but then I only use raw files
> occasionally.
> > >
> > > Strictly speaking, this is not about raw (regular) files, but raw
> block
> > > devices. 'file' is fine for actual regular files, but the protocol
> > > driver for block devices is 'host_device'.
> > >
> > > > > raw files should use the "raw" driver, so we aren't done yet.
> > > >
> > > > Ok. Having a strictly 2-layer stack actually makes things simpler
> anyway
> > > :-)
> > >
> > > Using 'raw' there will make the block layer auto-detect the right
> > > protocol layer, so this works. If you want to avoid the second layer,
> > > you'd have to figure out manually whether to use 'file' or
> > > 'host_device'.
> >
> > Thanks for the explanation. I'll give it a spin using a device... I've
> posted v8 but, given what you say, I'm still not sure I have it right.
> 
> Indeed, in v8, even with the extra 'raw' layer, the warning is still
> there. I was trying to understand why, and I only found out today that
> we would need to use the 'host_device' driver as explain by Kevin.
> 
> 
> BTW Paul, we can simplify the code that manage layers, by not managing
> them.
> Instead of (in JSON / QMP term):
>     { 'driver': 'file', 'filename': '/file', 'node-name': 'node-file' }
>     { 'driver': 'qcow2', 'file': 'node-file', 'node-name': 'node-qcow2' }
> we can have:
>     { 'driver': 'qcow2', 'node-name': 'node-qcow2',
>       'file': { 'driver': 'file', 'filename': '/file' } }
>

I kind of like the clean separation though... From what Kevin said, it sounds 
like the lowest layer should use 'raw' instead of 'file' to DTRT, and then we 
should be back to only needing the single layer in that case. I'll revert back 
to v7 and give it a try.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.