Eredicator X wrote:
> ----- "Fajar A. Nugraha" <fajar@xxxxxxxxx> wrote:
>
>
>> I don't think that's true.
>> When using virt-install, the LV will be treated as a whole disk. Thus
>> it
>> may have partitions, or even PV/LV inside it.
>>
>
> Yes it does and that is what I was using kpart for.
>
>
I must've missed your post about using kpartx.
>> I'd actually suggest one of the followings :
>> - startup domU, setup nfs, have dom0 mount domU's share, or
>> - reinstall domU with virt-install, choose partitioning setup (not
>> LVM)
>> on domU, or
>>
>
> These are just test machines so reinstalling is not a issue.
> My true end goal is to clone a guest, make a script that mounts it changes
> some parameters like IP and Users etc. Unmounts it and starts it. Simple down
> and dirty provisioning.
>
> Simple goal. Painful execution.
>
>
Depends. I'll tell you how to do it easily at the end of this email :D
>> - reinstall domU WITHOUT virt-install, use LVS on dom0 directly as
>> filesystem on domU (e.g. no more partioning or LVM on domU). This is
>> not
>> possible using anaconda, thus have to be done manually.
>>
>
> Not sure I follow you on this one.
>
>
Read on, comments below.
>> - learn how to use kpartx, pvscan, and vgscan, and hope you don't
>> have
>> conflicting VG names.
>>
>>
>
> This is what I am currently trying to do.
>
>
>
Okay. From your post, I gather that /dev/xen-system/test01.max is LV on
dom0 used for domU's disk.
I don't see you using kpartx.
If fdisk -l says
# Device Boot Start End Blocks Id System
#test01.max1 * 63 208844 104391 83 Linux
#test01.max2 208845 20964824 10377990 8e Linux LVM
Then running "kpartx -av /dev/xen-system/test01.max" should create
/dev/mapper/test01.max1 and /dev/mapper/test01.max2 (or something similar).
/dev/mapper/test01.max1 -> domU's /boot
/dev/mapper/test01.max2 -> domU's PV
You can mount /dev/mapper/test01.max1 to get domU's /boot, but to get
domU's "/" you need to do more. After you get /dev/mapper/test01.max2,
try running pvscan and vgscan again and pray that you get a new VG. That
would be domU's VG.
IMHO, the steps above are painful. So I'd suggest that you reinstall
using only one partition (/) WITHOUT LVM, WITHOUT SWAP. If you don't
have enough memory and absolutely need swap, use another LV on dom0 for
that (in other words, domU will have two disks : one for /, one for
swap). This way, you don't need vgscan (and don't have to worry about
conflicting VG names) anymore. You simply need fdisk and kpartx (for
both the working domU and the new domU).
There is another method which uses dom0's LV directly as domU's fs.
Assuming you have succesfully mount a working domU, you can do something
like this :
- create two new LV's on dom0 : /dev/xen-system/test03root and
/dev/xen-system/test03swap
- mkfs.ext3 /dev/xen-system/test03root
- mkswap /dev/xen-system/test03swap
- mount /dev/xen-system/test03root somewhere
- copy all files from the working domU (including /boot) with either
rsync -av, cp -av, or tar (I like tar better)
- adjust new domU's config file to look like this
memory = "2000"
disk = [
'phy:/dev/xen-system/test03root,xvda1,w',
'phy:/dev/xen-system/test03swap,xvda2,w',
]
Note the difference : it's xvda1 and xvda2, NOT xvda and xvdb.
you can use either hda1/2, sda1/2, or xvda1/2. xvda is probably best on
Centos.
- edit new domU's fstab to use xvda1 as "/" and xvda2 as swap
- unmount new domU's fs
- startup new domU
- create an archive (tar.gz or something) of the original domU. That
way, subsequent domU's only need to extract from that archive.
This way you don't need fdisk, kpartx, or pv/vgscan to create another domU.
Regards,
Fajar
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home