High Availablility

Hi,

I was wondering if there is software out there for Xen which will handle 
high availability for a cluster of servers. By high availability here I 
mean if one of the Xen physical nodes should die, the VMs from that host 
will be started on other nodes. I know something like this can be 
achieved with linux ha for a pair of servers, but I'm looking for 
something which will work across 5 or more servers and I can't see 
anything documented for this.

Jeff Williams
wherethebitsroam.com

Setup doc for Solaris dom0?

This feels like a dumb question, but... is there a HOWTO for getting
dom0 set up for xVM on Solaris?  I went to the obvious place,

 http://opensolaris.org/os/community/xen/docs/specs/

...but it doesn't cover kernel installation for dom0.  Google isn't
helping either, so far.

I installed the xvm packages (using 'pkg install'), and rebooted, but
xvm services won't start and I assume it's because the proper kernel
didn't get installed.  (Logs?  What logs?  Remember when
/var/adm/messages told you stuff?  Ah, the days.)

All of this is on an OpenSolaris machine where I did have a working
dom0, but 'pkg update' hosed it.  Sad.  So I'm trying to retrace steps
that I apparently failed to document the first time around.  Sadder.

Re: Setup doc for Solaris dom0?

_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users

xm create results in blocked state guest

root <at> cbananth:/home/cbananth/new_guest/guests/fedora.fc9.20080706.img# xm create
fedora1.fc9.xen3.cfg -c
Using config file "./fedora1.fc9.xen3.cfg".
Started domain fedora9_1
                        Linux version 2.6.18.8-xenU (root <at> cbananth) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Tue Apr
28 04:12:58 IST 2009
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 000000001b400000 (usable)
0MB HIGHMEM available.
436MB LOWMEM available.
Allocating PCI resources starting at 20000000 (gap: 1b400000:e4c00000)
Detected 2793.219 MHz processor.
Built 1 zonelists.  Total pages: 111616
Kernel command line: root=/dev/sda1 ro ip=:127.0.255.255::::eth0:192.168.31.29 
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Xen reported: 2793.180 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Software IO TLB disabled
vmalloc area: dc000000-f53fe000, maxmem 2d7fe000
Memory: 430136k/446464k available (1929k kernel code, 8108k reserved, 525k data, 140k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 5593.29 BogoMIPS (lpj=27966470)
Mount-cache hash table entries: 512
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 16k freed
Brought up 1 CPUs
migration_cost=0
NET: Registered protocol family 16
Brought up 1 CPUs
suspend: event channel 6
xen_mem: Initialising balloon driver.
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Xen virtual console successfully installed as xvc0
Event-channel device installed.
netfront: Initialising virtual ethernet driver.
i8042.c: No controller found.
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
xen-vbd: registered block device major 8
blkfront: sda1: barriers enabled
XENBUS: Device with no driver: device/console/0
IP-Config: Incomplete network configuration information.
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 140k freed

_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users

Re: Qcow utilities

On 01/05/09 04:20, Javier Guerra wrote:
> On Thu, Apr 30, 2009 at 2:02 AM, Fajar A. Nugraha <fajar <at> fajar.net> wrote:
>   
>> This is part of the reason I like zfs volume, either directly on
>> Opensolaris dom0 or by exporting it (via iscsi) to Linux dom0. zfs
>> snapshot-clone feature is very efficient, and even in the event of
>> domU's data change a lot (like the above scenario) you can still have
>> space savings by turning on compression and setting refreservation=0.
>>     
>
> does ZFS have block deduplication?
>
>
>
>   
The latest update seems integration this (northern) summer:

http://mail.opensolaris.org/pipermail/zfs-code/2009-March/001058.html

Jeff Williams
wherethebitsroam.com

Re: Does I/O from Dom0 skip the PV backend drivers ?

On Thu, Apr 30, 2009 at 9:29 PM, Joe Armstrong <Joe.Armstrong <at> webex.com> wrote:
> Thanks for the info - since I am running CentOs (with xen 3.0.3) it sounds
> like my best bet for real network numbers is to run on bare metal,

Actually it depends on what you're trying to do.
Network PV drivers are good enough so (for example) if you have a
recent enough CPU, you can easily saturate 1 GB link with only a minor
difference in CPU load.

If your benchmark is something like sysbench for MySQL, the limiting
factor is usually disk I/O. In this case testing on a native Linux and
testing on dom0 would yield very similar results.

> but disk
> I/O numbers from dom0 should be consistent with a bare metal machine.

Correct.

Another thing to note is memory allocation. By default Xen
automatically baloons down dom0 memory as needed when domU is started,
but it does NOT automatically baloon-up later when domU is stopped. So
make sure your dom0 is using all memory (try "xm list" or "xm info")
before starting your benchmark.

Regards,

Fajar

Re: "device model failure" when launching Windows SBS 2003 HVM

On Fri, May 1, 2009 at 3:59 AM, Frans Lawaetz <frans <at> tributes.com> wrote:
> Hi-
>
> I am trying to install Windows SBS 2003 32-bit in a HVM on a CentOS 5.1
> x86_64 system running Xen 3.3.1 from the gitco repositories.
>
> The domU config is below.  I have tried a variety of different settings to
> no avail.
>

> disk = [ 'phy:/dev/VolGroup00/win2k3,xvda,w', ',hdc:cdrom,r' ]
> cdrom = '/dev/cdrom'

This seems wrong. Try

disk = [ 'phy:/dev/VolGroup00/win2k3,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]

and remove the "cdrom=" line completely
It would also be faster if you ISO image instead of physical cdrom drive.

Regards,

Fajar

Re: Increasing network performance on Windows DomUs

On Fri, May 1, 2009 at 1:08 AM, Adam Wead <awead <at> indiana.edu> wrote:
> - It's possible to use Windows paravirtual (PV) drivers from XenExpress or
> other commercial products, but they will only work with commercial versions
> of Xen and not open-source ones such as Red Hat's version
>
> If the last point is true, what options are there?

Try gplpv :
- http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing (a
little out of date)
- http://lists.xensource.com/archives/html/xen-users/2009-04/msg00058.html
- http://meadowcourt.org/downloads/

The other option is using stubdom (http://wiki.xensource.com/xenwiki/StubDom)

Regards,

Fajar

Re: Qcow utilities

On Fri, May 1, 2009 at 3:20 AM, Javier Guerra <javier <at> guerrag.com> wrote:
> does ZFS have block deduplication?

Nothing usable yet.

Re: Qcow utilities

On Fri, May 1, 2009 at 3:34 AM, Joe Hammerman <jhammerman <at> videoegg.com> wrote:
> Hi Fajar,
>        The main goal is a to use a shared root image for a set of Virtual Machines. Management thinks this
will keep the machine more 'in sync'. We cannot use NFS booting due to a bug in the kernel version employed by
CentOS 5.3, so that rules out UnionFS and ClusterNFS, etc.
>        Qcow images seemed like a pretty good way to satisfy my deliverable

If you want "shared root image" to "keep domUs in sync", qcow is not
usable. You can't update the qcow base image. Updates will need to go
to each domU, not on a centralized place.