Xen users - Sep 2009 - Creating a paravirtualized guest with Xen 3.4.1 and Centos 5.3 (64bit)

Hi,

I have a set of 32bit HVM images running fine under Xen 3.2.1 and Xen 3.4.1. Due
to performance issues with the fully virtualized setup, I would like to migrate
one of those images to a paravirtualized image to compare the network
performance. As I do not have a Xen-aware kernel for that VM, I thought the best
would be to provide one from outside.

Sounds like an easy task, doesn''t it? ;-)

However, I fail miserably on this task. It just does not work. To get rid of any
side effects, I thought it would be nice to try with a known-working image.

Therefore I got the image Centos 5.3 image from
http://stacklet.com/downloads/images/centos/5.3. And voila, using the pygrub
version works like a charm - I can either log in using xm console, or ssh. This
is the config used:

bootloader = "/usr/bin/pygrub"
memory = 256
name = "centos_pygrub"
vif = [ ''bridge=eth0,mac=02:00:00:00:01:86''  ]
disk = [''file:image,sda1,w'']
root = "/dev/sda1"
extra = "fastboot"

Now, as this kernel appears to be working fine, I thought I''d like to
just take this kernel and initrd out of the known-good vm, and give it to Xen as
parameters. In my naive thinking, this should be the very same as pygrub is
doing - loading the kernel specified in /boot/grub.conf with initrd and
parameters (all taken from the VM running fine with pygrub):

kernel = "vmlinuz"
initrd = "initrd"
extra = "console=xvc0"
root = "/dev/sda1"
memory = 256
name = "centos_pv"
vif = [ ''bridge=eth0,mac=02:00:00:00:01:86''  ]
disk = [''file:image,sda1,w'']

BUT - this fails! The last lines on the command line are:

XENBUS: Device with no driver: device/vbd/2048
XENBUS: Device with no driver: device/vif/0
XENBUS: Device with no driver: device/console/0
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
VFS: Cannot open root device "sda1" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

The only obvious difference compared to the previous VM is the line stating
"md: autodetecting RAID arrays.". But why should this very same
kernel, that initializes fine when using pygrub, now start setting up raid
configs? I don''t seem to get it, so I really appreciate some help here,
I already spent too long debugging this, I have no idea what goes wrong here.
Does my host config have anything to do with it (yes, it has a raid)? But if
yes, why would it? I did not build the initrd image myself, it''s the
one taken from the VM which booted fine using pygrub...

Thanks a lot!

Regards,
Martin

P.S.: The Xen log does not show any error at all, only reports the VM having
crashed.
P.P.S.: When I get this running (there''s still hope left...), I would
like to understand what''s the best option to provide a disk - is it
tap:aio, or file? Any documentation on reasons to choose either the one or the
other?
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/


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

I think your problem is the lack of xenblk/xennet drivers. Try `cp -pr 
/lib/modules` to your target VM. I think then you''ll be able to boot.

-Andrew

Martin Tröster wrote:
> Hi,
>
> I have a set of 32bit HVM images running fine under Xen 3.2.1 and Xen
3.4.1. Due to performance issues with the fully virtualized setup, I would like
to migrate one of those images to a paravirtualized image to compare the network
performance. As I do not have a Xen-aware kernel for that VM, I thought the best
would be to provide one from outside.
>
> Sounds like an easy task, doesn''t it? ;-)
>
> However, I fail miserably on this task. It just does not work. To get rid
of any side effects, I thought it would be nice to try with a known-working
image.
>
> Therefore I got the image Centos 5.3 image from
http://stacklet.com/downloads/images/centos/5.3. And voila, using the pygrub
version works like a charm - I can either log in using xm console, or ssh. This
is the config used:
>
> bootloader = "/usr/bin/pygrub"
> memory = 256
> name = "centos_pygrub"
> vif = [ ''bridge=eth0,mac=02:00:00:00:01:86''  ]
> disk = [''file:image,sda1,w'']
> root = "/dev/sda1"
> extra = "fastboot"
>
> Now, as this kernel appears to be working fine, I thought I''d like
to just take this kernel and initrd out of the known-good vm, and give it to Xen
as parameters. In my naive thinking, this should be the very same as pygrub is
doing - loading the kernel specified in /boot/grub.conf with initrd and
parameters (all taken from the VM running fine with pygrub):
>
> kernel = "vmlinuz"
> initrd = "initrd"
> extra = "console=xvc0"
> root = "/dev/sda1"
> memory = 256
> name = "centos_pv"
> vif = [ ''bridge=eth0,mac=02:00:00:00:01:86''  ]
> disk = [''file:image,sda1,w'']
>
> BUT - this fails! The last lines on the command line are:
>
> XENBUS: Device with no driver: device/vbd/2048
> XENBUS: Device with no driver: device/vif/0
> XENBUS: Device with no driver: device/console/0
> md: Autodetecting RAID arrays.
> md: autorun ...
> md: ... autorun DONE.
> VFS: Cannot open root device "sda1" or unknown-block(0,0)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
>
> The only obvious difference compared to the previous VM is the line stating
"md: autodetecting RAID arrays.". But why should this very same
kernel, that initializes fine when using pygrub, now start setting up raid
configs? I don''t seem to get it, so I really appreciate some help here,
I already spent too long debugging this, I have no idea what goes wrong here.
Does my host config have anything to do with it (yes, it has a raid)? But if
yes, why would it? I did not build the initrd image myself, it''s the
one taken from the VM which booted fine using pygrub...
>
> Thanks a lot!
>
> Regards,
> Martin
>
> P.S.: The Xen log does not show any error at all, only reports the VM
having crashed.
> P.P.S.: When I get this running (there''s still hope left...), I
would like to understand what''s the best option to provide a disk - is
it tap:aio, or file? Any documentation on reasons to choose either the one or
the other?
> ________________________________________________________________
> Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
> für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>   

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

Hi Andrew,

thanks for your quick response here. But no, that solution would be too 
easy... Maybe I expressed myself not clear enough in the first note - 
the very same VM runs fine using pygrub, but fails using 
"kernel","initrd","root" and "extras"
parameters in the cfg file...

So everything necessary should be in the image. I doublechecked, and can 
confirm xennet and xenblk are both in /lib/modules and (probably more 
important) initrd. But it must be something like this, I just don''t 
understand why and where to look... Maybe someone can clarify what''s 
going on differently between using pygrub (this boots the disk-internal 
kernel and initrd, at least that''s what I''m thinking) and
moving the
internal kernel and initrd outside, and using the very same command 
lines? Is there anything special automatically appended to the kernel 
parameters specified in /boot/grub/grub.conf via pygrub?

Is there a way to force kernel output to tell me which modules are 
loaded in which order during boot? I don''t find enough on the kernel 
messages output...

Thanks again,
Martin

Andrew Evans wrote:
> I think your problem is the lack of xenblk/xennet drivers. Try `cp -pr 
> /lib/modules` to your target VM. I think then you''ll be able to
boot.
> 
> -Andrew
> 
> Martin Tröster wrote:
>> Hi,
>>
>> I have a set of 32bit HVM images running fine under Xen 3.2.1 and Xen 
>> 3.4.1. Due to performance issues with the fully virtualized setup, I 
>> would like to migrate one of those images to a paravirtualized image 
>> to compare the network performance. As I do not have a Xen-aware 
>> kernel for that VM, I thought the best would be to provide one from 
>> outside.
>>
>> Sounds like an easy task, doesn''t it? ;-)
>>
>> However, I fail miserably on this task. It just does not work. To get 
>> rid of any side effects, I thought it would be nice to try with a 
>> known-working image.
>>
>> Therefore I got the image Centos 5.3 image from 
>> http://stacklet.com/downloads/images/centos/5.3. And voila, using the 
>> pygrub version works like a charm - I can either log in using xm 
>> console, or ssh. This is the config used:
>>
>> bootloader = "/usr/bin/pygrub"
>> memory = 256
>> name = "centos_pygrub"
>> vif = [ ''bridge=eth0,mac=02:00:00:00:01:86''  ]
>> disk = [''file:image,sda1,w'']
>> root = "/dev/sda1"
>> extra = "fastboot"
>>
>> Now, as this kernel appears to be working fine, I thought I''d
like to
>> just take this kernel and initrd out of the known-good vm, and give it 
>> to Xen as parameters. In my naive thinking, this should be the very 
>> same as pygrub is doing - loading the kernel specified in 
>> /boot/grub.conf with initrd and parameters (all taken from the VM 
>> running fine with pygrub):
>>
>> kernel = "vmlinuz"
>> initrd = "initrd"
>> extra = "console=xvc0"
>> root = "/dev/sda1"
>> memory = 256
>> name = "centos_pv"
>> vif = [ ''bridge=eth0,mac=02:00:00:00:01:86''  ]
>> disk = [''file:image,sda1,w'']
>>
>> BUT - this fails! The last lines on the command line are:
>>
>> XENBUS: Device with no driver: device/vbd/2048
>> XENBUS: Device with no driver: device/vif/0
>> XENBUS: Device with no driver: device/console/0
>> md: Autodetecting RAID arrays.
>> md: autorun ...
>> md: ... autorun DONE.
>> VFS: Cannot open root device "sda1" or unknown-block(0,0)
>> Please append a correct "root=" boot option
>> Kernel panic - not syncing: VFS: Unable to mount root fs on 
>> unknown-block(0,0)
>>
>> The only obvious difference compared to the previous VM is the line 
>> stating "md: autodetecting RAID arrays.". But why should this
very
>> same kernel, that initializes fine when using pygrub, now start 
>> setting up raid configs? I don''t seem to get it, so I really 
>> appreciate some help here, I already spent too long debugging this, I 
>> have no idea what goes wrong here. Does my host config have anything 
>> to do with it (yes, it has a raid)? But if yes, why would it? I did 
>> not build the initrd image myself, it''s the one taken from the
VM
>> which booted fine using pygrub...
>>
>> Thanks a lot!
>>
>> Regards,
>> Martin
>>
>> P.S.: The Xen log does not show any error at all, only reports the VM 
>> having crashed.
>> P.P.S.: When I get this running (there''s still hope left...),
I would
>> like to understand what''s the best option to provide a disk -
is it
>> tap:aio, or file? Any documentation on reasons to choose either the 
>> one or the other?
>> ________________________________________________________________
>> Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
>> für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/xen-users
>>   
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 

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

Andrew,

you are right. Looking into my settings again, I now realize that I just 
gave the wrong parameter to the config file. I used initr where I should 
have been using ramdisk. Arrrrrrgh.

So now my VM boots fine with the second config file as well. It works so 
easy if you do things right ;-)

Now I''ll find out if I can get my original problem solved, migrate the 
existing fully virtualized system to a paravirtualizded kernel. Let''s
see...

Thanks again for your support.

Regards,
Martin

Andrew Evans wrote:
> I think your problem is the lack of xenblk/xennet drivers. Try `cp -pr 
> /lib/modules` to your target VM. I think then you''ll be able to
boot.
> 
> -Andrew
> 
> Martin Tröster wrote:
>> Hi,
>>
>> I have a set of 32bit HVM images running fine under Xen 3.2.1 and Xen 
>> 3.4.1. Due to performance issues with the fully virtualized setup, I 
>> would like to migrate one of those images to a paravirtualized image 
>> to compare the network performance. As I do not have a Xen-aware 
>> kernel for that VM, I thought the best would be to provide one from 
>> outside.
>>
>> Sounds like an easy task, doesn''t it? ;-)
>>
>> However, I fail miserably on this task. It just does not work. To get 
>> rid of any side effects, I thought it would be nice to try with a 
>> known-working image.
>>
>> Therefore I got the image Centos 5.3 image from 
>> http://stacklet.com/downloads/images/centos/5.3. And voila, using the 
>> pygrub version works like a charm - I can either log in using xm 
>> console, or ssh. This is the config used:
>>
>> bootloader = "/usr/bin/pygrub"
>> memory = 256
>> name = "centos_pygrub"
>> vif = [ ''bridge=eth0,mac=02:00:00:00:01:86''  ]
>> disk = [''file:image,sda1,w'']
>> root = "/dev/sda1"
>> extra = "fastboot"
>>
>> Now, as this kernel appears to be working fine, I thought I''d
like to
>> just take this kernel and initrd out of the known-good vm, and give it 
>> to Xen as parameters. In my naive thinking, this should be the very 
>> same as pygrub is doing - loading the kernel specified in 
>> /boot/grub.conf with initrd and parameters (all taken from the VM 
>> running fine with pygrub):
>>
>> kernel = "vmlinuz"
>> initrd = "initrd"
>> extra = "console=xvc0"
>> root = "/dev/sda1"
>> memory = 256
>> name = "centos_pv"
>> vif = [ ''bridge=eth0,mac=02:00:00:00:01:86''  ]
>> disk = [''file:image,sda1,w'']
>>
>> BUT - this fails! The last lines on the command line are:
>>
>> XENBUS: Device with no driver: device/vbd/2048
>> XENBUS: Device with no driver: device/vif/0
>> XENBUS: Device with no driver: device/console/0
>> md: Autodetecting RAID arrays.
>> md: autorun ...
>> md: ... autorun DONE.
>> VFS: Cannot open root device "sda1" or unknown-block(0,0)
>> Please append a correct "root=" boot option
>> Kernel panic - not syncing: VFS: Unable to mount root fs on 
>> unknown-block(0,0)
>>
>> The only obvious difference compared to the previous VM is the line 
>> stating "md: autodetecting RAID arrays.". But why should this
very
>> same kernel, that initializes fine when using pygrub, now start 
>> setting up raid configs? I don''t seem to get it, so I really 
>> appreciate some help here, I already spent too long debugging this, I 
>> have no idea what goes wrong here. Does my host config have anything 
>> to do with it (yes, it has a raid)? But if yes, why would it? I did 
>> not build the initrd image myself, it''s the one taken from the
VM
>> which booted fine using pygrub...
>>
>> Thanks a lot!
>>
>> Regards,
>> Martin
>>
>> P.S.: The Xen log does not show any error at all, only reports the VM 
>> having crashed.
>> P.P.S.: When I get this running (there''s still hope left...),
I would
>> like to understand what''s the best option to provide a disk -
is it
>> tap:aio, or file? Any documentation on reasons to choose either the 
>> one or the other?
>> ________________________________________________________________
>> Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
>> für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/xen-users
>>   
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 

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

> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com [mailto:xen-users-
> bounces@lists.xensource.com] On Behalf Of Martin Troester
> Sent: Tuesday, September 22, 2009 4:17 PM
> To: xen-users@lists.xensource.com
> Subject: Re: [Xen-users] Creating a paravirtualized guest with Xen
3.4.1 andCentos
> 5.3 (64bit)
> 
> Now I''ll find out if I can get my original problem solved, migrate
the
> existing fully virtualized system to a paravirtualizded kernel.
Let''s
see...

It''s not exactly the same, but I have done physical-to-paravirt
migrations on CentOS 5.2 with little effort.  It''s probably easiest if
you install kernel-xen packages before you migrate:

1) yum install kernel-xen
2) shutdown
3) copy disk images to dom0
4) create domU config
5) start domU

Afterwards you can use either pygrub or kernel/ramdisk, whichever you
prefer.

-Jeff



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

You meen are it posible to first install a real e.g centos on a disk and
install kernel-xen and boot it with xen?

-----Ursprungligt meddelande-----
Från: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] För Jeff Sturm
Skickat: den 22 september 2009 23:02
Till: Martin Troester; xen-users@lists.xensource.com
Ämne: RE: [Xen-users] Creating a paravirtualized guest with Xen
3.4.1andCentos 5.3 (64bit)

> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com [mailto:xen-users- 
> bounces@lists.xensource.com] On Behalf Of Martin Troester
> Sent: Tuesday, September 22, 2009 4:17 PM
> To: xen-users@lists.xensource.com
> Subject: Re: [Xen-users] Creating a paravirtualized guest with Xen
3.4.1 andCentos
> 5.3 (64bit)
> 
> Now I''ll find out if I can get my original problem solved, migrate
the
> existing fully virtualized system to a paravirtualizded kernel.
Let''s
see...

It''s not exactly the same, but I have done physical-to-paravirt
migrations on CentOS 5.2 with little effort.  It''s probably easiest if
you install kernel-xen packages before you migrate:

1) yum install kernel-xen
2) shutdown
3) copy disk images to dom0
4) create domU config
5) start domU

Afterwards you can use either pygrub or kernel/ramdisk, whichever you
prefer.

-Jeff



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


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

> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com [mailto:xen-users-
> bounces@lists.xensource.com] On Behalf Of mattias
> Sent: Wednesday, September 23, 2009 1:48 AM
> To: xen-users@lists.xensource.com
> Subject: SV: [Xen-users] Creating a paravirtualized guest with
Xen3.4.1andCentos 5.3
> (64bit)
> 
> You meen are it posible to first install a real e.g centos on a disk
and
> install kernel-xen and boot it with xen?
Yes, that''s essentially what we had done.  I may have omitted some
steps, like fixing block device names in /etc/fstab or Ethernet hardware
addresses in /etc/sysconfig/network-scripts, but neither were difficult
and the results were as expected.

-Jeff



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

Jeff,

thanks for the steps to move an existing physical image to a paravirt 
DomU image. However, I think this only works if both Dom0 and DomU use 
the same architecture  (64bit e.g.). In my case, my host is a 64bit Dom0 
with 32bit DomU guests, so I think it''s at least necessary to get 32bit
kernel and initrd images someplace. Is there an official way to get the 
released 32bit xen kernel versions to be used on a 64bit host? Otherwise 
there''s no problem to get them manually, but that means not getting 
auto-updates...

In addition, I found some comments on the list about CentOS 5.3 initrd 
images coming with scsi modules, and thus not working without rebuilding 
or manually changing to disable scsi.

Therefore I did the following steps to get an HVM VM initially 
transformed to PV:

1) get a known-good Centos image for Xen, e.g. at 
http://stacklet.com/downloads/images/centos/5.3
2) make sure that image works for you with pygrub
3) extract kernel, initrd and /lib/modules/
3) make it work with kernel/initrd/parameters provided externally
3a) don''t use a wrong option for ramdisk support ;-)
4) add /lib/modules extracted from other image to HVM image
5a) add kernel parameter "console=/dev/tty" to prove it boots up
5b) modify /etc/securetty and /etc/inittab (if not done yet by your 
distro), see
http://xen.xensource.com/files/xensummit_4/xensummit_linux_console_slides.pdf
6) boot up the HVM VM in paravirtualized mode

Especially 5) caused me some trouble, as without this option in 
/etc/inittab, the VM just froze before bringing the login prompt.

This is how far I got in a few hours tonight, but now the previously 
automatically launching X server does not start. Well, but I''m getting 
closer.

Open question:
- how to get a Centos 32bit Xen DomU kernel on a 64bit host via 
repositories?

Ultimatively, it will probably be best to use pygrub and do the kernel 
management from inside the VM (this will also be easier when thinking 
about /lib/modules). But at least for my VM, the harddisk layout does 
not work with pygrup (yet).

Regards,
Martin

Jeff Sturm wrote:
>> -----Original Message-----
>> From: xen-users-bounces@lists.xensource.com [mailto:xen-users-
>> bounces@lists.xensource.com] On Behalf Of Martin Troester
>> Sent: Tuesday, September 22, 2009 4:17 PM
>> To: xen-users@lists.xensource.com
>> Subject: Re: [Xen-users] Creating a paravirtualized guest with Xen
> 3.4.1 andCentos
>> 5.3 (64bit)
>>
>> Now I''ll find out if I can get my original problem solved,
migrate the
>> existing fully virtualized system to a paravirtualizded kernel.
Let''s
> see...
> 
> It''s not exactly the same, but I have done physical-to-paravirt
> migrations on CentOS 5.2 with little effort.  It''s probably
easiest if
> you install kernel-xen packages before you migrate:
> 
> 1) yum install kernel-xen
> 2) shutdown
> 3) copy disk images to dom0
> 4) create domU config
> 5) start domU
> 
> Afterwards you can use either pygrub or kernel/ramdisk, whichever you
> prefer.
> 
> -Jeff
> 
> 
> 

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

Hi all,

looks I am somewhat stuck with getting X11 to run inside a DomU. 
Searching for this gives me only little help. As far as I understand, it 
does not work out of the box because there is on real graphics hardware 
available. That definitely explains the output of the X server, 
complaining about not finding any screens to use.

One thing seems to be provide an external framebuffer, as described 
here: http://wiki.xensource.com/xenwiki/VirtualFramebuffer
This page is dated Feb 2008, so is there any important news about this? 
The last line is most discouraging to me, is there any interesting 
updates regarding desktop size? What about performance? Well, I''ll try 
that now anyway.

In addition, as the VM runs fine in HVM (including X), is there any way 
to configure an emulated graphics device for a pv DomU? Reads strange... 
But with graphics hardware not being virtualizable, something like this 
would help.

Any hints/links/documentation on my problem is really appreciated.

Thanks!

Regards,
Martin

Martin Troester wrote:
> Jeff,
> 
> thanks for the steps to move an existing physical image to a paravirt 
> DomU image. However, I think this only works if both Dom0 and DomU use 
> the same architecture  (64bit e.g.). In my case, my host is a 64bit Dom0 
> with 32bit DomU guests, so I think it''s at least necessary to get
32bit
> kernel and initrd images someplace. Is there an official way to get the 
> released 32bit xen kernel versions to be used on a 64bit host? Otherwise 
> there''s no problem to get them manually, but that means not
getting
> auto-updates...
> 
> In addition, I found some comments on the list about CentOS 5.3 initrd 
> images coming with scsi modules, and thus not working without rebuilding 
> or manually changing to disable scsi.
> 
> Therefore I did the following steps to get an HVM VM initially 
> transformed to PV:
> 
> 1) get a known-good Centos image for Xen, e.g. at 
> http://stacklet.com/downloads/images/centos/5.3
> 2) make sure that image works for you with pygrub
> 3) extract kernel, initrd and /lib/modules/
> 3) make it work with kernel/initrd/parameters provided externally
> 3a) don''t use a wrong option for ramdisk support ;-)
> 4) add /lib/modules extracted from other image to HVM image
> 5a) add kernel parameter "console=/dev/tty" to prove it boots up
> 5b) modify /etc/securetty and /etc/inittab (if not done yet by your 
> distro), see
>
http://xen.xensource.com/files/xensummit_4/xensummit_linux_console_slides.pdf
> 
> 6) boot up the HVM VM in paravirtualized mode
> 
> Especially 5) caused me some trouble, as without this option in 
> /etc/inittab, the VM just froze before bringing the login prompt.
> 
> This is how far I got in a few hours tonight, but now the previously 
> automatically launching X server does not start. Well, but I''m
getting
> closer.
> 
> Open question:
> - how to get a Centos 32bit Xen DomU kernel on a 64bit host via 
> repositories?
> 
> Ultimatively, it will probably be best to use pygrub and do the kernel 
> management from inside the VM (this will also be easier when thinking 
> about /lib/modules). But at least for my VM, the harddisk layout does 
> not work with pygrup (yet).
> 
> Regards,
> Martin
> 
> Jeff Sturm wrote:
>>> -----Original Message-----
>>> From: xen-users-bounces@lists.xensource.com [mailto:xen-users-
>>> bounces@lists.xensource.com] On Behalf Of Martin Troester
>>> Sent: Tuesday, September 22, 2009 4:17 PM
>>> To: xen-users@lists.xensource.com
>>> Subject: Re: [Xen-users] Creating a paravirtualized guest with Xen
>> 3.4.1 andCentos
>>> 5.3 (64bit)
>>>
>>> Now I''ll find out if I can get my original problem solved,
migrate the
>>> existing fully virtualized system to a paravirtualizded kernel.
Let''s
>> see...
>>
>> It''s not exactly the same, but I have done
physical-to-paravirt
>> migrations on CentOS 5.2 with little effort.  It''s probably
easiest if
>> you install kernel-xen packages before you migrate:
>>
>> 1) yum install kernel-xen
>> 2) shutdown
>> 3) copy disk images to dom0
>> 4) create domU config
>> 5) start domU
>>
>> Afterwards you can use either pygrub or kernel/ramdisk, whichever you
>> prefer.
>>
>> -Jeff
>>
>>
>>
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 

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

> In addition, as the VM runs fine in HVM (including X), is there any
way
> to configure an emulated graphics device for a pv DomU? Reads
> strange...
> But with graphics hardware not being virtualizable, something like
this
> would help.
You need to have CONFIG_XEN_FRAMEBUFFER support in the domU kernel and
create a virtual framebuffer device in the domU config vfb = [
''type=vnc,vncunused=1'' ] (see the example configuration files
for other
parameters).  X then needs to use the fbdev driver.  In this example you
would connect to the graphical interface with a VNC client.

James





This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

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

Hi!

 If you try the Xen Live CD v2.0, you will see what you want working out of
the box!    ;-)

 http://wiki.xensource.com/xenwiki/LiveCD

Cheers!
Thiago

2009/9/24 Martin Troester <TroyMcClure@web.de>
> Hi all,
>
> looks I am somewhat stuck with getting X11 to run inside a DomU. Searching
> for this gives me only little help. As far as I understand, it does not
work
> out of the box because there is on real graphics hardware available. That
> definitely explains the output of the X server, complaining about not
> finding any screens to use.
>
> One thing seems to be provide an external framebuffer, as described here:
> http://wiki.xensource.com/xenwiki/VirtualFramebuffer
> This page is dated Feb 2008, so is there any important news about this? The
> last line is most discouraging to me, is there any interesting updates
> regarding desktop size? What about performance? Well, I''ll try
that now
> anyway.
>
> In addition, as the VM runs fine in HVM (including X), is there any way to
> configure an emulated graphics device for a pv DomU? Reads strange... But
> with graphics hardware not being virtualizable, something like this would
> help.
>
> Any hints/links/documentation on my problem is really appreciated.
>
> Thanks!
>
> Regards,
> Martin
>
> Martin Troester wrote:
>
>> Jeff,
>>
>> thanks for the steps to move an existing physical image to a paravirt
DomU
>> image. However, I think this only works if both Dom0 and DomU use the
same
>> architecture  (64bit e.g.). In my case, my host is a 64bit Dom0 with
32bit
>> DomU guests, so I think it''s at least necessary to get 32bit
kernel and
>> initrd images someplace. Is there an official way to get the released
32bit
>> xen kernel versions to be used on a 64bit host? Otherwise
there''s no problem
>> to get them manually, but that means not getting auto-updates...
>>
>> In addition, I found some comments on the list about CentOS 5.3 initrd
>> images coming with scsi modules, and thus not working without
rebuilding or
>> manually changing to disable scsi.
>>
>> Therefore I did the following steps to get an HVM VM initially
transformed
>> to PV:
>>
>> 1) get a known-good Centos image for Xen, e.g. at
>> http://stacklet.com/downloads/images/centos/5.3
>> 2) make sure that image works for you with pygrub
>> 3) extract kernel, initrd and /lib/modules/
>> 3) make it work with kernel/initrd/parameters provided externally
>> 3a) don''t use a wrong option for ramdisk support ;-)
>> 4) add /lib/modules extracted from other image to HVM image
>> 5a) add kernel parameter "console=/dev/tty" to prove it boots
up
>> 5b) modify /etc/securetty and /etc/inittab (if not done yet by your
>> distro), see
>>
>>
http://xen.xensource.com/files/xensummit_4/xensummit_linux_console_slides.pdf
>> 6) boot up the HVM VM in paravirtualized mode
>>
>> Especially 5) caused me some trouble, as without this option in
>> /etc/inittab, the VM just froze before bringing the login prompt.
>>
>> This is how far I got in a few hours tonight, but now the previously
>> automatically launching X server does not start. Well, but I''m
getting
>> closer.
>>
>> Open question:
>> - how to get a Centos 32bit Xen DomU kernel on a 64bit host via
>> repositories?
>>
>> Ultimatively, it will probably be best to use pygrub and do the kernel
>> management from inside the VM (this will also be easier when thinking
about
>> /lib/modules). But at least for my VM, the harddisk layout does not
work
>> with pygrup (yet).
>>
>> Regards,
>> Martin
>>
>> Jeff Sturm wrote:
>>
>>> -----Original Message-----
>>>> From: xen-users-bounces@lists.xensource.com [mailto:xen-users-
>>>> bounces@lists.xensource.com] On Behalf Of Martin Troester
>>>> Sent: Tuesday, September 22, 2009 4:17 PM
>>>> To: xen-users@lists.xensource.com
>>>> Subject: Re: [Xen-users] Creating a paravirtualized guest with
Xen
>>>>
>>> 3.4.1 andCentos
>>>
>>>> 5.3 (64bit)
>>>>
>>>> Now I''ll find out if I can get my original problem
solved, migrate the
>>>> existing fully virtualized system to a paravirtualizded kernel.
Let''s
>>>>
>>> see...
>>>
>>> It''s not exactly the same, but I have done
physical-to-paravirt
>>> migrations on CentOS 5.2 with little effort.  It''s
probably easiest if
>>> you install kernel-xen packages before you migrate:
>>>
>>> 1) yum install kernel-xen
>>> 2) shutdown
>>> 3) copy disk images to dom0
>>> 4) create domU config
>>> 5) start domU
>>>
>>> Afterwards you can use either pygrub or kernel/ramdisk, whichever
you
>>> prefer.
>>>
>>> -Jeff
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/xen-users
>>
>>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>

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

James,

thanks for that explanation. I have a DomU kernel with FB support, and I 
am now able to configure X to use the /dev/fb0 device for graphical 
output (although only 800*600 at the moment, but let''s see how to get 
that configured properly).

James Dingwall wrote:
> You need to have CONFIG_XEN_FRAMEBUFFER support in the domU kernel and
> create a virtual framebuffer device in the domU config vfb = [
> ''type=vnc,vncunused=1'' ] (see the example configuration
files for other
> parameters).  X then needs to use the fbdev driver.  In this example you
> would connect to the graphical interface with a VNC client.
As stated above, that works - but it requires me to have a special 
Xorg.conf when using my DomU as a PV image, and another Xorg.conf for 
HVM use, as both use different HW devices.

Without this requirement, I could boot up the unmodified VM without 
further modifications from outside (when having a distro which comes 
with xvc0 being configured correctly in /etc/inittab and 
/etc/securetty), but without a modified Xorg conf, I will not be able to 
start X in the PV guest. So at some point a modification inside the VM 
has to happen to migrate a formerly HVM guest to PV.

Regards,
Martin


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

On Sat, Sep 26, 2009 at 4:16 AM, Martin Troester <TroyMcClure@web.de>
wrote:
> James,
>
> thanks for that explanation. I have a DomU kernel with FB support, and I am
> now able to configure X to use the /dev/fb0 device for graphical output
> (although only 800*600 at the moment, but let''s see how to get
that
> configured properly).
Isn''t it hardcoded to 800x600?
http://readlist.com/lists/lists.xensource.com/xen-users/7/39476.html
>
> James Dingwall wrote:
>>
>> You need to have CONFIG_XEN_FRAMEBUFFER support in the domU kernel and
>> create a virtual framebuffer device in the domU config vfb = [
>> ''type=vnc,vncunused=1'' ] (see the example
configuration files for other
>> parameters).  X then needs to use the fbdev driver.  In this example
you
>> would connect to the graphical interface with a VNC client.
>
> As stated above, that works - but it requires me to have a special
Xorg.conf
> when using my DomU as a PV image, and another Xorg.conf for HVM use, as
both
> use different HW devices.
>
> Without this requirement, I could boot up the unmodified VM without further
> modifications from outside (when having a distro which comes with xvc0
being
> configured correctly in /etc/inittab and /etc/securetty), but without a
> modified Xorg conf, I will not be able to start X in the PV guest. So at
> some point a modification inside the VM has to happen to migrate a formerly
> HVM guest to PV.
Perhaps something like vnc/xrdp/NX would be more suitable.

-- 
Fajar

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

>
>
>
> Perhaps something like vnc/xrdp/NX would be more suitable.
>
> --
> Fajar
>
My thoughts exactly. I''ve never bothered with X in xen because NX works
great. Why have a local server on a Virtual Machine? I think that''s
what
KVM/VirtualBox are for. I''m sure everyones application are different
though.


Grant McWilliams

Some people, when confronted with a problem, think "I know, I''ll
use
Windows."
Now they have two problems.


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

Hi Grant, Fajar,
>> Perhaps something like vnc/xrdp/NX would be more suitable.
> My thoughts exactly. I''ve never bothered with X in xen because NX
works
> great. Why have a local server on a Virtual Machine? I think
that''s what
> KVM/VirtualBox are for. I''m sure everyones application are
different though.
Well, the idea is to have an image that runs on bare metal, in HVM and 
(now) in a PV environment. On all systems I want to reconnect to my 
desktop, and on the physical hardware I want the physical display to be 
exported (not a virtual, additional display). Thus on the physical 
installation I export the X server via x11vnc for both local and remote 
operation on the very same desktop. That works fine as well in HVM (as 
it comes with its own emulated graphics adapter), but not so well in the 
framebuffer setup coming with PV - until now the resoltion stays limited 
to 800x600, which seems to be the native virtual fb resolution. This 
setup may sound strange, but as I said, it worked so far ;-)

However, I now got it (almost) running with the fb device, using the 
descriptions I found in:
http://lists.xensource.com/archives/html/xen-devel/2008-02/msg01036.html
and:
http://lists.xensource.com/archives/html/xen-devel/2008-03/msg00398.html

In my words, I had to add the following line to the kernel parameters 
passed via the extra keyword in the xen config file:
extra="xenfb.videomem=32,1024 "
This line configures the xenfb device with 32MB of Video RAM and a 
resolution of 1024x768 (as far as I understand, I did not find a lot 
more docu than this).

The following config works as xorg.conf inside the VM (based on the mail 
threads mentioned above):
Section "Monitor"
    HorizSync 30-65
    Identifier "Monitor[0]"
    ModelName "XEN PV"
    VendorName "XEN"
    VertRefresh 43-75
    UseModes "Modes[0]"
EndSection

Section "Modes"
    Identifier "Modes[0]"]
    Modeline "1024x768" 79.52 1024 1080 1192 1360 768 769 772 801
EndSection

Section "Device"
    Identifier "Device[0]".
    Driver "fbdev"
    Option "fbdev" "/dev/fb0"
EndSection

Section "Screen"
    SubSection "Display"
      Depth 24
      Modes "1024x768"
      Virtual 1024 768
    EndSubSection
    Device "Device[0]"
    Identifier "Screen[0]"
    Monitor "Monitor[0]"
EndSection

Section "ServerLayout"
    Identifier "Default Layout"
    Screen "Screen[0]"
    InputDevice "Mouse1" "CorePointer"
    InputDevice "Mouse2" "SendCoreEvents"
    InputDevice "Keyboard_us" "CoreKeyboard"
EndSection

Section "InputDevice"
         Identifier "Keyboard_us"
         Driver "keyboard"
         Option "XkbLayout" "us"
         Option "XkbModel" "pc104"
EndSection

Section "InputDevice"
     Identifier  "Mouse1"
     Driver      "mouse"
     Option "Protocol"    "PS/2"
     Option "Device"      "/dev/input/mouse0"
EndSection

Section "InputDevice"
     Identifier  "Mouse2"
     Driver      "mouse"
     Option      "Protocol"      "IMPS/2"
     Option      "Device"        "/dev/input/mice"
     Option      "ZAxisMapping"   "4 5"
     Option      "Emulate3Buttons" "no"
EndSection

Well, that''s almost it - I seemed to be lucky so far not to have to
work
with mode lines...Those come from the posts mentioned above, and I now 
get a full 1024x768 desktop exported via x11vnc. Unfortunately, some 
lines of the virtual desktop are showing strange colors and seem screwed 
up. I thought decreasing the color depth to 16bit might do the trick, 
but with that changed, the resolution reduces to 800x600 - no idea why, 
but I blame the mode line on this... Any ideas anybody?

Well, that''s it for tonight. I understand this is a more or less exotic
setup, but maybe this helps somebody running into the same issue.

Regards,
Martin

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