[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |