溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章給大家介紹OpenStack中怎么面向用戶的操作，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
鏡像
OpenStack 鏡像通常可以被理解為“虛機模板”。鏡像也可以被認為是標準安裝介質例如ISO 鏡像. 基本上，它們都含有能啟動實例的啟動系統文件。
增加鏡像
有幾種預制作好的鏡像可以被很簡單的導入鏡像服務。一個最通常被加入的鏡像就是CirrOS 鏡像，非常小，被用來作為測試。為增加這種鏡像，只需要：
# wget https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img # glance image-create –name=’cirros image’ –is-public=true –container-format=bare –disk-format=qcow2 < cirros-0.3.0-x86_64-disk.img
glance image-create 命令有很多選項，例如 min-disk選項對啟動分區有大小要求的鏡像(象windows需要比較大的分區)非常有用。為查看這些選項： $ glance help image-create location 選項需要特別注意。它并不復制整個鏡像到Glance，而是提供鏡像的原始路徑。當啟動一個實例的時候，Glance會到該路徑加載鏡像。 copy-from 選項從指定路徑復制鏡像到 /var/lib/glance/images 。在例子中使用STDIN 重定向也完成相同任務。 運行下述命令來查看已有鏡像的詳細信息： $ glance details 刪除鏡像 為了刪除一個鏡像，用以下命令：
$ glance image-delete <image uuid>
注意：刪除鏡像不影響基于此鏡像的虛機實例或快照。
其他命令行選項： 全部選項可以用以下命令查看： $ glance help 或： OpenStack Image Service 命令行指南。 (http://docs.openstack.org/cli/quick-start/content/glance-cli-reference.html) 鏡像服務和數據庫 唯一不被Glance 數據庫存儲的是鏡像本身。Glance數據庫有兩個主要的表： images image_properties 通過直接對數據庫的操作，SQL查詢等可以得到定制化的Glance鏡像的列表和報告。 技術上，可以通過操作數據庫來更新鏡像的屬性，雖然這不是推薦的做法。 鏡像數據庫查詢示例 一個有趣的例子是修改鏡像列表和鏡像擁有者。這可以簡單地通過查找擁有者的ID來實現。以下的例子做得更多的事-會顯示擁有者的名字：
$ mysql> select glance.images.id, glance.images.name, keystone.tenant.name, is_public from glance. Images inner join keystone.tenant on glance. images.owner=keystone.tenant.id;
另一個例子，顯示某個鏡像的詳細信息：
$ mysql> select name, value from image_properties where id = <image_id>
類型模板(flavor) 在Openstack中，虛機硬件模板被稱為類型模板(flavor)，包括RAM和硬盤大小，CPU核數等。標準安裝后有5個缺省的類型。類型模板可以被有管理員權限的用戶修改(修改的權限也可以被編輯，通過在nova-api 服務器上的/etc/nova/policy.json 文件中修改訪問控制：compute_extension:flavormanage )。在系統上查看可用的類型模板： $ nova flavor-list +—-+———–+———–+——+———–++——-+-+————-+ | ID | Name | Memory_MB | Disk | Ephemeral |/| VCPUs | /| extra_specs | +—-+———–+———–+——+———–++——-+-+————-+ | 1 | m1.tiny | 512 | 0 | 0 |/| 1 | /| {} | | 2 | m1.small | 2048 | 10 | 20 |\| 1 | \| {} | | 3 | m1.medium | 4096 | 10 | 40 |/| 2 | /| {} | | 4 | m1.large | 8192 | 10 | 80 |\| 4 | \| {} | | 5 | m1.xlarge | 16384 | 10 | 160 |/| 8 | /| {} | +—-+———–+———–+——+———–++——-+-+————-+ nova flavor-create 命令可以讓經過授權的用戶創建新類型模板。其他控制功能可以通過以下命令查看：
$ nova help | grep flavor.
類型模板定義了以下元素: 列 描述 ID 一個唯一的數字ID Name 描述性的名字。xx.size_name通常方式是不需要的，雖然有些第三方工具可能需要這么設置 Memory_MB 虛機內存(MB) Disk 虛擬啟動硬盤的大小（GB）。這是個裝載啟動軟件的非持久化的硬盤。當從一個持久化硬盤啟動的時候就不需要了。 大小為 “0” 是一個特殊的大小，表示采用和啟動軟件鏡像相同的大小。 Ephemeral 指定第二個非持久化硬盤的大小。這是一個空的，沒有被格式化的硬盤，只在虛機存在的時候存在。 Swap 虛機的可選的交換分區空間 VCPUs 虛機中虛擬CPU的核數 RXTX_Factor 此可選屬性讓被創建的服務器有和其帶有的網絡硬件有不同的帶寬。這個可變因子定義RXTX(輸入輸出)與網絡硬件帶寬的比例。 缺省值是1.0，也就是說，和硬件帶寬相同。 Is_Public 布爾值，類型模板是只給租戶內的用戶用還是可以給其他租戶使用（公開）。缺省為真，即公開。 extra_specs 附加的可選項，限制哪臺主機可以運行某種類型模板。采用key/value值得方式，只有有相同key/value值得主機才能運行相關類型模板。可以用來處理在特殊情況下部署，例如： 有些類型模板只能在有GPU的主機上運行。 如何修改一個已有的類型模板? 不幸的是，OpenStack沒有提供修改模板的接口，只有增加和刪除。Dashboard里的模板修改的工作模式其實是刪除舊模板并增加一個同名模板。
安全組
對新用戶，Openstack最常見的問題是當啟動一個實例，未能設置適當的安全組，之后后無法訪問網絡上的實例。 安全組是一組應用于一個實例的網絡的IP過濾規則，是基于具體項目的，項目成員可以編輯默認的規則，或對他們組添加新規則。所有的項目如果沒有其他安全組定義，都有一個“默認”安全組，并將其應用于實例。（除非改變了這個安全組，阻擋所有的進入流量？）。 nova.conf 文件中的選項 allow_same_net_traffic (缺省為true) 是在全局范圍內，控制規則是否適用于共享一個網絡的主機群。當設置為true，在同一子網主機之間可以相互傳送所有類型數據，沒有經過過濾。在Flat模式的網絡，這使得所有項目中的所有實例可以未過濾的相互通信。在VLAN模式網絡,在同一個項目允許實例相互訪問。如果 allow_same_net_traffic 被設置為false, 安全組被部署到所有的連接，在這種情況下，還是可以模擬出 為true的效果，那就是配置缺省安全組為全部通過。 當前項目的安全組在dashboard的“訪問與安全”部分找到。 為查看一個安全組的細節，在安全組下選擇“編輯”。顯然，可以從這個界面修改安全組。另外在主訪問&安全頁面有一個“創建安全組”按鈕來創建新組。– 我們這里討論中使用的術語,與命令行的術語相同。 以下命令顯示在當前項目中的安全組列表：
$ nova secgroup-list +———+————-+ | Name | Description | +———+————-+ | default | default | | open | all ports | +———+————-+
查看一個叫‘open’的安全組：
$ nova secgroup-list-rules open +————-+———–+———+———–+————–+
IP Protocol | From Port | To Port | IP Range | Source Group |
| icmp tcp udp | -1 1 1 | 255 65535 65535 | 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 |
解釋：所有的規則都是“允許(allow)”，因為缺省都是“拒絕(deny)”。第一列是IP協議 (icmp, tcp, 或 udp) 第二列和第三列描述端口號范圍。第四列用CIDR格式描述IP地址范圍。這個例子中描述允許所有IP的所有端口。 在前面章節中介紹過，規則的條數是quota_security_group_rules被控制的，而每個項目的安全組數是被quota_security_groups quota 控制的。 當增加一個安全組時，應該用一個簡單又有解釋性的名字。因為名字會在被使用的實例中顯示但附帶說明不會顯示。比如一個安全組名字為‘http’ 會比較好，但‘張三的組’或‘組1’則不好理解。 作為例子，我們創建一個安全組，允許所有的從任何地方的web 流量能連接internet。 稱之為 “global_http”，意思為任何地方倒internet的web流量，容易理解。 +————-+————————————-+ | Name | Description | +————-+————————————-+ | global_http | allow web traffic from the internet | +————-+————————————-+ 用以下命令增加規則：
$ nova secgroup-add-rule <secgroup> <ip-proto> <from-port> <to-port><cidr> $ nova secgroup-add-rule global_http tcp 80 80 0.0.0.0/0 +————-+———–+———+———–+————–+ | IP Protocol | From Port | To Port | IP Range | Source Group | +————-+———–+———+———–+————–+ | tcp | 80 | 80 | 0.0.0.0/0 | | +————-+———–+———+———–+————–+
注意：這里的‘from-port’ 和 ‘to-port’并非源端口和目的端口，而是端口的范圍。復雜的規則可以通過多條規則實現。例如：如果想允許http 和 https 流量：
$ nova secgroup-add-rule global_http tcp 443 443 0.0.0.0/0 +————-+———–+———+———–+————–+ | IP Protocol | From Port | To Port | IP Range | Source Group | +————-+———–+———+———–+————–+ | tcp | 443 | 443 | 0.0.0.0/0 | | +————-+———–+———+———–+————–+
增加上一條之后，規則變為：
$ nova secgroup-list-rules global_http +————-+———–+———+———–+————–+ | IP Protocol | From Port | To Port | IP Range | Source Group | +————-+———–+———+———–+————–+ | tcp | 80 | 80 | 0.0.0.0/0 | | | tcp | 443 | 443 | 0.0.0.0/0 | | +————-+———–+———+———–+————–+
反方向操作是secgroup-delete-rule，同樣的格式。如果想刪除整個安全組可以用：secgroup-delete. 為一個實例的集群創建安全組： SourceGroups 采用動態的模式定義CIDR 可訪問資源。一個用戶設置一個SourceGroup (有安全組名字)， 所有此用戶在其他的實例上可以動態選擇使用這個SourceGroup。 這種方式減輕了每個新用戶需要一個新的規則的麻煩。使用方式： usage: nova secgroup-add-group-rule <secgroup> <source-group> <ip-proto> <from-port> <to-port> $ nova secgroup-add-group-rule cluster global-http tcp 22 22 “cluster” 規則允許所有使用‘global-http’的實例能通過ssh 訪問。
塊存儲
連接： 塊存儲創建失敗 OpenStack卷是持久的塊存儲設備，可以附加到實例或分離，但同時只能連接到一個實例，類似于一個外部硬盤，不象網絡文件系統或對象存儲那樣提供共享存儲方式。塊存儲讓實例中的操作系統把文件系統加載和安裝到塊設備。 類似于其他可移動磁盤技術，重要的是操作系統不能利用磁盤，然后馬上移掉它，數據容易出問題。在Linux實例中任何文件系統在硬件移除前需要從卷中卸載。OpenStack volume 服務不知道從一個實例中移除卷是否安全，因此只能根據指令去做。如果用戶告訴volume服務從一個實例卸載卷，而這個卷正在被寫入，可以想象文件系統肯定會有某種程度的損壞，不管是什么進程在用這個卷。 OpenStack沒有涉及實例操作系統在訪問塊設備時需要的步驟等等相關規則。 所涉及到的只有如何創建卷并將其掛載到實例或卸載。這些操作可以在dashboard的‘卷（volume）’頁面中找到，或用cinder命令行客戶端。 為了增加一個卷只需要名字和卷大小（GB），將其輸入到‘創建卷’菜單，或者用命令行方式： $ cinder create –display-name test-volume 10 創建了一個人名為‘test-volume’的卷，10GB。列出已存在的卷和所連接的實例(如果有)：
$ cinder list +————+———+——————–+——+————-+————-+ | ID | Status | Display Name | Size | Volume Type | Attached to | +————+———+——————–+——+————-+————-+ | 0821...19f | active | test-volume | 10 | None | | +————+———+——————–+——+————-+————-+
塊存儲服務還允許創建快照。記住這是塊級別的快照，最好在卷沒有連接到實例的時候進行快照，或者卷沒有被加載或使用的時候做。 如果在卷被頻繁使用的時候做，可能得到的是一個不一致的文件系統。 實際上，缺省情況下，volume卷服務在卷被加載時不做快照，–你可以強迫它做。為了創建快照，一種方式是在dashboard的卷頁面選擇“創建快照”，或使用命令行：
usage: cinder snapshot-create [–force <True|False>] [–display-name <display-name>] [–display-description <display-description>] <volume-id>
Positional arguments: <volume-id> ID of the volume to snapshot Optional arguments: –force <True|False> Optional flag to indicate whether to snapshot a volume even if its attached to an instance. (Default=False) –display-name <display-name> Optional snapshot name. (Default=None) –display-description <display-description> Optional snapshot description. (Default=None) 塊存儲創建失敗 如果用戶試圖創建卷時馬上進入一個錯誤狀態，查錯最好的辦法是基于卷的UUID 來查詢(grep) cinder的log文件。首先嘗試云控制器上的日志文件，然后試所要創建卷的存儲節點: # grep 903b85d0-bacc-4855-a261-10843fc2d65b /var/log/cinder/*.log
實例 啟動實例 實例啟動失敗 實例特性數據
實例是在一個OpenStack云運行的虛擬機。本節討論如何操作實例，相關鏡像，網絡特性，以及如何在數據庫中顯示的。 啟動實例：為了發起一個實例，需要選擇一個鏡像，一個類型模型，和一個名字。 名字不一定需要唯一，但如果是唯一的話，你的日子會好過很多，因為很多工具用到名字代替UUID。 發起實例可以通過dashboard的“實例”頁面的“發起實例(launch instance)”按鈕，然后到選擇鏡像和快照頁面。 命令行模式：$ nova boot –flavor <flavor> –image <image> <name> 這里有些選項。在啟動實例之前最好讀完本節，這是最基本的命令。 $ nova delete <instance-uuid> 要注意， 將一個實例關閉電源(關機)并不代表這個實例在openstack中被去除。 實例啟動失敗 如果一個實例不能啟動并馬上進入”Error” 狀態，有幾種方式來排查故障。有些只需普通用戶權限有些需要能login到log服務器或計算節點。 不能啟動最通常的原因， 是對配額的分配使系統中沒有合適的計算節點滿足實例要求。這種情況下可以用nova show 命令來查看，錯誤信息如下：
| $ nova show test-instance +————————+————————————————————–| Property | Value / +————————+————————————————————–| OS-DCF:diskConfig | MANUAL / | OS-EXT-STS:power_state | 0 | OS-EXT-STS:task_state | None / | OS-EXT-STS:vm_state | error | accessIPv4 | / | accessIPv6 | | config_drive | / | created | 2013-03-01T19:28:24Z | fault | {u’message’: u’NoValidHost’, u’code’: 500, u’created’: u‘2013/ | flavor | xxl.super (11) | hostId | / | id | 940f3b2f-bd74-45ad-bee7-eb0a7318aa84 | image | quantal-test (65b4f432-7375-42b6-a9b8-7f654a1e676e) / | key_name | None | metadata | {} / | name | test-instance | security_groups | [{u’name’: u’default’}] / | status | ERROR | tenant_id | 98333a1a28e746fa8c629c83a818ad57 / | updated | 2013-03-01T19:28:26Z | user_id | a1ef823458d24a68955fec6f3d390019 / +————————+————————————————————– |
在本例子中看到錯誤信息顯示為 NoValidHost 表明調度器無法滿足實例的需求。 如果nova show 顯示的信息不夠，可以搜索相關計算節點的nova-compute.log文件中的內容，用實例的UUID檢索。或者調度服務器上的nova-scheduler.log，這些都能提供底層的錯誤信息。 作為管理員用 nova show 命令會顯示實例所在的計算節點的HostID 。但如果實例沒有被調度成功，則沒有這個ID。 實例特性數據 有各種各樣的方法來注入定制化的數據包括用戶數據，元數據服務，授權密鑰(authorized_keys)注入，和文件注入。 澄清用戶數據與元數據的區別： “用戶數據”是一部分數據，在實例沒有運行時設置。這個用戶數據可以在實例運行中存取和使用。人們使用這個用戶數據來存儲配置，腳本,或其他的數據，如果租戶想要的話。 而元數據，是與實例相關聯的一組 鍵/值（key/value）。在實例存在期間，當用戶通過Compute API 發出指令時，nova-compute從實例的內部或外部來讀寫這些鍵/值。但是，你不能通過與EC2元數據服務兼容的方式來直接查詢元數據。 用戶可以通過nova命令生成和注冊ssh 密鑰：
$ nova keypair-add mykey > mykey.pem
這生成了一個名字為mykey的密鑰，可以關聯到實例上。mykey.pem 文件是私鑰，需要保存到一個安全的地方，因為它允許以root的用戶訪問與其關聯的實例。 你可以用以下命令注冊一個公鑰： $ nova keypair-add –pub-key mykey.pub mykey 你必須有相對應的私鑰來訪問和此公鑰相關聯的實例。 在一個實例啟動時關聯密鑰：在命令行增加 –key_name mykey：
$ nova boot –image ubuntu-cloudimage –flavor 1 –key_name mykey
當啟動一個服務器時，可以加上元數據，這樣就能更容易地分辨運行的實例。 用 –meta 選項，帶一個 key=value 對, 并確定這個鍵值對的定義。例如，可以增加一個描述：
$ nova boot –image=test-image –flavor=1 smallimage –meta description=’Small test image’
在實例信息中可以看到元數據的信息：
| $ nova show smallimage +————————+—————————————–+ | Property | Value | +————————+—————————————–+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-STS:power_state | 1 | | OS-EXT-STS:task_state | None | | OS-EXT-STS:vm_state | active | | accessIPv4 | | | accessIPv6 | | | config_drive | | | created | 2012-05-16T20:48:23Z | | flavor | m1.small | | hostId | de0...487 | | id | 8ec...f915 | | image | natty-image | | key_name | | | metadata | {u’description’: u’Small test image’} | | name | smallimage2 | | private network | 172.16.101.11 | | progress | 0 | | public network | 10.4.113.11 | | status | ACTIVE | | tenant_id | e83...482 | | updated | 2012-05-16T20:48:35Z | | user_id | de3...0a9 | +————————+—————————————–+ |
用戶數據是元數據服務里一個特殊的鍵，它持有一個文件，在本實例上的云應用能訪問。例如 cloudinit (https://help.ubuntu.com/community/CloudInit) 是一個開源軟件包，在實例啟動的時候可以使用這些用戶數據。 用戶數據的生成：可以在本地創建一個文件然后傳送給實例，在實例創建的時候，增加選項： –user-data <user-data-file> 。 舉例：
$ nova boot –image ubuntu-cloudimage –flavor 1 –user-data mydata.file
任意文件可以被放到實例的文件系統，采用 –file <dst-path=src-path> 選項。 最多可以存放5個文件。 例如有一個特殊授權密鑰文件名字為：special_authorized_keysfile ， 要放到實例中代替通常的ssh密鑰注入，可以用以下名利：
$ nova boot –image ubuntu-cloudimage –flavor 1 –file /root/.ssh/authorized_keys=special_authorized_keysfile
關聯安全組
如前面所講，如果允許網絡流量到實例，安全組的配置是需要的，除非缺省安全組已經被配置了允許流量通過。 添加安全組通常在實例啟動時做。在dashboard上這部分在“訪問與安全”選項卡的“啟動實例”對話框。在命令行啟動方式下， 增加安全組用 –security-groups 選項， 并用逗號分隔一組安全組。 還可以在實例運行的時候增加安全組。目前此功能只能在命令行方式下做。
$ nova add-secgroup <server> <securitygroup> $ nova remove-secgroup <server> <securitygroup>
Floating IPs 前面介紹過，項目有一個配額來控制floating ip的數量，但是這些在可以使用之前需要被一個用戶分配好。分配一個floating IP到項目是通過dashboard “訪問與安全”頁面里的 “分配IP項目” 按鈕， 或在命令行上使用: $ nova floating-ip-create 一旦被分配， floating ip 可以被設置到運行實例中，通過dashboard， 一種方式是在“訪問與安全”頁面里的IP 操作的 “設置IP項目” 按鈕，或者在“實例”頁面中對應實例的相關按鈕。相反操作“floating ip去關聯” , 只在“訪問與安全”頁面里可以操作。 命令行的方式中，下列命令完成以上任務：
$ nova add-floating-ip <server> <address> $ nova remove-floating-ip <server> <address>
加載塊存儲
可以在dashboard的“卷”頁面上為實例加載塊存儲。點擊“編輯加載”選擇加載哪個卷。 在命令行中，可以：
$ nova volume-attach <server> <volume>
還可以用命令行在實例啟動的時候指定塊設備，命令如下：
–block-device-mapping <dev-namedev-name=mapping>
塊設備 mapping的格式是： <dev-name=<id>:<type>:<size(GB)>:<delete-on-terminate>，這里dev-name 卷所加載的設備名稱：/dev/dev_name。id 卷啟動的ID，會在 nova volume-list 的輸出中看到。 Type 或是 snap，表示卷是從一個快照建立的，或其他類型(空字符串都可以)。在上面例子中，卷并非由快照建立的，因此下面的顯示為空。 size (GB) 卷大小（GB）。也可以不填，讓計算服務決定大小。 delete-on-terminate 布爾值， 表明在實例被刪除后卷是否被刪除。 True 為1， False為0。 如果原來就有一個塊存儲上有啟動文件的，甚至可以直接從塊存儲上啟動實例。下面例子中會嘗試從ID=13的卷中啟動，這個卷不會被刪除。 –key-name 要改為正確的密鑰。
$ nova boot –flavor 2 –key-name mykey –block-device-mapping vda=13:::0 boot-from-vol-test
因為bug 1163566 (https://bugs.launchpad.net/nova/+bug/1163566) 在horizon中你必須選擇一個鏡像來啟動，雖然這個鏡像你沒有用。 為了正常從一個鏡像啟動并加載塊存儲，不要將設備映射到vda。
制作快照
保證快照的一致性 OpenStack的快照機制允許你從一臺運行的實例中創建鏡像。這使得對基礎鏡像的升級或做定制修改變得非常容易。 為一個正在運行的實例做鏡像可以用命令：
$ nova image-create <instance name or uuid> <name of new image> Dashboard
上面關于鏡像的接口有些清晰，因為它們將快照頁面分在三個部分：鏡像、實例快照、卷快照。但是，實例快照是一個鏡像。快照鏡像和從網上下載的原始鏡像的唯一區別就是快照鏡像在glance數控庫中有附加的屬性，這些屬性可以在image_properties 表中找到，包括：屬性 值 image_type 快照 instance_uuid <被快照的實例的uuid > base_image_ref <被快照的卷的uuid > image_location 快照 保證快照一致性。
本節內容來自 Sébastien Han’s OpenStack: Perform Consistent Snapshots blog entry (http://www.sebastien-han.fr/blog/2012/12/10/openstack-perform-consistent-snapshots/)
快照抓取的是文件系統的狀態，而非內存的狀態。因此為了保證快照包括所需要的信息，要運行的程序將數據寫到磁盤上。文件系統不能有‘臟’緩存數據：當程序要求寫磁盤時，系統還沒寫完。 為了確保重要內容寫到磁盤(例如，數據庫)，我們建議您閱讀對于那些應用程序的命令文檔來確定他們的內容同步到磁盤。如果你不確定如何做到這一點，最安全的方法是簡單地正常停止這些服務運行。 為解決‘臟’緩存數據問題，我們還建議在做快照前用sync命令。 # sync 運行sync寫臟緩沖區(緩沖塊已修改但還沒有寫到磁盤塊)到磁盤。 只運行sync命令還不足以保證文件系統的一致性。建議用fsfreeze 工具，可以阻止對文件系統的新的訪問，以建立一個適合做鏡像的文件系統。fsfreeze 支持幾種文件系統, ext3, ext4, 和 XFS. 如果你的系統是在ubuntu上的，安裝 util-linux 包以得到 fsfreeze：
# apt-get install util-linux
如果你的操作系統沒有一個版本的fsfreeze可用，您可以使用xfs_freez代替，可以在Ubuntu的xfsprogs包找到。盡管是“xfs”的名字，xfs_freez也適用在ext3和ext4，如果您使用的是Linux內核版本2.6.29或更新的情況下。Xfs_freez 支持相同的命令行參數fsfreeze一樣。 例如需要對一個持久的塊存儲卷做快照，客戶機操作系統探測到的/ dev /vdb 掛載到 /mnt。fsfreeze命令接受2個參數: -f: freeze the system -u: un-freeze the system 為了凍結一個卷，作為root用戶: # fsfreeze -f /mnt 卷必須被掛載才能被凍結。 當“fsfreeze - f”命令發出，在文件系統所有正在進行中的事務被允許完成，新寫系統的調用被阻止，以及其他修改文件系統的調用都停止了。最重要的是，所有的臟數據、元數據和日志信息被寫入到磁盤。 一旦卷已被凍結,不要試圖讀或寫，因為這些操作會掛起。 操作系統停止每個I / O操作和任何I / O的嘗試被延遲，直到文件系統被解凍。 一旦你已經執行了fsfreeze命令，就可以安全的執行快照。例如,如果您的實例被命名為mon-instance，你用快照得到一個鏡像，名字叫mon-snapshot，命令如下：
$ nova image-create mon-instance mon-snapshot
當快照已經完成，可以用下面的命令解凍文件系統，在實例中用root用戶： # fsfreeze -u /mnt 如果你想備份根文件系統，您不能簡單地執行上面的命令，因為它會凍結提示。而是運行下面的命令：
# fsfreeze -f / && sleep 30 && fsfreeze -u /
實例在數據庫中的信息 實例信息存儲在幾個數據庫表中，表操作者最可能需要查看的是‘實例instanse’表。 實例表 帶有正在運行或被刪除的實例的幾乎所有的信息。如果詳細地看，它有很復雜的字段，都我我我在是操作者查詢信息所需要的。 實例已被刪除時“delete”字段設置為“1”， 如果沒有刪除為NULL。這對于實例的查詢是非常重要的。 “uuid”字段是實例的uuid，作為外鍵用于在整個數據庫中其他的表。這個id還在日志、dashboard和命令行工具等里面來唯一地標識一個實例。 通過一組外鍵可以找到實例之間的關系。最有用的是“user_id”和“項目id”，它們是創建實例的用戶的和其所在項目的uuid。 “hostname” 字段表示實例是在哪個計算節點上運行。”display-name”與”host”名字相同，可以用nova rename命令修改。 還有一些時間相關字段，可以在一個實例狀態發生改變時用于跟蹤：
created_at updated_at deleted_at scheduled_at launched_at terminated_at
關于OpenStack中怎么面向用戶的操作就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
