Xen & Automated Disk Management for Domains

Xen & Automated Disk Management for Domains

[Michael Vrable]

I'm experimenting with using Xen to simulate a network of computers for
security research--essentially to create a network of honeypots using
one (or a few) systems running Xen.  This is all using the development
branch of Xen.

One feature that would be really nice to have is the ability to easily
manage the disk images used by the Xen domains, so that I could, for
example, quickly load a particular Linux distribution on a set of LVM
logical volumes, then start a new Xen instance with those.

This isn't terribly difficult to do with a few scripts running in Domain
0, and I already have a basic working version.  But as I'm looking at
cleaning this code up, I'm wondering if it this functionality wouldn't
be useful to others, and if it's worth integrating into the Xen control
tools.

Are there any current tools to do this sort of thing?  Any plans for
such tools (in xend, the future Xen Cluster Daemon, or elsewhere)?
Would it be worthwhile to try to make my code more general so that it
could possibly be included in Xen?  Integration with xend/xm has some
benefits:
  - management over the network comes almost for free
  - could integrate better with domain management; for example, it would
    be easy to check that logical volumes for a running domain aren't
    accidentally deleted
On the other hand:
  - perhaps there are already plans to accomplish this in some other way
  - the persistence requirements for disk images are different than for
    domains, and so there's not a perfect match

Would anyone else find it useful if I worked on this?  If so, what features
would you like to see?  Or am I going about this the wrong way?

--Michael Vrable


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Ian Pratt]

> One feature that would be really nice to have is the ability to easily
> manage the disk images used by the Xen domains, so that I could, for
> example, quickly load a particular Linux distribution on a set of LVM
> logical volumes, then start a new Xen instance with those.

I'd certainly like to see more support for this.

Copy-on-write (CoW) sparse disks are pretty high on everyone's
wish list. In principle, it should be possible to do this today,
but it's a pain to setup: use LVM snapshot with the log device as
a loop interface connected to a sparse file.

I've never actually tried this, but it should work. Has anyone?

[The LVM snapshot device is a bit 'odd' for our purposes as
writes occur in-place, with the old block contents being copied
to a log device. It would make more sense if we slightly modified
the code to have the writes go to the log and leave the original
device pristine. ]

It would certainly be very nice to have xend assist with setting
all this up, and have a nice way of naming images etc (leveraging
LVM wherever possible).
 
> This isn't terribly difficult to do with a few scripts running in Domain
> 0, and I already have a basic working version.  But as I'm looking at
> cleaning this code up, I'm wondering if it this functionality wouldn't
> be useful to others, and if it's worth integrating into the Xen control
> tools.
> 
> Are there any current tools to do this sort of thing?  Any plans for
> such tools (in xend, the future Xen Cluster Daemon, or elsewhere)?
> Would it be worthwhile to try to make my code more general so that it
> could possibly be included in Xen?  Integration with xend/xm has some
> benefits:
>   - management over the network comes almost for free
>   - could integrate better with domain management; for example, it would
>     be easy to check that logical volumes for a running domain aren't
>     accidentally deleted
> On the other hand:
>   - perhaps there are already plans to accomplish this in some other way
>   - the persistence requirements for disk images are different than for
>     domains, and so there's not a perfect match
> 
> Would anyone else find it useful if I worked on this?  If so, what features
> would you like to see?  Or am I going about this the wrong way?

xend is intended to be extensible for exactly this sort of
thing. Mike's writing a manual for it, which should be going into
the tree RSN.

Best,
Ian


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Michael Vrable]

On Thu, Aug 05, 2004 at 06:56:58PM +0100, Ian Pratt wrote:
> > One feature that would be really nice to have is the ability to easily
> > manage the disk images used by the Xen domains, so that I could, for
> > example, quickly load a particular Linux distribution on a set of LVM
> > logical volumes, then start a new Xen instance with those.
> 
> I'd certainly like to see more support for this.
> 
> Copy-on-write (CoW) sparse disks are pretty high on everyone's
> wish list. In principle, it should be possible to do this today,
> but it's a pain to setup: use LVM snapshot with the log device as
> a loop interface connected to a sparse file.

[Just to make sure we're on the same page since I didn't specify
earlier, I'm using LVM2 and not LVM1.]

I haven't gotten snapshots working yet...in my last attempts, I've
gotten a kernel NULL pointer dereference when trying to create a
snapshot.  I haven't put much effort into tracking the problem down, so
I'm not even sure if it's Xen-related yet, but I'd like to look into it
more soon.  Perhaps with XenoLinux 2.6 ready to run as Domain 0, I can
give that a shot as well--I'm currently using 2.4.

At the moment, I'm simply using LVM as a convenient way to create and
destroy partitions for new domains.  (Disk space is cheap, and I've
found this easier to manage than I think using sparse files and the
loopback driver would be.)

> [The LVM snapshot device is a bit 'odd' for our purposes as
> writes occur in-place, with the old block contents being copied
> to a log device. It would make more sense if we slightly modified
> the code to have the writes go to the log and leave the original
> device pristine. ]

Very true, but I don't know how much work this would be.  Since I
haven't been able to test, I don't know how multiple COW images of the
same underlying disk would work in the current implementation (if at
all).  They would certainly work better with the behavior you describe.

> It would certainly be very nice to have xend assist with setting
> all this up, and have a nice way of naming images etc (leveraging
> LVM wherever possible).
> 
> xend is intended to be extensible for exactly this sort of
> thing. Mike's writing a manual for it, which should be going into
> the tree RSN.

I've been reading over some of the code for xend the last few days, so I
at least have some ideas for how to proceed.  I'm hoping that I wouldn't
be stepping on anyone else's toes or duplicating work if I did work on
this.

Oh, and to everyone who has helped build Xen: Thanks!  It's been a lot
of fun to use.

--Michael Vrable


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Brian Wolfe]

Wouldn't it make more sense to alter the COW driver to do just that?
writes goto the COW partition, leaving the original pristine for
multiple COW targets? The way it is now, it sounds like you can only
have one COW device using the origin partition.....

On Thu, 2004-08-05 at 14:02, Michael Vrable wrote:
> On Thu, Aug 05, 2004 at 06:56:58PM +0100, Ian Pratt wrote:
> > > One feature that would be really nice to have is the ability to easily
> > > manage the disk images used by the Xen domains, so that I could, for
> > > example, quickly load a particular Linux distribution on a set of LVM
> > > logical volumes, then start a new Xen instance with those.
> > 
> > I'd certainly like to see more support for this.
> > 
> > Copy-on-write (CoW) sparse disks are pretty high on everyone's
> > wish list. In principle, it should be possible to do this today,
> > but it's a pain to setup: use LVM snapshot with the log device as
> > a loop interface connected to a sparse file.
> 
> [Just to make sure we're on the same page since I didn't specify
> earlier, I'm using LVM2 and not LVM1.]
> 
> I haven't gotten snapshots working yet...in my last attempts, I've
> gotten a kernel NULL pointer dereference when trying to create a
> snapshot.  I haven't put much effort into tracking the problem down, so
> I'm not even sure if it's Xen-related yet, but I'd like to look into it
> more soon.  Perhaps with XenoLinux 2.6 ready to run as Domain 0, I can
> give that a shot as well--I'm currently using 2.4.
> 
> At the moment, I'm simply using LVM as a convenient way to create and
> destroy partitions for new domains.  (Disk space is cheap, and I've
> found this easier to manage than I think using sparse files and the
> loopback driver would be.)
> 
> > [The LVM snapshot device is a bit 'odd' for our purposes as
> > writes occur in-place, with the old block contents being copied
> > to a log device. It would make more sense if we slightly modified
> > the code to have the writes go to the log and leave the original
> > device pristine. ]
> 
> Very true, but I don't know how much work this would be.  Since I
> haven't been able to test, I don't know how multiple COW images of the
> same underlying disk would work in the current implementation (if at
> all).  They would certainly work better with the behavior you describe.
> 
> > It would certainly be very nice to have xend assist with setting
> > all this up, and have a nice way of naming images etc (leveraging
> > LVM wherever possible).
> > 
> > xend is intended to be extensible for exactly this sort of
> > thing. Mike's writing a manual for it, which should be going into
> > the tree RSN.
> 
> I've been reading over some of the code for xend the last few days, so I
> at least have some ideas for how to proceed.  I'm hoping that I wouldn't
> be stepping on anyone else's toes or duplicating work if I did work on
> this.
> 
> Oh, and to everyone who has helped build Xen: Thanks!  It's been a lot
> of fun to use.
> 
> --Michael Vrable
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Ian Pratt]

> I haven't gotten snapshots working yet...in my last attempts, I've
> gotten a kernel NULL pointer dereference when trying to create a
> snapshot.  I haven't put much effort into tracking the problem down, so
> I'm not even sure if it's Xen-related yet, but I'd like to look into it
> more soon.  Perhaps with XenoLinux 2.6 ready to run as Domain 0, I can
> give that a shot as well--I'm currently using 2.4.

AFAIK, LVM2 broke snapshot functionality, but that it'll be going
back into 2.6.8 (which will likely be released in the next week
or two).

> > [The LVM snapshot device is a bit 'odd' for our purposes as
> > writes occur in-place, with the old block contents being copied
> > to a log device. It would make more sense if we slightly modified
> > the code to have the writes go to the log and leave the original
> > device pristine. ]
> 
> Very true, but I don't know how much work this would be.  Since I
> haven't been able to test, I don't know how multiple COW images of the
> same underlying disk would work in the current implementation (if at
> all).  They would certainly work better with the behavior you describe.

I believe it should b e pretty easy to change the
behaviour. Alternatively, Bin Ren's CoW md block driver is
believed to work and is rather simpler....

> > xend is intended to be extensible for exactly this sort of
> > thing. Mike's writing a manual for it, which should be going into
> > the tree RSN.
> 
> I've been reading over some of the code for xend the last few days, so I
> at least have some ideas for how to proceed.  I'm hoping that I wouldn't
> be stepping on anyone else's toes or duplicating work if I did work on
> this.

I'm certainly not aware of anyone working in this area.

Ian


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Ian Pratt]

> Wouldn't it make more sense to alter the COW driver to do just that?
> writes goto the COW partition, leaving the original pristine for
> multiple COW targets? The way it is now, it sounds like you can only
> have one COW device using the origin partition.....

Yep -- I was proposing modifying the DM snapshot driver to create
a DM CoW driver. It shouldn't be too hard.

Ian


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Michael Vrable]

On Thu, Aug 05, 2004 at 11:26:09PM +0100, Ian Pratt wrote:
> AFAIK, LVM2 broke snapshot functionality, but that it'll be going
> back into 2.6.8 (which will likely be released in the next week
> or two).

Snapshots work with LVM2 on Linux 2.4, assuming all the device mapper
patches are applied to the kernel.  I just did a test with a non-Xen
Linux 2.4 kernel; I'll have to look into the problems I had with the Xen
kernel to see if I can figure out the cause of the trouble.

It's true that snapshot functionality wasn't merged into Linux 2.6 when
device mapper support was merged.  My understanding is that it is
possible to get this on current 2.6 systems with additional patches.
However, it looks like those patches currently pull in all of Linux
2.4.7-mm4, which makes the patch rather intrusive.  Linux 2.6.8 should
be better since it won't be necessary to apply any additional patches.

Also, on the subject the way snapshots are implemented in the device
mapper, I think I got confused yesterday.  I don't think any
modifications are necessary.

Say we start with a logical volume /dev/vg1/disk, then create an LVM
snapshot of vg1/disk called vg1/disk-snap.  We could mount vg1/disk-snap
as a read-only filesystem to store a consistent backup of vg1/disk; this
is the normal suggested use.  But LVM actually makes both resulting
devices writable, so we could equally well not touch vg1/disk and use
vg1/disk-snap as a writable, CoW block device.  (If we did accidentally
touch vg1/disk, LVM would keep those changes isolated from the
snapshots.)

While LVM won't allow snapshots of snapshots, multiple snapshots of the
same underlying (non-snapshot) device are allowed.  So we could start
with vg1/disk and create vg1/disk-copy1, vg1/disk-copy2, vg1/disk-copy3,
and so on, as CoW devices.

I think this meets all our needs for CoW devices...am I missing
something?  (Other than getting it to work in my XenoLinux kernel.)

--Michael Vrable


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Ian Pratt]

> Say we start with a logical volume /dev/vg1/disk, then create an LVM
> snapshot of vg1/disk called vg1/disk-snap.  We could mount vg1/disk-snap
> as a read-only filesystem to store a consistent backup of vg1/disk; this
> is the normal suggested use.  But LVM actually makes both resulting
> devices writable, so we could equally well not touch vg1/disk and use
> vg1/disk-snap as a writable, CoW block device.  (If we did accidentally
> touch vg1/disk, LVM would keep those changes isolated from the
> snapshots.)
> 
> While LVM won't allow snapshots of snapshots, multiple snapshots of the
> same underlying (non-snapshot) device are allowed.  So we could start
> with vg1/disk and create vg1/disk-copy1, vg1/disk-copy2, vg1/disk-copy3,
> and so on, as CoW devices.

Great! -- I didn't realise the snapshots were themselves writeable.

It's kind of a shame that snapshots can't be used recursively,
but I guess we can live with this. It would have been nice to
create a 'pristine install', then snapshot it to create several
tailored instances for different applications, and then base the
actual VM disks on those snapshots.  Oh well. The performance
would probably have sucked with all the disk seeking anyhow...

Ian


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Björn Sessler]

hi,

i tried lvm (vers. 1) with xenU 2.4. i created one group on a raid0-device /dev/md/0 (devfs with gentoo) with several lv's for swap and root for virtual hosts. on xen0 i can mount and use these devices without any problem, one of these device is currently used as swap for xen0. 

i tried to give access with this xmdefaults configuration
(not mounted in vm as root like the name says, only access for later test-mount):

disk = [ 'phy:hdb5,hdb5,w' , 'phy:hda6,hda6,w' , 'phy:/dev/vg0/rootvm101,hdx1,w' ]
before:
disk = [ 'phy:hdb5,hdb5,w' , 'phy:hda6,hda6,w' ]

when trying to start the vm, this error occurs (i modified xmdefaults to accept vmid=vm101 like the name of the vm):

root@vm0 vm # xm create -c vmid=vm101
Using config file /etc/xen/xmdefaults
Error: Error creating domain: [Failure instance: Traceback: xen.xend.XendError.VmError, vbd: Segments not found: uname=phy:/dev/vg0/rootvm101

the xend-log says following while creation:

[2004-08-07 12:14:15 xend] DEBUG (XendDomainInfo:692) init_domain> Created domain=14 name=vm101 memory=61
[2004-08-07 12:14:15 xend] INFO (console:93) Created console id=14 domain=14 port=9614
[2004-08-07 12:14:15 xend] DEBUG (XendDomainInfo:1046) Creating vbd dom=14 uname=phy:hdb5 dev=hdb5
[2004-08-07 12:14:15 xend] DEBUG (XendDomainInfo:1046) Creating vbd dom=14 uname=phy:hda6 dev=hda6
[2004-08-07 12:14:15 xend] DEBUG (XendDomainInfo:1046) Creating vbd dom=14 uname=phy:/dev/vg0/rootvm101 dev=hdx1
[2004-08-07 12:14:15 xend] DEBUG (XendDomainInfo:659) Destroying vbds for domain 14
[2004-08-07 12:14:15 xend] DEBUG (blkif:339) Destroying blkif domain=14
[2004-08-07 12:14:15 xend] DEBUG (blkif:415) >BlkifController>send_be_disconnect> dom=14
[2004-08-07 12:14:15 xend] DEBUG (XendDomainInfo:619) Closing channel to domain 14
[2004-08-07 12:14:15 xend] DEBUG (blkif:422) >BlkifController>send_be_destroy> dom=14


i also noticed that changing configuration to 
disk = [ 'phy:hdb5,hdxSWAP,w' , 'phy:hda6,hdxUSR,w' ]
produces also an error like:
Using config file /etc/xen/xmdefaults
Error: Error creating domain: [Failure instance: Traceback: <type 'tuple'>, (<twisted.python.failure.Failure exceptions.TypeError>, 1)

output in xend-log is the same.

any hints for this? or is lvm 1 generally not supported which means i have to patch?

thanks & best regards,
bjoern
_______________________________________________________
WEB.DE Video-Mail - Sagen Sie mehr mit bewegten Bildern
Informationen unter: http://freemail.web.de/?mc=021199



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Christian Limpach]

On Sat, Aug 07, 2004 at 01:33:12PM +0200, =?iso-8859-1?Q? Bj=F6rn=20Sessler ?= wrote:
> 
> disk = [ 'phy:hdb5,hdb5,w' , 'phy:hda6,hda6,w' , 'phy:/dev/vg0/rootvm101,hdx1,w' ]
> before:
> disk = [ 'phy:hdb5,hdb5,w' , 'phy:hda6,hda6,w' ]

There's a couple of things wrong with that entry:
- the destination device has to have a /dev/ entry in the
domain where you run xend (i.e. /dev/hdx1 would have to exist in
dom0's filesystem).
- like with all devices, xend will prepend /dev/ to the device name.

For completeness, let me also mention that the destination
device has to be a hd or sd with an existing major number in
the domain where the device will be used.
(in 2.4, cciss might work as well ans here might be support for it to
be an xbd but that can go away anytime...).

It should work if you use:
disk = [ 'phy:hdb5,hdb5,w' , 'phy:hda6,hda6,w' , 'phy:vg0/rootvm101,sda1,w' ]

    christian



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Ian Pratt]

> On Sat, Aug 07, 2004 at 01:33:12PM +0200, =?iso-8859-1?Q? Bj=F6rn=20Sessler ?= wrote:
> > 
> > disk = [ 'phy:hdb5,hdb5,w' , 'phy:hda6,hda6,w' , 'phy:/dev/vg0/rootvm101,hdx1,w' ]
> > before:
> > disk = [ 'phy:hdb5,hdb5,w' , 'phy:hda6,hda6,w' ]
> 
> There's a couple of things wrong with that entry:
> - the destination device has to have a /dev/ entry in the
> domain where you run xend (i.e. /dev/hdx1 would have to exist in
> dom0's filesystem).

At some point (probably post 2.0) we need to modify the vbd
interface so that both the backend and frontend drivers get
passed device _names_ rather than numbers, that they each resolve
in their own context (within the kernel).

The current situation where xend looks up both device names and
passes 32bit device numbers is not ideal, particularly when
booting a non-Linux OS. (Christian pointed this out many months
ago while doing the NetBSD port, but we haven't gotten around to
fixing it).

> - like with all devices, xend will prepend /dev/ to the device name.

xend appends /dev/ if it's not already there, but it should be
safe to leave it on.
 
> For completeness, let me also mention that the destination
> device has to be a hd or sd with an existing major number in
> the domain where the device will be used.
> (in 2.4, cciss might work as well ans here might be support for it to
> be an xbd but that can go away anytime...).

It's somewhat bizarre that the cciss driver uses its own
major/minor rather that the normal scsi disk ones. I'm surprised
they were allowed to...

Ian


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Christian Limpach]

On Sat, Aug 07, 2004 at 02:11:39PM +0100, Ian Pratt wrote:
> > - like with all devices, xend will prepend /dev/ to the device name.
> 
> xend appends /dev/ if it's not already there, but it should be
> safe to leave it on.

well, then that needs to be changed in xend because if I change my
config file to include the /dev/ part, it fails the same way as
observed by Bjoern Sessler.

Error: Error creating domain: [Failure instance: Traceback: xen.xend.XendError.VmError, vbd: Segments not found: uname=phy:/dev/vgtest/root8

    christian



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Ian Pratt]

> On Sat, Aug 07, 2004 at 02:11:39PM +0100, Ian Pratt wrote:
> > > - like with all devices, xend will prepend /dev/ to the device name.
> > 
> > xend appends /dev/ if it's not already there, but it should be
> > safe to leave it on.
> 
> well, then that needs to be changed in xend because if I change my
> config file to include the /dev/ part, it fails the same way as
> observed by Bjoern Sessler.

Now believed fixed...

Ian


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Xen & Automated Disk Management for Domains

[Björn Sessler]

Christian Limpach schrieb:
> On Sat, Aug 07, 2004 at 02:11:39PM +0100, Ian Pratt wrote:
>
>>> - like with all devices, xend will prepend /dev/ to the device name.
>>
>> xend appends /dev/ if it's not already there, but it should be
>> safe to leave it on.
>
>
> well, then that needs to be changed in xend because if I change my
> config file to include the /dev/ part, it fails the same way as
> observed by Bjoern Sessler.
>
> Error: Error creating domain: [Failure instance: Traceback: xen.xend.XendError.VmError, vbd: Segments not found: uname=phy:/dev/vgtest/root8
>
>     christian
>

hi,

thanks, it works now. prepending the /dev part was also my second 
thought too, as the xenU kernel didn't noticed the device called 'swap' 
or 'root'. first i thought the /dev/vg0/device wasn't recognised 
correctly and xen would create that dev-entry. but anyhow, i didn't 
recognised any problems yet and its working with really good performance 
on that raid0-set

greetz,
bjoern


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com