Problem With Lvm Disks Assigned To Kvm Guests
Hi all,
I have a strange problem when I use lvm disks to expose to virtual guests (host is CentOS 6.5 x86_64). If I remove a kvm guest and all lvm disks attached to it, and I create a new kvm with another lvm disks that use the same disk space previously assigned to the previous kvm guest, this new guest sees all partitions and data. Creating new lvm volumes with different names to this new kvm doesn’t resolves the problem.
Any idea why??
Thanks.
10 thoughts on - Problem With Lvm Disks Assigned To Kvm Guests
When you delete a volume the data isn’t cleared only the metadata removed so if you later create a new volume that ends up using the same area on disk then you will see the old data as expected. If you don’t want this to happen then you need to overwrite the volume before you delete it.
This is a general issue in virtualization/clouds that you need to take into account for security reasons. See for example:
https://github.com/fog/fog/issues/2525
Regards,
Dennis
Many thanks Dennis … Then if I do:
dd if=/dev/zero of=/dev/sdc1 bs=1M (it is a 1TiB disk), will erase all data and partitions created by the kvm guest??
That should work although if you want to be really safe you should probably use /dev/urandom instead of /dev/zero as using random data is a better way to deal with the problem of data remanence:
http://en.wikipedia.org/wiki/Data_remanence#Overwriting
Regards,
Dennis
Ok, thanks … This procedure can works when I reuse a full disk, but what about if I want to reuse only a logical volume??
Only way is to overwrite the lvol while it still exists, before deleting it.
Regards,
Doing another dd over this logical volume??
To avoid seeing the old partitions or boot loader, you can simply zero the partition information. That will avoid the confusion, and it is
*much, much faster* than zeroing the whole disk.
dd if=/dev/zero of=/dev/sdc1 count0
/dev/urandom take *much* longer.. Also, that article you mention merely describes the technique. The *expense* of data recovery from something that’s been overwritten simply with zeroes or ones is hideous, and the results quite poor according to previous analyses I’ve seen. So while thousands of Google articles recommend “for real security, use /dev/urandom”, it’s extremely difficult to find any that justify the expense and time.
If you really feel the need to do military grade scrubbing, use
“dban”, with the source code available at http://sourceforge.net/projects/dban/files/dban/dban-2.2.8/.. It’s at the core of most disk erasure CD’s and USB stick tools that I’ve seen..
If these are private VMs (i.e. security is no concern) then the dd above is sufficient but then you could just skip this as well and delete the partitions when installing the new VM. If these are not private VMs (i.e. for customers) and you use the dd above then you give the new customer basically access to all the data of the customer who was previously using this space. In the non-private case you should always wipe the complete volume and not trade in security for convenience.
Regards,
Dennis
You wanted to deal with an LV, so the LV is what you should write, not the underlying disk as that would destroy whatever else is present
bs=1M is pretty small. Experiment to see what is the fastest btw when you dd.