retrofitting LUKS encryption on installed system

[Bill Davidsen]

Reindl Harald wrote:
> 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 we use KVM, migrations may not be within a cluster. Or be real time 
"migrations" as you are thinking of it, but rather may involve being backed up 
until the next time there is a support need for the machine. Different 
environment, different goals.
> 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
>
And as I remember if there was one old machine in the cluster you wouldn't have 
the aes instruction either. That's from docs, haven't tried VMware in a very 
long time.

-- 
Bill Davidsen <davidsen at tmr.com>
   "'Nothing to hide' does not imply 'nothing to fear'"
       - me
   "AT&T could not seriously contend that a reasonable entity in its position
    could have believed that the alleged domestic dragnet was legal."
       -judge Vaughn R. Walker of the U.S. District Court
        for the Northern District of California, EFF vs. AT&T