Saya memiliki mesin virtual Windows Server 2012 R2; ya dengan semua pembaruan. Perangkat lunak tambahan termasuk Microsoft SQL Server 2014 (2012 pada VM sebelumnya). Perusahaan web hosting menyertakan xenpci.sys (EJBPV XenPCI Driver (Checked Build), James Harper) sebagai bagian dari instalasi default mereka di semua VM dan Plesk.
Secara berkala, OS hang, layar biru, atau reboot. Saya mendapatkan mini dump, meskipun tidak setiap saat. Masalah yang biasa terjadi adalah:
Galat: CRITICAL_STRUCTURE_CORRUPTION
File tingkat atas spesifik, jelas bukan penyebabnya, bervariasi: win32k.sys, ntoskrnl.exe, xenpci.sys (driver Xen, meskipun hanya muncul beberapa kali), dan ndis.sys.
Penganalisa OSR (Open System Resources) tidak banyak membantu. Alat analisis WhoCrashed sedikit lebih membantu.
Disebutkan:
17 dump dumping telah ditemukan dan dianalisis. Hanya 10 yang termasuk dalam laporan ini. Pengemudi pihak ketiga telah diidentifikasi sebagai penyebab sistem crash pada komputer Anda. Sangat disarankan agar Anda memeriksa pembaruan untuk driver ini di situs web perusahaan mereka. Klik tautan di bawah untuk mencari dengan Google untuk pembaruan untuk driver ini:
xenpci.sys (EJBPV XenPCI Driver (Checked Build), James Harper)
Saya mencoba mendorong perusahaan web hosting untuk meneliti topik tersebut, tetapi mereka bisa dengan tangan kosong. Saya tidak yakin bahwa driver Xen salah. WhoCrashed mengambilnya, saya berasumsi hanya karena itu adalah pembalap terakhir beberapa kali dan itu adalah pihak ketiga, sehingga membuatnya bersalah. Saya tidak menulis WhoCrashed, jadi sulit untuk berkomentar lebih lanjut.
Pertanyaan saya adalah bagaimana cara mengatasi masalah tersebut.
Perusahaan web hosting sudah mencoba memberi saya dua mesin virtual baru selama beberapa tahun terakhir. Masalahnya bermigrasi. Saya menginstal SQL Server, tetapi OS dan Plesk datang secara default. Oke, ada perangkat lunak server surat juga. Perusahaan web hosting juga mengatakan kepada saya bahwa mereka tidak memiliki klien lain yang juga mengeluh. Mereka menjalankan tes disk beberapa kali. Kesehatan disk bagus.
Saya tidak memeriksa kesehatan registri, tetapi masalahnya terjadi pada instalasi dan terjadi secara rutin, jadi saya harus mengabaikannya. Saya menggunakan VM ketiga atau keempat saya sekarang.
Sekali lagi, saya menyebutkan Xen karena WhoCrashed menyebutkannya, tetapi saya tidak yakin itu sebagai penyebabnya, dan klien lain benar-benar menggunakannya. Sistem memiliki memori dan penyimpanan yang memadai, sehingga tidak menjadi masalah.
UPDATE: Berikut adalah beberapa jawaban dari perusahaan hosting web untuk pertanyaan saya.
Dalam skenario biasa, kinerja VM akan terdegradasi setelah Anda menghapus driver. Mungkin ada beberapa masalah sinkronisasi dengan Hardware Node.
Apakah saya menggunakan bangunan yang dicentang atau dirilis?
Anda menggunakan bangunan bertanda-uji, yang sama dari situs pengembang.
Bagaimana saya tahu? Dialog properti Xen PCI di Device Manager tidak mengatakan satu atau lain cara. Apakah entri di Pengelola Perangkat satu-satunya lokasi? Saya memeriksa Program dan Fitur dan tidak melihat apa pun yang tercantum.
Anda dapat memeriksa versi di bawah Tambah atau Hapus program. Lihat snapshot terlampir.
Bagaimana / di mana saya dapat menemukan di mana versi terbaru di situs mereka?
Situs pengembang tidak berfungsi - http://www.meadowcourt.org/downloads/ Anda dapat donwload rilis yang ditandatangani terbaru dari sini - http://wiki.univention.de/index.php?title=Instaling-signed-GPLPV- driver
Bagaimana saya tahu Xen, 0.11.0.373 milik (Xen 4.6? 3.0? Xy?)
Kami menggunakan Xen 3.4.4, Anda tidak dapat melihatnya dari VM Anda. Itu hanya dapat dilihat dari simpul perangkat keras.
Pembaruan 2: Perusahaan hosting menginstal dua perangkat lunak James Harper.
GPL PV Drivers for Windows
EJB PV Drivers for Windows
sumber
Jawaban:
( Checked Build ) adalah bendera merah besar. Anda benar-benar tidak boleh menggunakan "memeriksa" membangun apa pun dalam produksi. Jika perusahaan hosting Anda memuat driver ini untuk Anda, maka mereka benar-benar membuat kesalahan.
Bangunan yang diperiksa termasuk simbol asing dan pengecekan kesalahan tambahan yang membantu pengembang. Mereka bukan membangun produksi.
Lebih jauh, apa yang dikatakan di sini adalah bahwa kesalahan apa pun yang menyebabkan mesin berhenti mungkin masih terjadi pada driver yang tidak diperiksa, namun, itu mungkin hanya menyebabkan efek samping yang tidak fatal seperti kebocoran memori di rilis build. Tetapi dalam membangun diperiksa, karena pemeriksaan kesalahan yang lebih ketat, itu menghentikan seluruh OS. Itulah inti dari bangunan yang diperiksa, untuk menonjolkan kesalahan dan mendorongnya ke wajah pengembang, sebelum mengirimkan kode ke pelanggan.
Untuk lebih jauh, tidak terlalu penting jika VM lain juga memiliki driver yang sama persis dimuat (yang diperiksa diperiksa) dan tampaknya tidak crash. Beberapa komponen khusus untuk VM itu menjalankan beberapa perilaku atau keadaan tertentu yang memicu bug pada driver itu. (Driver dan aplikasi berinteraksi dalam segala macam cara, mungkin dua mesin memiliki driver buggy yang sama dimuat, tetapi hanya satu dari server yang menginstal SQL, dan karena server telah menginstal SQL, ia melakukan penguncian halaman memori unik ini dengan cara yang server lain tidak melakukan, yang menyebabkan bug driver pihak ke-3 untuk memundurkan kepalanya yang jelek. (Hanya sebuah contoh.))
Tidak ada tempat lain untuk menyalahkan di sini. Anda tidak dapat menjalankan build driver yang telah diperiksa dalam produksi dan berharap bersenang-senang. Mereka hanya untuk tujuan pengembangan dan pengujian.
Terakhir, satu-satunya tempat lain untuk pergi dari sini adalah untuk mengumpulkan dump penuh dan menjalankannya melalui WinDBG. Anda dapat menghabiskan waktu enam jam untuk debugging yang intens, tumpukan yang tidak ditangguhkan, melacak utas, mengikuti IRP ke port penyelesaiannya ... atau Anda bisa menyingkirkan driver build yang dicentang itu. :)
Mungkin juga mencoba menjalankan driver melalui Driver Verifier . Dalam lingkungan pengujian. Di mana bangunan yang diperiksa harus tetap. ;)
sumber
Xen 3.4.4 terlalu tua. 13 Maret 2013
Windows 2012 R2 dirilis pada 18 Oktober 2013 .
Untuk memberi Anda perbandingan yang sebenarnya, XenServer dari Citrix menambahkan dukungan Windows Server 2012 R2 dalam versi 6.2SP1 mereka, yang dirilis pada 13 Desember 2013 . ( http://support.citrix.com/article/CTX139788 )
Lihat itu untuk driver GPLPV; Anda hanya melihat referensi ke cabang Xen 4.4.0 untuk 2008R2 ..
Lihat itu untuk pernyataan resmi proyek xen tentang dukungan Windows. Saya tidak bermaksud itu tidak dapat menjalankannya, tetapi Anda melihat dukungannya. Anda akan menjalankan server produksi pada platform itu?
sumber