Gdzie udokumentowano użycie obrazu gościa w chmurze Ubuntu w OpenStack?

Ilekroć konfiguruję wdrożenie devstack lub OpenStack, chcę dodać najnowszy obraz serwera LTS Ubuntu. W przeszłości udało mi się to kilka razy i wierzę, że można to osiągnąć za pomocą:

wget http://uec-images.ubuntu.com/releases/12.04.2/release/ubuntu-12.04.2-server-cloudimg-amd64-disk1.img
glance image-create --is-public true --disk-format qcow2 --container-format bare --name "precise" < ubuntu-12.04.2-server-cloudimg-amd64-disk1.img

Zastanawiam się jednak, gdzie mogę znaleźć oficjalnie wspieraną dokumentację na ten temat? Jak mogę się do tego przyczynić? Czasami mam problemy i bez oficjalnych instrukcji nigdy nie jestem pewien, czy jest to powyższe polecenie, czy moje wdrożenie. Dwukrotnie próbowałem dodać te instrukcje do oficjalnych dokumentów OpenStack i / lub towarzyszących im komentarzy Disqus, ale zostały one usunięte i nie mogę znaleźć spójnej, obsługiwanej instrukcji, aby to zrobić, spodziewałbym się bardzo podstawowej procedury.

A co z nieuchwytnymi opcjami inicjowania chmury dla gości? Gdzie mogę znaleźć instrukcje, jak z nich korzystać? Z terminala i interfejsu internetowego? Kiedyś musiałem poszukać tych informacji w kodzie źródłowym.

Do tej pory znalazłem witrynę z listą dostępnych obrazów , ale taką, która nie określa, jakie są formaty obrazów - zawsze muszę szukać w Google tych informacji. Istnieje wiki UEC, która zawiera wiele przepisów na temat tworzenia własnych obrazów, ale nie na temat korzystania z istniejących (lub gotowych obrazów w chmurze Ubuntu). Następnie jest najłatwiejsza do znalezienia kategoria „chmura” na ubuntu.com, która prowadzi tylko do niektórych broszur promocyjnych i listy nieinformacyjnych obrazów w chmurze.

Wiem, że jest to raport częściowo błędny (który chciałbym naprawić lub pomóc naprawić :)), ale chciałbym również poznać odpowiedzi na zadane pytania.

Miałem ten sam problem, więc ostatecznie pobrałem wszystkie prefiksy „trusty-server-cloudimg-amd64”. Była tar, która po rozpakowaniu zawierała pliki README., które zawierały pewne informacje:

To skompresowane archiwum tar zawiera pliki związane z tym obrazem maszyny. Każda nazwa pliku jest poprzedzona ciągiem ciągłym oznaczającym informacje o wydaniu i architekturze. Prefiksem może być na przykład „maverick-server-cloudimg-amd64”, w którym to przypadku pliki będą nazywane jak maverick-server-cloudimg-amd64.img maverick-server-cloudimg-amd64-vmlinuz-virtual

W archiwum mogą znajdować się wszystkie lub niektóre z następujących plików:

• .img Ten plik jest obrazem partycji. Można go łączyć, przesyłać i rejestrować w EC2, Eucalyptus lub OpenStack jako Amazon Machine Image (ami / emi).

• -disk1.img To jest skompresowany obraz dysku qcow2. Można go przesłać do OpenStack lub uruchomić bezpośrednio za pomocą kvm. Prawdopodobnie powinieneś rozpakować obraz (konwersja qemu-img) przed użyciem w środowisku innym niż testowanie.

• -uefi1.img To jest obraz dysku skompresowanego qcow2, który ma partycjonowanie GPT i bootloader UEFI. Jest bootowalny przez UEFI, BIOS / GPT i PVGRUB (z obsługą tablic partycji GPT. Jest bootowalny w OpenStack lub bezpośrednio przez kvm. Prawdopodobnie powinieneś rozpakować obrazy (konwersja qemu-img) przed użyciem go w środowisku innym niż testowanie .

• -root.tar.gz To jest skompresowany plik tar zawierający zawartość głównego systemu plików. Zasadniczo „tar cpzf - /”.

• -vmlinuz-virtual To jest jądro Linuksa. Można go łączyć, przesyłać i rejestrować UEC jako obraz jądra Amazon (aki / eki). Ciąg „-virtual” reprezentuje pakiet Ubuntu Linux, z którego pochodzi to jądro. Może to być potencjalnie „-server” lub inny ciąg.

• -initrd-virtual To jest initrd dla Linuksa. Można go łączyć, przesyłać i rejestrować UEC jako Amazon Ramdisk Image (ari / eri). Nie wszystkie obrazy wymagają initrd, dlatego ten plik może nie być obecny. Jeśli nie jest obecny, obraz powinien zostać zarejestrowany bez ramdysku.

• -loader Ten plik to obraz zgodny z wieloma systemami, który może załadować obraz gościa. W instalacjach UEC, gdzie systemem operacyjnym hosta jest wersja 10.10 lub nowsza (LP: # 611144), można to zarejestrować jako jądro (eki). Zapewnia funkcję podobną do wydanej przez Amazon funkcji „Włączanie jądra dostarczanego przez użytkownika”. Gdy moduł ładujący jest używany do rozruchu instancji, aktualizacja jądra wykonana wewnątrz instancji będzie miała wpływ na kolejne rozruchy.

• -floppy Ten plik to obraz dyskietki. Nie jest użyteczny ani odpowiedni do uruchamiania wewnątrz EC2 lub UEC. Celem tego pliku jest umożliwienie rozruchu .img poza chmurą. Aby uruchomić system poza środowiskiem chmurowym (w którym nie ma usługi metadanych), można użyć następującego wiersza polecenia kvm: kvm -boot a -fda -floppy -drive plik = .img, if = virtio Nie jest to konieczne, i ogólnie przestarzały, jeśli dostępny jest -disk1.img.

możesz znaleźć format obrazu, używając:

# qemu-img info image_filename.

Dzięki temu dowiesz się, czy jest on surowy, czy qcow2 i jaki jest jego rozmiar.