On Wed, Aug 04, 2021 at 03:32:16PM +0100, Daniel P. Berrangé wrote: > On Wed, Aug 04, 2021 at 11:54:07AM +0200, Pavel Hrdina wrote: > > 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@xxxxxxxxxx> > > > > > > --- > > > > > > 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." > > IIUC, the implication is that the VMID associated with QEMU gets > associated with I/O issued from any <disk> devices that happen to > be backed by the fibre channel HBA consuming it. > > > 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". > > Ok, so the "group of VMs can share the VMID" eliminates the option > of unconditionally using the VM UUID. > > > I'm inclined to suggest that we put it inside the <resource> element, > since it is essentially a tunable for FC resource control. > > eg something like > > <resource> > <fibrechannel appid="...."/> > </resouce> Sounds reasonable as this is somehow related to cgroups and we already have <partition> there. Thanks! I'll post v2 as I like this better as well. Pavel
Attachment:
signature.asc
Description: PGP signature
