[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



Paul Durrant writes ("RE: [PATCH RESEND] tools/libxl: add support for emulated 
NVMe drives"):
> > From: Ian Jackson [mailto:ian.jackson@xxxxxxxxxxxxx]
> > That's not my point.  The purpose of this table is to advise guests
> > what the conventional in-guest device name ought to be for a certain
> > vbd.
> 
> Yes, and xvd<something> is a perfectly fine name for a PV device in pretty 
> much every case. It's already the case that emulated IDE disks are exposed to 
> guests using xvd* numbering.

No, I don't think so:

/libxl/5/device/vbd/5632/params = 
"aio:/root/68254.test-amd64-amd64-xl-qemuu-debianhvm-amd64.debianhvm-em\..."
(n0)

5632 = 22 << 8 | 0 ie "hd, disk 2, partition 0"

Some operating systems (including many recent Linux kernels) present
all vbds as xvd*.

> > Presumably these NVME devices should be subject to the same vbd and
> > unplug approach as scsi and ide disks.
> 
> Yes, that's what the QEMU patch does.

So maybe they should reuse the hd* numbering ?

> That means modifications to PV frontends would be needed, which is
> going to make things more difficult. Most OS find disks by UUID
> these days anyway so I'm still not sure that just using xvd*
> numbering would really be a problem.

In terms of the "nominal disk type" discussed in
xen-vbd-interface.markdown.7, I don't think these emulated devices,
which get unplugged, should be have a "nomainl disk type" of "Xen
virtual disk".

Ian.

_______________________________________________
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®.