retrofitting LUKS encryption on installed system

[Reindl Harald]

Am 29.06.2013 23:12, schrieb Bill Davidsen:
> And right again. Unfortunately I didn't say or mean vSphere, but rather KVM, the facility used by qemu-kvm to run
> virtual machines.
> 
> Hardware CPU:
>   vendor_id       : GenuineIntel
>   model name      : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
>   flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx
> fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
> nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid
> sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm
> tpr_shadow vnmi flexpriority ept vpid
> 
> On 2.6.32-358.11.1.el6.i68 VM:
>   vendor_id       : GenuineIntel
>   model name      : QEMU Virtual CPU version 1.0.1
>   flags           : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall
> nx lm unfair_spinlock pni cx16 popcnt hypervisor lahf_lm
> 
> But on 3.9.6-200.fc18.x86_64 VM:
>   vendor_id       : GenuineIntel
>   model name      : QEMU Virtual CPU version 1.0.1
>   flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2
> syscall nx lm rep_good nopl pni cx16 popcnt hypervisor lahf_lm
> 
> Other than the flag name change, neither VM has aes set, I assume the flag is blocked for security, although I
> don't see bugs about it.
> 
> Anyway, switching all our servers to something else at this time is not even a worth discussion, so my note was
> just a warning for people using the KVM tools included in Fedora

looks like KVM is still far behind VMware

"model name: QEMU Virtual CPU version 1.0.1"
what the hell - on VMware you have the same CPU as the host and only "VMware EVC"
is filtering CPU capabilities to provide relieable hot-migration between hosts
by make only the flags of the oldest CPU in the cluster visible to guests

that's why a VMwar eguest has around 905-98 % of the native performance because
there is only few binary translation and most instrcutions are passed 1:1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20130629/80acbf08/attachment.sig>