[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] DomU in it's own LVM partition fails to boot CentOS 5.2 Dom0/U


  • To: "Fajar A. Nugraha" <fajar@xxxxxxxxx>
  • From: Peter Hoose <phoose@xxxxxxxxx>
  • Date: Sat, 24 Jan 2009 15:19:14 -0500
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Sat, 24 Jan 2009 12:20:03 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UX3ih+ZGFEwJE5vn3Syvm02Jx5t9b2SNh0FCTITOktffcEG95GNz/WlWCVIMhmQEPK WYkkDvdrEUOafXlnM6/S9ceTUmERg5gFsl9Eic8jqsQTiCpFbjgqvnhjCWZy5oiwf5dO vCy+uqccpNG/hcXOvRrSJtoG26dLOhwaX0t+Q=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

> Some would argue that with current implementation (i.e. with tap:aio
> instead of files) and by using full (i.e. not sparse) image files you
> can get a similar performance from file-based vbd compared to
> LVM-based.

Sorry, I should have been more specific. I was using tap:aio with a non-sparse file. Testing with bonnie++ showed about 10MB/s vs. my local disk which is closer to 100MB/s+ , So I'm trying a partition as the XEN documnetation says this has better performance (maybe this was based on legacy 'file:' instead of tap?)

> From your post, I'd say you're trying to do two things at once :
> - move from file-based to LVM-based vbd
> - using whole domU disk directly as filesystem, without additional
> partition/LVM on domU side.

> When trying new things sometimes it's better to do it one at a time.

Not necessarily, I just created a LVM based vbd in my dom0, I want to use this as my 'disk' for my domU, which I would create my partitions on. Is this possible, or do I need to create a /boot, / and /swap on my domU and share those with dom0 for it to access natively? IE: Does the dom0 see this partition as a disk that it can create partitions on, or does it see it just like a normal partition? I'm not moving from one thing to another, this is my first VM on XEN and I'm just trying to find the optimal configuration for performance.

> No it's not. Any backend vbd on dom0 side should look the same to domU
> when it's presented as the same device (i.e. xvda). However, changing
> xvda to xvda1 has the effect that you mentioned.

Good to know, I got the impression that I could only do a NFS, or image based (copy all files/folders over) when using a partition of a file image. Not exactly, all the examples I found either did HTTP based with file/tap, or image copies with disk/parition.

> Actually there's door #3 :
> - install to a file-based vbd (you got this already)
> - copy files (or copy the whole domU disk with dd) to the new LVM partition

I had actually tried that copying from the jailtime image, however, I think my problem was the xvda1 issue you listed above, re-testing now.

> "-x" should prevent that, but I don't think you need 20G for domU
> anyway, so stay away from using bloated "template" (like your dom0).

Ok, again I should have been more clear :D the whole partition was only 20G the install was much smaller, but that's besides the point :) If I can, with your suggestions make this work with an HTTP install or the jailtime image I'd be happier anyway.

> In your case I'd actually recommend you try two things :
> - try non-sparse file-based (or disk images, if you prefer that term)
> vbd making sure that it uses tap:aio: instead of file:

Tried that initially, which delivered the poor performance that I'm trying to avoid :(

> - change your domU config file to say
> disk = [ 'phy:/dev/VolGroup00/guest01,
> xvda,w', ]

re-testing with this, that may have been the whole issue.

> You need this if you still want to use HTTP-install (e..g. usingvirt-install or something similar).

> And drop the
> root="/dev/xvda1"line. You don't need it anyway.

That came from the jailtime example, I didn't see it anywhere else either, dropped now, thank you.

> From your config file, I'd say Mike made a good point: you don't have an initrd.
> I'd rather not go into this yet though, because I'm not familiar with
> jailtime.org images, and how you create them can make "best way to
> create initrd" differ.

The jailtime  example didn't have it either, my initial test with file based had an initrd , I re-added it for my re-test.

Thanks for you suggestions, I'll try this again and see what I get, I think xvda1 thing might have been the 'major' issue, and possibly trying to use my dom0 as a 'disk' instead of creating inidividual partitions for my domU to access directly.

Thank you,
Peter

On Sat, Jan 24, 2009 at 2:51 PM, Fajar A. Nugraha <fajar@xxxxxxxxx> wrote:
On Sun, Jan 25, 2009 at 1:19 AM, Peter Hoose <phoose@xxxxxxxxx> wrote:
> I'm trying to do what I think would be relatively simple but can't seem to
> make it work. Essentially I want to create several domU's running CentOS
> each with it's own LVM partition for increased performance over image files.
>
Some would argue that with current implementation (i.e. with tap:aio
instead of files) and by using full (i.e. not sparse) image files you
can get a similar performance from file-based vbd compared to
LVM-based.

>From your post, I'd say you're trying to do two things at once :
- move from file-based to LVM-based vbd
- using whole domU disk directly as filesystem, without additional
partition/LVM on domU side.

When trying new things sometimes it's better to do it one at a time.

> Initially I did a test with image files and everything went fine, I booted
> the supplied initrd and vmlinuz images installed CentOS from http, etc...

That's good.

> However, the performance of image files is pretty slow for what I intend to
> use this for (Web/DB servers).

I'd recommend you try that one more time, but by making sure that :
- the generated domU config file uses tap:aio: instead of file: (I
haven't tested virt-install in a long time, so I'm not sure which one
it uses by default)
- use non-sparse image file

> So I wanted to do the same thing but in a
> dedicated partition. Problem is, when I do this and try to install via http,
> the disk doesn't show up in the installer, it just shows a "#". This appears
> to be expected when using a dedicated partition

No it's not. Any backend vbd on dom0 side should look the same to domU
when it's presented as the same device (i.e. xvda). However, changing
xvda to xvda1 has the effect that you mentioned.

> and the solution seems to be
> to copy an image to my partition and go that route. I tried this 2 different
> ways: 1: jailtime image 2: copy of my dom0 OS.

Actually there's door #3 :
- install to a file-based vbd (you got this already)
- copy files (or copy the whole domU disk with dd) to the new LVM partition

> When I try to copy my own OS the file copy takes forever (only 20G) and my
> load average starts creeping up to 3+, which I assume may have to do with
> the fact that I'm running cp -ax / /mnt/guest01 which may loop copying
> /mnt/guest01 to itself or something similar?

"-x" should prevent that, but I don't think you need 20G for domU
anyway, so stay away from using bloated "template" (like your dom0).

> Anyways, long story short, is there a way to install to a partition via HTTP
> like with disk images?

In your case I'd actually recommend you try two things :
- try non-sparse file-based (or disk images, if you prefer that term)
vbd making sure that it uses tap:aio: instead of file:
- change your domU config file to say

disk = [ 'phy:/dev/VolGroup00/guest01,xvda,w', ]

You need this if you still want to use HTTP-install (e..g. using
virt-install or something similar). And drop the

root="/dev/xvda1"

line. You don't need it anyway.

> If not, what am I doing wrong using the prebuilt
> images?

From your config file, I'd say Mike made a good point: you don't have an initrd.
I'd rather not go into this yet though, because I'm not familiar with
jailtime.org images, and how you create them can make "best way to
create initrd" differ.

Regards,

Fajar

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.