G
guedouarj
Guest
I wonder if it's possible to install proxmox with LUKS encryption ( dm-crypt )
It can give us more securities on our VM !
It can give us more securities on our VM !
Hello guedouarj.
Setting up a PROXMOX installation with LUKS/dm-crypt is
possible, but, I think, not with the PROXMOX ISO-Installer
and will not be supported by PROXMOX.
You can get it the Debian-installer-way:
http://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Lenny
on an usual debian "expert" installation process.
But I think, that LUKS-encryption on the host is a *VERY* bad idea.
We currently run about 8 PROXMOX nodes and the number raises.
Some Systems we use only for KVM-based Windows XP, 7 , Server
2003-2008 based and some for OpenVZ/KVM dual usage or OpenVZ single
use for productional systems of our software appliances.
And for some weeks I did a benchmark for some brandnew DELL 19"
servers with big hardware, e.g. 8-Port-SAS-RAID controller.
As in the real world, I/O is the main bottleneck, but in virtual
environments it is even more necessary to provide an adequate
performance, especially in IO.
One main criteria is the FSYNC/s value. For example, measured
by the "pveperf {DIRECTORY}" commandline tool of PROXMOX.
I benchmarked this and some other values in the PROXMOX host
and also inside the VMs. In conclusion if you use LUKS encryption
on the host your performance values will drop to the ground.
e.g. I got
* 20 - 60 FSYNCs/sec on LUKS-encrypted software raid (mdadm)
* 40 - 120 FSYNCs/sec on LUKS-encrypted hardware RAID (256 MB cache, BBU); tested with different encryption algorithms
while I got up to
* 1400 - 2000 FSYNCs/sec on an unecrypted system
@PROXMOX-Team: LUKS-encryption should officially and generally
be avoided, I think? Or is there a way know without such a big
impact on IO-performance?
Best regards,
René Kerner
IT Consultant, Software Developer,
Datenschutz Consultant
-tacticx GmbH-
Setting up a PROXMOX installation with LUKS/dm-crypt is
possible, but, I think, not with the PROXMOX ISO-Installer
and will not be supported by PROXMOX.
You can get it the Debian-installer-way:
http://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Lenny
on an usual debian "expert" installation process.
But I think, that LUKS-encryption on the host is a *VERY* bad idea.
We currently run about 8 PROXMOX nodes and the number raises.
Some Systems we use only for KVM-based Windows XP, 7 , Server
2003-2008 based and some for OpenVZ/KVM dual usage or OpenVZ single
use for productional systems of our software appliances.
And for some weeks I did a benchmark for some brandnew DELL 19"
servers with big hardware, e.g. 8-Port-SAS-RAID controller.
As in the real world, I/O is the main bottleneck, but in virtual
environments it is even more necessary to provide an adequate
performance, especially in IO.
One main criteria is the FSYNC/s value. For example, measured
by the "pveperf {DIRECTORY}" commandline tool of PROXMOX.
I benchmarked this and some other values in the PROXMOX host
and also inside the VMs. In conclusion if you use LUKS encryption
on the host your performance values will drop to the ground.
e.g. I got
* 20 - 60 FSYNCs/sec on LUKS-encrypted software raid (mdadm)
* 40 - 120 FSYNCs/sec on LUKS-encrypted hardware RAID (256 MB cache, BBU); tested with different encryption algorithms
while I got up to
* 1400 - 2000 FSYNCs/sec on an unecrypted system
@PROXMOX-Team: LUKS-encryption should officially and generally
be avoided, I think? Or is there a way know without such a big
impact on IO-performance?
Best regards,
René Kerner
IT Consultant, Software Developer,
Datenschutz Consultant
-tacticx GmbH-
Last edited:
I never really tried that, but encryption need CPU performance - you wont get that for free.
No, I don't think it's only a cpu performance issue, or probably it's depending
on the os encryption algorithms implementation and the ability of multicore
scalability of processing.
The used cpus had a AES-unit, so AES performance should be good and we
tested that on some 4 - 8 core intel systems with 2.4 - over 3 ghz/s.
LUKS encryption on the host could be valueable on non-RAID / sw-RAID
systems, where e.g. fsync/s is about 120-150 without encryption and
80 - 120 with LUKS, but there is a big impact, about factor 20 or bigger,
when using HW-raid.
The impact on the fsync/s is not the only one!
e.g. we have one non-RAID system running on LUKS-crypted hdds
and got some IO-related issues:
2x Win 2008 enterprise server and 1x Win 7 KVM VMs
2x OpenVZ hosts, one for Redmine (+Postgres), one for SVN-Repository & Dev-System (PHP Software Dev, MySQL, ...)
The Win servers perform "ok", but the OpenVZ VEs got bad IO performance,
e.g. one website-request needed 15-20 second for a complete answer,
when the one Win server VM was a little busy because of a misconfigured
index-service. The same request without the Win VMs with much IO is
handled in less then one or two seconds.
Best regards,
René Kerner
IT Consultant, Software Developer,
Datenschutz Consultant
-tacticx GmbH-
on the os encryption algorithms implementation and the ability of multicore
scalability of processing.
The used cpus had a AES-unit, so AES performance should be good and we
tested that on some 4 - 8 core intel systems with 2.4 - over 3 ghz/s.
LUKS encryption on the host could be valueable on non-RAID / sw-RAID
systems, where e.g. fsync/s is about 120-150 without encryption and
80 - 120 with LUKS, but there is a big impact, about factor 20 or bigger,
when using HW-raid.
The impact on the fsync/s is not the only one!
e.g. we have one non-RAID system running on LUKS-crypted hdds
and got some IO-related issues:
2x Win 2008 enterprise server and 1x Win 7 KVM VMs
2x OpenVZ hosts, one for Redmine (+Postgres), one for SVN-Repository & Dev-System (PHP Software Dev, MySQL, ...)
The Win servers perform "ok", but the OpenVZ VEs got bad IO performance,
e.g. one website-request needed 15-20 second for a complete answer,
when the one Win server VM was a little busy because of a misconfigured
index-service. The same request without the Win VMs with much IO is
handled in less then one or two seconds.
Best regards,
René Kerner
IT Consultant, Software Developer,
Datenschutz Consultant
-tacticx GmbH-
This is interesting to hear BUT...
When encryption is absolutely required what is the best way forward?
Do you suggest that VM-level LUKS encryption would somehow perform better?
hdparm gave me a result of over 200MB/s with LUKS on, but I know read performance is just one piece in this puzzle.
Any ideas?
When encryption is absolutely required what is the best way forward?
Do you suggest that VM-level LUKS encryption would somehow perform better?
hdparm gave me a result of over 200MB/s with LUKS on, but I know read performance is just one piece in this puzzle.
Any ideas?