xVM Hypervisor
xVM hypervisor, the Oracle Solaris Xen-based hypervisor for x86 systems, has been removed. Oracle offers two x86-based hypervisor solutions for Oracle Solaris users: Oracle VM Server for x86 and Oracle VM VirtualBox. See http://www.oracle.com/virtualization

Schade


xm vcpu-set Domain-0 1 # Nur eine vCPU für die Dom0
xm vcpu-pin Domain-0 0 0 # Diese eine vCPU soll nur auf Core 0 laufen
xm vcpu-pin VM all 1-3 # Die vCPU(s) der VM sollen nur Cords 1-3 nutzen


Erfreulicherweise bekommt die libvirt dies auch gleich mit und fügt ein <vcpu cpuset='1-3'>1</vcpu> in die XML Config mit ein.

Damit die Dom0 nach einem Reboot mit einer vCPU und nur auf Core 0 läuft müssen dem Hypervisor die Optionen dom0_vcpus_pin=true dom0_max_vcpus=1 mitgegeben werden.

Wer übrigens sein OpenSolaris auf eines der letzten Releases von Oracle aktualisieren möchte, kann hierzu ein Repository von Illumos nutzen und somit nochmal auf svn_145 aktualisieren. Leider ist hier aber der xVM Support kaputt. Der xend stürzt beim Starten mit einer python Fehlermeldung ab. Wer es dennoch probieren möchte, hier der Link:
http://www.illumos.org/projects/illumos-gate/wiki/How_To_Build_Illumos

Fazit: OpenSolaris ist tot! Aber noch nicht ganz und hoffentlich gibt es eine Wiedergeburt mit Illumos

http://www.c0t0d0s0.org/archives/6515-Interesting-way-to-create,-rename-and-delete-snapshots-with-ZFS.html

set zfs:zfs_arc_max = 0x10000000

hinzufügen.

Wenn eine VM abstürzt wird ein Dump unter /var/xen/dump geschrieben. Da hierdurch ggf. das root Filesystem vollgeschrieben werden kann, sollte man dieses Verzeichnis in ein eigenes Dateisystem legen:

zfs create -o mountpoint=/var/xen/dump,quota=2G rpool/xendumps

Die CPU und RAM Ressourcen der Dom0 möchte man ggf. ebenfalls beschränken. Hierzu übergibt man geeignete Parameter an den Hypervisor, indem man in /rpool/boot/grub/menu.lst den Aufruf des Xen Hypervisors z.B. wie folgt anpasst:

kernel$ /boot/$ISADIR/xen.gz console=com1 com1=auto dom0_mem=1024M dom0_max_vcpus=1

Weiterhin sollte man noch folgende Option setzen und den xend neu starten:

svccfg -s svc:/system/xvm/xend setprop config/dom0-min-mem = 2334
svcadm refresh svc:/system/xvm/xend:default
svcadm restart svc:/system/xvm/xend:default

Schlussendlich sollte man noch den gdm deaktivieren:

svcadm disable gdm

Quelle: http://hub.opensolaris.org/bin/view/Community+Group+xen/configuring-dom0

Jetzt kann man sich einen ZFS Poo erstellen, wenn gewünscht, (zpool create xvmpool raidz2 c7t0d0 c7t1d0 c7t2d0 c7t3d0 c7t4d0) und darin Volumes für die VMs einrichten (zfs create -V 10G xvmpool/domain). Diese stehen dann unter /dev/zvol/dsk/xvmpool/domain zur Verfügung. VMs lassen sich jetzt z.B. per virt-manager oder virt-install installieren. Hierbei ist das jeweilige zvol als file anzugeben. Falls man bereits vorhandene (Xen) VMs hat, kann man diese z.B. per cat domainimage > /dev/zvol/rdsk/xvmpool/domain importieren. Auch das ggf. vorhandene Xen Configfile lässt sich per xm create domainconfig importieren. Da allerdings einige Anpassungen notwendig sind und man xVM lieber über virsh steuern möchte, empfiehlt es sich gleich das XML Format von virsh zu nutzen. Ich poste hier mal eine Config für ein paravirtualisiertes Ubuntu, welches als Vorlage genutzt werden kann:

<domain type='xen'>
<name>ubuntu</name>
<bootloader>/usr/lib/xen/bin/pygrub</bootloader>
<os>
<type>linux</type>
</os>
<memory>262144</memory>
<vcpu>1</vcpu>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<clock offset='utc'/>
<devices>
<interface type='bridge'>
<source bridge='rge0'/>
<script path='vif-vnic'/>
</interface>
<disk type='block' device='disk'>
<driver name='phy'/>
<source dev='/dev/zvol/dsk/xvmpool/ubuntu'/>
<target dev='hda'/>
</disk>
<console tty='/dev/pts/7'/>
</devices>
</domain>

Das ganze als z.B. ubuntu.xml speichern, via virsh define ubuntu.xml importieren, mit virsh start ubuntu starten und über virt-console ubuntu beim booten zuschauen.
Neue VMs habe ich einfach voll virtualisiert installiert und dann innerhalb der VM einen Xen Kernel installiert. Bei ubuntu muss man aufpassen, dass ein update-grub in der Vollvirtualisierung keinen Grub Eintrag für den Xen Kernel erzeugt. Diesen muss man händisch zur /boot/grub/menu.lst hinzufügen und als default Kernel einrichten. Anschließend kann man die Config per virsh dumpxml domain > domain.xml exportieren, anhand obiger Beispielconfig anpassen und per virsh define domain.xml wieder importieren.

/bin/pkg -R install \
SUNWrge \
SUNWsshd \
SUNWssh \
SUNWsshcu \
SUNWvim \
SUNWahc

nach installieren. Nun noch ein reboot und schon kann man sich in seinem Minimal-OpenSolaris einloggen. Die Netzwerkkonfiguration muss nun noch manuell erledigt werden. Ich empfehle erst mal SSH an den Start zu bekommen und dann den Rest remote zu machen. Erst mal braucht es eine IP: ifconfig rge0 plumb 192.168.1.2/24 up. In meinem Fall fehlten noch die SSH-Keys für den Host. Diese habe ich per

ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N "" -C ""
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N "" -C ""

nachinstalliert. Danach svcadm enable ssh und einloggen per ssh sollte möglich sein. Jetzt muss man noch die Netzwerkkonfiguration nach der alten Methode gemacht werden. Ich gehe hier nicht weiter darauf ein. Nur ein paar Files die angepasst werden müssen gebe ich hier an:

florian@ackbar:~# rmformat -l
Looking for devices…
1. Logical Node: /dev/rdsk/c10t0d0p0
Physical Node: /pci@0,0/pci1458,5004@12,2/storage@4/disk@0,0
Connected Device: Lexar JD FireFly 1100
Device Type: Removable
Bus: USB
Size: 7,6 GB
Label:
Access permissions: Medium is not write protected.
2. Logical Node: /dev/rdsk/c9t0d0p0
Physical Node: /pci@0,0/pci1458,5004@12,2/storage@3/disk@0,0
Connected Device: Lexar JD FireFly 1100
Device Type: Removable
Bus: USB
Size: 7,6 GB
Label:
Access permissions: Medium is not write protected.

Die beiden Sticks nennen sich also c9t0d0p0 und c10t0d0p0.

florian@ackbar:~# zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c9t0d0s0 ONLINE 0 0 0

errors: No known data errors

c9t0d0s0 ist also der bereits verwendete Stick. Ich erstelle eine große Solaris Partition auf dem zweiten Stick.

florian@ackbar:~# fdisk -B /dev/rdsk/c10t0d0p0

Nun muss das Label vom ersten auf den zweiten Stick kopiert werden.

florian@ackbar:~# prtvtoc /dev/rdsk/c9t0d0s2 | fmthard -s – /dev/rdsk/c10t0d0s2
fmthard: New volume table of contents now in place.

Jetzt würde ich den zweiten Stick zum zpool rpool hinzufügen:

florian@ackbar:~# zpool attach -f rpool c9t0d0s0 c10t0d0s0
cannot attach c10t0d0s0 to c9t0d0s0: new device must be a single disk
florian@ackbar:~#

Leider funktioniert das nicht. Scheint irgendein Bug zu sein. Siehe auch:
https://opensolaris.org/jive/thread.jspa?messageID=360872

Also boote ich die OpenSolaris Live CD (Console reicht) (User: jack/jack; root/opensolaris) und probiere es da:

jack~# zpool import -f rpool
jack~# zpool attach -f rpool c8t0d0s0 c9t0d0s0

-> geht

Nun muss noch grub auf dem zweiten Stick installiert werden, das funktioniert nun wieder aus der normalen Installation heraus:

florian@ackbar:~# installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c9t0d0s0
Updating master boot sector destroys existing boot managers (if any).
continue (y/n)?y
stage1 written to partition 0 sector 0 (abs 4096)
stage2 written to partition 0, 271 sectors starting at 50 (abs 4146)
stage1 written to master boot sector
florian@ackbar:~#

Nun noch warten, biss der Mirror aufgebaut ist (resilver) und fertig.

Möglicherweise funktioniert ein reboot nun erst mal nicht. Hintergrund: OpenSolaris klont die aktuelle Boot Umgebung per Snapshot und installiert die Patches nur in diesem Klon. Dadurch kann man bei Problemen immer wieder in den alten Zustand vor der Aktualisierung zurückkehren. Der Klon verbraucht auch nur Speicherplatz für die Änderungen gegenüber der alten Version. Im Grub gibt es einen neuen Eintrag, welcher standardmäßig ausgewählt wird. Falls sich dieser nicht booten läßt sollte man den Eintrag händisch auswählen, der vor dem patchen gebootet wurde. Dann hilft es sich mit beadm list alle Boot Umgebungen anzuzeigen und die neu erstelle mit beadm mount /mnt in das System einzubinden. Anschließend braucht es noch /mnt/boot/solaris/bin/update_grub -R /mnt um grub auf der neuen Umgebung zu installieren. Funktioniert die neue Boot Umgebung problemlos, kann man die alte(n) mit beadm destroy wieder löschen.