OpenStack4j > Documentation / Compute / Servers

Servers

A server is a running VM instance. The OpenStack4j supports all major server based operations and actions. The examples below will cover all the major scenarios that are commonly utilized to manage running servers within the cloud.

Boot a Server VM (Create)

Booting a new Server is simple with OpenStack4j. The two requirements are specifying a flavor and an image.

// Create a Server Model Object
ServerCreate sc = Builders.server().name("Ubuntu 2").flavor("flavorId").image("imageId").build();

// Boot the Server
Server server = os.compute().servers().boot(sc);

Personalities

When you create a new VM/Server you can also override various files or lay down additional files that will be available when the VM is running. For example you may want to override the /etc/passwd file with a default set of users and passwords. Below takes the example above but overrides the /etc/motd

// Create a Server Model Object
ServerCreate sc = Builders.server()
        .name("Ubuntu 2")
        .flavor("flavorId")
        .image("imageId")
        .addPersonality("/etc/motd", "Welcome to the new VM! Restricted access only")
        .build();

// Boot the Server
Server server = os.compute().servers().boot(sc);

Booting from an existing Volume vs Image

When creating a server you typically boot from an Image to install the operating system. There are other scenarios where you may have a volume that you would like attached to the new server and have the boot process use that volume. See the example below:

BlockDeviceMappingBuilder blockDeviceMappingBuilder = Builders.blockDeviceMapping() 
        .uuid(volumeId)
        .deviceName("/dev/vda")
        .bootIndex(0);

ServerCreate sc = Builders.server().name("Server").blockDevice(blockDeviceMappingBuilder.build());
Server server = os.compute().servers().boot(sc);

Note: The device name unfortunatelly matters, and even worse - it depends on the hypervisor you use. In our experience - for KVM it is /dev/vda, for Xen it is /dev/xvda.

Server Actions

Server actions provide realtime management of a live server.

Simple Actions

Simple Server Actions are a single command giving the Server ID and desired action.

PAUSEPause the server
UNPAUSEUn-Pause the server
STOPStop the server
STARTStart the server
LOCKLock the server
UNLOCKUnlock a locked server
SUSPENDSuspend the server
RESUMEResume a suspended server
RESCUERescue the server
UNRESCUEUn-Rescue the server
SHELVEShelve the server
SHELVE_OFFLOADRemove a shelved instance from the compute node
UNSHELVEUn-Shelve the server
// Suspend a Server
os.compute().servers().action(server.getId(), Action.SUSPEND);

// Resume a Server
os.compute().servers().action(server.getId(), Action.RESUME);

Extended Actions

Reboot a Server

os.compute().servers().reboot(server.getId(), RebootType.SOFT);

Resize a Server

os.compute().servers().resize(server.getId(), newFlavor.getId());

Confirm a Resize

os.compute().servers().confirmResize(server.getId());

Revert a Resize

os.compute().servers().revertResize(server.getId());

Create a new Server Snapshot

A snapshot is merely a pointer to a point in time. This can be handy if you are doing a risky upgrade or migration and need a quick way to revert back. You can take a snapshot and then proceed with your migrations. If the migrations fail you can quickly revert back to created snapshot.

String imageId = os.compute().servers().createSnapshot(server.getId(), "Clean State Snapshot");

Metadata

Creating Metadata during Create

// Can fluently add adhoc items
ServerCreate sc = Builders.server()
        .image("0f4a93c6-a08c-4cf3-9fec-abe968f06892")
        .addMetadataItem("Group", "MyGroup")
        .addMetadataItem("Serial", "232432")
        .name("Test Server")
        .build();

// Or set the actual Map 
ServerCreate sc = Builders.server()
        .image("0f4a93c6-a08c-4cf3-9fec-abe968f06892")
        .addMetadata(someMap)
        .name("Test")
        .build();

Management Examples

// Grabbing just the Metadata
Map<String, String> md = os.compute().servers().getMetadata(serverId);

// Updating or Replace metadata items
Map<String, String> md = os.compute().servers().updateMetadata(serverId, inboundMapofMD);

// Remove a Metadata item
os.compute().servers().deleteMetadataItem(serverId, metadataKey);

VNC and Console Output

OpenStack provides the ability to grab the tail of the console log based on the specified number of lines. See the example below on grabbing the last 50 lines of a running servers console.

Console Output

String consoleOutput = os.compute().servers().getConsoleOutput("serverId", 50);

You can also grab the VNC connection URL based on two VNC types that OpenStack offers, novnc and xvpvnc. See the example below on obtaining the connection information for VNC. The returned class contains the request type and the url used to connect.

VNC Console

VNCConsole console = os.compute().servers().getVNCConsole("serverId", Type.NOVNC);

Diagnostics

Diagnostics are usage information about the server. Usage includes CPU, Memory and IO. Information is dependent on the hypervisor used by the OpenStack installation. As of right now there is no concrete diagnostic specification which is why the information is variable and in map form (key and value)

Map<String, ? extends Number> diagnostics = os.compute().servers().diagnostics("serverId");

Querying for Servers

// List all Servers
List<? extends Server> servers = os.compute().servers().list();

// List all servers (light) ID, Name and Links populated
List<? extends Server> servers = os.compute().servers().list(false);

// Get a specific Server by ID
Server server = os.compute().servers().get("serverId");

Delete a Server

os.compute().servers().delete("serverId");