Libvirt NVME support

Thanos Makatos thanos.makatos at nutanix.com
Mon Nov 23 13:07:51 UTC 2020


> On Mon, Nov 23, 2020 at 09:47:23 +0000, Thanos Makatos wrote:
> > > On Thu, Nov 19, 2020 at 10:17:56 +0000, Thanos Makatos wrote:
> > > > > As a starting point a trivial way to model this in the XML will be:
> > > > >
> > > > >     <controller type='nvme' index='1' model='nvme'>
> > > > >
> > > > > And then add the storage into it as:
> > > > >
> > > > >     <disk type='file' device='disk'>
> > > > >       <source dev='/Host/QEMUGuest1.qcow2'/>
> > > > >       <target dev='sda' bus='nvme'/>
> > > >
> > > > 'target dev' is how the device appears in the guest, right? It should be
> > > > something like 'nvme0n1'. I'm  not sure though this is something that
> we
> > > can
> > > > put here anyway, I think the guest driver can number controllers
> arbitrarily.
> > >
> > > Well, it was supposed to be like that but really is not. Even with other
> > > buses the kernel can name the device arbitrarily, so it doesn't really
> > > matter.
> > >
> > > > Maybe we should specify something like BDF? Or is this something
> QEMU
> > > will
> > > > have to figure out how to do?
> > > >
> > > > >       <address type='drive' controller='1' bus='0' target='0' unit='0'/>
> > > > >     </disk>
> > > > >
> > > > >     <disk type='file' device='disk'>
> > > > >       <source dev='/Host/QEMUGuest2.qcow2'/>
> > > > >       <target dev='sdb' bus='nvme'/>
> > > > >       <address type='drive' controller='1' bus='0' target='0' unit='1'/>
> > > > >     </disk>
> >
> > Revistiting your initial suggestion, it should be something like this
> > (s/sdb/nvme0):
> >
> >     <disk type='file' device='disk'>
> >       <source dev='/Host/QEMUGuest2.qcow2'/>
> >       <target dev='nvme0' bus='nvme'/>
> >       <address type='drive' controller='1' bus='0' target='0' unit='1'/>
> >     </disk>
> 
> Note that the parser for 'dev' is a bit quirky, old, and used in many
> places besides the qemu driver. It's also used with numbers in non-qemu
> cases. Extending that to parse numbers for nvme but not for sda might
> become ugly very quickly. Sticking with a letter at the end ('nvmea'
> might be a more straightforward approach.

Then I think we should just stick with 'nvme'.

> 
> >
> > > > >
> > > > > The 'drive' address here maps the disk to the controller. This example
> >
> > IIUC we need a way to associate storage (this XML snippet) with the
> controller
> > you defined earlier (<controller type='nvme' index='1' model='nvme'>). So
> > shouldn't we only require associating this piece of storage with the
> controller
> > based on the index?
> 
> No. The common approach is to do it via what's specified as <address>
> 
> >
> > > > > uses unit= as the way to specify the namespace ID. Both 'bus' and
> 'target'
> > > > > must be 0.
> >
> > I think 'namespace' or 'ns' would be more suitable instead of 'unit'.
> > What are 'bus' and 'target' here? And why do they have to be 0?
> > Do we really need dev='nvme0' in <target ...>? Specifying the controller
> index
> > should be enough, no?
> 
> You certainly can add <address type='nvme' controller='1' ns='2'/>
> 
> > Wouldn't this contain the minimum amount of information to
> unambiguously map
> > this piece of storage to the controller?
> >
> >     <disk type='file' device='disk'>
> >       <source dev='/Host/QEMUGuest2.qcow2'/>
> >       <target dev='sdb' bus='nvme'/>
> >       <address controller='1' ns='1'/>
> >     </disk>
> 
> That certainly is correct if you include the "type='nvme'" attribute.

Great, so the following would be a good place for us to start?

        <controller type='nvme' index='1' model='nvme'>

        <disk type='file' device='disk'>
          <source dev='/Host/QEMUGuest2.qcow1'/>
          <target dev='nvme' bus='nvme'/>
          <address type='nvme' controller='1' ns='1'/>
        </disk>

        <disk type='file' device='disk'>
          <source dev='/Host/QEMUGuest2.qcow2'/>
          <target dev='nvme' bus='nvme'/>
          <address type='nvme' controller='1' ns='2'/>
        </disk>





More information about the libvir-list mailing list