Boris Derzhavets | 1 Jun 12:47
Picon
Favicon
Gravatar

Re: OpenSolaris 2008.05 domU on Debian dom0

Would address it to xen-discuss forum <at> opensolaris.org.

--- On Sat, 5/31/08, Daniel Bareiro <daniel-listas <at> gmx.net> wrote:
From: Daniel Bareiro <daniel-listas <at> gmx.net>
Subject: [Xen-users] OpenSolaris 2008.05 domU on Debian dom0
To: "Xen-Users" <xen-users <at> lists.xensource.com>
Date: Saturday, May 31, 2008, 2:21 PM

Hi all!

I am trying to install OpenSolaris 2008.05 PV domU on Debian GNU/Linux
dom0 follow t his [1] steps. Xen version is 3.0.3-1 from Debian packages.

But I got this messages during boot:

Configuring devices.
Mounting local partitions/cdroms
May 31 11:04:29 svc.startd[7]: svc:/system/coreadm:default: Method
"/lib/svc/method/svc-coreadm start" failed due to signal KILL.
Reading ZFS config: done.
May 31 11:05:36 svc.startd[7]: svc:/system/coreadm:default: Method or
service exit timed out. Killing contract 31.
May 31 11:07:12 svc.startd[7]: svc:/network/routing/route:default:
Method or service exit timed out. Killing contract 33.
May 31 11:07:16 svc.startd[7]: svc:/network/rpc/bind:default: Couldn't
fork to execute method /lib/svc/method/rpc-bind start: Resource
temporarily unavailable
May 31 11:07:39 svc.startd[7]: svc:/network/routing/route:default:
Method or service exit timed out. Killing contract 33.
May 31 11:07:42 svc.startd[7]: svc:/system/coreadm:default: Metho d
"/lib/svc/method/svc-coreadm refresh" failed with exit status 96.
May 31 11:07:44 svc.startd[7]: svc:/network/routing/route:default:
Method "/lib/svc/method/svc-route" failed due to signal KILL.
May 31 11:07:44 svc.startd[7]: svc:/system/dbus:default: Method or
service exit timed out. Killing contract 34.
May 31 11:07:46 svc.startd[7]: svc:/system/dbus:default: Method
"/lib/svc/method/svc-dbus start" failed with exit status 95.
May 31 11:07:52 svc.startd[7]: system/coreadm:default misconfigured:
transitioned to maintenance (see 'svcs -xv' for details)
May 31 11:08:00 svc.startd[7]: system/dbus:default failed fatally:
transitioned to maintenance (see 'svcs -xv' for details)
May 31 11:08:15 svc.startd[7]: svc:/network/inetd-upgrade:default:
Method or service exit timed out. Killing contract 35.
May 31 11:08:25 svc.startd[7]: svc:/network/inetd-upgrade:default:
Method or service exit timed o ut. Killing contract 35.
May 31 11:08:28 svc.startd[7]: svc:/network/inetd-upgrade:default:
Method "/lib/svc/method/inetd-upgrade start" failed due to signal
KILL.
May 31 11:12:05 svc.startd[7]:
svc:/application/opengl/ogl-select:default: Method or service exit timed
out. Killing contract 47.
May 31 11:13:03 svc.startd[7]:
svc:/application/opengl/ogl-select:default: Method or service exit timed
out. Killing contract 47.
May 31 11:15:53 svc.startd[7]:
svc:/application/opengl/ogl-select:default: Method
"/lib/svc/method/ogl-select start" failed due to signal KILL.
May 31 11:15:55 svc.startd[7]: svc:/network/inetd-upgrade:default:
Method "/lib/svc/method/inetd-upgrade start" failed due to signal
KILL.
May 31 11:15:55 svc.startd[7]: svc:/network/routing/route:default:
Method or service exit timed out. Killing contract 51.
May 31 11:16:01 svc.startd[7]: svc:/network/routing/route:default:
Method "/lib/svc/method/svc-route" failed due to signal KILL.

And I do not reach to obtain login. Some idea than can be happening?

Thanks in advance.

Regards,
Daniel

[1] http://www.mobilnews.cz/blog/?p=42
--
Daniel Bareiro - System Administrator
Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Lenny - Linux user #188.598_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users

_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users
James Harper | 1 Jun 15:22
Picon

Release 0.9.5 of GPL PV Drivers for Windows

I've just made my first ever attempt at an Nullsoft installer, so if you
want to try it download "Xen PV Drivers 0.9.5.exe" from
http://www.meadowcourt.org/downloads/

The installer should detect the version of windows you are running and
install the drivers. At the moment you'll need to install the shutdown
monitor service manually, but you can do that from the start menu.

I haven't figured out a way to update the boot.ini (and the vista
equivalent) yet, and I'm a bit reluctant to try it as there is plenty of
potential to break things. I have added some documentation on the use of
bcdedit to the wiki though (you can get to the wiki page from the start
menu, or http://wiki.xensource.com/xenwiki/XenWindowsGplPv), so if
someone can have a look and let me know if there's a better way I'd be
very grateful.

Other than that, I fixed a bug which was stopping the drivers working
for me under windows 2008, so if 2008 or Vista wasn't working previously
you might like to try this version.

I'd still like to hear from anyone who's run disk performance testing
recently... 0.9.3+ might perform a little better...

Thanks

James
Nick Couchman | 1 Jun 15:29
Favicon

Re: OpenSolaris 2008.05 domU on Debian dom0

I don't know exactly, but I'm thinking that OpenSolaris requires Xen 3.1 or higher.  Could be wrong, but it
seems that success with pre-3.1 versions is pretty hit-or-miss.

-Nick

>>> On 2008/05/31 at 12:21, Daniel Bareiro <daniel-listas <at> gmx.net> wrote:
Hi all!

I am trying to install OpenSolaris 2008.05 PV domU on Debian GNU/Linux
dom0 follow this [1] steps. Xen version is 3.0.3-1 from Debian packages.

But I got this messages during boot:

Configuring devices.
Mounting local partitions/cdroms
May 31 11:04:29 svc.startd[7]: svc:/system/coreadm:default: Method
"/lib/svc/method/svc-coreadm start" failed due to signal KILL.
Reading ZFS config: done.
May 31 11:05:36 svc.startd[7]: svc:/system/coreadm:default: Method or
service exit timed out.  Killing contract 31.
May 31 11:07:12 svc.startd[7]: svc:/network/routing/route:default:
Method or service exit timed out.  Killing contract 33.
May 31 11:07:16 svc.startd[7]: svc:/network/rpc/bind:default: Couldn't
fork to execute method /lib/svc/method/rpc-bind start: Resource
temporarily unavailable
May 31 11:07:39 svc.startd[7]: svc:/network/routing/route:default:
Method or service exit timed out.  Killing contract 33.
May 31 11:07:42 svc.startd[7]: svc:/system/coreadm:default: Method
"/lib/svc/method/svc-coreadm refresh" failed with exit status 96.
May 31 11:07:44 svc.startd[7]: svc:/network/routing/route:default:
Method "/lib/svc/method/svc-route" failed due to signal KILL.
May 31 11:07:44 svc.startd[7]: svc:/system/dbus:default: Method or
service exit timed out.  Killing contract 34.
May 31 11:07:46 svc.startd[7]: svc:/system/dbus:default: Method
"/lib/svc/method/svc-dbus start" failed with exit status 95.
May 31 11:07:52 svc.startd[7]: system/coreadm:default misconfigured:
transitioned to maintenance (see 'svcs -xv' for details)
May 31 11:08:00 svc.startd[7]: system/dbus:default failed fatally:
transitioned to maintenance (see 'svcs -xv' for details)
May 31 11:08:15 svc.startd[7]: svc:/network/inetd-upgrade:default:
Method or service exit timed out.  Killing contract 35.
May 31 11:08:25 svc.startd[7]: svc:/network/inetd-upgrade:default:
Method or service exit timed out.  Killing contract 35.
May 31 11:08:28 svc.startd[7]: svc:/network/inetd-upgrade:default:
Method "/lib/svc/method/inetd-upgrade start" failed due to signal KILL.
May 31 11:12:05 svc.startd[7]:
svc:/application/opengl/ogl-select:default: Method or service exit timed
out.  Killing contract 47.
May 31 11:13:03 svc.startd[7]:
svc:/application/opengl/ogl-select:default: Method or service exit timed
out.  Killing contract 47.
May 31 11:15:53 svc.startd[7]:
svc:/application/opengl/ogl-select:default: Method
"/lib/svc/method/ogl-select start" failed due to signal KILL.
May 31 11:15:55 svc.startd[7]: svc:/network/inetd-upgrade:default:
Method "/lib/svc/method/inetd-upgrade start" failed due to signal KILL.
May 31 11:15:55 svc.startd[7]: svc:/network/routing/route:default:
Method or service exit timed out.  Killing contract 51.
May 31 11:16:01 svc.startd[7]: svc:/network/routing/route:default:
Method "/lib/svc/method/svc-route" failed due to signal KILL.

And I do not reach to obtain login. Some idea than can be happening?

Thanks in advance.

Regards,
Daniel

[1] http://www.mobilnews.cz/blog/?p=42 
--

-- 
Daniel Bareiro - System Administrator
Fingerprint: BFB3 08D6 B4D1 31B2 72B9  29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Lenny - Linux user #188.598

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. 
If this email is not intended for you, or you are not responsible for the delivery of this message to the
intended recipient, please note that this message may contain SEAKR Engineering (SEAKR)
Privileged/Proprietary Information.  In such a case, you are strictly prohibited from downloading,
photocopying, distributing or otherwise using this message, its contents or attachments in any way.  If
you have received this message in error, please notify us immediately by replying to this e-mail and
delete the message from your mailbox.  Information contained in this message that does not relate to the
business of SEAKR is neither endorsed by nor attributable to SEAKR.
_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users
Christian Tramnitz | 1 Jun 15:33
Picon

Re: FW: Xen Backups

I guess most people would like to avoid the necessary downtime.
On the other hand, when doing live-snapshots (i.e. LVM snapshot target),
live-data may be corrupt (open file handles, databases)...

Best regards,
    Christian

James Alspach wrote:
>  
> 
> How do most people backup their VM’s?  I understand that the suggested 
> method right now is to install your backup client just as you would if 
> you were backing up a physical server.  It just feels like you should be 
> able to snapshot the entire VM instead of worrying about just the data.
> 
> For instance, how difficult it would be to script taking a VM offline, 
> exporting it and then bringing it back online.  To me this sounds like a 
> good way to backup your VM’s  (as long as you can stand them being 
> offline for some amount of time while they export).  If you could back 
> up this way recovering from a disaster should be fairly painless. Just 
> reinstall Xensource, hook it back up to the SAN and import the 
> VM’s…done.  What am I missing? Is it the size of the VM’s that keeps 
> this from being viable?
> 
>  
> 
> Thanks for your help;
> 
> James
Boris Derzhavets | 1 Jun 15:53
Picon
Favicon
Gravatar

Re: OpenSolaris 2008.05 domU on Debian dom0

Works at Xen 3.0.3 Debian Dom0
http://www.mobilnews.cz/blog/?p=42
Works at Xen 3.2.1 CentOS 5.1 Dom0
  http://lxer.com/module/newswire/view/102728/index.html
Works at Xen 3.2 Ubuntu 8.04 Desktop(Server) Dom0
    http://lxer.com/module/newswire/view/103407/index.html
Works at Xen 3.1 F8 Dom0, Xen 3.1 CentOS 5.1 Dom0,
Xen 3.1 Ubuntu 7.10 Dom0. Just doesn't require kernel
patch (vs Xen 3.2 Linux Dom0).

--- On Sun, 6/1/08, Nick Couchman &lt ;Nick.Couchman <at> seakr.com> wrote:
From: Nick Couchman <Nick.Couchman <at> seakr.com>
Subject: Re: [Xen-users] OpenSolaris 2008.05 domU on Debian dom0
To: dbareiro <at> gmx.net, "Xen-Users" <xen-users <at> lists.xensource.com>
Date: Sunday, June 1, 2008, 9:29 AM

I don't know exactly, but I'm thinking that OpenSolaris requires Xen 3.1 or higher.  Could be wrong, but it seems that success with pre-3.1 versions is pretty hit-or-miss.
 
-Nick

>>> On 2008/05/31 at 12:21, Daniel Bareiro <daniel-listas <at> gmx.net> wrote:
Hi all!

I am trying to install OpenSolaris 2008.05 PV domU on Debian GNU/Linux
dom0 follow this [1] steps. Xen version is 3.0.3-1 from Debian packages.

But I got this messages during boot:

Configuring devices.
Mounting local partitions/cdroms
May 31 11:04:29 svc.startd[7]: svc:/system/coreadm:default: Method
"/lib/svc/method/svc-coreadm start" failed due to signal KILL.
Reading ZFS config: done.
May 31 11:05:36 svc.startd[7]: svc:/system/coreadm:default: Method or
service exit timed out.  Killing contract 31.
May 31 11:07:12 svc.startd[7]: svc:/network/routing/route:default:
Method or service exit timed out .  Killing contract 33.
May 31 11:07:16 svc.startd[7]: svc:/network/rpc/bind:default: Couldn't
fork to execute method /lib/svc/method/rpc-bind start: Resource
temporarily unavailable
May 31 11:07:39 svc.startd[7]: svc:/network/routing/route:default:
Method or service exit timed out.  Killing contract 33.
May 31 11:07:42 svc.startd[7]: svc:/system/coreadm:default: Method
"/lib/svc/method/svc-coreadm refresh" failed with exit status 96.
May 31 11:07:44 svc.startd[7]: svc:/network/routing/route:default:
Method "/lib/svc/method/svc-route" failed due to signal KILL.
May 31 11:07:44 svc.startd[7]: svc:/system/dbus:default: Method or
service exit timed out.  Killing contract 34.
May 31 11:07:46 svc.startd[7]: svc:/system/dbus:default: Method
"/lib/svc/method/svc-dbus start" failed with exit status 95.
May 31 11:07:52 svc.startd[7]: system/coreadm:default misconfigured:
transitioned to maintenan ce (see 'svcs -xv' for details)
May 31 11:08:00 svc.startd[7]: system/dbus:default failed fatally:
transitioned to maintenance (see 'svcs -xv' for details)
May 31 11:08:15 svc.startd[7]: svc:/network/inetd-upgrade:default:
Method or service exit timed out.  Killing contract 35.
May 31 11:08:25 svc.startd[7]: svc:/network/inetd-upgrade:default:
Method or service exit timed out.  Killing contract 35.
May 31 11:08:28 svc.startd[7]: svc:/network/inetd-upgrade:default:
Method "/lib/svc/method/inetd-upgrade start" failed due to signal KILL.
May 31 11:12:05 svc.startd[7]:
svc:/application/opengl/ogl-select:default: Method or service exit timed
out.  Killing contract 47.
May 31 11:13:03 svc.startd[7]:
svc:/application/opengl/ogl-select:default: Method or service exit timed
out.  Killing contract 47.
May 31 11:15:53 svc.startd[7]:
svc:/application/opengl/ogl-select:default: Method
"/lib/svc/me thod/ogl-select start" failed due to signal KILL.
May 31 11:15:55 svc.startd[7]: svc:/network/inetd-upgrade:default:
Method "/lib/svc/method/inetd-upgrade start" failed due to signal KILL.
May 31 11:15:55 svc.startd[7]: svc:/network/routing/route:default:
Method or service exit timed out.  Killing contract 51.
May 31 11:16:01 svc.startd[7]: svc:/network/routing/route:default:
Method "/lib/svc/method/svc-route" failed due to signal KILL.

And I do not reach to obtain login. Some idea than can be happening?

Thanks in advance.

Regards,
Daniel

[1] http://www.mobilnews.cz/blog/?p=42
--
Daniel Bareiro - System Administrator
Fingerprint: BFB3 08D6 B4D1 31B2 72B9  29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Lenny - Linux user #188.598

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

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

_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users
Joost Roeleveld | 1 Jun 16:16
Picon

Re: Re: FW: Xen Backups

On Sunday 01 June 2008 15:33:32 Christian Tramnitz wrote:
> I guess most people would like to avoid the necessary downtime.
> On the other hand, when doing live-snapshots (i.e. LVM snapshot target),
> live-data may be corrupt (open file handles, databases)...

I actually run a script on the host that does the following:
All activities on the guest are done using SSH and shared key authentication

1) Stop the service(s) on the guest
2) Unmount the filesystem(s) on the guest to be backed up
3) detach the filesystems (xm block-detach <domain> <hd??/sd??>)
4) create snapshots
5) reattach the filesystems (xm block-attach <domain> <device> <hd??/sd??> w)
6) remount the filesystems on the guest
7) Restart the service(s) on the guest

I can then backup the filesystems using the snapshots and remove the snapshots 
when the backups are finished.
Using this, the total 'downtime' is around 40 seconds (on my system) to:
- stop and start 3 services
- backup OpenLDAP and PostgreSQL
- unmount / mount 6 filesystems
- detach / attach 6 filesystems
- create 6 snapshots

The script I use also has error-handling implemented in case any action fails. 
This will prevent, for example, a detach-attempt to take place on still 
mounted filesystems.

HTH,

Joost Roeleveld

>
> Best regards,
>     Christian
>
> James Alspach wrote:
> > How do most people backup their VM’s?  I understand that the suggested
> > method right now is to install your backup client just as you would if
> > you were backing up a physical server.  It just feels like you should be
> > able to snapshot the entire VM instead of worrying about just the data.
> >
> > For instance, how difficult it would be to script taking a VM offline,
> > exporting it and then bringing it back online.  To me this sounds like a
> > good way to backup your VM’s  (as long as you can stand them being
> > offline for some amount of time while they export).  If you could back
> > up this way recovering from a disaster should be fairly painless. Just
> > reinstall Xensource, hook it back up to the SAN and import the
> > VM’s…done.  What am I missing? Is it the size of the VM’s that keeps
> > this from being viable?
> >
> >
> >
> > Thanks for your help;
> >
> > James
>
> _______________________________________________
> Xen-users mailing list
> Xen-users <at> lists.xensource.com
> http://lists.xensource.com/xen-users
Ronnie Tartar | 1 Jun 18:59

Virtual Inteface Assigment

I am looking to use mrtg to map bandwidth usage on my DomU's.

But by default the vif26.0, vif28.0 is created, can I assign the same vif
everytime a domu is started?

Thanks
Ronnie Tartar | 1 Jun 19:01

RE: Release 0.9.4 of GPL PV Drivers for Windows

I installed the PV drivers for the first time, they work like a champ, love
the system restart/shutdown, also the increment of the xentop counters.  

Great stuff, thanks for your hard work.

Regards,

Ronnie

-----Original Message-----
From: xen-users-bounces <at> lists.xensource.com
[mailto:xen-users-bounces <at> lists.xensource.com] On Behalf Of James Harper
Sent: Saturday, May 31, 2008 9:31 AM
To: xen-users <at> lists.xensource.com; xen-devel <at> lists.xensource.com
Subject: [Xen-users] Release 0.9.4 of GPL PV Drivers for Windows

0.9.3 was missing the amd64 version of xenvbd.sys, so I'm just uploading
0.9.4.

James

_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users
Tim Post | 1 Jun 19:21
Picon
Favicon
Gravatar

Re: Virtual Inteface Assigment

On Sun, 2008-06-01 at 12:59 -0400, Ronnie Tartar wrote:
> I am looking to use mrtg to map bandwidth usage on my DomU's.
> 
> But by default the vif26.0, vif28.0 is created, can I assign the same vif
> everytime a domu is started?

I use cacti for this but its pretty much the same. In your config (vif=)
just add vifname=blah

>From a live config file:

vif = ['bridge=br0, mac=00:00:6d:8c:2b:41, vifname=6-a-1.0']

The domname is 6-a-1, so I know easily (in cacti) that 6-a-1.0 is eth0
in guest 6-a-1.

HTH

Cheers,
--Tim

--

-- 
Monkey + Typewriter = Echoreply ( http://echoreply.us )
Boris Derzhavets | 1 Jun 19:23
Picon
Favicon
Gravatar

What is pygrub status in Xen 3.2.1 ?

Looking  at  http://strugglers.net/~andy/blog/2008/01/20/red-hat-based-linux-under-xen-from-debian-etch/
I found following  statement.
Quote:-
  1. Andy Says:
    March 29th, 2008 at 2:42 am

    Hi,

    The broken pygrub is not a security bug so not going to be fixed at least until the next stable release I suppose.

    Do you have the details of the pygrub exploit? I thought I saw it fixed, which is what I would  expect as a security issue.

    If you’re just here to bash Debian then I’m not really interested however.

My concern is failure to manage with "xm"  CentOS 5.1 DomU at Xen 3.2.1 F8 Dom0 after successful DomU creating by virt-install obtained as a result of "yum install python_libvirt" on xen-disabled F8 instance (64-bit)

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

Gmane