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

Re: [Xen-devel] [PATCH RESEND] tools/libxl: add support for emulated NVMe drives



On Wed, Jan 18, 2017 at 12:15:22PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> > Sent: 18 January 2017 12:02
> > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> > Cc: Wei Liu <wei.liu2@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; Ian
> > Jackson <Ian.Jackson@xxxxxxxxxx>
> > Subject: Re: [PATCH RESEND] tools/libxl: add support for emulated NVMe
> > drives
> > 
> [snip]
> > > > >
> > > > > -   For HVM guests, each whole-disk hd* and and sd* device is made
> > > > > -   available _both_ via emulated IDE resp. SCSI controller, _and_ as 
> > > > > a
> > > > > -   Xen VBD.  The HVM guest is entitled to assume that the IDE or SCSI
> > > > > -   disks available via the emulated IDE controller target the same
> > > > > +   For HVM guests, each whole-disk hd*, sd* or nvme* device is made
> > > > > +   available _both_ via emulated IDE, SCSI controller or NVMe drive
> > > > > +   respectively _and_ as a Xen VBD.  The HVM guest is entitled to
> > > > > +   assume that the disks available via the emulation target the same
> > > >
> > > > How do you expect the guest to deal with multipath NVMe devices?
> > Maybe
> > > > we need to add unplug support for NVMe devices in QEMU?
> > >
> > > That's true. For convenience, there would need to a QEMU patch for
> > unplug to allow displacement of the emulated device with PV. I can
> > document this as a shortcoming at the moment, if that's ok?
> > >
> > 
> > The unplug functionality, as I understand, is crucial to data integrity.
> > Documenting this as shortcoming doesn't seem to be good enough.  Do we
> > need to wait until QEMU is ready before we can apply this patch?
> 
> It will take time to get a patch into QEMU and if you're going to use
> PV drivers then you have little interest in the emulation model. I
> think just documenting it would be ok.

This is OK provided there is no safety issue. If we can't rule that out,
...

> For safety I guess I could explore the possibility of having libxl not
> create a PV backend for this vdev type.

... this is the best option for now.

Wei.

> 
>   Paul
> 
> > 
> > Wei.
> > 
> > 
> > >   Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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