Showing headlines posted by dba477

Recent pulling GRUB2 supporting CSs into xen-3.4-testing.hg immediately makes sense to build xen 3.4.3-2.fc12.src.rpm to be able to set up current version of 3.4.3 Xen Hypervisor on Fedora 12 working pretty smoothly with Libvirt packages ( vs Xen 4.0) and the at same time supporting GRUB2 PV DomUs , say Ubuntu 9.10 Server or Debian Squeeze.

Due to set of CSs for GRUB 2 Support written by Ian Campbell usual sharing image devices between Ubuntu Karmic Koala Server HVM and PV Guests appears available at Xen-4.0 Linux Dom0. Fedora 12 has been selected due to presence of Libvirt 0.7.1 providing virt-install and virt-manager utilities.

This posting is actually responding recent entry in Martin's Blog OpenSolaris 2009.06 domU on opensuse 11.2 dom0 Martin states:- Then I tried out a number of current linux distributions, but except for openSuSE none had a dom0 kernel out of the box which really is a shame. Seems I need to look more closely into KVM with virtio support. Via article bellow i try to explain that due to efforts of Jan Beulich and Andy Lyon xenified aka Suse Kernel 2.6.31.8(9) may be built on any Linux and along with the most recent stable Xen Hypervisor (3.4.2 and higher) port provide Xen Environment supporting OpenSolaris PV Guests , including the most recent unstable builds like 129,130,131 ( i mean vncserver behavior on OSOL PV DomU and GDM/VNC setup ).

Recent “zypper update” on November’s openSUSE 11.2 release brought system to the most recent status. Current 2.6.31.8-xen kernel works fine. Seems like a next generation of xenified aka Suse kernels is on the go right now. However, i believe,that vm-install on recently updated 11.2 works same way as before maintenance update. So, in meantime vm-install doesn’t inderstand either HTTP or CDROM sources attempting to create PV Guest and virsh scripting appears to be the only one option to create Xen PV Guests manageable via virt-manager. Notice, that F12 PV Guest install doesn’t require HTTP or NFS share , pygrub performs install just via F12 ISO image , like OpenSolaris PV Guests get installed as usual.

Install Libvirt 0.7.0 along with KVM creates environment with default Hypervisor QEMU . Two steps in procedure bellow makes Xen default Hypervisor on Ubuntu 9.10 .

Setup bellow might seem strange unless you will become aware of some ongoing issues with VNC-Console behavior during virt-install running on the most recent OSOL build 130. View recent threads at xen-discuss forum@opensolaris.org

Following bellow is step by step instruction how to clone Sun's xvm 3.4.2 repository and build packages , required to setup xVM 3.4.2 Dom0 on top of OpenSolaris 1002-128a. View also manuals at opensolaris.org How to Build the Development gates

Set up Sun xVM 3.4.2 on top of opensolaris 1002-128a via binary packages been built by Pascal Gienger at Index of /software/xvm/3.4.2. Been performing testing bellow my major concern was ability Sun xVM 3.4.2 to handle PV DomUs with boot file systems of ext4fs type. Actually, two guests have been tested : F12 and Ubuntu Karmic Server, in both cases boot partition has been converted to ext3fs to create DomUs manageable via virsh ( virt-manager).

Blog entry "OpenSolaris 2008.11 guest domain on a Linux dom0" was written by John Levon and supposed to help community users to install OSOL 2008-11 DomU at Xen 3.1 Dom0 on top of Fedora 8. It’s core technique utilizes virsh , so is supposed to be applicable to current release of Libvirt as well. However , /usr/bin/xenstore-read fails to obtain IP address for OSOL DomU via XenStore at Xen 3.4.2 Dom0. Posting bellow fixes this issue and provide an option to build via virsh the most recent OSOL PV DomU at Xen 3.4.2 Dom0 & Libvirt 0.7.1-15 on Fedora 12.

We presume , that xen-3.4.1-5.fc12.src.rpm has been already installed on the system and Xen Host been built via mentioned “rpm” , Libvirt 0.7.1-15 and 2.6.31.6 pvops kernel is up and running at the time of upgrade. Apply following patch to /root/rpmbuild/SPECS/xen.spec

A brief description of Xen 3.4.1 and Libvirt 0.7.1-15 deployment to Fedora 12 follows bellow. Next step is install Ubuntu Karmic Koala Server in HVM DomU with ext4fs image via virt-install. Ubuntu Karmic PV DomU gets loaded via pygrub profile due to Xen Hypervisor has been built on F12 along with e2fsprogs-devel package, what allows to handle PV DomUs images (F12,Ubuntu 9.10) having ext4fs on boot partition.

Setup xvm per Sun the most recent instructions. As appears latter Virt-Manager is broken in 126 ( vs 124), but this is not the worst thing supposed to happen. Virt-install rejects to install Fedora12 PV DomU which is not yet in the dictionary in meantime. XML startup file for f12 allows to avoid this restriction mostly connected i believe with xVM version unable to handle ext4 FS for boot partition of Linux DomU

This application will use Java Server Faces 2.0 for displaying the results, Enterprise Java Beans 3.1 + Java Persistence API 2.0 for middle tier, and Oracle database server + GlassFish v3 as the backend. The most recent development bundle NetBeans 6.8 & GlassFish V3 build 68 would be good work for testing Download NetBeans IDE Build 200910170201

Posting bellow provides a workaround for failure of straight forward virt-install Debian Lenny 64-bit DomU via location http://ftp.us.debian.org/debian/dists/lenny/main/installer-a... . It doesn’t require debootstrap involvement and would work on OpenSolaris 2010-02-124 and Solaris Nevada 124 as well. Download mini installer iso image and virt-install Lenny HVM DomU

The most recent features of Jeremy Fitzhardinge kernel have been enabled and tested at Xen 3.5 Dom0 on top of Ubuntu Karmic Koala (Beta) Server. Xen host been built reboots directly into Gnome Desktop environment on the box with Core2Quad CPU, 8 GB RAM, Radeon HD 4X50 Video Card. Tuning kernel 2.6.31.1 described in details bellow with snapshots of every configuration step been taken. Deployment Xen Unstable to Ubuntu Karmic Server environment was done in same way as in [1] and is also briefly documented. Xen 3.5 Dom0 with 2.6.31.1 pvops kernel has been verified via F12 (rawhide) PV DomU install.

Brief description of Xen 3.4.1 and Libvirt 0.7.0-6 deployment to Fedora 12 Alpha (rawhide) follows bellow. F12 instance was created on the second drive. All my attempts to resize default LVM created by intaller caused installer to crash.

Due to GRUB2 doesn’t allow module entries to accept parameters via command line in meantime , creating corresponding Xen grub2 entries for xenified aka Suse kernels went a bit different from the same procedures on Jaunty and Intrepid Servers.

This post follows up Mark McLoughlin's ANNOUNCE: Rawhide virt repo for F11 users:- Another update available in http://markmc.fedorapeople.org/virt-preview It's targeting install the most recent version of Fedora's libvirt on F11 and testing virt-manager and virt-install to work properly with Xen 3.4.1 Hypervisor been installed on F11 via xen 3.4.1-1 src.rpm downloaded from http://kojipkgs.fedoraproject.org/packages/xen/3.4.1/1.fc12/ PVOPS kernel 2.6.31-rc6 has been installed via Jeremy Fitzhardinge Git Repository to support Xen 3.4.1 Dom0.

PVOPS kernel been installed to run under Xen 3.4.1 was 2.6.31-rc5. To build Xen 3.4.1 Dom0 via Bug Attachments at Please merge xen-3.4 (3.4.0-2) from debian unstable installed "prevu" and performed build to obtain debian packages.

Regardless bug with failure checksum offloading was fixed in SNV_81 , i.e. a while ago. OpenSolaris 2009.06 PV DomU install at Xen 3.4.1 Linux Dom0 appears still to be affected. Wrong checksum may be easily captured via tcpdump on the LAN due to DHCPDISCOVER request issued by OSOL installer is a broadcast request. Following bellow procedure involves Solaris Kernel module debugger to patch OSOL’s (SNV_111b) kernel at booting up to succeed with dhcp lease and to be able proceed with initial install. File /etc/system gets updated via root terminal session before standard reboot to make the patch for kernel permanent. Posting is devoted first of all to Linux users , who are not aware of “kmdb” syntax and involving into boot process.