Subject: [OPSAWG] VM-MIB issue vm-mib-03: cpu type identification

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Apr 2012 12:36:06 +0200

Hi,

* vm-mib-03: cpu type identification

  It is necessary to identify the CPU architecture or type since some
  virtual machine systems can emulate different CPU types.

** Solution #03-01

   Provide an IANA controlled enumeration that provides a CPU
   classification. The problem will be to provide rules about what
   constitutes a new CPU type and what not.

** Solution #03-02

   Use OBJECT IDENTITIES to identify CPU types. Such a distributed
   enumeration will not achieve a great deal of interoperability
   and is likely close to #03-03.

** Solution #03-03

   Use a string data type and rely on systems to put meaningful
   information there, perhaps provide guidelines how to structure the
   CPU type names, e.g. <vendor>-<arch>-<model>*(-<features>) that is
   amd-x86_64-opteron or intel-i686-pentium3-vmx-acpi (perhaps using a
   different separator character since a dash might easily clash).
   Applications may have to do some normalization across VM-MIB
   implementations (e.g., regular expression matching) but on the
   other hand this allows to provide details where necessary.

** Solution #03-04

   Following #03-03, we provide ...GuestCpuVendor, ...GuestCpuArch
   and ...GuestCpuModel objects plus an additional table that provides
   details about the features of the CPUs used by a certain virtual
   machine. This essentially breaks the string into a set of separate
   MIB objects.

** Solution #03-05

   Following #03-04, we provide ...GuestCpuVendor, ...GuestCpuArch and
   ...GuestCpuModel objects plus a string object containing a list of
   features. This way, things are more compact but still the most
   important components (vendor, arch, model) are broken out as
   separate objects.

** Resolution

   TBD

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Story <[email-masked]>
Date: Tue, 24 Apr 2012 11:12:19 -0400

On Tue, 24 Apr 2012 12:36:06 +0200 Juergen wrote:
JS> Hi,
JS> 
JS> * vm-mib-03: cpu type identification
JS> 
JS>   It is necessary to identify the CPU architecture or type since some
JS>   virtual machine systems can emulate different CPU types.

JS> ** Solution #03-03
JS> 
JS>    Use a string data type and rely on systems to put meaningful
JS>    information there, perhaps provide guidelines how to structure the
JS>    CPU type names, e.g. <vendor>-<arch>-<model>*(-<features>) that is
JS>    amd-x86_64-opteron or intel-i686-pentium3-vmx-acpi (perhaps using a
JS>    different separator character since a dash might easily clash).
JS>    Applications may have to do some normalization across VM-MIB
JS>    implementations (e.g., regular expression matching) but on the
JS>    other hand this allows to provide details where necessary.
JS> 

I like this option, but with two string columns. A name, and the
configuration. There is likely going to be a limited number of supported
configurations on given machine, and the (vendor provided) name will be
what managers are looking for when trying to find another host when
migrating machines. e.g.

 "486", "x86 fpu vme pse"
 "pentium", "x86 fpu vme pse de tsc msr mce cx8 mmx"
 ...

I don't think we need to worry about interoperability, because I'm not
aware of any VM solution that allows you to migrate to another vendor's
solution. So a VMWare host cpu table will look different from a KVM host
cpu table.

Robert

--
Senior Software Engineer
SPARTA, Inc., a Parsons Company

---

From: Michael MacFaden <[email-masked]>
Date: Tue, 24 Apr 2012 10:43:33 -0700 (PDT)

>   virtual machine systems can emulate different CPU types.

Yes. VMs can emulate a single-core cpu or multi-core cpu with or without hyper-threading.

>    constitutes a new CPU type and what not.

This model has generally worked even with the noise and confusion
of various persons registering whatever they like. Take the IF-MIB ifTypes
where we'd end up with the official types and non-official
types as anyone might register anything. RFCs then point out what
official numbers *should* be used. Example: ifType 6 vs other gig ethernet
types in http://www.iana.org/assignments/ianaiftype-mib

>From experience, this style was not adopted by industry for a number of
mib modules including RFC 2790.

>    amd-x86_64-opteron or intel-i686-pentium3-vmx-acpi (perhaps using
>    a different separator character since a dash might easily clash).

That's something I might do in a proprietary mib, don't prefer it
in a standard mib module. On practice I believe formatted octet strings
makes interoperability harder to achieve.

>    and ...GuestCpuModel objects plus an additional table that
>    provides details about the features of the CPUs used by a certain virtual

Yes. That's what I'd expect from an IETF standard.

> ** Solution #03-05
> 
>    Following #03-04, we provide ...GuestCpuVendor, ...GuestCpuArch
>    and ...GuestCpuModel objects plus a string object containing a list of

Personally like this the best, but presents the same issue as 03-03
Namely these octet string values then need to be codified precisely for any
chance of having interoperability. Variation on a theme here, consider
using enumerations with BITS to simplify parsing, make it compact ala
RFC 2674 PortList TC.

The thing is that new CPU feature sets will continue to be added over time. If
we don't want to rev this MIB module every time then this solution works great.
How to do this such that new feature sets show up in a consistent way in fielded
products is the crux. 

The purpose of this CPU data is to match a given VM and its cpu state
to a real CPU to determine if vm migration will succeed. 

Would like to see, as I previously mentioned, that we model the real 
cpu's properly in the HOST-RESOURCES-MIB and in this draft focus on what 
a given VM's cpu(s) expects of a x86 server's cpu(s).

Mike MacFaden