VM disk image for openshift-origin3 finally downloaded. Converted the supplied vmdk disk image to raw as the doco suggested (40Gb). Then converted it to qcow2 (less than 6Gb now) as I didn’t have 40Gb free on my test VM host machine.
The screen shots in the provided documentation to build the VM using virt-manager must be pre-F20. I had slightly different screens, and no way of using NAT as the doco requires as that was not an option; but then all my VM hosts use bridging which may have disables the NAT option ?.
Built the VM based as closely to the install doco as I could, booted it, and into emergency command line prompt, hmm. Ok, changed default of VirtIO disk type when using the gui to be an IDE disk type and rebooted, all started after that.
What I did not like about the doco is it uses virt-manager. My test host has a console but my main one doesn’t so I would have to install from the command line there. And the GUI defaulted to a VirtIO disk for storage (which may have worked for a raw disk image ?, but IDE is needed for qcow2 which at about a fifth the size of the raw image is best for a test installation); and used spice on a randomly assigned port number for the console allowing uncontroled access which nobody is really likely to want. Using the GUI overly complicates the install document.
The install doco could replace pages of examples of the GUI with a simple command line example to create the kvm instance.
The below command would emulate what I ended up with (vnc port and disk serial xx changed to be unique of course) using a static port number with password protection on the console vnc connection.
Of course I use bridging so I am not sure what the equivalent NAT setup would be, but it boots up with a dhcp assigned 192.168.1 address instead of the 10.whatever that would have been assigned using NAT so my kvm installation is fully networked… which may be what openshift is supposed to avoid ?; but works for me.
virt-install --name openshift_origin3 \ --virt-type kvm \ --connect=qemu:///system \ --ram 1024 \ --vcpus=1,maxvcpus=1 \ --description "Openshift Origin3" \ --os-type=linux --os-variant=fedora19 \ --boot hd,menu=off \ --disk=openshift-origin3.qcow2,size=40,format=qcow2,error_policy=enospace,serial=WD-WMAP000000xx,bus=ide \ --graphics vnc,port=59xx,listen=0.0.0.0,password=somepassword \ --noautoconsole \ --noreboot \ --network bridge=br0,mac=52:54:00:95:5f:dd
Console access simply by “remote-viewer vnc://yourhostname:59xx –display :0 &” from any desktop on the same network and enter the password. No need to go near virt-manager or have any GUI components on the host machine to get a console.
Anyway; it was installed; and working which was a good start.
The ‘pre-packaged’ demo services included wordpress. So I selected that. It installed a working wordpress system using configuration information on github; which just worked (using local broker URLs anyway). Not usefull to me in the real world as the local broker URLs obviously cannot be pushed out (although could nat in I suppose)…but I have wordpress running on a prod server anyway.
What does interest me as that as any github repository can be used for configuration information I should be able to create custom instances easily; maybe deploy a mvs38j system :-).
And I still don’t have a positive handle on where things run. I assume everything installed into the VM and runs in there rather than seperate instances of VMs being created under openshift for each application, but I will have to investigate further over the weekend to see what it actually does.
If it is designed to be served as base ‘flavour’/image OS as an initial instance under something like openstack in a build-up/tear-down machine environment I can see how it can be usefull; and I might just spend a few days building a dynamically resizing openstack base disk to play with that; and that will need the qcow2 image as I’m not storing a 40Gb raw image in an object store !.
But for smallish installations that is overkill, so still need to investgate Docker containers at some point anyway.`
