Proxmox 沒有檔案管理員時，如何把檔案放進虛擬機器

檔案在自己的電腦上，需要放進客體裡。在介面上找遍了往那個方向上傳的按鈕，卻一個也沒有。

這個缺席是設計上的決定，不是疏忽，而理解了原因，其餘的部分就一目了然。Proxmox VE 管理的是機器，而不是機器的內部。從外部看，客體的儲存空間是一個磁碟映像檔：一大塊看不透內容的資料。虛擬化管理程式不會去讀取其中的檔案系統，正因如此，它才能承載任何作業系統，而不需要知道關於它的任何事。

所以每一種進入方式，都是刻意跨越這道邊界的方式，而每一種跨越的方法都不同。

平淡無奇、但通常正確的答案

透過網路複製，就像對任何其他機器一樣。透過 SSH 複製檔案、檔案共用、物件儲存，或是在客體內部從網頁下載。

這個方法常常意外地被跳過，因為它感覺太普通，彷彿虛擬化應該提供更好的東西。並沒有，也不應該有。客體就是網路上的一台機器，就該把它當成一台機器看待。這條路徑能處理任何大小的檔案，保有自己的權限，而且完全不牽涉虛擬化管理程式。

以下幾種情況，適用於這條路走不通的時候。

客體在執行中，卻連不上

客體代理程式提供了一條不經過網路的通道，因為它是透過主機與客體之間的虛擬裝置運作的。

它確實能讀寫檔案。這兩項操作各自有獨立的端點，要把設定檔或金鑰放進一台失去網路的機器時，正好派得上用場。

依賴它之前值得先知道的限制：單次寫入的上限大約是 60 KB，讀取更大的檔案時，結果會標示為已截斷。這條通道是為小東西設計的。用來傳設定檔非常好用，用來傳安裝映像檔則毫無用處，而在事故處理到一半時才發現這一點，比在這裡讀到要糟得多。

在用來驗證這一點的主機上，八台虛擬機器中有七台已啟用代理程式，所以對大多數人來說，這條路早已可用，只是沒有人知道。

客體已關機時

客體停止後，可以在主機上掛載它的磁碟映像檔，直接瀏覽其中的檔案系統。這是最強大的選項：完整存取、不限大小、不需要代理程式。

它也是本文中最容易傷到自己的一把刀。

悄悄造成破壞的捷徑

不要從主機掛載執行中客體的檔案系統。

這樣做常常看起來沒問題。掛載映像檔，看到檔案，複製一個進去，什麼錯誤也沒有。與此同時，客體也掛載著同一個檔案系統，並快取著它自己認定的磁碟內容。兩個彼此獨立的寫入者，一個檔案系統，誰也不知道對方的存在。結果就是日後才浮現的損壞，看起來像是磁碟出了問題，而不像是某個操作造成的。

客體在執行中時，就走網路或代理程式。需要用到磁碟時，先停止客體。

客體完全無法開機時

這正是最想把檔案拿出來的時刻，而前面的選項全都行不通了。

這時就走備份這條路。備份可以檢視內容，也能從中取出個別檔案，而不必還原整個客體。它比這裡提到的其他方法都慢，卻是機器本身無法使用時唯一還能走通的路。

值得留意的是：這也說明了為什麼從未打開過的備份還稱不上是備份。需要從一台已經掛掉的機器取出單一檔案的那天，才發現封存檔無法還原，是最糟糕的時機。

容器是另一回事

容器並沒有一個內含不透明檔案系統的磁碟映像檔。它的檔案就放在主機自己的儲存空間上，所以從主機看過去，檔案就直接在那裡。

正是這種不對稱，讓容器版本的同一個問題成了另一個獨立的搜尋主題。同樣的任務，難度完全不同，為其中一方寫的建議，套用到另一方時往往是錯的。

Atlas 的做法與限制

Atlas 為客體提供檔案瀏覽器，而其中的設計選擇才是值得一提的部分。

它在客體內部執行，只在客體自己的回送位址上監聽，所以從網路上完全無法連到它。要透過 Atlas 才能連到它。也就是說，加上檔案瀏覽器並不會多出一個暴露給區域網路上其他裝置的服務，而這通常正是在機器上架設網頁版檔案管理員時，不知不覺付出的代價。

限制直說如下：它以單一客體為單位，必須存在於要瀏覽的那個客體中；它是用來查看與搬移個別檔案的便利工具，不是大量資料的傳輸機制；它也不能取代備份。大量資料仍然應該走上面提到的網路路徑，而對於無法開機的機器，備份路線依然是唯一的方法。