headers
Ana | 1 Jul 07:53

Re: xen and windows xp

On Fri, Jun 29, 2007 at 11:47:22AM +0200, Petersson, Mats wrote:
> > Does anyone have an idea of what may be preventing me from 
> > running this Windows XP 64 system in a DOMu? I have also 
> > tried a 32 bit system with the same results. Thank you.
> 
> I don't see why 32-bit XP shouldn't work in this setup - I'm pretty
> certain that it should work. I can also with almost certainty say that
> 3.0.3 doesn't support 64-bit XP version.  You need 3.0.4 for that (I
> would recommend an upgrade to 3.1, as it has a bunch of other
> improvements too). 

I had trouble with installing 32-bit WinXP on a Debian 64-bit AMD system
until I installed 3.1.  Since then it's been smooth sailing.

- Ana
Permalink | Reply | 1 comment |
headers
Christian Horn | 1 Jul 11:12
Favicon

Re: Re: Is Anybody Running Xen in Production Environment

On Sat, Jun 30, 2007 at 04:14:53PM +0100, Nuno Fernandes wrote:
> Nops.. no modules from HP so far..
> 
> "RH EL 5 = Red Hat Enterprise Linux 5
> HP will issue a customer advisory for RH EL 5 Xen. HP has certified and will 
> support these servers listed below with the following caveats:
> 
>     * No HP management agent support
Wonder who uses those anyway, with proprietary modules around this is
one of the first things to point to when the kernel behaves strange.

Getting aware of disk-failure in HP-servers was good enough for us
and only needs tools operating in userspace.
Did someone try to run array-info in a dom0 running on HP-hardware?

Christian
Permalink | Reply | 1 comment |
headers
Nico Kadel-Garcia | 1 Jul 11:25
Picon

Re: Re: Is Anybody Running Xen in Production Environment

Christian Horn wrote:
> On Sat, Jun 30, 2007 at 04:14:53PM +0100, Nuno Fernandes wrote:
>   
>> Nops.. no modules from HP so far..
>>
>> "RH EL 5 = Red Hat Enterprise Linux 5
>> HP will issue a customer advisory for RH EL 5 Xen. HP has certified and will 
>> support these servers listed below with the following caveats:
>>
>>     * No HP management agent support
>>     
> Wonder who uses those anyway, with proprietary modules around this is
> one of the first things to point to when the kernel behaves strange.
>
> Getting aware of disk-failure in HP-servers was good enough for us
> and only needs tools operating in userspace.
> Did someone try to run array-info in a dom0 running on HP-hardware?
>
>   
You've noticed that?

I'm going through this now as part of negotiating some co-location 
services. They couldn't *imagine* that I'd rather have backup OS images 
scattered around multiple servers than burning half of my available disk 
using RAID1, and couldn't imagine using SNMP monitoring of overall 
services rather than these familiar integrated tools. It's leading to a 
lot of... negotiation.

It's handy when you only have a very few staff, and a 99.9% uptime SLA, 
to get the reports of hardware outages rather than poking the OS's. But
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oliver Kowalke | 1 Jul 18:51
Picon
Picon

need a patched version of xen-3.1.0 (kernel-2.6.18)

Hello,
is there a patch for xen-3.1.0 available which adds support for JMB363 ide 
controller?
without it I couldN#t boot the kernel.
regards,Oliver
Permalink | Reply | 0 comments |
headers
Ian Tobin | 1 Jul 17:26
Favicon

RE: Make error

Hi,

Did anyone get to the bottom of this in the end? I still can't install
it.

thanks

-----Original Message-----
From: Petersson, Mats [mailto:Mats.Petersson <at> amd.com] 
Sent: 13 June 2007 10:33
To: Ian Tobin; James Harper; xen-users <at> lists.xensource.com
Subject: RE: [Xen-users] Make error

> -----Original Message-----
> From: Ian Tobin [mailto:itobin <at> tidyhosts.com] 
> Sent: 13 June 2007 10:30
> To: Petersson, Mats; James Harper; xen-users <at> lists.xensource.com
> Subject: RE: [Xen-users] Make error
> 
> I think this is a big bug, ive have tried it on several 
> systems all with
> the same problem.

Yes, it's almost certainly some form of bug, but I think the real
problem is that we're doing "make mrproper" in the wrong place. I had
the same problem the other day (sorry, I should have posted about it,
but I didn't remember at the time), and I found that if you do "cd
build-linux-2.6.18-xen_x86_32; make mrproper; cd ..; make dist" it will
work.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Warfield | 1 Jul 22:28
Picon
Picon
Favicon

Re: Re: [Xen-devel] Re: Writing a tool for Shared Persistent Windows Boot Image

The problem with this approach is that you end up using two instances
of whatever virtual disk code you want.  In the case of raw writes to
an image file (tap:aio) this is more or less okay, except for the fact
that qemu has a bad habit of buffering writes and so you can get stuck
in a nasty late write race when you switch from emulated writes over
to using pv drivers.

For non-raw writes this is worse, because most of the image file
drivers cache metadata in memory and don't necessarily pick up changes
to the image files when you switch from emulated to pv.  Also, the
disparate implementations make me a bit nervous about headers exactly
matching and so on.

The intention of the phantom device is to try to keep things down to a
single data path, and a single driver implementation.

a.

On 6/29/07, Daniel P. Berrange <berrange <at> redhat.com> wrote:
> On Fri, Jun 29, 2007 at 09:18:50AM -0700, Andrew Warfield wrote:
> > If you can send some more details on the crash we should be able to
> > sort this out -- it's certainly something that has worked in the past.
>
> Ok, so here's the scenario. Traditionally with HVM I have a disk
>
>    file:/xen/rhel4i386.img,hda,w
>
> Having seen the changeset 13827:6524e02edbeb I tried
>
>   tap:aio:/xen/rhel4i386.img,hda,w
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel P. Berrange | 1 Jul 23:41
Picon
Favicon

Re: Re: [Xen-devel] Re: Writing a tool for Shared Persistent Windows Boot Image

On Sun, Jul 01, 2007 at 01:28:56PM -0700, Andrew Warfield wrote:
> The problem with this approach is that you end up using two instances
> of whatever virtual disk code you want.  In the case of raw writes to
> an image file (tap:aio) this is more or less okay, except for the fact
> that qemu has a bad habit of buffering writes and so you can get stuck
> in a nasty late write race when you switch from emulated writes over
> to using pv drivers.

AFAIR, if the guest OS sends a flush request to the IDE device, then
QEMU should immediately be flushing the data to disk in the host - if
it doesn't, then this is already a potential data corrupter if either
the guest or host crashes because journaling fileystems rely on the
fact that when they ask for a journal flush it is not buffered in RAM.

I don't think a guest OS would ever be activating both the IDE and
paravirt drivers for a device though would it ? You either load IDE
drivers, or paravirt at any given time. If you've got a guest using
PV drivers, then the only point where the IDE interface would come
into play is for the initial BIOS boot process & that should be 
read-only access.

> For non-raw writes this is worse, because most of the image file
> drivers cache metadata in memory and don't necessarily pick up changes
> to the image files when you switch from emulated to pv.  Also, the
> disparate implementations make me a bit nervous about headers exactly
> matching and so on.

Are you refering to the qcow file format headers here ? If blktap isn't
in compliance with the QEMU QCOW spec then that is a bug in itself which
needs fixing, because it is not good for portability of FS images.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel P. Berrange | 1 Jul 23:55
Picon
Favicon

Re: Re: [Xen-devel] Re: Writing a tool for Shared Persistent Windows Boot Image

On Sun, Jul 01, 2007 at 10:41:37PM +0100, Daniel P. Berrange wrote:
> On Sun, Jul 01, 2007 at 01:28:56PM -0700, Andrew Warfield wrote:
> > The problem with this approach is that you end up using two instances
> > of whatever virtual disk code you want.  In the case of raw writes to
> > an image file (tap:aio) this is more or less okay, except for the fact
> > that qemu has a bad habit of buffering writes and so you can get stuck
> > in a nasty late write race when you switch from emulated writes over
> > to using pv drivers.
> 
> AFAIR, if the guest OS sends a flush request to the IDE device, then
> QEMU should immediately be flushing the data to disk in the host - if
> it doesn't, then this is already a potential data corrupter if either
> the guest or host crashes because journaling fileystems rely on the
> fact that when they ask for a journal flush it is not buffered in RAM.
> 
> I don't think a guest OS would ever be activating both the IDE and
> paravirt drivers for a device though would it ? You either load IDE
> drivers, or paravirt at any given time. If you've got a guest using
> PV drivers, then the only point where the IDE interface would come
> into play is for the initial BIOS boot process & that should be 
> read-only access.

Thinking about it from the safety POV, the QEMU process could register
a xenstore watch to be notified when the paravirt frontend driver
connected to the backend. At this time it could forceably disable the
IDE device associated with the backend, thus ensuring you never have 
two concurrently active data paths to the same underlying disk.

Regards,
Dan.
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Harper | 2 Jul 02:13
Picon

Push local rather than utc time to HVM domains

When I start a HVM domain, it appears to be out by the number of hours
of my UTC offset. I am guessing that qemu is setting the virtual BIOS
date to the physical UTC time, rather than the local time.

UTC makes sense for Linux, but Windows isn't so smart so it would be
nice to have a choice... 

ntp fixes it up of course, but big time jumps like that can cause all
sorts of race conditions (eg scheduled tasks thinking they ought to run
before ntp kicks in).

Or maybe this option already exists and I don't know about it?

Thanks

James
Permalink | Reply | 2 comments |
headers
Stephan Seitz | 2 Jul 03:16
Picon

Re: Push local rather than utc time to HVM domains

James Harper schrieb:
> When I start a HVM domain, it appears to be out by the number of hours
> of my UTC offset. I am guessing that qemu is setting the virtual BIOS
> date to the physical UTC time, rather than the local time.

> 
> Or maybe this option already exists and I don't know about it?

Hi,

according to the examples, the HVM DomU configuration files could take
localtime=1
as argument.

--

-- 
Stephan Seitz
Senior System Administrator

*netz-haut* e.K.
multimediale kommunikation

zweierweg 22
97074 würzburg

fon: +49 931 2876247
fax: +49 931 2876248

web: www.netz-haut.de <http://www.netz-haut.de/>

registriergericht: amtsgericht würzburg, hra 5054
(Continue reading)

Permalink | Reply | 1 comment |

Gmane