Oracle Database Appliance: random notes

How to create a shared repository

[root@oda11 ~]# oakcli create repo shared1 -dg data -size 50G

How to import a VM template

You must/can download a template from edelivery.oracle.com
You need to put the template or the assemly inside the DOM0, then import it from ODA_BASE.
[root@oda11 ~]# oakcli import vmtemplate prova -assembly /tmp/OVM_OL7U2_x86_64_PVHVM.ova -repo shared1 -node 0

How to create a VM

[root@oda11 ~]# oakcli clone vm pigna -vmtemplate prova -repo shared1 -node 0

How to create a vdisk

A vdisk that will be attacched to the VM

[root@oda11 ~]# oakcli create vdisk pignadiskl -repo shared1 -size 5G -type local

How to create a cpupool

The same pool name must be configured on each node.

[root@oda12 ~]# oakcli create cpupool provapool -numcpu 2 -node 1

[root@oda12 ~]# oakcli create cpupool provapool -numcpu 2 -node 0

How to configure the VM

Add two network interfaces

[root@oda11 ~]# oakcli configure vm pigna -network "['type=netfront,bridge=net1','type=netfront,bridge=net2']"

Enable failover

[root@oda11 ~]# oakcli configure vm pigna -failover true

Attach an additional disk

[root@oda11 ~]# oakcli modify vm pigna -attachvdisk pignadiskl

Configuring cpupool

[root@oda11 ~]# oakcli configure vm pigna -cpupool provapool

Starting the VM

[root@oda11 ~]# oakcli start vm pigna

Attacching to the console

You must ssh to the ODA_BASE using -Y flag.
[root@oda11 ~]# oakcli show vmconsole pigna
A VNC session will start

Expanding the disk space from inside the VM

This is the vdisk created before.

[root@pigna ~]# btrfs device add /dev/xvdb /

You can attach additional vdisks, and the VM OS will see them without the need to reboot it.

Adding space to the repo

[root@oda11 ~]# oakcli configure repo shared1 -incsize 25G

SmartOS: move (migrate) a VM to another Global Zone

To move a running virtual machine, either a zone or a KVM, from an hypervisor (Global Zone) to another, I usually follow these steps in an handicraft way.

In order to minimize downtime, there are 2 steps.
The first snapshot and transfer of the ZFS filesystem will be done without halting the VM.
In the second step we will shutdown the VM, take another snapshot, then we will send it using an incremental transfer, that is very fast.

First of all you need the UUID of the VM you want to move from a global zone to another GZ.

[root@gz1 /]#vmadm list
UUID                                  TYPE  RAM      STATE             ALIAS
561b686e-3119-4ab0-932e-20fc944fb001  KVM   512      running           vm1
e44f3c76-4acb-11e3-a536-a7cfa8b66838  OS    512      running           vm2
b803b5b9-bc86-4d0f-b450-16862e7bd7ed  OS    2048     running           vm3


Now we need the list of all the ZFS filesystem related to that VM.

[root@gz1 ~]# zfs list -o name | grep 561b686e-3119-4ab0-932e-20fc944fb001

zones/561b686e-3119-4ab0-932e-20fc944fb001
zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0
zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1
zones/cores/561b686e-3119-4ab0-932e-20fc944fb001

Now we must create a snapshot of every ZFS.
Note: at this time the VM doesn't need to be stopped, you can leave it up and running, just to minimize downtime.

[root@gz1 ~]# zfs snapshot zones/561b686e-3119-4ab0-932e-20fc944fb001@tosend
[root@gz1 ~]# zfs snapshot zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0@tosend
[root@gz1 ~]# zfs snapshot zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1@tosend
[root@gz1 ~]# zfs snapshot zones/cores/561b686e-3119-4ab0-932e-20fc944fb001@tosend

Now it is time to send these snapshots to the destination. It may require a lot of time.

[root@gz1 ~]# zfs send zones/561b686e-3119-4ab0-932e-20fc944fb001@tosend | ssh gz2.domain zfs receive -v zones/561b686e-3119-4ab0-932e-20fc944fb001[root@gz1 ~]# zfs send zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0@tosend | ssh gz2.domain zfs receive -v zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0[root@gz1 ~]# zfs send zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1@tosend | ssh gz2.domain zfs receive -v zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1
[root@gz1 ~]# zfs send zones/cores/561b686e-3119-4ab0-932e-20fc944fb001@tosend | ssh gz2.domain zfs receive -v zones/cores/561b686e-3119-4ab0-932e-20fc944fb001

After that, we have to stop the virtual machine.

[root@gz1 ~]# vmadm stop 561b686e-3119-4ab0-932e-20fc944fb001

And get additional snapshots of the ZFS filesystems, like before, giving them a different name. Now, these snapshots are potentially in a consistent state, since the operating system inside the virtual machine is not running.

[root@gz1 ~]# zfs snapshot zones/cores/561b686e-3119-4ab0-932e-20fc944fb001@tosend-last 
[root@gz1 ~]# zfs snapshot zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1@tosend-last 
[root@gz1 ~]# zfs snapshot zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0@tosend-last 
[root@gz1 ~]# zfs snapshot zones/561b686e-3119-4ab0-932e-20fc944fb001@tosend-last


Finally, we have to send these ZFS snapshots using incremental send. It will take a little bit of time.

[root@gz1 ~]# zfs send -i zones/561b686e-3119-4ab0-932e-20fc944fb001@tosend zones/561b686e-3119-4ab0-932e-20fc944fb001@tosend-last | ssh gz2.domain zfs receive -Fv zones/561b686e-3119-4ab0-932e-20fc944fb001
[root@gz1 ~]# zfs send -i zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0@tosend zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0@tosend-last | ssh gz2.domain zfs receive -Fv zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0
[root@gz1 ~]# zfs send -i zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1@tosend zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1@tosend-last | ssh gz2.domain zfs receive -Fv zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1

[root@gz1 ~]# zfs send -i zones/cores/561b686e-3119-4ab0-932e-20fc944fb001@tosend zones/cores/561b686e-3119-4ab0-932e-20fc944fb001@tosend-last | ssh gz2.domain zfs receive -v zones/cores/561b686e-3119-4ab0-932e-20fc944fb001

Some last operations.
Grab the line related to the VM from inside the /etc/zones/index in the source global zone, and paste it at the end of same file in the destination global zone.

[root@gz1 ~]# cat /etc/zones/index | grep 561b686e-3119-4ab0-932e-20fc944fb001


[root@gz2 ~]# echo "561b686e-3119-4ab0-932e-20fc944fb001:installed:/zones/561b686e-3119-4ab0-932e-20fc944fb001:561b686e-3119-4ab0-932e-20fc944fb001" >> /etc/zones/index

Finally, copy the xml configuration file from the source global zone, to the destination one.


[root@gz1 ~]#scp /etc/zones/561b686e-3119-4ab0-932e-20fc944fb001.xml gz2.domain:/etc/zones/561b686e-3119-4ab0-932e-20fc944fb001.xml 

At this point, you can boot the VM on the destination global zone, check if all is working as expected, then delete the old VM from the source global zone.

smartos: add additional disk from a different zpool

I have 2 zpools

  pool: zones
  pool: zpool_repos


I want to add to a KVM machine a disk living not in the zones pool, but in the other one.

My VM is already provisioned.
First of all I must stop it.

vmadm stop <uuid>

Now I create a ZFS volume

zfs create -V 10G zpool_repos/mykvmdata

Now I create a json file for the update

vi adddisk.json

{
   "add_disks": [
      {
          "media": "disk",
          "model": "virtio",
          "nocreate": "true",
          "boot": false,
          "path": "/dev/zvol/rdsk/zpool_repos/uuu"
      }
   ]
}

Now I update the KVM machine.

vmadm update 5942c90f-ecbb-4acd-822f-43e1901e2eb6 -f dataset.json

That's all.
Now, after starting the virtual machine, from inside it, I must partition the new disk (i.e. /dev/vdb in linux) and format.

smartos update_disks

I want to change the disk model in a KVM machine on SmartOS.

vi upddisk.json

  {
   "update_disks": [
    {
     "path": "/dev/zvol/rdsk/zones/e888a82a-bca1-49fda6d7-988debb09703-disk0",
     "model": "ide"
    }
   ]
  }

vmadm update e888a82a-bca1-49fd-a6d7-988debb09703 -f upddisk.json

vmadm get  e888a82a-bca1-49fd-a6d7-988debb09703

openindiana, virtualbox and bridged network

openindiana, virtualbox and bridged network

As far I can see, there are problems assigning the physical guest interface (i.e. igb0) to the bridged virtualbox VM network interface.

 

To avoid problems (i.e. the virtual machine hangs), you must first create a vnic

dladm create-vnic -l igb0 vnic0

... but ... it is not sufficient: you must assign the MAC address of the vnic to the bridged network interface of the VM

dladm show-vnic
LINK         OVER    SPEED  MACADDRESS        MACADDRTYPE    VID
vnic0        igb0    1000   2:8:20:68:25:9b   random    0

If you don't assign the vnic MAC address to the VM network adapter, simply the VM networking doesn't work.

centos kvm console

To enable console access from the host command line to a CentOS guest, this was an useful link