Revision ffc64d7c docs/usage.rst
| b/docs/usage.rst | ||
|---|---|---|
| 28 | 28 |
-f, --force overwrite output files if they exist |
| 29 | 29 |
-s, --silent output only errors |
| 30 | 30 |
-u FILENAME, --upload=FILENAME |
| 31 |
upload the image to pithos with name FILENAME
|
|
| 31 |
upload the image to the storage service with name FILENAME
|
|
| 32 | 32 |
-r IMAGENAME, --register=IMAGENAME |
| 33 |
register the image with ~okeanos as IMAGENAME
|
|
| 33 |
register the image with the compute service as IMAGENAME
|
|
| 34 | 34 |
-m KEY=VALUE, --metadata=KEY=VALUE |
| 35 | 35 |
add custom KEY=VALUE metadata to the image |
| 36 | 36 |
-t TOKEN, --token=TOKEN |
| ... | ... | |
| 51 | 51 |
media |
| 52 | 52 |
--no-sysprep don't perform any system preparation operation |
| 53 | 53 |
--no-shrink don't shrink any partition |
| 54 |
--public register image with cyclades as public
|
|
| 54 |
--public register image with the compute service as public
|
|
| 55 | 55 |
--tmpdir=DIR create large temporary image files under DIR |
| 56 | 56 |
|
| 57 | 57 |
Most input options are self-describing. If you want to save a local copy of |
| 58 | 58 |
the image you create, provide a filename using the *-o* option. To upload the |
| 59 |
image to *pithos+*, provide valid cloud API access info (by either using a |
|
| 60 |
token with *-t* and a URL with *-a* pair or a cloud name with *-c*) and a |
|
| 61 |
filename using *-u*. If you also want to register the image with *~okeanos*, in |
|
| 62 |
addition to *-u* provide a registration name using *-r*. All images are |
|
| 59 |
image to the storage service of a cloud, provide valid cloud API access info |
|
| 60 |
(by either using a token and a URL with *-t* and *-a* respectively, or a cloud |
|
| 61 |
name with *-c*) and a remote filename using *-u*. If you also want to register |
|
| 62 |
the image with the compute service of the cloud, in addition to *-u* provide a |
|
| 63 |
registration name using *-r*. All images are |
|
| 63 | 64 |
registered as *private*. Only the user that registers the image can create |
| 64 | 65 |
VM's out of it. If you want the image to be visible by other user too, use the |
| 65 | 66 |
*--public* option. |
| ... | ... | |
| 187 | 188 |
(ex. "Slackware Linux 14.0 with KDE") |
| 188 | 189 |
* Registration Type: Private or Public |
| 189 | 190 |
|
| 190 |
After confirming, the image will be extracted, uploaded to *pithos+* and
|
|
| 191 |
registered with *~okeanos*. The user will also be given the choice to keep a
|
|
| 192 |
local copy of it. |
|
| 191 |
After confirming, the image will be extracted, uploaded to the storage service
|
|
| 192 |
and registered with the compute service of the selected cloud. The user will
|
|
| 193 |
also be given the choice to keep a local copy of it.
|
|
| 193 | 194 |
|
| 194 | 195 |
For most users the functionality this mode provides should be sufficient. |
| 195 | 196 |
|
| ... | ... | |
| 211 | 212 |
In the *Register* sub-menu the user can provide: |
| 212 | 213 |
|
| 213 | 214 |
* Which cloud account to use |
| 214 |
* A *pithos+* filename for the uploaded *diskdump* image
|
|
| 215 |
* A name for the image to use when registering it with *~cyclades*, as well as
|
|
| 216 |
the registration type (*private* or *public*) |
|
| 215 |
* A filename for the uploaded *diskdump* image |
|
| 216 |
* A name for the image to use when registering it with the storage service of
|
|
| 217 |
the cloud, as well as the registration type (*private* or *public*)
|
|
| 217 | 218 |
|
| 218 | 219 |
By choosing the *Extract* menu entry, the user can dump the image to the local |
| 219 | 220 |
file system. Finally, if the user selects *Reset*, the system will ignore |
| ... | ... | |
| 283 | 284 |
|
| 284 | 285 |
.. image:: /snapshots/wizard.png |
| 285 | 286 |
|
| 286 |
Then you will be asked to provide a name, a description, a registration type
|
|
| 287 |
(*private* or *public*) and the authentication token corresponding to your
|
|
| 288 |
*~okeanos* account. Finally, you'll be asked to confirm the provided data.
|
|
| 287 |
Then you will be asked to select a cloud and provide a name, a description and
|
|
| 288 |
a registration type (*private* or *public*). Finally, you'll be asked to
|
|
| 289 |
confirm the provided data. |
|
| 289 | 290 |
|
| 290 | 291 |
.. image:: /snapshots/confirm.png |
| 291 | 292 |
|
| 292 |
Choosing *YES* will create and upload the image to your *~okeanos* account.
|
|
| 293 |
Choosing *YES* will create and upload the image to your cloud account.
|
|
| 293 | 294 |
|
| 294 | 295 |
Limitations |
| 295 | 296 |
=========== |
| ... | ... | |
| 311 | 312 |
Para-virtualized drivers |
| 312 | 313 |
------------------------ |
| 313 | 314 |
|
| 314 |
*~Okeanos* uses the *VirtIO* framework. The disk I/O controller and the
|
|
| 315 |
Ethernet cards on the VM instances are para-virtualized and need special
|
|
| 316 |
*VirtIO* drivers. Those drivers are included in the Linux Kernel mainline since
|
|
| 317 |
version 2.6.25 and are shipped with all the popular Linux distributions. The
|
|
| 318 |
problem is that if the driver for the para-virtualized disk I/O controller is
|
|
| 319 |
built as module, it needs to be preloaded using an initial ramdisk, otherwise
|
|
| 320 |
the VM won't be able to boot. |
|
| 315 |
Most synnefo deployments uses the *VirtIO* framework. The disk I/O controller
|
|
| 316 |
and the Ethernet cards on the VM instances are para-virtualized and need
|
|
| 317 |
special *VirtIO* drivers. Those drivers are included in the Linux Kernel
|
|
| 318 |
mainline since version 2.6.25 and are shipped with all the popular Linux
|
|
| 319 |
distributions. The problem is that if the driver for the para-virtualized disk
|
|
| 320 |
I/O controller is built as module, it needs to be preloaded using an initial
|
|
| 321 |
ramdisk, otherwise the VM won't be able to boot.
|
|
| 321 | 322 |
|
| 322 | 323 |
Many popular Linux distributions, like Ubuntu and Debian, will automatically |
| 323 | 324 |
create a generic initial ramdisk file that contains many different modules, |
Also available in: Unified diff