| To use an hypervisor, some configuration needs to be added to the domain.xml. This configuration is basically falling into 3 steps, one is configuring the access to the hypervisor (libvirt, ovm), two is adding the server pool configuration, and finally optionally adding the server machines within the defined server pools. KVM (libvirt) To access KVM enabled machine, you need to configure the IMS to use the libvirt libraries. First step is defining the emulator used on the target machine. Depending on the hypervisor used on the target machine (KVM, Xen), the emulator definition is slightly different. Emulator Emulators are used to run virtual machine, there are different types of emulators supported so far, kvm for the hardware accelerated virtual machines, and qemu for the software emulated virtual machines (slower). Emulators will also define how we will connect to the remote machine by replacing the connection-string keys with configured values for that particular machine :
| key |
value |
| #{auth.sep} |
separator for the authentication method (if any) |
| #{auth.method} |
authentication method on the remote machine |
| #{user.name} |
user name configured for the machine access |
| #{target.host} |
host identification |
By default the libvirt plugin will configure kvm with accelerated hardware. connection string = qemu#
Unknown macro: {auth.sep}
#
Unknown macro: {auth.method}
://#
Unknown macro: {user.name}
@#
Unknown macro: {target.host}
/system
emulator path = /usr/bin/kvm
Default hypervisor configuration
You also need to add some default hypervisor configuration, with the right default emulator (can be overriden at the machine level when issuing a create-machine command), the above default connection string and emulator path will be used.
asadmin add-libirt-virtualization --emulator kvm
if you are not planning the default connection string and default emulator path :
asadmin add-libirt-virtualization --emulatorpath /usr/bin/kvm --connectionstring qemu#
#
Unknown macro: {auth.method}
://#
Unknown macro: {user.name}
@#
Unknown macro: {target.host}
/system kvm
asadmin add-libvirt-virtualization --emulatorpath /usr/bin/qemu-system-x86_64 --connectionstring qemu#
Unknown macro: {auth.sep}
#
://#
Unknown macro: {user.name}
@#
Unknown macro: {target.host}
/system qemu
asadmin add-libvirt-virtualization --emulatorpath /usr/lib64/xen/bin/qemu-dm --connectionstring xen#
Unknown macro: {auth.sep}
#
Unknown macro: {auth.method}
://#
@#
Unknown macro: {target.host}
xen
h3. Server Pools and machines
Machines are organized in server pools, each server pool is administered by a pool master. The pool master maintains the list of attached machines using either the IP address (if machines have static IPs) or the MAC address. To find out a machine mac address, do
{{ifconfig \-a}}
So far, IMS only support the server pool definition in the DAS. This does not mean that the DAS must be the server pool master (administering the target machines itself), as the server pool implementation can be a proxy to a separate entity managing machines and allocating virtual machines (ovm for instance).
h4. Add a server pool
A server pool is a set of machines that can be referenced and targeted together. You need to create a server pool first and then optionally add remote machines (and/or the local machine) to it. If you do not add machines to a server pool, that means the server pool implementation is able to allocate virtual machines without the notion of physical machines attached to it, it's basically a VM allocation service itself.
asadmin create-server-pool --virtualization kvm --subnet 10.132.181.0/24 --portName "cscotun0;br0" cloud on a mac, it becomes :
asadmin create-server-pool --virtualization kvm --subnet 10.132.181.0/24 --portName "utun0;en0" cloud
the subnet is the group-master subnet that will be use to find the group's machine current IP address. This subnet will be used to do a multicast ping and retrieve a machine current IP address from it's mac address.
The portName are the port the group master will use in sequence to communicate. Here I have 2 ports, one is the VPN port (if enabled), the other is the bridged wired connection (br0).
h4. Adding machines to the server pool master
h5. local machine
To add the local machine to a group so virtual machines can be started on the same machines that runs the DAS, do :
asadmin create-machine --serverPool <poolName> --networkName localhost local
h5. remote machine
If you are using a DHCP machine, you need to add the machine to the group master using the mac address. Also, the
group master must reside in the same subnet as the machine.
asadmin create-machine --serverPool <poolName> --mac <mac address of your machine> name
to obtain your machine mac address on linux, use ifconfig \-a
for example :
asadmin create-machine \--serverPool cloud \--mac 00:1c:c4:9f:e9:3b cloud-1
Bug warning : after adding machine(s) to the group master/DAS, restart the server.
If you have a fixed IP address or it's not on the same subnet as the pool controller, you should add the IP to the create-machine command like :
asadmin create-machine --serverPool cloud --networkName office --ip 10.132.181.57 office
h4. User
A user must be associated with the pool which mean that glassfish will use this user's account to talk to the remote machines part of that group. To add a user for the newly created group :
asadmin create-server-pool-user --serverPool <groupName> --userId <unix-user-id> --groupId <unix-group-id> unix_user_name
asadmin create-server-pool-user --serverPool cloud --userId 1001 --groupId 1001 cloud
A machine can override the group user setting by creating a user specific to that machine.
asamin create-machine-user --serverPool <groupName> --machine <machineName> --userId <unix-user-id> --groupId <unix-group-id> unix_user_name
|
