Saya baru saja membangun host mesin virtual berbasis KVM / libvirt baru yang mengkilap, berisi 4 hard drive SATA II, dan menjalankan CentOS 5.5 x86_64.
Saya telah memutuskan untuk membuat disk mesin virtual sebagai volume logis dalam grup volume LVM yang dikelola sebagai kumpulan penyimpanan libvirt, alih-alih praktik yang biasa membuat disk sebagai gambar qcow.
Yang tidak bisa saya putuskan adalah apakah saya harus membuat volume logis mesin virtual dalam grup volume host VM, atau dalam grup volume khusus.
Metode mana yang harus saya pilih, dan mengapa?
Metode 1: Gunakan grup volume host VM
Penerapan:
- RAID1 kecil yang
md0berisi/bootsistem file - RAID10 besar
md1menempati ruang yang tersisa, yang berisi grup volume LVMvghost.vghostberisi sistem file root host VM dan partisi swap - buat disk mesin virtual sebagai volume logis
vghostsesuai kebutuhan
Pro:
- jika sistem file root host VM kehabisan ruang, saya dapat mengalokasikan lebih banyak ruang dari
vghostdengan relatif mudah - Sistem sudah berjalan dan berjalan (tetapi bukan masalah besar untuk memulai kembali)
Cons:
Mengabaikan fakta bahwa metode ini tampaknya berhasil, saya tidak dapat menghilangkan perasaan bahwa ini adalah ide yang buruk. Aku merasakannya:
- ini entah bagaimana bisa menjadi risiko keamanan
- di beberapa titik di masa depan saya mungkin menemukan beberapa batasan dengan pengaturan, dan berharap bahwa saya menggunakan grup khusus
- sistem (CentOS, libvirt, dll.) mungkin tidak benar-benar dirancang untuk digunakan seperti ini, dan karena itu pada titik tertentu saya mungkin secara korup merusak / kehilangan file host VM dan / atau filesystem
Metode 2: Gunakan grup volume khusus
Penerapan:
- sama
md0danmd1seperti pada Metode 1, kecuali buatmd1cukup besar untuk menampung VM host (mis. 5 hingga 10GB) - RAID10 besar
md2menempati ruang yang tersisa.md2berisi grup volume LVMvgvms, yang volume logisnya digunakan secara eksklusif oleh mesin virtual
Pro:
- Saya bisa bermain-main
vgvmstanpa takut merusak OS host - ini sepertinya solusi yang lebih elegan dan aman
Cons:
- jika filesystem VM host kehabisan ruang, saya harus memindahkan bagian dari filesystem-nya (mis. / usr atau / var)
vgvms, yang sepertinya tidak terlalu bagus. - Saya harus menginstal ulang OS host (yang seperti yang dinyatakan sebelumnya saya tidak keberatan melakukan)
PEMBARUAN # 1:
Salah satu alasan mengapa saya khawatir kehabisan ruang disk host VM dalam Metode 2 adalah karena saya tidak tahu apakah host VM cukup kuat untuk menjalankan semua layanan di mesin virtual, yaitu. Saya mungkin harus memigrasi beberapa / semua layanan dari mesin virtual ke OS host.
Spesifikasi perangkat keras host VM:
- Prosesor Phenom II 955 X4 Black Edition (3.2GHz, 4-core CPU)
- 2x3GB Kingston PC3-10600 DDR3 RAM
- Motherboard Gigabyte GA-880GM-USB3
- 4x WD Caviar RE3 500GB SATA II HDD (7200rpm)
- Antec BP500U Basiq 500W ATX power supply
- Casing CoolerMaster CM 690
PEMBARUAN # 2:
Salah satu alasan mengapa saya merasa bahwa sistem mungkin tidak dirancang untuk menggunakan host VG sebagai kumpulan penyimpanan libvirt di Metode 1 adalah beberapa perilaku yang saya perhatikan di virt-manager:
- setelah ditambahkan, ia mengeluh bahwa ia tidak dapat mengaktifkan VG (jelas, karena OS host sudah mengaktifkannya)
- setelah dihapus, ia menolak untuk melakukannya karena tidak dapat menonaktifkan VG (jelas, karena OS host masih menggunakan root dan menukar LVs)
Jawaban:
Pertanyaan yang dipikirkan dengan matang!
Saya akan menggunakan Metode 2, tetapi itu lebih merupakan pilihan pribadi. Bagi saya, Metode 2 Kontra tidak banyak masalah. Saya tidak melihat OS host melebihi partisi 5-10GB, kecuali jika Anda mulai menginstal hal-hal tambahan di atasnya, yang seharusnya tidak Anda lakukan. Demi kesederhanaan dan keamanan, OS host harus benar-benar instalasi minimal, tidak menjalankan apa pun kecuali minimum yang diperlukan untuk administrasi (misalnya sshd).
Metode 1 Kontra juga bukan masalah, IMO. Saya tidak berpikir akan ada risiko keamanan tambahan, karena jika VM yang di-root entah bagaimana dapat keluar dari partisi dan menginfeksi / merusak partisi lain, memiliki OS host pada VG terpisah mungkin tidak ada bedanya. Dua lainnya Kontra bukan sesuatu yang saya dapat berbicara dengan dari pengalaman langsung, tetapi saya nyali mengatakan bahwa CentOS, LVM, dan libvirt fleksibel dan cukup kuat untuk tidak khawatir tentang mereka.
EDIT - Respons terhadap Pembaruan 1
Saat ini, kinerja virtualisasi sangat rendah, terutama menggunakan prosesor dengan dukungan bawaan untuk itu, jadi saya tidak berpikir memindahkan layanan dari VM tamu ke host OS akan layak dilakukan. Anda mungkin mendapatkan peningkatan kecepatan 10% dengan menjalankan "bare metal", tetapi Anda akan kehilangan manfaat memiliki OS host yang kecil, kencang, aman, dan berpotensi berdampak pada stabilitas seluruh server. Tidak layak, IMO.
Mengingat hal ini, saya masih akan menyukai Metode 2.
Respons terhadap Pembaruan 2
Tampaknya cara khusus yang diasumsikan oleh libvirt penyimpanan adalah titik lain yang mendukung Metode 2. Rekomendasi saya adalah: lanjutkan dengan Metode 2.
sumber
Selama hanya satu sistem yang mencoba menggunakan LV yang diberikan dalam mode baca / tulis kapan saja, layak untuk menggunakan VG yang sama untuk host dan tamu. Jika beberapa sistem mencoba menulis ke LV yang sama maka kerusakan pada sistem file akan terjadi.
sumber
Anda mungkin ingin melihat ini, mungkin bermain-main & melihat bagaimana proyek ini melakukan apa yang Anda bicarakan.
ProxmoxVE adalah host KVM bare-metal yang menggunakan implementasi perl libvirt daripada rekan yang lebih berat RHEL. Ini mengimplementasikan kedua skenario.
Disk virtual .raw dan jarang, mirip dengan .qcow tetapi lebih cepat.
Format gambar disk qcow & vmdk juga didukung tetapi saya pikir mungkin ada batasan LVM yang terlibat. Saya tidak menggunakannya jadi saya tidak bisa mengatakan banyak tentang itu.
Penyimpanan LVM dibagi antara VM pada node, dan dapat berupa perangkat DRBD.
Sedangkan untuk berbagi ruang VG OS, satu-satunya batasan yang harus diperhatikan adalah ukuran foto selama pencadangan. Di sini nilai ini dapat diubah dalam file konfigurasi, dan kadang-kadang saya melihat di forum di mana orang harus mengubahnya, tetapi standarnya telah membantu saya dengan baik selama beberapa tahun sekarang - bahkan dengan disk virtual besar.
Detail penyimpanan LVM PVE:
http://pve.proxmox.com/wiki/Storage_Model#LVM_Groups_with_Network_Backing
Beginilah VG disusun:
Ditemukan grup volume "LDatastore1" menggunakan metadata tipe lvm2
Ditemukan grup volume "LDatastore0" menggunakan metadata tipe lvm2
Grup volume yang ditemukan "pve" menggunakan metadata tipe lvm2
Ini adalah LV saya:
ACTIVE '/ dev / LDatastore1 / vm-9098-disk-1' [4,00 GB] mewarisi
ACTIVE '/ dev / LDatastore1 / vm-7060-disk-1' [2.00 GB] mewarisi
ACTIVE '/ dev / LDatastore1 / vm-5555-disk-1' [8.00 GB] mewarisi
ACTIVE '/ dev / LDatastore0 / vm-4017-disk-1' [8.00 GB] mewarisi
ACTIVE '/ dev / LDatastore0 / vm-4017-disk-2' [512.00 GB] mewarisi
ACTIVE '/ dev / LDatastore0 / vm-7057-disk-1' [32.00 GB] mewarisi
ACTIVE '/ dev / LDatastore0 / vm-7055-disk-1' [32.00 GB] mewarisi
ACTIVE '/ dev / LDatastore0 / vm-6030-disk-1' [80.01 GB] mewarisi
ACTIVE '/ dev / pve / swap' [3,62 GB] mewarisi
ACTIVE '/ dev / pve / root' [7,25 GB] mewarisi
AKTIF '/ dev / pve / data' [14,80 GB] mewarisi
Ini adalah LVM pada RAID10 yang terbuat dari 6 SATA Seagate Barracuda SATA 6.700:
CPU BOGOMIPS: 53199,93
REGEX / DETIK: 824835
UKURAN HD: 19,69 GB (/ dev / mapper / LDatastore0-testlv)
BACA BUFFERED: 315,17 MB / detik
AVERAGE SEEK TIME: 7,18 ms
FSYNCS / KEDUA: 2439.31
Dan ini adalah LVM pada satu SSD Intel X25-E SATA, VG yang sama dengan data / dev / pve / di mana VM tinggal:
BOGOMIPS CPU: 53203.97
REGEX / DETIK: 825323
UKURAN HD: 7.14 GB (/ dev / mapper / pve-root)
BACA BUFFERED: 198,52 MB / detik
AVERAGE SEEK TIME: 0,26 ms
FSYNCS / KEDUA: 1867.56
sumber