2:52 p.m.
The SMBIOS data are a standardized set of data structures available
in the BIOS area of PCs. Those blocks of data describe things like
BIOS version informations, machine vendor, model and identifiers,
as well as various parts of the machine capability. On a linux
machine running dmidecode allows to dump those informations.
Spec available at the DMTF: http://dmtf.org/standards/smbios
From a virtualization POV, it's mostly the first block describing
the BIOS named "type 0" and the second block describing the machine
named "type 1" which are of interest. Those data are usually accessed
either from the OS or from management application, and being able to
override the default setings may be needed for such management.
The suggested XML description follows the logical structure of the
data, one top smbios description, with one or more blocks, each
containing the entries, the example below gives an idea:
<smbios>
<table type="0">
<entry name="Vendor">QEmu/KVM</entry>
<entry name="Version">0.13</entry>
</table>
<table type="1">
<entry name="Manufacturer">Fedora</entry>
<entry name="Product">Virt-Manager</entry>
<entry name="Version">0.8.2-3.fc14</entry>
<entry name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
</table>
</smbios>
The patch serie includes:
- the change to the doamin schemas
- the code to parse this in config structure
- the QEmu driver part
- a test example
Currently missing is the conf code to save the data back, and
documentation for the domain extension. I think it's possible
set some of those settings in Xen too, but I don't know if I will
take the time of a driver for it. For ESX it seems there is an option
to inherit some of the SMBIOS data from the host on the guest but
I'm not sure some of the fields can be manipulated directly. I don't
know what VirtualBox can set there either,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
3:13 p.m.
New subject: [libvirt] [PATCH] 1/4 SMBIOS XML format extension
The suggested XML description follows the logical structure of the
data, one top smbios description, with one or more blocks, each
containing the entries, the example below gives an idea:
<smbios>
<table type="0">
<entry name="Vendor">QEmu/KVM</entry>
<entry name="Version">0.13</entry>
</table>
<table type="1">
<entry name="Manufacturer">Fedora</entry>
<entry name="Product">Virt-Manager</entry>
<entry name="Version">0.8.2-3.fc14</entry>
<entry name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
</table>
</smbios>
I didn't tried in the RNG and in the conf parser in general to wire
down the description to the very limited set actually allowed by QEmu,
but tried to stay generic. However a lot of the smbios data has
'no serviceable parts' inside, and is mostly a binary blob with various
data encoded in binary, but I think the above model is sufficiently
flexible and common to allow setting other various types of data.
To avoid problems with space normalization in attribute values, I
preferred to encode the entry content as text node chidren of entries
rather than use an attribute. The name descriptions used by the
standard are simple enough that they should not be a problem in
attributes.
In the schemas I currently limit to only type 0 and 1, I could remove
that and limit to 0..32 since that's the set allowed by the spec, but
other blocks are a priori harder to use in virtualization at least when
and user describes a domain.
Daniel
diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng
index a934a77..a42961c 100644
--- a/docs/schemas/domain.rng
+++ b/docs/schemas/domain.rng
@@ -30,6 +30,9 @@
<optional>
<ref name="cpu"/>
</optional>
+ <optional>
+ <ref name="smbios"/>
+ </optional>
<ref name="os"/>
<ref name="clock"/>
<ref name="resources"/>
@@ -1746,6 +1749,51 @@
</element>
</define>
+ <!--
+ SMBIOS specification
+ The DMTF spec doesn't specify any string subset, just 0 terminated
+ byte strings, but better be safe and restrict at least the names
+ to avoid problems with space normalization in attribute values,
+ the value is kept as the element body for maximum flexibility.
+ A priori we allow only type 0 and type 1 string updates
+ -->
+ <define name="smbios">
+ <element name="smbios">
+ <zeroOrMore>
+ <element name="table">
+ <attribute name="type">
+ <ref name="smbios-type"/>
+ </attribute>
+ <oneOrMore>
+ <element name="entry">
+ <attribute name="name">
+ <ref name="smbios-name"/>
+ </attribute>
+ <ref name="smbios-value"/>
+ </element>
+ </oneOrMore>
+ </element>
+ </zeroOrMore>
+ </element>
+ </define>
+
+ <define name="smbios-type">
+ <data type="int">
+ <param name="minInclusive">0</param>
+ <param name="maxInclusive">1</param>
+ </data>
+ </define>
+
+ <define name="smbios-name">
+ <data type="string">
+ <param name='pattern'>[a-zA-Z0-9\-_\. ]+</param>
+ </data>
+ </define>
+
+ <define name="smbios-value">
+ <data type="string"/>
+ </define>
+
<define name="address">
<element name="address">
<choice>
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
4:35 p.m.
New subject: [libvirt] [PATCH] 1/4 SMBIOS XML format extension
On 10/21/2010 02:13 PM, Daniel Veillard wrote:
The suggested XML description follows the logical structure of
the
data, one top smbios description, with one or more blocks, each
containing the entries, the example below gives an idea:
<smbios>
<table type="0">
<entry name="Vendor">QEmu/KVM</entry>
<entry name="Version">0.13</entry>
</table>
<table type="1">
<entry name="Manufacturer">Fedora</entry>
<entry name="Product">Virt-Manager</entry>
<entry name="Version">0.8.2-3.fc14</entry>
<entry name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
</table>
</smbios>
Seems reasonable to me.
+<define name="smbios-name">
+<data type="string">
+<param name='pattern'>[a-zA-Z0-9\-_\. ]+</param>
^^^
Is that the range of characters from \ to _, or is just the two
characters - and _?
Currently missing is the conf code to save the data back, and
documentation for the domain extension.
Indeed.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
3:40 a.m.
New subject: [libvirt] [PATCH] 1/4 SMBIOS XML format extension
On Thu, Oct 21, 2010 at 03:35:37PM -0600, Eric Blake wrote:
On 10/21/2010 02:13 PM, Daniel Veillard wrote:
> The suggested XML description follows the logical structure of the
>data, one top smbios description, with one or more blocks, each
>containing the entries, the example below gives an idea:
>
> <smbios>
> <table type="0">
> <entry name="Vendor">QEmu/KVM</entry>
> <entry name="Version">0.13</entry>
> </table>
> <table type="1">
> <entry name="Manufacturer">Fedora</entry>
> <entry name="Product">Virt-Manager</entry>
> <entry name="Version">0.8.2-3.fc14</entry>
> <entry
name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
> </table>
> </smbios>
Seems reasonable to me.
>+<define name="smbios-name">
>+<data type="string">
>+<param name='pattern'>[a-zA-Z0-9\-_\. ]+</param>
^^^
Is that the range of characters from \ to _, or is just the two
characters - and _?
just the two characters, \is an escape code to avoid the sequence
>Currently missing is the conf code to save the data back, and
>documentation for the domain extension.
Indeed.
TODO :-)
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
3:16 p.m.
New subject: [libvirt] [PATCH] 2/4 Add conf parsing and freeing
This lacks the saving of the smbios data, should not be hard really,
and the parsing is rather trivial, the data structures follow the XML
format:
Daniel
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 5499f28..9dff0f7 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -606,6 +606,29 @@ struct _virDomainMemballoonDef {
};
+
+typedef struct _virSmbiosEntry virSmbiosEntry;
+typedef virSmbiosEntry *virSmbiosEntryPtr;
+struct _virSmbiosEntry {
+ virSmbiosEntryPtr next;
+ char *name;
+ char *value;
+};
+
+typedef struct _virSmbiosBlock virSmbiosBlock;
+typedef virSmbiosBlock *virSmbiosBlockPtr;
+struct _virSmbiosBlock {
+ unsigned int type;
+ virSmbiosEntryPtr entries;
+};
+
+typedef struct _virSmbiosDef virSmbiosDef;
+typedef virSmbiosDef *virSmbiosDefPtr;
+struct _virSmbiosDef {
+ unsigned int nbblocks;
+ virSmbiosBlockPtr *blocks;
+};
+
/* Flags for the 'type' field in next struct */
enum virDomainDeviceType {
VIR_DOMAIN_DEVICE_DISK,
@@ -943,6 +966,7 @@ struct _virDomainDef {
virDomainWatchdogDefPtr watchdog;
virDomainMemballoonDefPtr memballoon;
virCPUDefPtr cpu;
+ virSmbiosDefPtr smbios;
void *namespaceData;
virDomainXMLNamespace ns;
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index a997e06..fd85398 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -712,6 +712,48 @@ virDomainClockDefClear(virDomainClockDefPtr def)
VIR_FREE(def->timers);
}
+static void virSmbiosEntriesFree(virSmbiosEntryPtr cur)
+{
+ virSmbiosEntryPtr next;
+
+ if (cur == NULL)
+ return;
+
+ while (cur != NULL) {
+ next = cur->next;
+
+ VIR_FREE(cur->name);
+ VIR_FREE(cur->value);
+ VIR_FREE(cur);
+
+ cur = next;
+ }
+}
+
+static void virSmbiosBlockFree(virSmbiosBlockPtr block)
+{
+ if (block == NULL)
+ return;
+
+ virSmbiosEntriesFree(block->entries);
+ VIR_FREE(block);
+}
+
+static void virSmbiosDefFree(virSmbiosDefPtr def)
+{
+ unsigned int i;
+
+ if (def == NULL)
+ return;
+
+ if (def->blocks != NULL) {
+ for (i = 0;i < def->nbblocks;i++)
+ virSmbiosBlockFree(def->blocks[i]);
+ VIR_FREE(def->blocks);
+ }
+ VIR_FREE(def);
+}
+
void virDomainDefFree(virDomainDefPtr def)
{
unsigned int i;
@@ -796,6 +838,8 @@ void virDomainDefFree(virDomainDefPtr def)
virCPUDefFree(def->cpu);
+ virSmbiosDefFree(def->smbios);
+
if (def->namespaceData && def->ns.free)
(def->ns.free)(def->namespaceData);
@@ -3341,6 +3385,150 @@ error:
goto cleanup;
}
+static virSmbiosEntryPtr
+virSmbiosEntryParseXML(xmlXPathContextPtr ctxt)
+{
+ char *name, *value;
+ virSmbiosEntryPtr def;
+
+ name = virXPathString("string(./@name)", ctxt);
+ if (name == NULL) {
+ virDomainReportError(VIR_ERR_XML_ERROR, "%s",
+ _("XML element 'entry' requires a 'name'
attrbute"));
+ return(NULL);
+ }
+ value = virXPathString("string(.)", ctxt);
+ if (value == NULL) {
+ virDomainReportError(VIR_ERR_XML_ERROR, "%s",
+ _("failed to get content of element 'entry'"));
+ VIR_FREE(name);
+ return(NULL);
+ }
+
+ if (VIR_ALLOC(def) < 0) {
+ virReportOOMError();
+ VIR_FREE(name);
+ VIR_FREE(value);
+ return(NULL);
+ }
+ def->name = name;
+ def->value = value;
+ def->next = NULL;
+
+ return(def);
+}
+
+static virSmbiosBlockPtr
+virSmbiosBlockParseXML(xmlXPathContextPtr ctxt)
+{
+ virSmbiosBlockPtr def;
+ virSmbiosEntryPtr cur, next;
+ xmlNodePtr *nodes = NULL;
+ int n;
+ unsigned int i;
+ long type;
+
+ if (virXPathLong("string(./@type)", ctxt, &type) < 0) {
+ virDomainReportError(VIR_ERR_XML_ERROR, "%s",
+ _("XML element 'table' requires a numeric 'type'
attrbute"));
+ return(NULL);
+ }
+ if ((type < 0) || (type > 32)) {
+ virDomainReportError(VIR_ERR_XML_ERROR,
+ _("XML 'type' attribute on 'table' out of 0..32 range
got %ld"),
+ type);
+ return(NULL);
+ }
+ n = virXPathNodeSet("./entry", ctxt, &nodes);
+ if (n <= 0)
+ return(NULL);
+
+ if (VIR_ALLOC(def) < 0) {
+ virReportOOMError();
+ goto error;
+ }
+ def->type = (unsigned int) type;
+ def->entries = NULL;
+ cur = NULL;
+
+ for (i = 0;i < n;i++) {
+ if (nodes[i] != NULL) {
+ ctxt->node = nodes[i];
+ next = virSmbiosEntryParseXML(ctxt);
+ if (next == NULL)
+ goto error;
+ if (cur == NULL) {
+ def->entries = next;
+ cur = next;
+ } else {
+ cur->next = next;
+ cur = next;
+ }
+ cur->next = NULL;
+ }
+ }
+
+cleanup:
+ xmlFree(nodes);
+ return(def);
+
+error:
+ virSmbiosBlockFree(def);
+ def = NULL;
+ goto cleanup;
+}
+
+static virSmbiosDefPtr
+virSmbiosParseXML(const xmlNodePtr node,
+ xmlXPathContextPtr ctxt)
+{
+ virSmbiosDefPtr def;
+ virSmbiosBlockPtr block;
+ xmlNodePtr *nodes = NULL;
+ int n;
+ unsigned int i, j;
+
+ if (!xmlStrEqual(node->name, BAD_CAST "smbios")) {
+ virDomainReportError(VIR_ERR_XML_ERROR, "%s",
+ _("XML does not contain expected 'smbios'
element"));
+ return(NULL);
+ }
+
+ n = virXPathNodeSet("./table", ctxt, &nodes);
+ if (n <= 0)
+ return(NULL);
+
+ if (VIR_ALLOC(def) < 0) {
+ virReportOOMError();
+ goto error;
+ }
+ if (VIR_ALLOC_N(def->blocks, n) < 0) {
+ virReportOOMError();
+ goto error;
+ }
+
+ for (i = 0, j = 0;i < n;i++) {
+ if (nodes[i] != NULL) {
+ ctxt->node = nodes[i];
+ block = virSmbiosBlockParseXML(ctxt);
+ if (block != NULL)
+ def->blocks[j++] = block;
+ else
+ goto error;
+ def->nbblocks = j;
+ }
+ }
+
+
+cleanup:
+ xmlFree(nodes);
+ return(def);
+
+error:
+ virSmbiosDefFree(def);
+ def = NULL;
+ goto cleanup;
+}
int
virDomainVideoDefaultRAM(virDomainDefPtr def,
@@ -4970,6 +5158,16 @@ static virDomainDefPtr virDomainDefParseXML(virCapsPtr caps,
goto error;
}
+ if ((node = virXPathNode("./smbios[1]", ctxt)) != NULL) {
+ xmlNodePtr oldnode = ctxt->node;
+ ctxt->node = node;
+ def->smbios = virSmbiosParseXML(node, ctxt);
+ ctxt->node = oldnode;
+
+ if (def->smbios == NULL)
+ goto error;
+ }
+
/* we have to make a copy of all of the callback pointers here since
* we won't have the virCaps structure available during free
*/
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
4:45 p.m.
New subject: [libvirt] [PATCH] 2/4 Add conf parsing and freeing
On 10/21/2010 02:16 PM, Daniel Veillard wrote:
This lacks the saving of the smbios data, should not be hard
really,
and the parsing is rather trivial, the data structures follow the XML
format:
Daniel
+static void virSmbiosEntriesFree(virSmbiosEntryPtr cur)
Should this function be added to the list of useless_free_options in cfg.mk?
+{
+ virSmbiosEntryPtr next;
+
+ if (cur == NULL)
+ return;
Redundant, given that
+
+ while (cur != NULL) {
this safely skips a NULL argument.
@@ -3341,6 +3385,150 @@ error:
goto cleanup;
}
+static virSmbiosEntryPtr
+virSmbiosEntryParseXML(xmlXPathContextPtr ctxt)
+{
+ char *name, *value;
+ virSmbiosEntryPtr def;
+
+ name = virXPathString("string(./@name)", ctxt);
+ if (name == NULL) {
+ virDomainReportError(VIR_ERR_XML_ERROR, "%s",
+ _("XML element 'entry' requires a 'name'
attrbute"));
s/attrbute/attribute/
+
+static virSmbiosBlockPtr
+virSmbiosBlockParseXML(xmlXPathContextPtr ctxt)
+{
+ virSmbiosBlockPtr def;
+ virSmbiosEntryPtr cur, next;
+ xmlNodePtr *nodes = NULL;
+ int n;
+ unsigned int i;
+ long type;
+
+ if (virXPathLong("string(./@type)", ctxt,&type)< 0) {
+ virDomainReportError(VIR_ERR_XML_ERROR, "%s",
+ _("XML element 'table' requires a numeric 'type'
attrbute"));
s/attrbute/attribute/
+ return(NULL);
+ }
+ if ((type< 0) || (type> 32)) {
+ virDomainReportError(VIR_ERR_XML_ERROR,
+ _("XML 'type' attribute on 'table' out of 0..32 range
got %ld"),
+ type);
+ return(NULL);
+ }
Should you also be checking for duplicate types, or is it okay to do:
<smbios>
<table type="0">
<entry name="Vendor">QEmu/KVM</entry>
</table>
<table type="0">
<entry name="Version">0.13</entry>
</table>
</smbios>
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
3:47 a.m.
New subject: [libvirt] [PATCH] 2/4 Add conf parsing and freeing
On Thu, Oct 21, 2010 at 03:45:40PM -0600, Eric Blake wrote:
On 10/21/2010 02:16 PM, Daniel Veillard wrote:
> This lacks the saving of the smbios data, should not be hard really,
>and the parsing is rather trivial, the data structures follow the XML
>format:
>
>Daniel
>
>
>+static void virSmbiosEntriesFree(virSmbiosEntryPtr cur)
Should this function be added to the list of useless_free_options in cfg.mk?
>+{
>+ virSmbiosEntryPtr next;
>+
>+ if (cur == NULL)
>+ return;
Redundant, given that
>+
>+ while (cur != NULL) {
this safely skips a NULL argument.
ah, true :-) fixed
>@@ -3341,6 +3385,150 @@ error:
> goto cleanup;
> }
>
>+static virSmbiosEntryPtr
>+virSmbiosEntryParseXML(xmlXPathContextPtr ctxt)
>+{
>+ char *name, *value;
>+ virSmbiosEntryPtr def;
>+
>+ name = virXPathString("string(./@name)", ctxt);
>+ if (name == NULL) {
>+ virDomainReportError(VIR_ERR_XML_ERROR, "%s",
>+ _("XML element 'entry' requires a 'name'
attrbute"));
s/attrbute/attribute/
heh, good spotting
[...]
>+ if ((type< 0) || (type> 32)) {
>+ virDomainReportError(VIR_ERR_XML_ERROR,
>+ _("XML 'type' attribute on 'table' out of 0..32
range got %ld"),
>+ type);
>+ return(NULL);
>+ }
Should you also be checking for duplicate types, or is it okay to do:
<smbios>
<table type="0">
<entry name="Vendor">QEmu/KVM</entry>
</table>
<table type="0">
<entry name="Version">0.13</entry>
</table>
</smbios>
For type 0 and 1 no they are unique in theory, but other tables
can have duplicates like type 4 since there is one per processor.
I don't think we should go too deep trying to assert semantic at
that level, since anyway the drivers will have a very restricted
view of the whole thing, and will only pick some of the information
they can process. Still I wanted the format to be as generic as
possible,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
3:23 p.m.
New subject: [libvirt] [PATCH] 3/4 Add SMBIOS QEmu driver
The main trouble here is that the QEmu command uses names which are
similar to the official names for the entries used by the DMTF, but
that mean we cant base on name equality. I was tempted to use
something like strcasestr to go fishing on the names but since we
never used this in libvirt yet, and I'm not sure it's available in
gnulib, I did the patch using strstr, assuming entries provided by the
users would contain the word in lower case usually except maybe for the
first character. The matching glue is certainly perfectible.
Also decided that if we can't associate an entry with an existing
QEmu SMBIOS command we would ignore it. On the ther hand if a block
other than type 0 or 1 is used in the XML definition we would emit
a warning, but still not fail.
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 5907bf3..6d4479e 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -1224,6 +1224,8 @@ static unsigned long long qemudComputeCmdFlags(const char *help,
flags |= QEMUD_CMD_FLAG_BOOT_MENU;
if (strstr(help, "-fsdev"))
flags |= QEMUD_CMD_FLAG_FSDEV;
+ if (strstr(help, "-smbios type"))
+ flags |= QEMUD_CMD_FLAG_SMBIOS_TYPE;
/* Keep disabled till we're actually ready to turn on netdev mode
* The plan is todo it in 0.13.0 QEMU, but lets wait & see... */
@@ -3494,6 +3496,73 @@ error:
return NULL;
}
+static char *qemuBuildSmbiosBlockStr(virSmbiosBlockPtr def)
+{
+ virSmbiosEntryPtr cur;
+
+ virBuffer buf = VIR_BUFFER_INITIALIZER;
+
+ virBufferVSprintf(&buf, "type=%d", def->type);
+
+ /*
+ * QEmu accepts only a limited set of System informations, and
+ * use command line arguments shortcuts from the DMTF real names
+ * so go fishing for those
+ */
+ cur = def->entries;
+ while (cur != NULL) {
+ /* 0:Vendor */
+ if ((def->type == 0) && (strstr(cur->name, "endor")))
+ virBufferVSprintf(&buf, ",vendor=\"%s\"",
cur->value);
+ /* 0:BIOS Version */
+ else if ((def->type == 0) && (strstr(cur->name,
"ersion")))
+ virBufferVSprintf(&buf, ",version=\"%s\"",
cur->value);
+ /* 0:BIOS Release Date */
+ else if ((def->type == 0) && (strstr(cur->name, "ate")))
+ virBufferVSprintf(&buf, ",date=\"%s\"",
cur->value);
+ /* 0:System BIOS Major Release and 0:System BIOS Minor Release */
+ else if ((def->type == 0) && (strstr(cur->name,
"elease")))
+ virBufferVSprintf(&buf, ",date=\"%s\"",
cur->value);
+ /* 1:Manufacturer */
+ else if ((def->type == 1) && (strstr(cur->name,
"anuf")))
+ virBufferVSprintf(&buf, ",manufacturer=\"%s\"",
cur->value);
+ /* 1:Product Name */
+ else if ((def->type == 1) && (strstr(cur->name,
"roduct")))
+ virBufferVSprintf(&buf, ",product=\"%s\"",
cur->value);
+ /* 1:Version */
+ else if ((def->type == 1) && (strstr(cur->name,
"ersion")))
+ virBufferVSprintf(&buf, ",version=\"%s\"",
cur->value);
+ /* 1:Serial Number */
+ else if ((def->type == 1) && (strstr(cur->name,
"erial")))
+ virBufferVSprintf(&buf, ",serial=\"%s\"",
cur->value);
+ /* 1:UUID */
+ else if ((def->type == 1) && (strstr(cur->name,
"uuid")))
+ virBufferVSprintf(&buf, ",uuid=\"%s\"",
cur->value);
+ else if ((def->type == 1) && (strstr(cur->name,
"UUID")))
+ virBufferVSprintf(&buf, ",uuid=\"%s\"",
cur->value);
+ /* 1:SKU Number */
+ else if ((def->type == 1) && (strstr(cur->name, "sku")))
+ virBufferVSprintf(&buf, ",sku=\"%s\"",
cur->value);
+ else if ((def->type == 1) && (strstr(cur->name, "SKU")))
+ virBufferVSprintf(&buf, ",sku=\"%s\"",
cur->value);
+ /* 1:Family */
+ else if ((def->type == 1) && (strstr(cur->name,
"amily")))
+ virBufferVSprintf(&buf, ",family=\"%s\"",
cur->value);
+ /* other non string or type are not available just ignore them */
+ cur = cur->next;
+ }
+
+ if (virBufferError(&buf)) {
+ virReportOOMError();
+ goto error;
+ }
+
+ return virBufferContentAndReset(&buf);
+
+error:
+ virBufferFreeAndReset(&buf);
+ return(NULL);
+}
static char *
qemuBuildClockArgStr(virDomainClockDefPtr def)
@@ -4074,6 +4143,26 @@ int qemudBuildCommandLine(virConnectPtr conn,
}
}
+ if ((def->smbios != NULL) && (qemuCmdFlags &
QEMUD_CMD_FLAG_SMBIOS_TYPE)) {
+ int blk;
+
+ for (blk = 0;blk < def->smbios->nbblocks;blk++) {
+ virSmbiosBlockPtr block = def->smbios->blocks[blk];
+ char *smbiosblockcmd;
+
+ if ((block->type == 0) || (block->type == 1)) {
+ smbiosblockcmd = qemuBuildSmbiosBlockStr(block);
+ if (smbiosblockcmd == NULL)
+ goto error;
+ ADD_ARG_LIT("-smbios");
+ ADD_ARG(smbiosblockcmd);
+ } else {
+ VIR_WARN("QEmu handles only SMBIOS type 0 and 1, not
'%d'",
+ block->type);
+ }
+ }
+ }
+
/*
* NB, -nographic *MUST* come before any serial, or monitor
* or parallel port flags due to QEMU craziness, where it
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index 005031d..7ff7900 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -96,6 +96,7 @@ enum qemud_cmd_flags {
QEMUD_CMD_FLAG_FSDEV = (1LL << 40), /* -fstype filesystem passthrough
*/
QEMUD_CMD_FLAG_NESTING = (1LL << 41), /* -enable-nesting (SVM/VMX) */
QEMUD_CMD_FLAG_NAME_PROCESS = (1LL << 42), /* Is -name process= available */
+ QEMUD_CMD_FLAG_SMBIOS_TYPE = (1LL << 43), /* Is -smbios type= available */
};
/* Main driver state */
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
4:58 p.m.
New subject: [libvirt] [PATCH] 3/4 Add SMBIOS QEmu driver
On 10/21/2010 02:23 PM, Daniel Veillard wrote:
The main trouble here is that the QEmu command uses names which are
similar to the official names for the entries used by the DMTF, but
that mean we cant base on name equality. I was tempted to use
s/cant/can't/
something like strcasestr to go fishing on the names but since we
never used this in libvirt yet, and I'm not sure it's available in
gnulib, I did the patch using strstr, assuming entries provided by the
Gnulib provides strcasestr() as LGPLv2+ (but beware - it only does what
you want in unibyte locales); it also provides the c-strcasestr module
(which is probably exactly what you want!), but it is currently LGPLv3+,
although I can request on the gnulib list to have it relaxed if you'd like.
users would contain the word in lower case usually except maybe for
the
first character. The matching glue is certainly perfectible.
c_strcasestr() would certainly make it easier.
Or, is this something where STRCASEEQ() would be good enough? That is,
do we expect a user to always provide the full DMTF name "BIOS Version",
or is the substring matching important because we want to all the user
the shortcut of "Version"?
Also decided that if we can't associate an entry with an
existing
QEmu SMBIOS command we would ignore it. On the ther hand if a block
s/ther/other/
other than type 0 or 1 is used in the XML definition we would emit
a warning, but still not fail.
+ /*
+ * QEmu accepts only a limited set of System informations, and
+ * use command line arguments shortcuts from the DMTF real names
+ * so go fishing for those
+ */
+ cur = def->entries;
+ while (cur != NULL) {
+ /* 0:Vendor */
+ if ((def->type == 0)&& (strstr(cur->name, "endor")))
+ virBufferVSprintf(&buf, ",vendor=\"%s\"",
cur->value);
+ /* 0:BIOS Version */
+ else if ((def->type == 0)&& (strstr(cur->name,
"ersion")))
+ virBufferVSprintf(&buf, ",version=\"%s\"",
cur->value);
+ /* 0:BIOS Release Date */
+ else if ((def->type == 0)&& (strstr(cur->name,
"ate")))
+ virBufferVSprintf(&buf, ",date=\"%s\"",
cur->value);
+ /* 0:System BIOS Major Release and 0:System BIOS Minor Release */
+ else if ((def->type == 0)&& (strstr(cur->name,
"elease")))
+ virBufferVSprintf(&buf, ",date=\"%s\"",
cur->value);
If the user provides both "Date" and "Major Release" names, does qemu
complain about the doubled-up date="" option?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
3:54 a.m.
New subject: [libvirt] [PATCH] 3/4 Add SMBIOS QEmu driver
On Thu, Oct 21, 2010 at 03:58:50PM -0600, Eric Blake wrote:
On 10/21/2010 02:23 PM, Daniel Veillard wrote:
>The main trouble here is that the QEmu command uses names which are
>similar to the official names for the entries used by the DMTF, but
>that mean we cant base on name equality. I was tempted to use
s/cant/can't/
>something like strcasestr to go fishing on the names but since we
>never used this in libvirt yet, and I'm not sure it's available in
>gnulib, I did the patch using strstr, assuming entries provided by the
Gnulib provides strcasestr() as LGPLv2+ (but beware - it only does
what you want in unibyte locales); it also provides the c-strcasestr
module (which is probably exactly what you want!), but it is
currently LGPLv3+, although I can request on the gnulib list to have
it relaxed if you'd like.
>users would contain the word in lower case usually except maybe for the
>first character. The matching glue is certainly perfectible.
c_strcasestr() would certainly make it easier.
Or, is this something where STRCASEEQ() would be good enough? That
is, do we expect a user to always provide the full DMTF name "BIOS
Version", or is the substring matching important because we want to
all the user the shortcut of "Version"?
Well coming from a QEmu usage, people will likely just expect
"version" as that's what is used on the command line. I think matching
by subset is less likely to get users wondering why this doesn't work
as expected. Since we don't do exact name checking on input, I think
it's better to be flexible.
>Also decided that if we can't associate an entry with an
existing
>QEmu SMBIOS command we would ignore it. On the ther hand if a block
s/ther/other/
>other than type 0 or 1 is used in the XML definition we would emit
>a warning, but still not fail.
>
>+ /*
>+ * QEmu accepts only a limited set of System informations, and
>+ * use command line arguments shortcuts from the DMTF real names
>+ * so go fishing for those
>+ */
>+ cur = def->entries;
>+ while (cur != NULL) {
>+ /* 0:Vendor */
>+ if ((def->type == 0)&& (strstr(cur->name,
"endor")))
>+ virBufferVSprintf(&buf, ",vendor=\"%s\"",
cur->value);
>+ /* 0:BIOS Version */
>+ else if ((def->type == 0)&& (strstr(cur->name,
"ersion")))
>+ virBufferVSprintf(&buf, ",version=\"%s\"",
cur->value);
>+ /* 0:BIOS Release Date */
>+ else if ((def->type == 0)&& (strstr(cur->name,
"ate")))
>+ virBufferVSprintf(&buf, ",date=\"%s\"",
cur->value);
>+ /* 0:System BIOS Major Release and 0:System BIOS Minor Release */
>+ else if ((def->type == 0)&& (strstr(cur->name,
"elease")))
>+ virBufferVSprintf(&buf, ",date=\"%s\"",
cur->value);
If the user provides both "Date" and "Major Release" names, does
qemu complain about the doubled-up date="" option?
No actually that's different entries :-)
But qemu will complain if release is not formated as %d.%d, it takes as
a string what is 2 byte values in the SMBIOS tables. I didn't tried to
validate that at the driver level, rather let qemu report the error
I checked it shows up back up to virt-manager if something is not
formatted to its taste like the UUID
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
3:45 p.m.
New subject: [libvirt] [PATCH] 4/4 Add SMBIOS test data
Add an entry in the test suite and add the new flag detection
Note that the UUID will have to be fixed as QEmu check the UUID format
and requires the standard formation with dashes
Daniel
libvirt/tests/qemuxml2argvdata/qemuxml2argv-smbios.args:
LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214
-smp 1 -smbios type=0,vendor="QEmu/KVM",version="0.13" -smbios
type=1,manufacturer="Fedora",product="Virt-Manager",version="0.8.2-3.fc14",serial="32dfcb375af1552b357cbe8c3aa38310",uuid="c7a5fdbdedaf9455926ad65c16db1809"
-nographic -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -hda
/dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb
libvirt/tests/qemuxml2argvdata/qemuxml2argv-smbios.xml
<domain type='qemu'>
<name>QEMUGuest1</name>
<uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
<memory>219200</memory>
<currentMemory>219200</currentMemory>
<vcpu>1</vcpu>
<smbios>
<table type="0">
<entry name="Vendor">QEmu/KVM</entry>
<entry name="Version">0.13</entry>
</table>
<table type="1">
<entry name="Manufacturer">Fedora</entry>
<entry name="Product">Virt-Manager</entry>
<entry name="Version">0.8.2-3.fc14</entry>
<entry name="Serial">32dfcb375af1552b357cbe8c3aa38310</entry>
<entry name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
</table>
</smbios>
<os>
<type arch='i686' machine='pc'>hvm</type>
<boot dev='hd'/>
</os>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/bin/qemu</emulator>
<disk type='block' device='disk'>
<source dev='/dev/HostVG/QEMUGuest1'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0'
unit='0'/>
</disk>
<controller type='ide' index='0'/>
<memballoon model='virtio'/>
</devices>
</domain>
diff --git a/tests/qemuhelptest.c b/tests/qemuhelptest.c
index d4453db..afd1e4a 100644
--- a/tests/qemuhelptest.c
+++ b/tests/qemuhelptest.c
@@ -196,7 +196,8 @@ mymain(int argc, char **argv)
QEMUD_CMD_FLAG_NO_HPET |
QEMUD_CMD_FLAG_NO_KVM_PIT |
QEMUD_CMD_FLAG_TDF |
- QEMUD_CMD_FLAG_NESTING,
+ QEMUD_CMD_FLAG_NESTING |
+ QEMUD_CMD_FLAG_SMBIOS_TYPE,
10050, 1, 0);
DO_TEST("qemu-kvm-0.11.0-rc2",
QEMUD_CMD_FLAG_VNC_COLON |
@@ -225,7 +226,8 @@ mymain(int argc, char **argv)
QEMUD_CMD_FLAG_TDF |
QEMUD_CMD_FLAG_BOOT_MENU |
QEMUD_CMD_FLAG_NESTING |
- QEMUD_CMD_FLAG_NAME_PROCESS,
+ QEMUD_CMD_FLAG_NAME_PROCESS |
+ QEMUD_CMD_FLAG_SMBIOS_TYPE,
10092, 1, 0);
DO_TEST("qemu-0.12.1",
QEMUD_CMD_FLAG_VNC_COLON |
@@ -251,7 +253,8 @@ mymain(int argc, char **argv)
QEMUD_CMD_FLAG_RTC |
QEMUD_CMD_FLAG_NO_HPET |
QEMUD_CMD_FLAG_BOOT_MENU |
- QEMUD_CMD_FLAG_NAME_PROCESS,
+ QEMUD_CMD_FLAG_NAME_PROCESS |
+ QEMUD_CMD_FLAG_SMBIOS_TYPE,
12001, 0, 0);
DO_TEST("qemu-kvm-0.12.3",
QEMUD_CMD_FLAG_VNC_COLON |
@@ -284,7 +287,8 @@ mymain(int argc, char **argv)
QEMUD_CMD_FLAG_TDF |
QEMUD_CMD_FLAG_BOOT_MENU |
QEMUD_CMD_FLAG_NESTING |
- QEMUD_CMD_FLAG_NAME_PROCESS,
+ QEMUD_CMD_FLAG_NAME_PROCESS |
+ QEMUD_CMD_FLAG_SMBIOS_TYPE,
12003, 1, 0);
return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 551d6c4..eb66620 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -358,6 +358,8 @@ mymain(int argc, char **argv)
DO_TEST("console-virtio", QEMUD_CMD_FLAG_DEVICE |
QEMUD_CMD_FLAG_NODEFCONFIG);
+ DO_TEST("smbios", QEMUD_CMD_FLAG_SMBIOS_TYPE);
+
DO_TEST("watchdog", 0);
DO_TEST("watchdog-device", QEMUD_CMD_FLAG_DEVICE |
QEMUD_CMD_FLAG_NODEFCONFIG);
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
5:01 p.m.
New subject: [libvirt] [PATCH] 4/4 Add SMBIOS test data
On 10/21/2010 02:45 PM, Daniel Veillard wrote:
Add an entry in the test suite and add the new flag detection
Note that the UUID will have to be fixed as QEmu check the UUID format
and requires the standard formation with dashes
Looks like a reasonable start for a patch series, but as you pointed
out, there's more work to go before the series is complete. Looking
forward to a v2! Are you trying to target this for 0.8.5 or later?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
6:09 p.m.
2010/10/21 Daniel Veillard <veillard(a)redhat.com>:
 The SMBIOS data are a standardized set of data structures available
in the BIOS area of PCs. Those blocks of data describe things like
BIOS version informations, machine vendor, model and identifiers,
as well as various parts of the machine capability. On a linux
machine running dmidecode allows to dump those informations.
 Spec available at the DMTF: http://dmtf.org/standards/smbios
 From a virtualization POV, it's mostly the first block describing
the BIOS named "type 0" and the second block describing the machine
named "type 1" which are of interest. Those data are usually accessed
either from the OS or from management application, and being able to
override the default setings may be needed for such management.
 The suggested XML description follows the logical structure of the
data, one top smbios description, with one or more blocks, each
containing the entries, the example below gives an idea:
 <smbios>
  <table type="0">
   <entry name="Vendor">QEmu/KVM</entry>
   <entry name="Version">0.13</entry>
  </table>
  <table type="1">
   <entry name="Manufacturer">Fedora</entry>
   <entry name="Product">Virt-Manager</entry>
   <entry name="Version">0.8.2-3.fc14</entry>
   <entry name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
  </table>
 </smbios>
 The patch serie includes:
 - the change to the doamin schemas
 - the code to parse this in config structure
 - the QEmu driver part
 - a test example
Currently missing is the conf code to save the data back, and
documentation for the domain extension. I think it's possible
set some of those settings in Xen too, but I don't know if I will
take the time of a driver for it. For ESX it seems there is an option
to inherit some of the SMBIOS data from the host on the guest but
I'm not sure some of the fields can be manipulated directly. I don't
know what  VirtualBox can set there either,
Daniel
Okay, I looked at what can be done for ESX.
Looking at the SMBIOS data from _inside_ a ESX guest using dmidecode I
can get this
<smbios>
<table type="0">
<entry name="Vendor">Phoenix Technologies LTD</entry>
<entry name="Version">6.00</entry>
</table>
<table type="1">
<entry name="Manufacturer">VMware Inc.</entry>
<entry name="Product">VMware Virtual Platform</entry>
<entry name="Version">None</entry>
<entry name="Serial">VMware-[domain/uuid]</entry>
<entry name="UUID">[domain/uuid]</entry>
</table>
</smbios>
The UUID and Serial are basically the UUID of the guest.
Putting smbios.reflecthost = "true" (defaults to false) in the VMX
file results in
<smbios>
<table type="0">
<entry name="Vendor">Phoenix Technologies LTD</entry>
<entry name="Version">6.00</entry>
</table>
<table type="1">
<entry name="Manufacturer">LENOVO</entry>
<entry name="Product">7673J3G</entry>
<entry name="Version">None</entry>
<entry name="Serial">VMware-[domain/uuid]</entry>
<entry name="UUID">[domain/uuid]</entry>
</table>
</smbios>
So Manufacturer and Product from the type 1 table are now inherited
from the SMBIOS of the physical host.
But this is all from inside the guest. From _outside_ the guest over
the vSphere API I can only access "LENOVO" and "7673J3G", the data of
the physical host.
To make it even worse, it seems that none of this can be edited in any
way (apart from the Serial/UUID because this is the domain UUID).
Therefore, I think there is no possible useful implementation for this
in the ESX driver, besides outputting static unchangeable data.
Matthias
8:32 a.m.
On Fri, Oct 22, 2010 at 01:09:30AM +0200, Matthias Bolte wrote:
2010/10/21 Daniel Veillard <veillard(a)redhat.com>:
Okay, I looked at what can be done for ESX.
Looking at the SMBIOS data from _inside_ a ESX guest using dmidecode I
can get this
<smbios>
<table type="0">
<entry name="Vendor">Phoenix Technologies LTD</entry>
<entry name="Version">6.00</entry>
</table>
<table type="1">
<entry name="Manufacturer">VMware Inc.</entry>
<entry name="Product">VMware Virtual Platform</entry>
<entry name="Version">None</entry>
<entry name="Serial">VMware-[domain/uuid]</entry>
<entry name="UUID">[domain/uuid]</entry>
</table>
</smbios>
The UUID and Serial are basically the UUID of the guest.
Putting smbios.reflecthost = "true" (defaults to false) in the VMX
file results in
<smbios>
<table type="0">
<entry name="Vendor">Phoenix Technologies LTD</entry>
<entry name="Version">6.00</entry>
</table>
<table type="1">
<entry name="Manufacturer">LENOVO</entry>
<entry name="Product">7673J3G</entry>
<entry name="Version">None</entry>
<entry name="Serial">VMware-[domain/uuid]</entry>
<entry name="UUID">[domain/uuid]</entry>
</table>
</smbios>
So Manufacturer and Product from the type 1 table are now inherited
from the SMBIOS of the physical host.
But this is all from inside the guest. From _outside_ the guest over
the vSphere API I can only access "LENOVO" and "7673J3G", the data
of
the physical host.
To make it even worse, it seems that none of this can be edited in any
way (apart from the Serial/UUID because this is the domain UUID).
Therefore, I think there is no possible useful implementation for this
in the ESX driver, besides outputting static unchangeable data.
Okay, I looked up for VirtualBox, and apparently there is some support
for editing some of the BIOS and system entries too based on this post
http://forums.virtualbox.org/viewtopic.php?t=3224
but that looks like ad-hoc, the idea of trying to push a complete
SMBios implementation probably doesn't make that much sense, and a
simplified indirect version like Dan suggested might be sufficient
At least we should try to expose reflecthost = "true" at the libvirt
level, for ESX (and QEmu/VBox once we can parse the dmidecode output).
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
9 a.m.
2010/10/22 Daniel Veillard <veillard(a)redhat.com>:
On Fri, Oct 22, 2010 at 01:09:30AM +0200, Matthias Bolte wrote:
> 2010/10/21 Daniel Veillard <veillard(a)redhat.com>:
> Okay, I looked at what can be done for ESX.
>
> Looking at the SMBIOS data from _inside_ a ESX guest using dmidecode I
> can get this
>
> Â <smbios>
> Â Â <table type="0">
> Â Â Â <entry name="Vendor">Phoenix Technologies LTD</entry>
> Â Â Â <entry name="Version">6.00</entry>
> Â Â </table>
> Â Â <table type="1">
> Â Â Â <entry name="Manufacturer">VMware Inc.</entry>
> Â Â Â <entry name="Product">VMware Virtual Platform</entry>
> Â Â Â <entry name="Version">None</entry>
> Â Â Â <entry name="Serial">VMware-[domain/uuid]</entry>
> Â Â Â <entry name="UUID">[domain/uuid]</entry>
> Â Â </table>
> Â </smbios>
>
> The UUID and Serial are basically the UUID of the guest.
>
> Putting smbios.reflecthost = "true" (defaults to false) in the VMX
> file results in
>
> Â <smbios>
> Â Â <table type="0">
> Â Â Â <entry name="Vendor">Phoenix Technologies LTD</entry>
> Â Â Â <entry name="Version">6.00</entry>
> Â Â </table>
> Â Â <table type="1">
> Â Â Â <entry name="Manufacturer">LENOVO</entry>
> Â Â Â <entry name="Product">7673J3G</entry>
> Â Â Â <entry name="Version">None</entry>
> Â Â Â <entry name="Serial">VMware-[domain/uuid]</entry>
> Â Â Â <entry name="UUID">[domain/uuid]</entry>
> Â Â </table>
> Â </smbios>
>
> So Manufacturer and Product from the type 1 table are now inherited
> from the SMBIOS of the physical host.
>
> But this is all from inside the guest. From _outside_ the guest over
> the vSphere API I can only access "LENOVO" and "7673J3G", the
data of
> the physical host.
>
> To make it even worse, it seems that none of this can be edited in any
> way (apart from the Serial/UUID because this is the domain UUID).
>
> Therefore, I think there is no possible useful implementation for this
> in the ESX driver, besides outputting static unchangeable data.
 Okay, I looked up for VirtualBox, and apparently there is some support
for editing some of the BIOS and system entries too based on this post
 http://forums.virtualbox.org/viewtopic.php?t=3224
It seems that one of the posters suggests to hack the VirtualBox
codebase. It doesn't look like the XPCOM API exposes this.
src/vbox/vbox_CAPI_v3_2.h in the libvirt codebase doesn't contain any
SMBIOS related things.
Matthias
9:13 a.m.
On Fri, Oct 22, 2010 at 04:00:31PM +0200, Matthias Bolte wrote:
2010/10/22 Daniel Veillard <veillard(a)redhat.com>:
> Â Okay, I looked up for VirtualBox, and apparently there is some support
> for editing some of the BIOS and system entries too based on this post
> Â http://forums.virtualbox.org/viewtopic.php?t=3224
It seems that one of the posters suggests to hack the VirtualBox
codebase. It doesn't look like the XPCOM API exposes this.
Yeah, I misunderstood though it was a config file :-(
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
12:13 p.m.
2010/10/22 Daniel Veillard <veillard(a)redhat.com>:
On Fri, Oct 22, 2010 at 04:00:31PM +0200, Matthias Bolte wrote:
> 2010/10/22 Daniel Veillard <veillard(a)redhat.com>:
> > Â Okay, I looked up for VirtualBox, and apparently there is some support
> > for editing some of the BIOS and system entries too based on this post
> > Â http://forums.virtualbox.org/viewtopic.php?t=3224
>
> It seems that one of the posters suggests to hack the VirtualBox
> codebase. It doesn't look like the XPCOM API exposes this.
 Yeah, I misunderstood though it was a config file :-(
Daniel
I just came a cross this forum post from 2008:
http://forums.virtualbox.org/viewtopic.php?f=2&t=7731
I tested it and it works. This allows to override the defaults.
Matthias
12:15 p.m.
2010/10/22 Matthias Bolte <matthias.bolte(a)googlemail.com>:
2010/10/22 Daniel Veillard <veillard(a)redhat.com>:
> On Fri, Oct 22, 2010 at 04:00:31PM +0200, Matthias Bolte wrote:
>> 2010/10/22 Daniel Veillard <veillard(a)redhat.com>:
>> > Â Okay, I looked up for VirtualBox, and apparently there is some support
>> > for editing some of the BIOS and system entries too based on this post
>> > Â http://forums.virtualbox.org/viewtopic.php?t=3224
>>
>> It seems that one of the posters suggests to hack the VirtualBox
>> codebase. It doesn't look like the XPCOM API exposes this.
>
> Â Yeah, I misunderstood though it was a config file :-(
>
> Daniel
>
I just came a cross this forum post from 2008:
http://forums.virtualbox.org/viewtopic.php?f=2&t=7731
I tested it and it works. This allows to override the defaults.
Matthias
The [sg]etextradata functions are also available in the XPCOM API.
Matthias
3:13 p.m.
On Fri, Oct 22, 2010 at 07:15:43PM +0200, Matthias Bolte wrote:
2010/10/22 Matthias Bolte <matthias.bolte(a)googlemail.com>:
> 2010/10/22 Daniel Veillard <veillard(a)redhat.com>:
>> On Fri, Oct 22, 2010 at 04:00:31PM +0200, Matthias Bolte wrote:
>>> 2010/10/22 Daniel Veillard <veillard(a)redhat.com>:
>>> > Â Okay, I looked up for VirtualBox, and apparently there is some
support
>>> > for editing some of the BIOS and system entries too based on this post
>>> > Â http://forums.virtualbox.org/viewtopic.php?t=3224
>>>
>>> It seems that one of the posters suggests to hack the VirtualBox
>>> codebase. It doesn't look like the XPCOM API exposes this.
>>
>> Â Yeah, I misunderstood though it was a config file :-(
>>
>> Daniel
>>
>
> I just came a cross this forum post from 2008:
>
> http://forums.virtualbox.org/viewtopic.php?f=2&t=7731
>
> I tested it and it works. This allows to override the defaults.
>
> Matthias
>
The [sg]etextradata functions are also available in the XPCOM API.
Ah, good ! I had seen it too but it was looking fuzzier than the other
thread :-)
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
3:28 a.m.
On Thu, Oct 21, 2010 at 09:52:51PM +0200, Daniel Veillard wrote:
The SMBIOS data are a standardized set of data structures available
in the BIOS area of PCs. Those blocks of data describe things like
BIOS version informations, machine vendor, model and identifiers,
as well as various parts of the machine capability. On a linux
machine running dmidecode allows to dump those informations.
Spec available at the DMTF: http://dmtf.org/standards/smbios
From a virtualization POV, it's mostly the first block describing
the BIOS named "type 0" and the second block describing the machine
named "type 1" which are of interest. Those data are usually accessed
either from the OS or from management application, and being able to
override the default setings may be needed for such management.
The suggested XML description follows the logical structure of the
data, one top smbios description, with one or more blocks, each
containing the entries, the example below gives an idea:
<smbios>
<table type="0">
<entry name="Vendor">QEmu/KVM</entry>
<entry name="Version">0.13</entry>
</table>
<table type="1">
<entry name="Manufacturer">Fedora</entry>
<entry name="Product">Virt-Manager</entry>
<entry name="Version">0.8.2-3.fc14</entry>
<entry name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
</table>
</smbios>
I've never really been a fan of the idea of including SMBios
data in the XML because it is an x86 specific concept, which
only works with HVM guests & the type=1/2/3 is rather opaque
in meaning.
I can't help thinking that we should define a set of general
metadata tags, and then have a internal mapping of those to
SMBIOS fields, in the same way that the <uuid> is automatically
mapped to SMBIOS.
eg, define a set of metadata like this:
<metadata>
<bios-vendor>SeaBIOS</bios-vendor>
<bios-version>0.13</bios-version>
<system-manufacturer>Fedora</system-manufacturer>
<system-product>KVM</system-product>
<system-version>0.8.2</system-version>
<system-uuid>c7a5fdbdedaf9455926ad65c16db1809</system-uuid>
</metadata>
And for smbios just indicate what the source of the data is:
<smbios mode="host|emulate"/>
host - copy from host SMBIOS
emulate - generic emulator settings + metadata overrides
This would map better to what VMWare is letting you do, and let us expose
the metadata through other non-SMBIOS data channels
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
4:23 a.m.
On Fri, Oct 22, 2010 at 09:28:48AM +0100, Daniel P. Berrange wrote:
On Thu, Oct 21, 2010 at 09:52:51PM +0200, Daniel Veillard wrote:
> The SMBIOS data are a standardized set of data structures available
> in the BIOS area of PCs. Those blocks of data describe things like
> BIOS version informations, machine vendor, model and identifiers,
> as well as various parts of the machine capability. On a linux
> machine running dmidecode allows to dump those informations.
>
> Spec available at the DMTF: http://dmtf.org/standards/smbios
>
> From a virtualization POV, it's mostly the first block describing
> the BIOS named "type 0" and the second block describing the machine
> named "type 1" which are of interest. Those data are usually accessed
> either from the OS or from management application, and being able to
> override the default setings may be needed for such management.
>
> The suggested XML description follows the logical structure of the
> data, one top smbios description, with one or more blocks, each
> containing the entries, the example below gives an idea:
>
> <smbios>
> <table type="0">
> <entry name="Vendor">QEmu/KVM</entry>
> <entry name="Version">0.13</entry>
> </table>
> <table type="1">
> <entry name="Manufacturer">Fedora</entry>
> <entry name="Product">Virt-Manager</entry>
> <entry name="Version">0.8.2-3.fc14</entry>
> <entry
name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
> </table>
> </smbios>
I've never really been a fan of the idea of including SMBios
data in the XML because it is an x86 specific concept, which
only works with HVM guests & the type=1/2/3 is rather opaque
in meaning.
The semantic is well defined it's information available
from the BIOS, c.f. the DMTF spec. The we know how to get it
from a guest, and it's not dependant on the virtualization
layer used, it may or may not support it, but at least
the expectation are clear.
I can't help thinking that we should define a set of general
metadata tags, and then have a internal mapping of those to
SMBIOS fields, in the same way that the <uuid> is automatically
mapped to SMBIOS.
eg, define a set of metadata like this:
<metadata>
<bios-vendor>SeaBIOS</bios-vendor>
<bios-version>0.13</bios-version>
<system-manufacturer>Fedora</system-manufacturer>
<system-product>KVM</system-product>
<system-version>0.8.2</system-version>
<system-uuid>c7a5fdbdedaf9455926ad65c16db1809</system-uuid>
</metadata>
Okay, but what is the semantic of <system-product> for example ?
Does that mean SMBIOS type 1 Product Name or something else left
to the appreciation of the driver or of the user ?
And for smbios just indicate what the source of the data is:
<smbios mode="host|emulate"/>
host - copy from host SMBIOS
emulate - generic emulator settings + metadata overrides
This would map better to what VMWare is letting you do, and let us expose
the metadata through other non-SMBIOS data channels
Your suggestion is far more flexible, but that comes with the
trouble that we have to define those metadata semantic, or we don't
define their semantic, and it may get messy in the long term.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
4:33 a.m.
On Fri, Oct 22, 2010 at 11:23:45AM +0200, Daniel Veillard wrote:
On Fri, Oct 22, 2010 at 09:28:48AM +0100, Daniel P. Berrange wrote:
> On Thu, Oct 21, 2010 at 09:52:51PM +0200, Daniel Veillard wrote:
> > The SMBIOS data are a standardized set of data structures available
> > in the BIOS area of PCs. Those blocks of data describe things like
> > BIOS version informations, machine vendor, model and identifiers,
> > as well as various parts of the machine capability. On a linux
> > machine running dmidecode allows to dump those informations.
> >
> > Spec available at the DMTF: http://dmtf.org/standards/smbios
> >
> > From a virtualization POV, it's mostly the first block describing
> > the BIOS named "type 0" and the second block describing the machine
> > named "type 1" which are of interest. Those data are usually
accessed
> > either from the OS or from management application, and being able to
> > override the default setings may be needed for such management.
> >
> > The suggested XML description follows the logical structure of the
> > data, one top smbios description, with one or more blocks, each
> > containing the entries, the example below gives an idea:
> >
> > <smbios>
> > <table type="0">
> > <entry name="Vendor">QEmu/KVM</entry>
> > <entry name="Version">0.13</entry>
> > </table>
> > <table type="1">
> > <entry name="Manufacturer">Fedora</entry>
> > <entry name="Product">Virt-Manager</entry>
> > <entry name="Version">0.8.2-3.fc14</entry>
> > <entry
name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
> > </table>
> > </smbios>
>
> I've never really been a fan of the idea of including SMBios
> data in the XML because it is an x86 specific concept, which
> only works with HVM guests & the type=1/2/3 is rather opaque
> in meaning.
The semantic is well defined it's information available
from the BIOS, c.f. the DMTF spec. The we know how to get it
from a guest, and it's not dependant on the virtualization
layer used, it may or may not support it, but at least
the expectation are clear.
> I can't help thinking that we should define a set of general
> metadata tags, and then have a internal mapping of those to
> SMBIOS fields, in the same way that the <uuid> is automatically
> mapped to SMBIOS.
>
> eg, define a set of metadata like this:
>
> <metadata>
> <bios-vendor>SeaBIOS</bios-vendor>
> <bios-version>0.13</bios-version>
> <system-manufacturer>Fedora</system-manufacturer>
> <system-product>KVM</system-product>
> <system-version>0.8.2</system-version>
> <system-uuid>c7a5fdbdedaf9455926ad65c16db1809</system-uuid>
> </metadata>
Okay, but what is the semantic of <system-product> for example ?
Does that mean SMBIOS type 1 Product Name or something else left
to the appreciation of the driver or of the user ?
It is simply a NULL terminated string for the system product name.
> And for smbios just indicate what the source of the data is:
>
> <smbios mode="host|emulate"/>
>
> host - copy from host SMBIOS
> emulate - generic emulator settings + metadata overrides
>
> This would map better to what VMWare is letting you do, and let us expose
> the metadata through other non-SMBIOS data channels
Your suggestion is far more flexible, but that comes with the
trouble that we have to define those metadata semantic, or we don't
define their semantic, and it may get messy in the long term.
It is worth the extra work, because it gives us a representation
of data which is hypervisor-agnostic, which is the primary goal
of our XML format. If I want to specify a 'product name' for
the LXC containers, I don't want to have to use different XML
for that, compared to setting 'product name' for KVM.
With the exception of the UUID field, these are all simply NULL
terminated free form strings, so defining a mapping to SMBIOS
fields is pretty straightforward.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
7:16 a.m.
On Fri, Oct 22, 2010 at 11:23:45AM +0200, Daniel Veillard wrote:
On Fri, Oct 22, 2010 at 09:28:48AM +0100, Daniel P. Berrange wrote:
> On Thu, Oct 21, 2010 at 09:52:51PM +0200, Daniel Veillard wrote:
> > The SMBIOS data are a standardized set of data structures available
> > in the BIOS area of PCs. Those blocks of data describe things like
> > BIOS version informations, machine vendor, model and identifiers,
> > as well as various parts of the machine capability. On a linux
> > machine running dmidecode allows to dump those informations.
> >
> > Spec available at the DMTF: http://dmtf.org/standards/smbios
> >
> > From a virtualization POV, it's mostly the first block describing
> > the BIOS named "type 0" and the second block describing the machine
> > named "type 1" which are of interest. Those data are usually
accessed
> > either from the OS or from management application, and being able to
> > override the default setings may be needed for such management.
> >
> > The suggested XML description follows the logical structure of the
> > data, one top smbios description, with one or more blocks, each
> > containing the entries, the example below gives an idea:
> >
> > <smbios>
> > <table type="0">
> > <entry name="Vendor">QEmu/KVM</entry>
> > <entry name="Version">0.13</entry>
> > </table>
> > <table type="1">
> > <entry name="Manufacturer">Fedora</entry>
> > <entry name="Product">Virt-Manager</entry>
> > <entry name="Version">0.8.2-3.fc14</entry>
> > <entry
name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
> > </table>
> > </smbios>
>
> I've never really been a fan of the idea of including SMBios
> data in the XML because it is an x86 specific concept, which
> only works with HVM guests & the type=1/2/3 is rather opaque
> in meaning.
The semantic is well defined it's information available
from the BIOS, c.f. the DMTF spec. The we know how to get it
from a guest, and it's not dependant on the virtualization
layer used, it may or may not support it, but at least
the expectation are clear.
> I can't help thinking that we should define a set of general
> metadata tags, and then have a internal mapping of those to
> SMBIOS fields, in the same way that the <uuid> is automatically
> mapped to SMBIOS.
>
> eg, define a set of metadata like this:
>
> <metadata>
> <bios-vendor>SeaBIOS</bios-vendor>
> <bios-version>0.13</bios-version>
> <system-manufacturer>Fedora</system-manufacturer>
> <system-product>KVM</system-product>
> <system-version>0.8.2</system-version>
> <system-uuid>c7a5fdbdedaf9455926ad65c16db1809</system-uuid>
> </metadata>
Okay, but what is the semantic of <system-product> for example ?
Does that mean SMBIOS type 1 Product Name or something else left
to the appreciation of the driver or of the user ?
> And for smbios just indicate what the source of the data is:
>
> <smbios mode="host|emulate"/>
>
> host - copy from host SMBIOS
> emulate - generic emulator settings + metadata overrides
>
> This would map better to what VMWare is letting you do, and let us expose
> the metadata through other non-SMBIOS data channels
Your suggestion is far more flexible, but that comes with the
trouble that we have to define those metadata semantic, or we don't
define their semantic, and it may get messy in the long term.
How about a different variation on the theme.
<sysinfo type="smbios">
<section name="bios">
<entry name="Vendor">QEmu/KVM</entry>
<entry name="Version">0.13</entry>
</section>
<section namee="platform">
<entry name="Manufacturer">Fedora</entry>
<entry name="Product">Virt-Manager</entry>
<entry name="Version">0.8.2-3.fc14</entry>
<entry name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
</section>
</sysinfo>
Where the valid section types, and entry names are defined according to
the sysinfo type. So with type='smbios', the valid section/entries names
would be 100% as per the SMBIOS spec. If we add different sysinfo
types, we can define appropriate sections/entries as per the spec for
those types. This keeps the strictly defined semantics, while avoiding
a schema that is tied to smbios
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
7:48 a.m.
On Fri, Oct 22, 2010 at 01:16:16PM +0100, Daniel P. Berrange wrote:
On Fri, Oct 22, 2010 at 11:23:45AM +0200, Daniel Veillard wrote:
> On Fri, Oct 22, 2010 at 09:28:48AM +0100, Daniel P. Berrange wrote:
[...]
> > I can't help thinking that we should define a set of
general
> > metadata tags, and then have a internal mapping of those to
> > SMBIOS fields, in the same way that the <uuid> is automatically
> > mapped to SMBIOS.
> >
> > eg, define a set of metadata like this:
> >
> > <metadata>
> > <bios-vendor>SeaBIOS</bios-vendor>
> > <bios-version>0.13</bios-version>
> > <system-manufacturer>Fedora</system-manufacturer>
> > <system-product>KVM</system-product>
> > <system-version>0.8.2</system-version>
> > <system-uuid>c7a5fdbdedaf9455926ad65c16db1809</system-uuid>
> > </metadata>
>
> Okay, but what is the semantic of <system-product> for example ?
> Does that mean SMBIOS type 1 Product Name or something else left
> to the appreciation of the driver or of the user ?
>
> > And for smbios just indicate what the source of the data is:
> >
> > <smbios mode="host|emulate"/>
> >
> > host - copy from host SMBIOS
> > emulate - generic emulator settings + metadata overrides
> >
> > This would map better to what VMWare is letting you do, and let us expose
> > the metadata through other non-SMBIOS data channels
>
> Your suggestion is far more flexible, but that comes with the
> trouble that we have to define those metadata semantic, or we don't
> define their semantic, and it may get messy in the long term.
How about a different variation on the theme.
<sysinfo type="smbios">
<section name="bios">
<entry name="Vendor">QEmu/KVM</entry>
<entry name="Version">0.13</entry>
</section>
<section namee="platform">
<entry name="Manufacturer">Fedora</entry>
<entry name="Product">Virt-Manager</entry>
<entry name="Version">0.8.2-3.fc14</entry>
<entry name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
</section>
</sysinfo>
Where the valid section types, and entry names are defined according to
the sysinfo type. So with type='smbios', the valid section/entries names
would be 100% as per the SMBIOS spec. If we add different sysinfo
types, we can define appropriate sections/entries as per the spec for
those types. This keeps the strictly defined semantics, while avoiding
a schema that is tied to smbios
Okay, agreed, hierarchy may look a bit more complex as a result
but it allows to preserve both viewpoint.
Also for the <smbios> element, should we make the mode a tristate:
- emulate: do not try to override the default set by the hypervisor
(if any)
- host: get the values from the host (libvirtd may have to parse
the dmidecode output as I don't see how to implement this for QEmu
otherwise), the only useful mode for ESX driver
- sysinfo: get the values from <sysinfo> section and pass them to
the hypervisor.
Also I'm wondering if we should treat <smbios> as a device or keep it
as a top level element along <cpu> etc.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
3:22 a.m.
On Thu, 2010-10-21 at 21:52 +0200, Daniel Veillard wrote:
The SMBIOS data are a standardized set of data structures available
in the BIOS area of PCs. Those blocks of data describe things like
BIOS version informations, machine vendor, model and identifiers,
as well as various parts of the machine capability. On a linux
machine running dmidecode allows to dump those informations.
Daniel,
Can you tell me if you are (or are willing or planning to) going to
implement structure Type 9 of the SMBIOS specification? Specifically,
this provides a mapping from the "system slots" (in the chassis) to the
PCI devices in the system (as an example), especially where network is
concerned (but not limited to that). We are investigating generic
solutions for mapping network devices presented by Linux through to the
physical devices themselves. So for example, network device eth0 is
replaced by eth-slot0-<etc> or lom0, or whatever.
I know virt doesn't have a physical slot, but the ordering of devices
does matter very much. Let me know your plans. I am still catching up
from LPC last week, so I just skimmed libvirt list. I have a plan to
read over your patches soon.
Jon.
4:29 a.m.
On Tue, Nov 09, 2010 at 04:22:56AM -0500, Jon Masters wrote:
On Thu, 2010-10-21 at 21:52 +0200, Daniel Veillard wrote:
> The SMBIOS data are a standardized set of data structures available
> in the BIOS area of PCs. Those blocks of data describe things like
> BIOS version informations, machine vendor, model and identifiers,
> as well as various parts of the machine capability. On a linux
> machine running dmidecode allows to dump those informations.
Daniel,
Can you tell me if you are (or are willing or planning to) going to
implement structure Type 9 of the SMBIOS specification? Specifically,
this provides a mapping from the "system slots" (in the chassis) to the
PCI devices in the system (as an example), especially where network is
concerned (but not limited to that). We are investigating generic
solutions for mapping network devices presented by Linux through to the
physical devices themselves. So for example, network device eth0 is
replaced by eth-slot0-<etc> or lom0, or whatever.
I know virt doesn't have a physical slot, but the ordering of devices
does matter very much. Let me know your plans. I am still catching up
from LPC last week, so I just skimmed libvirt list. I have a plan to
read over your patches soon.
A priori no hypervisor expose any of the type 9 informations. So
I don't think using the SMBIOS stucture may actually help solving
the device ordering in the guests. My pervious version of the patch
which was very close to SMBIOS structure would have allowed to expose
those but that's not something we could have used for the hypervisor.
Also contrary to the current set of sysinfo informations we won't be
able to pick them up from the host in any meaningful way.
The device ordering is still something to be improved but for a given
class of devices we tend to assign them PCI slots in the order found
in the XML docmain declaration. Right now the order between different
classes of devices is hardcoded and that is one point we should be
able to improve,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
4:51 a.m.
On Tue, Nov 09, 2010 at 11:29:31AM +0100, Daniel Veillard wrote:
On Tue, Nov 09, 2010 at 04:22:56AM -0500, Jon Masters wrote:
> On Thu, 2010-10-21 at 21:52 +0200, Daniel Veillard wrote:
> > The SMBIOS data are a standardized set of data structures available
> > in the BIOS area of PCs. Those blocks of data describe things like
> > BIOS version informations, machine vendor, model and identifiers,
> > as well as various parts of the machine capability. On a linux
> > machine running dmidecode allows to dump those informations.
>
> Daniel,
>
> Can you tell me if you are (or are willing or planning to) going to
> implement structure Type 9 of the SMBIOS specification? Specifically,
> this provides a mapping from the "system slots" (in the chassis) to the
> PCI devices in the system (as an example), especially where network is
> concerned (but not limited to that). We are investigating generic
> solutions for mapping network devices presented by Linux through to the
> physical devices themselves. So for example, network device eth0 is
> replaced by eth-slot0-<etc> or lom0, or whatever.
>
> I know virt doesn't have a physical slot, but the ordering of devices
> does matter very much. Let me know your plans. I am still catching up
> from LPC last week, so I just skimmed libvirt list. I have a plan to
> read over your patches soon.
A priori no hypervisor expose any of the type 9 informations. So
I don't think using the SMBIOS stucture may actually help solving
the device ordering in the guests. My pervious version of the patch
which was very close to SMBIOS structure would have allowed to expose
those but that's not something we could have used for the hypervisor.
Also contrary to the current set of sysinfo informations we won't be
able to pick them up from the host in any meaningful way.
The device ordering is still something to be improved but for a given
class of devices we tend to assign them PCI slots in the order found
in the XML docmain declaration. Right now the order between different
classes of devices is hardcoded and that is one point we should be
able to improve,
Actually that's not quite correct. If you give a XML config to libvirt
without any PCI addresses, libvirt will auto-assign slots in an order
that matches QEMU's default auto-assignment. If you want to explicitly
control PCI addresses yourself, you can include them in the XML given
to libvirt and that will cause libvirt's autoassignment to be skipped.
So a mgmt app can guarantee a PCI slot for a given device across all
guests if it so desires
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
9:56 a.m.
On Tue, 2010-11-09 at 11:29 +0100, Daniel Veillard wrote:
On Tue, Nov 09, 2010 at 04:22:56AM -0500, Jon Masters wrote:
> On Thu, 2010-10-21 at 21:52 +0200, Daniel Veillard wrote:
> > The SMBIOS data are a standardized set of data structures available
> > in the BIOS area of PCs. Those blocks of data describe things like
> > BIOS version informations, machine vendor, model and identifiers,
> > as well as various parts of the machine capability. On a linux
> > machine running dmidecode allows to dump those informations.
>
> Daniel,
>
> Can you tell me if you are (or are willing or planning to) going to
> implement structure Type 9 of the SMBIOS specification? Specifically,
> this provides a mapping from the "system slots" (in the chassis) to the
> PCI devices in the system (as an example), especially where network is
> concerned (but not limited to that). We are investigating generic
> solutions for mapping network devices presented by Linux through to the
> physical devices themselves. So for example, network device eth0 is
> replaced by eth-slot0-<etc> or lom0, or whatever.
>
> I know virt doesn't have a physical slot, but the ordering of devices
> does matter very much. Let me know your plans. I am still catching up
> from LPC last week, so I just skimmed libvirt list. I have a plan to
> read over your patches soon.
A priori no hypervisor expose any of the type 9 informations.
But that's not a reason not to :) One of the (many) reasons that
extension was added was to help even hypervisors.
I don't think using the SMBIOS stucture may actually help
solving
the device ordering in the guests.
Why not? Guest Operating Systems are starting to support this extension,
and there's an ACPI extension coming along too. I would have thought an
OS-independent way of ensuring consistent ordering is pretty useful!
The device ordering is still something to be improved but for a
given
class of devices we tend to assign them PCI slots in the order found
in the XML docmain declaration. Right now the order between different
classes of devices is hardcoded and that is one point we should be
able to improve,
You could just pass the SMBIOS data such that you map PCI "slots" to
devices in linear order. That will ensure one kind of ordering. And you
can change the logic later since you know how the guest OS(es) will
react and so can still ensure a consistent mapping.
Jon.
5128
days inactive
5147
days old
27 comments
5 participants
participants (5)
-
Daniel P. Berrange -
Daniel Veillard -
Eric Blake -
Jon Masters -
Matthias Bolte