User talk:Xiawenc

Summary

This feature will enhance VM backup functionality, to make it possible taking internal/external snapshots lively, and make it works better with underlining components such as LVM.

Owner

• Name: Wenchao Xia
• Email: xiawenc@linux.vnet.ibm.com, xiaxia347os@163.com

Detailed Summary

Provide APIs that can do:

• 1 block device live snapshot as internal/external/blank delta data, export sync API for all type.
• 2 vmstate live save as internal/external data, export async API for external data, fix the size problem.
• 3 combination(internal block snapshot + internal vmstate save, internal block snapshot + external vmstate save, external block snapshot + external vmstate save).

Now qemu support block device live external snapshot, live migration to file, static internal block snapshot + internal vmstate save, following are the blanks need to be filled:

• 1 block device live internal snapshot, block device data drain, provide the interfaces in unified style.
• 2 change vmstate save from static to live, fix the problem that size is not predictable, add support to save vmstate to external file format that qemu support(raw, qcow2...).
• 3 an API allow management stack configure the combination.
• 4 qmp/hmp for related information retrieving.

User Case

From the backup application's perspective, its goal may be forming a back up chain as following:

1# vmstate: mem mem mem mem mem

             |          |            |             |           |

2# disk: base& ---> delta&1 ---> delta&2 ---> delta&3 ---> delta&4...

            10G        100M         100M         100M         100M

• add feature flag name list for CPUID 7

Current Issues and proposed changes

Allowing CPU models to be updated

We need a mechanism to allow the existing CPU models on Qemu to be updated, without making guest-visible changes for existing Virtual Machines, when migrating to a new version.

Examples

Examples where CPU model updates are necessary and have to be deployed to users:

• The Nehalem CPU model currently has the wrong "level" value, making CPU topology information unavailable.
• The CPUID PMU leaf was added on Qemu 1.1, but it is not supposed to be visible to guests running using -M pc-1.0
• New features are implemented by KVM and we may want to add them to existing models (e.g. SandyBridge may need to have tsc-deadline added)

Requirements

• A different CPU will be visible to the guest depending on the machine-type chosen.
  • That means that "-M pc-1.0 -cpu Nehalem" will be different from "-M pc-1.1 -cpu Nehalem"
  • Rationale:
    • The meaning of "-M pc-1.0 -cpu Nehalem" can't be changed or it will change existing guests
    • The meaning of "-M pc-1.1 -cpu Nehalem" needs to be different from the pc-1.0 one, otherwise we would be stuck with a broken "Nehalem" model forever

Current design proposal

• CPU model definitions were moved to C code, so we can easily add compatibility code to them if necessary
• CPUs are now DeviceState objects
• CPU models will become separate classes, so per-CPU-model compatibility properties can be used on machine-type definitions

Probing of CPU model details

libvirt don't write CPU definitions from scratch, so it will reuse the CPU models from /usr/share. But it needs to probe for details of the CPU models.

Requirements

A detailed probing system, similar to "-cpu ?dump", but in a more extensible and machine-friendly format.

Current design proposal

• -query-capabilities RFC series from Anthony
  • Message-Id: <1332169763-30665-9-git-send-email-aliguori@us.ibm.com>
• To be defined: Command to list CPU models, and the features they include/exclude
• To be defined: Command to list the resulting CPUID bits of CPU models
  • Do we need a version that works before the VM is created? Some bits depend on other Virtual Machine parameters (e.g. SMP configuration), so it won't list every single bit
  • Do we need a version that works after the VM is created, so it lists every single bit? (maybe just the "query-cpus" QMP command is already enough for that)
    • Probably the final solution will require libvirt to actually create a VM and run a "query-cpus" (or similar) command to get the resulting CPUID bits
• To be defined: command to query which CPU flags are really available and can be enabled (based on host hardware + kernel + qemu capabilities)

-cpu host and feature probing

See http://article.gmane.org/gmane.comp.emulators.kvm.devel/90035

-cpu host vs -cpu best

Currently we have -cpu host, but the naming and semantics are unclear.

We have 3 possible modes of "try to get the best CPU model":

1. all-you-can-enable: Enable every single bit that can be enabled, including the ones not present on the host but that can be emulated.
2. match-host-CPU: Enable all bits that are present in the host CPU that can be enabled.
3. best-predefined-model: Use the best CPU model available from the pre-defined CPU model list.

Proposal

• -cpu host will be the "all-you-can-enable" mode, that will enable every bit from GET_SUPPORTED_CPUID on the VCPU
• The best-predefined-model will be implemented using -cpu best.
• We're not going to have a mode for match-host-CPU, probably