Re: [libvirt PATCH 2/3] conf: introduce support for Fibre Channel VMID
On Wed, Aug 04, 2021 at 10:32:00AM +0100, Daniel P. Berrangé wrote:
On Wed, Aug 04, 2021 at 11:19:35AM +0200, Pavel Hrdina wrote:
> On Wed, Aug 04, 2021 at 10:09:30AM +0100, Daniel P. Berrangé wrote:
> > On Tue, Aug 03, 2021 at 04:29:32PM +0200, Pavel Hrdina wrote:
> > > Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com>
> > > ---
> > > docs/formatdomain.rst | 13 +++++++++++++
> > > docs/schemas/domaincommon.rng | 11 +++++++++++
> > > src/conf/domain_conf.c | 5 +++++
> > > src/conf/domain_conf.h | 2 ++
> > > src/conf/domain_validate.c | 19 +++++++++++++++++++
> > > tests/genericxml2xmlindata/vmid.xml | 19 +++++++++++++++++++
> > > tests/genericxml2xmltest.c | 2 ++
> > > 7 files changed, 71 insertions(+)
> > > create mode 100644 tests/genericxml2xmlindata/vmid.xml
> >
> > > diff --git a/tests/genericxml2xmlindata/vmid.xml
b/tests/genericxml2xmlindata/vmid.xml
> > > new file mode 100644
> > > index 0000000000..df984df3f5
> > > --- /dev/null
> > > +++ b/tests/genericxml2xmlindata/vmid.xml
> > > @@ -0,0 +1,19 @@
> > > +<domain type='qemu'>
> > > + <name>QEMUGuest1</name>
> > > + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
> > > + <memory unit='KiB'>219100</memory>
> > > + <currentMemory unit='KiB'>219100</currentMemory>
> > > + <vcpu placement='static'>4</vcpu>
> > > + <os>
> > > + <type arch='x86_64'
machine='q35'>hvm</type>
> > > + <boot dev='hd'/>
> > > + </os>
> > > + <clock offset='utc'/>
> > > + <vmid>someapp:c7a5fdbd-edaf-9455-926a-d65c16db1809</vmid>
> >
> > I'm not convinced by adding this element here with this name.
> >
> > It is rather too generic and doesn't really give any suggestion
> > as to what it is used for.
>
> I was struggling with that as well. To be honest I don't know where to
> put it. In downstream BZ there was suggestion to place it under
> <blkiotune> but this is not tunning any IO so I don't thing it should
> belong there. We can move it closer to UUID and GENID and all this ID
> elements. Any idea is welcome :).
I'm struggling to find info on what this attribute actally does in
practice, and/or what format it is required to be in.
I was wondering what would happen if we simply wrote the VM UUID
into this attribute unconditionally, and thus avoid need for an
XML element ?
Right, should have provided some links probably, always forget to do
that. We need to have it in XML as users will provide their own VMID
and it can be anything, ti doesn't have to be VM UUID but it can be
part of it. I was not able to find any specification, only some mentions
from HW vendors:
[1] "Virtual-machine awareness: The MDS 9148T provides visibility into
all virtual machines that are accessing the storage LUNs in the fabric.
This feature is available through HBAs capable of priority tagging the
Virtual Machine Identifier (VMID) on every Fibre Channel frame.
Virtual-machine awareness can be extended to intelligent fabric services
such as analytics1 to visualize performance of every flow originating
from each virtual machine in the fabric."
[2] "Provides visibility into each virtual machine logged into the
fabric through HBAs capable of priority tagging the Virtual Machine
Identifier (VMID) on every FC frame."
Fibre Channel VMID is can be included in every FC frame which allows
monitoring or QoS and other things based on the VMID provided by users.
The VMID can contain anything so a group of VMs can share the same VMID,
for example "database". Or to allow per application and VM tracking
another example is "database:$UUID".
Originally before I started working on this feature I thought that the
VM UUID will be added automatically to the user provided string but I
realized that assumption was incorrect as the user doesn't necessarily
want to or need to have the UUID as part of the FC VMID.
I was just straggling how to model this in the XML.
Pavel
[1]
<https://www.cisco.com/c/en/us/products/collateral/storage-networking/mds-...
[2]
<https://buy.hpe.com/za/en/storage/storage-networking/c-series-switches/c-...
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)