FW: [Xen-ia64-devel] Add ptc.l emulation for 2.6.17 xenlinux to fixfederon-xen-ia64 boot
by Yang, Fred
Re-forwared to this correct miling list
-----Original Message-----
From: xen-ia64-devel-bounces(a)lists.xensource.com
[mailto:xen-ia64-devel-bounces@lists.xensource.com] On Behalf Of Zhang,
Xiantao
Sent: Wednesday, May 24, 2006 4:26 AM
To: xen-ia64-devel(a)lists.xensource.com; fedora-ia64-list(a)redhat.com
Subject: [Xen-ia64-devel] Add ptc.l emulation for 2.6.17 xenlinux to
fixfederon-xen-ia64 boot
This patch adds support for ptc.l emulation. In 2.6.16 kernel
flush_tlb_range will call global_tlb_purge directly, so ptc.l shouldn't
be used when CONFIG_SMP enable.
But in order to enhance performance (maybe), 2.6.17 kernel in smp
environment
will do mm check first. If mm is current->active_mm and the mm
(corresponding process) just runs on the local processor, kernel only
needs to do ptc.l at local processor instead of global purge. So ptc.l
emulation is necessary for 2.6.17 kernel.
Hi Aron,
With this patch, federon-xen-ia64 with rhel4-u2 can boot to "switch to
new root". Seems this error is related to FC6 OS, due to lack of FC6 at
hand, we couldn't try to boot it on FC6. Anyway, this patch is a must
for boot 2.6.17 kernel.
In addition, I attached the boot log, anyone can help to try on FC6 with
this patch?
Thanks
-Xiantao
18 years, 1 month
FW: [Xen-ia64-devel] Add ptc.l emulation for 2.6.17 xenlinux to fixfederon-xen-ia64 boot
by Yang, Fred
Forward to the correct mail list
-----Original Message-----
From: Zhang, Xiantao
Sent: Wednesday, May 24, 2006 6:59 AM
Subject: RE: [Xen-ia64-devel] Add ptc.l emulation for 2.6.17 xenlinux to
fixfederon-xen-ia64 boot
After many times' try, I think the main issue is the initrd
which created for booting FC6 couldn't match with rhel4-u2. Maybe their
module format is different. I think we should set up FC6 environment to
try next step. If so, I think debugging work maybe easier :)
> >> -----Original Message-----
> >> From: xen-ia64-devel-bounces(a)lists.xensource.com
> >> [mailto:xen-ia64-devel-bounces@lists.xensource.com] On
> >Behalf Of Zhang,
> >> Xiantao
> >> Sent: Wednesday, May 24, 2006 4:26 AM
> >> To: xen-ia64-devel(a)lists.xensource.com; fedora-ia64-list(a)redhat.com
> >> Subject: [Xen-ia64-devel] Add ptc.l emulation for 2.6.17 xenlinux
to
> >> fixfederon-xen-ia64 boot
> >>
> >> This patch adds support for ptc.l emulation. In 2.6.16 kernel
> >> flush_tlb_range will call global_tlb_purge directly, so
> >ptc.l shouldn't
> >> be used when CONFIG_SMP enable.
> >> But in order to enhance performance (maybe), 2.6.17 kernel in smp
> >> environment
> >> will do mm check first. If mm is current->active_mm and the mm
> >> (corresponding process) just runs on the local processor, kernel
only
> >> needs to do ptc.l at local processor instead of global
> >purge. So ptc.l
> >> emulation is necessary for 2.6.17 kernel.
> >>
> >> Hi Aron,
> >> With this patch, federon-xen-ia64 with rhel4-u2 can boot to
> >"switch to
> >> new root". Seems this error is related to FC6 OS, due to
> >lack of FC6 at
> >> hand, we couldn't try to boot it on FC6. Anyway, this patch is a
must
> >> for boot 2.6.17 kernel.
> >> In addition, I attached the boot log, anyone can help to try
> >on FC6 with
> >> this patch?
> >>
> >> Thanks
> >> -Xiantao
> >
> >
18 years, 1 month
expected disk performance?
by Ben
Today I upgraded to the new xen and kernel packages that just came
out, as I'd been looking forward to all the IO cleanup supposedly in
xen 3.0.2. Imagine my disappointment when I found out that my domU's
virtual disks still seem to be throttled at around 2MB/s sustain
writes for some reason. My dom0 is "much" better at ~14MB/s sustained
writes.
Is this what other people are seeing? It's painful.
18 years, 1 month
FW: [Xen-ia64-devel] Add ptc.l emulation for 2.6.17 xenlinux to fixfederon-xen-ia64 boot
by Yang, Fred
Forwared to this correct miling list
-----Original Message-----
From: xen-ia64-devel-bounces(a)lists.xensource.com
[mailto:xen-ia64-devel-bounces@lists.xensource.com] On Behalf Of Zhang,
Xiantao
Sent: Wednesday, May 24, 2006 4:26 AM
To: xen-ia64-devel(a)lists.xensource.com; fedora-ia64-list(a)redhat.com
Subject: [Xen-ia64-devel] Add ptc.l emulation for 2.6.17 xenlinux to
fixfederon-xen-ia64 boot
This patch adds support for ptc.l emulation. In 2.6.16 kernel
flush_tlb_range will call global_tlb_purge directly, so ptc.l shouldn't
be used when CONFIG_SMP enable.
But in order to enhance performance (maybe), 2.6.17 kernel in smp
environment
will do mm check first. If mm is current->active_mm and the mm
(corresponding process) just runs on the local processor, kernel only
needs to do ptc.l at local processor instead of global purge. So ptc.l
emulation is necessary for 2.6.17 kernel.
Hi Aron,
With this patch, federon-xen-ia64 with rhel4-u2 can boot to "switch to
new root". Seems this error is related to FC6 OS, due to lack of FC6 at
hand, we couldn't try to boot it on FC6. Anyway, this patch is a must
for boot 2.6.17 kernel.
In addition, I attached the boot log, anyone can help to try on FC6 with
this patch?
Thanks
-Xiantao
18 years, 1 month
Kickstart FC5 on FC5 (xen3.0.20.FC5.3 with kernel-xen0-2.6.16-1.2096_FC5) -> CPU0 FATAL TRAP 6
by Thomas von Steiger
Hello,
Last Night I try to kickstart fc5 guest on fc5 dom0 latest yum update and I
get a CPU0 FATAL TRAP 6.
The installation interruptps something by 50%...maybe it was to point where
the screensaver goes active ?
(XEN) (GUEST: 21) VMX go ...
(XEN) (GUEST: 21) VMXAssist (May 22 2006)
(XEN) (GUEST: 21) Memory size 256 MB
(XEN) (GUEST: 21) E820 map:
(XEN) (GUEST: 21) 0000000000000000 - 000000000009F800 (RAM)
(XEN) (GUEST: 21) 000000000009F800 - 00000000000A0000 (Reserved)
(XEN) (GUEST: 21) 00000000000A0000 - 00000000000C0000 (Type 16)
(XEN) (GUEST: 21) 00000000000F0000 - 0000000000100000 (Reserved)
(XEN) (GUEST: 21) 0000000000100000 - 000000000FFFE000 (RAM)
(XEN) (GUEST: 21) 000000000FFFE000 - 000000000FFFF000 (Type 18)
(XEN) (GUEST: 21) 000000000FFFF000 - 0000000010000000 (Type 17)
(XEN) (GUEST: 21) 0000000010000000 - 0000000010003000 (ACPI NVS)
(XEN) (GUEST: 21) 0000000010003000 - 000000001000D000 (ACPI Data)
(XEN) (GUEST: 21) 00000000FEC00000 - 0000000100000000 (Type 16)
(XEN) (GUEST: 21)
(XEN) (GUEST: 21) Start BIOS ...
(XEN) (GUEST: 21) Starting emulated 16-bit real-mode: ip=F000:FFF0
(XEN) (GUEST: 21) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
(XEN) HVM_PIT: guest freq in cycles=150013073
(XEN) (GUEST: 21) Remapping master: ICW2 0x8 -> 0x20
(XEN) (GUEST: 21) Remapping slave: ICW2 0x70 -> 0x28
(XEN) (GUEST: 21) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert
Exp $
(XEN) (GUEST: 21) HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date:
2005/05/07 15:55:26 $
(XEN) (GUEST: 21)
(XEN) (GUEST: 21) ata0-0: PCHS=12483/16/63 translation=lba LCHS=783/255/63
(XEN) (GUEST: 21) ata0 master: QEMU HARDDISK ATA-2 Hard-Disk (6144 MBytes)
(XEN) (GUEST: 21) ata0 slave: Unknown device
(XEN) (GUEST: 21) ata1 master: QEMU CD-ROM ATAPI-4 CD-Rom/DVD-Rom
(XEN) (GUEST: 21) ata1 slave: Unknown device
(XEN) (GUEST: 21)
(XEN) (GUEST: 21) Booting from CD-Rom...
(XEN) (GUEST: 21) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 21) KBD: unsupported int 16h function 03
(XEN) (GUEST: 21) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 21) int13_harddisk: function 02, unmapped device for ELDL=81
(XEN) (GUEST: 21) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) HVM_PIT: guest freq in cycles=12001749
(XEN) Assertion '(sp == 0) || (pending_eoi[cpu][sp-1].vector < vector)'
failed, line 189, file irq.c
(XEN) BUG at irq.c:189
(XEN) (file=extable.c, line=77) Pre-exception: ff13173f -> 00000000
(XEN) ----[ Xen-3.0.2-2 Not tainted ]----
(XEN) CPU: 0
(XEN) EIP: e008:[<ff13173f>] __do_IRQ_guest+0x192/0x2af
(XEN) EFLAGS: 00010086 CONTEXT: hypervisor
(XEN) eax: ff1a7138 ebx: ff117d4b ecx: 00004001 edx: 00009117
(XEN) esi: 00005305 edi: 00000000 ebp: ff1b9eac esp: ff1b9e74
(XEN) cr0: 8005003b cr3: 204ab000
(XEN) ds: e010 es: e010 fs: e010 gs: e010 ss: e010 cs: e008
(XEN) Xen stack trace from esp=ff1b9e74:
(XEN) ff197519 ff197527 000000bd ff197527 ffbfee80 00000001 00000013
ff1d2d00
(XEN) ffbb5280 ffffffff ff1b9ebc 00000001 00000000 ff117d4b ff1b9edc
ff131250
(XEN) 000000b0 00000000 ff1b9edc ff11cfc7 00000000 00000000 000000b0
ff1d2d00
(XEN) ff1c3680 ff117d4b 00e46103 ff12cdd5 ff1b9ee8 ff117d4b 00000003
ffbbb204
(XEN) 00005305 00000000 ff1b9f7c 00000000 00b00000 ff11b6b1 0000e008
00000246
(XEN) ff1c1100 ffbbb204 6e8e58f7 0000371f 00000000 00000000 ff1b9f5c
ff13125e
(XEN) ff1d2d10 0000371f 00000001 00000001 6e94e3b3 0000371f ffbbb180
0007a120
(XEN) 00000000 ffb1b080 ffbbb180 00000000 6e8e58f7 0000371f 00000000
0007a120
(XEN) 00005305 ffb1b080 ff1b9fac ff11bb79 00000001 ff1c2500 0000e008
00000282
(XEN) ff1b9fac ff17e171 00000002 00000001 00000000 00000002 00000000
ff17e376
(XEN) 00000000 00000000 00005305 00005305 00000000 00000000 c03b9fd8
00880000
(XEN) 0000acf9 00fc0000 00000000 0000e008 00000202 0000007b 0000007b
00000000
(XEN) 00000000 00000000 ffb1b080
(XEN) Xen call trace:
(XEN) [<ff13173f>] __do_IRQ_guest+0x192/0x2af
(XEN) [<ff131250>] do_IRQ+0x58/0x18e
(XEN) [<ff12cdd5>] common_interrupt+0x45/0x50
(XEN) [<ff11b6b1>] __enter_scheduler+0x3d8/0x48c
(XEN) [<ff11bb79>] do_softirq+0xa1/0xb8
(XEN)
(XEN) ************************************
(XEN) CPU0 FATAL TRAP 6 (invalid opcode), ERROR_CODE 0000, IN INTERRUPT
CONTEXT.
(XEN) System shutting down -- need manual reset.
(XEN) ************************************
18 years, 1 month
fedora-xen-ia64 first pass
by Aron Griffis
Hello,
I've made a first pass at modifying the Fedora Rawhide xen and kernel
rpms to support ia64. There is still a lot of work to do before this
would be suitable for inclusion in Fedora, but hopefully this
represents a proof-of-concept that can be improved to that point.
If you'd like to browse or contribute, the bits are available as
mercurial repositories at:
http://free.linux.hp.com/~agriffis/
There are 5 repositories presently:
fedora-xen-rpm Tracks xen.src.rpm from rawhide.
fedora-xen-ia64 Pulls from fedora-xen-rpm, contains
(trivial) modifications for ia64
fedora-kernel-rpm Tracks kernel.src.rpm from rawhide.
fedora-kernel-ia64 Pulls from fedora-kernel-rpm, contains
modifications for ia64
xen-ia64-unstable-2.6.17 Forward port of xen-ia64-unstable
sparse tree from 2.6.16.13 to 2.6.17,
generates linux-2.6-xen.patch for
fedora-kernel-ia64
Here is my non-comprehensive list of notes/issues for
fedora-kernel-ia64:
1. Upstream xen is presently based on 2.6.16.13. Fedora kernel is (or
was yesterday) based on 2.6.17-rc4-git5. To port xen forward, the
most maintainable method seems to be to do the port in the context
of a xen-ia64-unstable mercurial clone (xen-ia64-unstable-2.6.17
above). Using this method makes it relatively easy to:
(a) port forward to a new kernel at any time using the
sparse-merge script
(b) pull new changes from upstream xen and avoid most manual
merging
(c) extract a patch at any time that represents the forward-port
of xen to a new kernel
(d) generate a patch at any time that adds xen support to the
fedora kernel (linux-2.6-xen.patch generated with "make
mkpatches")
The only caveat here is that I probably didn't do the forward port
perfectly. In particular I know I bungled the TPM stuff because
there are lots of changes going into kernel.org and xen
simultaneously. Additionally I didn't pay a lot of attention to
other architectures for the moment.
Hopefully 2.6.17 will pop any day now, then xen upstream will move
to it, and we won't have to carry the forward port in the Fedora
patch. If by some chance this doesn't happen, then my forward
porting work will need to be revisited.
2. This first pass was created using the xen-ia64-unstable repo
instead of the xen-unstable repo. This is because xen-unstable is
broken recently on ia64. When the two have been resynced upstream,
and xen-unstable works on ia64, we should move this prototype to
using xen-unstable (which is what the current Fedora Xen patch is
based on).
3. The bare metal config is built for Generic. The xen0 and xenU
configs are built for DIG-Compliant. It seems that the kernel
won't build for Generic with CONFIG_XEN enabled. Using
DIG-compliant for the xen kernels is probably okay for now, but it
would be good to get Generic building.
4. After applying patch700 (linux-2.6-xen.patch), the spec file
executes xen-mkbuildtree-pre if it exists for the architecture.
In effect, this is applying an ia64-specific patch, even though it
looks more generic in the spec. The special modifications being
made by xen-mkbuildtree-pre need to be folded into
linux-2.6-xen.patch to prevent architecture-specific maintenance
headaches in the stack of Fedora kernel patches.
5. My forward port broke the exec-shield patch application. Juan has
this resolved in his version, but that's based on an older
xen-unstable changeset. I commented out patch810-812 for the
moment.
6. The xen patch is missing some function prototypes. (I believe this
is a problem in xen upstream not something introduced by my port.)
The Fedora kernel build normally turns on
-Werror-implicit-function-declaration in patch1018
(linux-2.6-debug-Wundef.patch). I commented out this patch for the
moment.
7. The hypervisor doesn't build on ia64 with "debug=y verbose=y
crash_debug=y". For the moment it builds with default flags on
ia64 instead.
8. /sbin/new-kernel-pkg doesn't handle installation of the hypervisor
to the EFI partition. This should be a trivial fix.
9. Various other rpms need trivial updates to build/install on ia64,
for example libvirt.
10. Anaconda needs updates to handle installation of xen on ia64
(interaction with elilo, etc)
11. After finally getting a full build, I tested it once on my rx2620.
The hypervisor booted, but the console didn't get hooked up for
xen0, and eventually the machine reset. Hopefully these are
trivial configuration or elilo.conf updates, but there may be more
work involved.
If you'd like to build these rpms for yourself, here's the quick and
dirty guide (thanks Anil):
hg clone http://free.linux.hp.com/~agriffis/fedora-kernel-ia64
# or http://free.linux.hp.com/~agriffis/fedora-xen-ia64
cd fedora-kernel-ia64
mkdir -p BUILD RPMS/ia64
source bashrc-snippet # might want this in your ~/.bashrc
cd SPECS
rpmbuild -ba kernel-2.6.spec
Regards,
Aron
18 years, 1 month
Re: Heads-up: Requiring PAE for running Xen
by Avi Kivity
Dimi Paun wrote:
> On Mon, 2006-05-22 at 18:24 +0300, Avi Kivity wrote:
>
>> How do you migrate your storage?
>>
>
> You don't just copy it blindly, you can synch it
> differentially, via something like rsync for example.
> I'm sure you can do even better with a special
> filesystem that can track what changed since last
> synch.
>
Well, you could have the desktop and laptop in a raid-1 over nbd with a
write intent bitmap, so that only changed blocks are copied. Seems like
everything is in place for that.
--
error compiling committee.c: too many arguments to function
18 years, 1 month
RE: [Fedora-xen] fedora-xen-ia64 first pass
by Zhang, Xiantao
Hi, Aron
We have tried to boot xen with your tip, but found the configuration for domain0 opens dom0_VP mode, however, the dom0_VP option of xen was closed by default. Maybe this is the main reason why xen dies at booting xen0. Correct?
If they don't match, it is impossible to boot up. Due to not familiar with rpmbuild scripts, so we have to modify it manually to try.
Thanks
-Xiantao
> -----Original Message-----
> From: fedora-xen-bounces(a)redhat.com [mailto:fedora-xen-bounces@redhat.com]
> On Behalf Of Aron Griffis
> Sent: 2006年5月21日 3:35
> To: fedora-xen(a)redhat.com; fedora-ia64-list(a)redhat.com
> Cc: xen-ia64-devel(a)lists.xensource.com
> Subject: [Fedora-xen] fedora-xen-ia64 first pass
>
> Hello,
>
> I've made a first pass at modifying the Fedora Rawhide xen and kernel
> rpms to support ia64. There is still a lot of work to do before this
> would be suitable for inclusion in Fedora, but hopefully this
> represents a proof-of-concept that can be improved to that point.
>
> If you'd like to browse or contribute, the bits are available as
> mercurial repositories at:
>
> http://free.linux.hp.com/~agriffis/
>
> There are 5 repositories presently:
>
> fedora-xen-rpm Tracks xen.src.rpm from rawhide.
>
> fedora-xen-ia64 Pulls from fedora-xen-rpm, contains
> (trivial) modifications for ia64
>
> fedora-kernel-rpm Tracks kernel.src.rpm from rawhide.
>
> fedora-kernel-ia64 Pulls from fedora-kernel-rpm, contains
> modifications for ia64
>
> xen-ia64-unstable-2.6.17 Forward port of xen-ia64-unstable
> sparse tree from 2.6.16.13 to 2.6.17,
> generates linux-2.6-xen.patch for
> fedora-kernel-ia64
>
> Here is my non-comprehensive list of notes/issues for
> fedora-kernel-ia64:
>
> 1. Upstream xen is presently based on 2.6.16.13. Fedora kernel is (or
> was yesterday) based on 2.6.17-rc4-git5. To port xen forward, the
> most maintainable method seems to be to do the port in the context
> of a xen-ia64-unstable mercurial clone (xen-ia64-unstable-2.6.17
> above). Using this method makes it relatively easy to:
>
> (a) port forward to a new kernel at any time using the
> sparse-merge script
>
> (b) pull new changes from upstream xen and avoid most manual
> merging
>
> (c) extract a patch at any time that represents the forward-port
> of xen to a new kernel
>
> (d) generate a patch at any time that adds xen support to the
> fedora kernel (linux-2.6-xen.patch generated with "make
> mkpatches")
>
> The only caveat here is that I probably didn't do the forward port
> perfectly. In particular I know I bungled the TPM stuff because
> there are lots of changes going into kernel.org and xen
> simultaneously. Additionally I didn't pay a lot of attention to
> other architectures for the moment.
>
> Hopefully 2.6.17 will pop any day now, then xen upstream will move
> to it, and we won't have to carry the forward port in the Fedora
> patch. If by some chance this doesn't happen, then my forward
> porting work will need to be revisited.
>
> 2. This first pass was created using the xen-ia64-unstable repo
> instead of the xen-unstable repo. This is because xen-unstable is
> broken recently on ia64. When the two have been resynced upstream,
> and xen-unstable works on ia64, we should move this prototype to
> using xen-unstable (which is what the current Fedora Xen patch is
> based on).
>
> 3. The bare metal config is built for Generic. The xen0 and xenU
> configs are built for DIG-Compliant. It seems that the kernel
> won't build for Generic with CONFIG_XEN enabled. Using
> DIG-compliant for the xen kernels is probably okay for now, but it
> would be good to get Generic building.
>
> 4. After applying patch700 (linux-2.6-xen.patch), the spec file
> executes xen-mkbuildtree-pre if it exists for the architecture.
> In effect, this is applying an ia64-specific patch, even though it
> looks more generic in the spec. The special modifications being
> made by xen-mkbuildtree-pre need to be folded into
> linux-2.6-xen.patch to prevent architecture-specific maintenance
> headaches in the stack of Fedora kernel patches.
>
> 5. My forward port broke the exec-shield patch application. Juan has
> this resolved in his version, but that's based on an older
> xen-unstable changeset. I commented out patch810-812 for the
> moment.
>
> 6. The xen patch is missing some function prototypes. (I believe this
> is a problem in xen upstream not something introduced by my port.)
> The Fedora kernel build normally turns on
> -Werror-implicit-function-declaration in patch1018
> (linux-2.6-debug-Wundef.patch). I commented out this patch for the
> moment.
>
> 7. The hypervisor doesn't build on ia64 with "debug=y verbose=y
> crash_debug=y". For the moment it builds with default flags on
> ia64 instead.
>
> 8. /sbin/new-kernel-pkg doesn't handle installation of the hypervisor
> to the EFI partition. This should be a trivial fix.
>
> 9. Various other rpms need trivial updates to build/install on ia64,
> for example libvirt.
>
> 10. Anaconda needs updates to handle installation of xen on ia64
> (interaction with elilo, etc)
>
> 11. After finally getting a full build, I tested it once on my rx2620.
> The hypervisor booted, but the console didn't get hooked up for
> xen0, and eventually the machine reset. Hopefully these are
> trivial configuration or elilo.conf updates, but there may be more
> work involved.
>
> If you'd like to build these rpms for yourself, here's the quick and
> dirty guide (thanks Anil):
>
> hg clone http://free.linux.hp.com/~agriffis/fedora-kernel-ia64
> # or http://free.linux.hp.com/~agriffis/fedora-xen-ia64
> cd fedora-kernel-ia64
> mkdir -p BUILD RPMS/ia64
> source bashrc-snippet # might want this in your ~/.bashrc
> cd SPECS
> rpmbuild -ba kernel-2.6.spec
>
> Regards,
> Aron
>
> --
> Fedora-xen mailing list
> Fedora-xen(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-xen
18 years, 1 month
Re: fedora-xen-ia64 first pass
by Aron Griffis
Let's consolidate this thread to the fedora-xen mailing list rather
than continuing to cross-post as I did initially. We can post patches
and requests back to the other lists as help is needed from those
communities.
Regards,
Aron
18 years, 1 month
Re: [Fedora-xen] Adding more space to the system withou using LVM in the host
by Ignacio Verona
Thanks Kwan,
I'll try that tomorrow.
Regards,
Ignacio.
Kwan Lowe escribió:
>> Hi,
>>
>> I've a few Virtual Machines running FC5, the host is also FC5. I want to
>> add some hd space to one of the VMs, and as they are using LVM, I think
>> it shouldn't be so difficult. This is the line configuring the harddisk
>> for the Xen VM:
>>
>> disk = [ 'file:/mnt/md0/xenM/autillo/autillo1,xvda,w' ]
>>
>> How do add other xvda? I want to create, for example
>> /mnt/md0/xenM/autillo/autillo2 and add that space to the LVM in the VM.
>> How should I do this? Maybe the solution is to export autillo2 as
>> /dev/hdX or /dev/sdX?
>>
>> How should I format the file using mke2fs? Thanks a lot and sorry if the
>> questions are easy to solve, but I'm still not clear about that things!
>>
>
> Easiest way is to use dd to create a blank file in ./autillo. E.g.:
>
> dd if=/dev/zero of=autillo2 count=1024 bs=1M
>
> Then, edit the configuration and add the new disk:
>
> disk = [ 'file:/mnt/md0/xenM/autillo/autillo1,xvda,w', \
> 'file:/mnt/md0/xenM/autillo/autillo2,xvdb,w' ]
>
> You need to shutdown then restart the domU at that point (xm restart on the domU
> doesn't seem to pick up the new disk).
>
> >From the domU, you should then be able to see a new disk ("dmesg |grep xvdb"). Use
> fdisk to partition it as an 8e partition. Write the new table. Run pvcreate against
> /dev/xvdb1. Then vgextend the new PVs into your existing volume group.
>
18 years, 1 month
