Readme: Fix grammar

This commit is contained in:
Jakub Jirutka 2019-12-22 15:36:06 +01:00
parent d4b56bd70a
commit 9a9446c27f

View file

@ -8,7 +8,7 @@ ifdef::env-github[]
image:https://travis-ci.org/{gh-name}.svg?branch=master["Build Status", link="https://travis-ci.org/{gh-name}"] image:https://travis-ci.org/{gh-name}.svg?branch=master["Build Status", link="https://travis-ci.org/{gh-name}"]
endif::env-github[] endif::env-github[]
This project provides script for making customized https://alpinelinux.org/[Alpine Linux] disk images for virtual machines. This project provides a script for making customized https://alpinelinux.org/[Alpine Linux] disk images for virtual machines.
Its quite simple (250 LoC of shell), fast (~40 seconds on Travis CI including Travis VM initialization) and requires minimum dependencies (QEMU and filesystem tools). Its quite simple (250 LoC of shell), fast (~40 seconds on Travis CI including Travis VM initialization) and requires minimum dependencies (QEMU and filesystem tools).
TIP: Dont need VM, just want to chroot into Alpine Linux (e.g. on CI)? TIP: Dont need VM, just want to chroot into Alpine Linux (e.g. on CI)?
@ -41,10 +41,10 @@ wget https://raw.githubusercontent.com/{gh-name}/v{version}/{script-name} \
=== Creating Image for VMware (ESXi) === Creating Image for VMware (ESXi)
VMware and disk images (virtual disks) is one big mess. VMware and disk images (virtual disks) is one big mess.
You can find that VMware uses format VMDK, but the problem is that this is not a single format. You can find that VMware uses the VMDK format, but the problem is that this is not a single format.
Actually it has many subformats with very different structure and various (in)compatibility with VMware hypervisors. Actually it has many subformats with very different structure and various (in)compatibility with VMware hypervisors.
When I created disk image using `qemu-img create -f vmdk` or converted Qcow2 to VMDK using `qemu-img convert -O vmdk`, vSphere client loaded this image without any problem, but data was corrupted. When Ive created a disk image using `qemu-img create -f vmdk` or converted Qcow2 to VMDK using `qemu-img convert -O vmdk`, vSphere client loaded this image without any problem, but the data was corrupted.
Eventually I found in some old documentation that ESXi does not support “sparse” disks… Eventually I found in some old documentation that ESXi does not support “sparse” disks…
So after many trials I found out that the least bad and functional solution is to create Qcow2 image and then convert it to VMDK using: So after many trials I found out that the least bad and functional solution is to create Qcow2 image and then convert it to VMDK using:
@ -52,7 +52,7 @@ So after many trials I found out that the least bad and functional solution is t
[source, sh] [source, sh]
qemu-img convert -f qcow2 -O vmdk -o adapter_type=lsilogic,subformat=monolithicFlat alpine.qcow2 alpine.vmdk qemu-img convert -f qcow2 -O vmdk -o adapter_type=lsilogic,subformat=monolithicFlat alpine.qcow2 alpine.vmdk
Unfortunately this creates a “thick” image, i.e. its size equals the “provisioned space”, not actually used space as in Qcow2. Unfortunately, this creates a “thick” image, i.e. its size equals the “provisioned space”, not actually used space as in Qcow2.
However, you can compress it with gzip to avoid transferring multiple gigabytes of zeros over network. However, you can compress it with gzip to avoid transferring multiple gigabytes of zeros over network.
Also note that VMware has some problem with hardened kernel, so you have to boot it with `pax_nouderef` (read more https://wiki.alpinelinux.org/wiki/Install_Alpine_on_VMware[here]). Also note that VMware has some problem with hardened kernel, so you have to boot it with `pax_nouderef` (read more https://wiki.alpinelinux.org/wiki/Install_Alpine_on_VMware[here]).