Hi, I''m the Mageia XEN packager and during QA, we stumbled into a problem. in fact, we wanted to test Mageia 3 installation on a HVM. so, we had a sparse image and a iso file: [ ''file:/opt/testhvm.img,sda,w'', ''file:/opt/mageialive.iso,hdb:cdrom,r'' ] the live booted, and was able to install to disk, but it never seemed to boot after the install... (for some reason) in the end, this "worked" when we changed to: [ ''file:/opt/testhvm.img,xvda,w'', ''file:/opt/testhvm.img,sda,w'' ] apparently ''xvda'' to get grub to boot the kernel; and ''sda'' so that it could start... any idea as to why it can''t be booted with sda? is there a specific driver missing?
On Mon, Jun 24, 2013 at 9:21 PM, AL13N <alien@rmail.be> wrote:> Hi, > > I''m the Mageia XEN packager and during QA, we stumbled into a problem. > > in fact, we wanted to test Mageia 3 installation on a HVM. > > so, we had a sparse image and a iso file: > > [ ''file:/opt/testhvm.img,sda,w'', ''file:/opt/mageialive.iso,hdb:cdrom,r'' ] > > the live booted, and was able to install to disk, but it never seemed to boot > after the install... (for some reason) > > in the end, this "worked" when we changed to: > > [ ''file:/opt/testhvm.img,xvda,w'', ''file:/opt/testhvm.img,sda,w'' ] > > apparently ''xvda'' to get grub to boot the kernel; and ''sda'' so that it could > start...My HVM Linux config files have ''hda'' instead of ''sda'' -- can you try that instead? Normally what happens is that qemu begins by exposing the hda device to the guest, to boot via grub; but when the Xen PV drivers in the Linux kernel come up, they write to a magic port which causes the physical hda device to disappear. I *think* then that the Xen PV drivers actually take over that major/minor, so that further reads and writes to the hda go through the PV protocol instead. All of this might get mixed up if you''re using sda instead. -George
> On Mon, Jun 24, 2013 at 9:21 PM, AL13N <alien@rmail.be> wrote: >> Hi, >> >> I''m the Mageia XEN packager and during QA, we stumbled into a problem. >> >> in fact, we wanted to test Mageia 3 installation on a HVM. >> >> so, we had a sparse image and a iso file: >> >> [ ''file:/opt/testhvm.img,sda,w'', ''file:/opt/mageialive.iso,hdb:cdrom,r'' >> ] >> >> the live booted, and was able to install to disk, but it never seemed to >> boot >> after the install... (for some reason) >> >> in the end, this "worked" when we changed to: >> >> [ ''file:/opt/testhvm.img,xvda,w'', ''file:/opt/testhvm.img,sda,w'' ] >> >> apparently ''xvda'' to get grub to boot the kernel; and ''sda'' so that it >> could >> start... > > My HVM Linux config files have ''hda'' instead of ''sda'' -- can you try > that instead? > > Normally what happens is that qemu begins by exposing the hda device > to the guest, to boot via grub; but when the Xen PV drivers in the > Linux kernel come up, they write to a magic port which causes the > physical hda device to disappear. I *think* then that the Xen PV > drivers actually take over that major/minor, so that further reads and > writes to the hda go through the PV protocol instead. > > All of this might get mixed up if you''re using sda instead. > > -George >well, hda is what we tried first, but we couldn''t see the disk from the live system with hda. only sda seemed to work for that...
On 06/25/2013 11:47 AM, AL13N wrote:>> On Mon, Jun 24, 2013 at 9:21 PM, AL13N <alien@rmail.be> wrote: >>> Hi, >>> >>> I''m the Mageia XEN packager and during QA, we stumbled into a problem. >>> >>> in fact, we wanted to test Mageia 3 installation on a HVM. >>> >>> so, we had a sparse image and a iso file: >>> >>> [ ''file:/opt/testhvm.img,sda,w'', ''file:/opt/mageialive.iso,hdb:cdrom,r'' >>> ] >>> >>> the live booted, and was able to install to disk, but it never seemed to >>> boot >>> after the install... (for some reason) >>> >>> in the end, this "worked" when we changed to: >>> >>> [ ''file:/opt/testhvm.img,xvda,w'', ''file:/opt/testhvm.img,sda,w'' ] >>> >>> apparently ''xvda'' to get grub to boot the kernel; and ''sda'' so that it >>> could >>> start... >> >> My HVM Linux config files have ''hda'' instead of ''sda'' -- can you try >> that instead? >> >> Normally what happens is that qemu begins by exposing the hda device >> to the guest, to boot via grub; but when the Xen PV drivers in the >> Linux kernel come up, they write to a magic port which causes the >> physical hda device to disappear. I *think* then that the Xen PV >> drivers actually take over that major/minor, so that further reads and >> writes to the hda go through the PV protocol instead. >> >> All of this might get mixed up if you''re using sda instead. >> >> -George >> > > > well, hda is what we tried first, but we couldn''t see the disk from the > live system with hda. only sda seemed to work for that...When you say, "we couldn''t see the disk from the live system", you''re talking about booting from the live CD? If post-install you try ''hda'' and it boots (after changing the grub and /etc/fstab if necessary), then I would suspect that there''s a problem with your live CD kernel. Do you use a different kernel image, and/or are the modules for the Xen PV devices not included? -George
> On 06/25/2013 11:47 AM, AL13N wrote: >>> On Mon, Jun 24, 2013 at 9:21 PM, AL13N <alien@rmail.be> wrote: >>>> Hi, >>>> >>>> I''m the Mageia XEN packager and during QA, we stumbled into a problem. >>>> >>>> in fact, we wanted to test Mageia 3 installation on a HVM. >>>> >>>> so, we had a sparse image and a iso file: >>>> >>>> [ ''file:/opt/testhvm.img,sda,w'', >>>> ''file:/opt/mageialive.iso,hdb:cdrom,r'' >>>> ] >>>> >>>> the live booted, and was able to install to disk, but it never seemed >>>> to >>>> boot >>>> after the install... (for some reason) >>>> >>>> in the end, this "worked" when we changed to: >>>> >>>> [ ''file:/opt/testhvm.img,xvda,w'', ''file:/opt/testhvm.img,sda,w'' ] >>>> >>>> apparently ''xvda'' to get grub to boot the kernel; and ''sda'' so that it >>>> could >>>> start... >>> >>> My HVM Linux config files have ''hda'' instead of ''sda'' -- can you try >>> that instead? >>> >>> Normally what happens is that qemu begins by exposing the hda device >>> to the guest, to boot via grub; but when the Xen PV drivers in the >>> Linux kernel come up, they write to a magic port which causes the >>> physical hda device to disappear. I *think* then that the Xen PV >>> drivers actually take over that major/minor, so that further reads and >>> writes to the hda go through the PV protocol instead. >>> >>> All of this might get mixed up if you''re using sda instead. >>> >>> -George >>> >> >> >> well, hda is what we tried first, but we couldn''t see the disk from the >> live system with hda. only sda seemed to work for that... > > When you say, "we couldn''t see the disk from the live system", you''re > talking about booting from the live CD? > > If post-install you try ''hda'' and it boots (after changing the grub and > /etc/fstab if necessary), then I would suspect that there''s a problem > with your live CD kernel. Do you use a different kernel image, and/or > are the modules for the Xen PV devices not included?what i mean is: 1st try was using hda en hdb:cdrom with an iso and boot=dc this booted from the livecd, but the disk was not visible, even though xenblk_front was loaded (does hvm use a different module for emulation? there were some ide modules loaded as well). this is one thing we wanted to get right when having Mageia to be xen-ready (ie: installable on HVM from iso) We''ll try using hda postinstall... PS: one weird thing that i saw in the log files, was a message about stripping tap from device, which was odd, since file:/... was specified and not tap:aio:... (and Mageia 3 doesn''t have a specific -xen kernel, nor a blktap-dkms...)
On 06/25/2013 11:57 AM, AL13N wrote:>> On 06/25/2013 11:47 AM, AL13N wrote: >>>> On Mon, Jun 24, 2013 at 9:21 PM, AL13N <alien@rmail.be> wrote: >>>>> Hi, >>>>> >>>>> I''m the Mageia XEN packager and during QA, we stumbled into a problem. >>>>> >>>>> in fact, we wanted to test Mageia 3 installation on a HVM. >>>>> >>>>> so, we had a sparse image and a iso file: >>>>> >>>>> [ ''file:/opt/testhvm.img,sda,w'', >>>>> ''file:/opt/mageialive.iso,hdb:cdrom,r'' >>>>> ] >>>>> >>>>> the live booted, and was able to install to disk, but it never seemed >>>>> to >>>>> boot >>>>> after the install... (for some reason) >>>>> >>>>> in the end, this "worked" when we changed to: >>>>> >>>>> [ ''file:/opt/testhvm.img,xvda,w'', ''file:/opt/testhvm.img,sda,w'' ] >>>>> >>>>> apparently ''xvda'' to get grub to boot the kernel; and ''sda'' so that it >>>>> could >>>>> start... >>>> >>>> My HVM Linux config files have ''hda'' instead of ''sda'' -- can you try >>>> that instead? >>>> >>>> Normally what happens is that qemu begins by exposing the hda device >>>> to the guest, to boot via grub; but when the Xen PV drivers in the >>>> Linux kernel come up, they write to a magic port which causes the >>>> physical hda device to disappear. I *think* then that the Xen PV >>>> drivers actually take over that major/minor, so that further reads and >>>> writes to the hda go through the PV protocol instead. >>>> >>>> All of this might get mixed up if you''re using sda instead. >>>> >>>> -George >>>> >>> >>> >>> well, hda is what we tried first, but we couldn''t see the disk from the >>> live system with hda. only sda seemed to work for that... >> >> When you say, "we couldn''t see the disk from the live system", you''re >> talking about booting from the live CD? >> >> If post-install you try ''hda'' and it boots (after changing the grub and >> /etc/fstab if necessary), then I would suspect that there''s a problem >> with your live CD kernel. Do you use a different kernel image, and/or >> are the modules for the Xen PV devices not included? > > what i mean is: > > 1st try was using hda en hdb:cdrom with an iso and boot=dcHmm, I think we normally use hdc for the cdrom instead of hdb. hda and hdb would be on the same controller, I think; so it''s probably not possible to unplug hda without also unplugging hdb. In that case, having the PV drivers loaded could actually make things worse: if they successfully unplug hda, then they lose the cdrom; if they don''t, then the PV drivers may be in a weird state where they''ve grabbed the hda device but aren''t able to provide access to the disk anymore.> this booted from the livecd, but the disk was not visible, even though > xenblk_front was loaded (does hvm use a different module for emulation? > there were some ide modules loaded as well). > > this is one thing we wanted to get right when having Mageia to be > xen-ready (ie: installable on HVM from iso)Absolutely -- I''m just exploring configuration / guest kernel setups that can be tweaked, particularly since at the moment we''re pretty much locked down for 4.3, so any changes won''t be in a public release until 4.4 in (probably) 6 months'' time.> > We''ll try using hda postinstall... > > > PS: one weird thing that i saw in the log files, was a message about > stripping tap from device, which was odd, since file:/... was specified > and not tap:aio:... (and Mageia 3 doesn''t have a specific -xen kernel, nor > a blktap-dkms...)If you could post the exact message, we could find out where the warning was coming from and see if it''s something to worry about. -George
> On 06/25/2013 11:57 AM, AL13N wrote: >>> On 06/25/2013 11:47 AM, AL13N wrote: >>>>> On Mon, Jun 24, 2013 at 9:21 PM, AL13N <alien@rmail.be> wrote: >>>>>> Hi, >>>>>> >>>>>> I''m the Mageia XEN packager and during QA, we stumbled into a >>>>>> problem. >>>>>> >>>>>> in fact, we wanted to test Mageia 3 installation on a HVM. >>>>>> >>>>>> so, we had a sparse image and a iso file: >>>>>> >>>>>> [ ''file:/opt/testhvm.img,sda,w'', >>>>>> ''file:/opt/mageialive.iso,hdb:cdrom,r'' >>>>>> ] >>>>>> >>>>>> the live booted, and was able to install to disk, but it never >>>>>> seemed >>>>>> to >>>>>> boot >>>>>> after the install... (for some reason) >>>>>> >>>>>> in the end, this "worked" when we changed to: >>>>>> >>>>>> [ ''file:/opt/testhvm.img,xvda,w'', ''file:/opt/testhvm.img,sda,w'' ] >>>>>> >>>>>> apparently ''xvda'' to get grub to boot the kernel; and ''sda'' so that >>>>>> it >>>>>> could >>>>>> start... >>>>> >>>>> My HVM Linux config files have ''hda'' instead of ''sda'' -- can you try >>>>> that instead? >>>>> >>>>> Normally what happens is that qemu begins by exposing the hda device >>>>> to the guest, to boot via grub; but when the Xen PV drivers in the >>>>> Linux kernel come up, they write to a magic port which causes the >>>>> physical hda device to disappear. I *think* then that the Xen PV >>>>> drivers actually take over that major/minor, so that further reads >>>>> and >>>>> writes to the hda go through the PV protocol instead. >>>>> >>>>> All of this might get mixed up if you''re using sda instead. >>>>> >>>>> -George >>>>> >>>> >>>> >>>> well, hda is what we tried first, but we couldn''t see the disk from >>>> the >>>> live system with hda. only sda seemed to work for that... >>> >>> When you say, "we couldn''t see the disk from the live system", you''re >>> talking about booting from the live CD? >>> >>> If post-install you try ''hda'' and it boots (after changing the grub and >>> /etc/fstab if necessary), then I would suspect that there''s a problem >>> with your live CD kernel. Do you use a different kernel image, and/or >>> are the modules for the Xen PV devices not included? >> >> what i mean is: >> >> 1st try was using hda en hdb:cdrom with an iso and boot=dc > > Hmm, I think we normally use hdc for the cdrom instead of hdb. hda and > hdb would be on the same controller, I think; so it''s probably not > possible to unplug hda without also unplugging hdb. In that case, > having the PV drivers loaded could actually make things worse: if they > successfully unplug hda, then they lose the cdrom; if they don''t, then > the PV drivers may be in a weird state where they''ve grabbed the hda > device but aren''t able to provide access to the disk anymore.we''ll retry with hdc:cdrom i didn''t think of a different controller issue. btw: is xenblk_front used for this, or something ide_generic ? (we didn''t experience any issue with the cdrom at least)>> this booted from the livecd, but the disk was not visible, even though >> xenblk_front was loaded (does hvm use a different module for emulation? >> there were some ide modules loaded as well). >> >> this is one thing we wanted to get right when having Mageia to be >> xen-ready (ie: installable on HVM from iso) > > Absolutely -- I''m just exploring configuration / guest kernel setups > that can be tweaked, particularly since at the moment we''re pretty much > locked down for 4.3, so any changes won''t be in a public release until > 4.4 in (probably) 6 months'' time. > >> >> We''ll try using hda postinstall... >> >> >> PS: one weird thing that i saw in the log files, was a message about >> stripping tap from device, which was odd, since file:/... was specified >> and not tap:aio:... (and Mageia 3 doesn''t have a specific -xen kernel, >> nor >> a blktap-dkms...) > > If you could post the exact message, we could find out where the warning > was coming from and see if it''s something to worry about.i don''t have an exact message, but i think i''ve seen this before on other XENs when you specify tap:aio: as backend device... i''ll see if we can refind this message
--On 25 June 2013 12:57:59 +0200 AL13N <alien@rmail.be> wrote:> what i mean is: > > 1st try was using hda en hdb:cdrom with an iso and boot=dc > > this booted from the livecd, but the disk was not visible, even though > xenblk_front was loaded (does hvm use a different module for emulation? > there were some ide modules loaded as well).This can happen if your live CD has one xen module but not the other (xen_platform_pci and blkfrnot). It works like this. Early on kernel boot the xen pci bridge module attempts to see if it has a connection to the hypervisor. If it finds it does, it pokes a magic value to a port (as George said) which unplugs the emulated hardware which has been used by grub. sd may or may not have initialised (I believe depending on whether it is a built in, whether the xen thing is built in, and module init order - a.k.a. phase of the moon). Sometime later another module (blkfront if I remember right) goes to see if there are any pv driver disks it can talk to. What this means in practice is that if you build your initrd without blkfront support but with some of the other xen modules enabled, you get the problem that you have no block devices on boot. If you want some information on how this works, I suggest you read this thread: http://www.gossamer-threads.com/lists/xen/devel/192003 Ubuntu used to be broken in a slightly different way that may also be relevant. See: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/804219 -- Alex Bligh
> > > --On 25 June 2013 12:57:59 +0200 AL13N <alien@rmail.be> wrote: > >> what i mean is: >> >> 1st try was using hda en hdb:cdrom with an iso and boot=dc >> >> this booted from the livecd, but the disk was not visible, even though >> xenblk_front was loaded (does hvm use a different module for emulation? >> there were some ide modules loaded as well). > > This can happen if your live CD has one xen module but not the other > (xen_platform_pci and blkfrnot). It works like this. Early on kernel boot > the xen pci bridge module attempts to see if it has a connection to > the hypervisor. If it finds it does, it pokes a magic value to a port > (as George said) which unplugs the emulated hardware which has been > used by grub. sd may or may not have initialised (I believe depending > on whether it is a built in, whether the xen thing is built in, and > module init order - a.k.a. phase of the moon). Sometime later another > module (blkfront if I remember right) goes to see if there are any > pv driver disks it can talk to.thanks for the underlying technical details, in the past i''ve looked for this stuff in documentation somewhere, (ie: how XENBUS handles the bus and how guests need to react), but i didn''t have much luck...> What this means in practice is that if you build your initrd without > blkfront support but with some of the other xen modules enabled, you > get the problem that you have no block devices on boot.xen_platform_pci -- i think we have this builtin in our kernel server... ah wait, i forgot to doublecheck if server kernel was used... i''m pretty sure we have blkfront and netfront in initrd...> If you want some information on how this works, I suggest you read > this thread: > http://www.gossamer-threads.com/lists/xen/devel/192003 > > Ubuntu used to be broken in a slightly different way that may also > be relevant. See: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/804219i''ll go read some more :-)
On Mon, Jun 24, 2013 at 10:21:48PM +0200, AL13N wrote:> Hi, > > I''m the Mageia XEN packager and during QA, we stumbled into a problem. > > in fact, we wanted to test Mageia 3 installation on a HVM. > > so, we had a sparse image and a iso file: > > [ ''file:/opt/testhvm.img,sda,w'', ''file:/opt/mageialive.iso,hdb:cdrom,r'' ] > > the live booted, and was able to install to disk, but it never seemed to boot > after the install... (for some reason) > > in the end, this "worked" when we changed to: > > [ ''file:/opt/testhvm.img,xvda,w'', ''file:/opt/testhvm.img,sda,w'' ] > > apparently ''xvda'' to get grub to boot the kernel; and ''sda'' so that it could > start... > > > any idea as to why it can''t be booted with sda? is there a specific driver > missing? >See here for more info: http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers This config works for both HVM and PVHVM: disk = [ ''phy:/dev/vg01/f16pvhvm-disk0,hda,w'', ''file:/root/iso/Fedora-16-x86_64-DVD.iso,hdc:cdrom,r'' ] You can enable or disable PV drivers with: xen_platform_pci=0|1 -- Pasi
Op dinsdag 25 juni 2013 18:39:06 schreef Pasi Kärkkäinen:> On Mon, Jun 24, 2013 at 10:21:48PM +0200, AL13N wrote: > > Hi, > > > > I''m the Mageia XEN packager and during QA, we stumbled into a problem. > > > > in fact, we wanted to test Mageia 3 installation on a HVM. > > > > so, we had a sparse image and a iso file: > > > > [ ''file:/opt/testhvm.img,sda,w'', ''file:/opt/mageialive.iso,hdb:cdrom,r'' ] > > > > the live booted, and was able to install to disk, but it never seemed to > > boot after the install... (for some reason) > > > > in the end, this "worked" when we changed to: > > > > [ ''file:/opt/testhvm.img,xvda,w'', ''file:/opt/testhvm.img,sda,w'' ] > > > > apparently ''xvda'' to get grub to boot the kernel; and ''sda'' so that it > > could start... > > > > > > any idea as to why it can''t be booted with sda? is there a specific driver > > missing? > > See here for more info: > http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers > > This config works for both HVM and PVHVM: > disk = [ ''phy:/dev/vg01/f16pvhvm-disk0,hda,w'', > ''file:/root/iso/Fedora-16-x86_64-DVD.iso,hdc:cdrom,r'' ] > > You can enable or disable PV drivers with: > xen_platform_pci=0|1i''m assuming that hda (ide_generic) would be using regular emulation? and the pv driver (xenblk_front) could be hda, sda, or xvda and it will choose the one you''ve chosen in the config? (via xen_platform_pci)?
On Tue, Jun 25, 2013 at 07:21:48PM +0200, AL13N wrote:> Op dinsdag 25 juni 2013 18:39:06 schreef Pasi Kärkkäinen: > > On Mon, Jun 24, 2013 at 10:21:48PM +0200, AL13N wrote: > > > Hi, > > > > > > I''m the Mageia XEN packager and during QA, we stumbled into a problem. > > > > > > in fact, we wanted to test Mageia 3 installation on a HVM. > > > > > > so, we had a sparse image and a iso file: > > > > > > [ ''file:/opt/testhvm.img,sda,w'', ''file:/opt/mageialive.iso,hdb:cdrom,r'' ] > > > > > > the live booted, and was able to install to disk, but it never seemed to > > > boot after the install... (for some reason) > > > > > > in the end, this "worked" when we changed to: > > > > > > [ ''file:/opt/testhvm.img,xvda,w'', ''file:/opt/testhvm.img,sda,w'' ] > > > > > > apparently ''xvda'' to get grub to boot the kernel; and ''sda'' so that it > > > could start... > > > > > > > > > any idea as to why it can''t be booted with sda? is there a specific driver > > > missing? > > > > See here for more info: > > http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers > > > > This config works for both HVM and PVHVM: > > disk = [ ''phy:/dev/vg01/f16pvhvm-disk0,hda,w'', > > ''file:/root/iso/Fedora-16-x86_64-DVD.iso,hdc:cdrom,r'' ] > > > > You can enable or disable PV drivers with: > > xen_platform_pci=0|1 > > i''m assuming that hda (ide_generic) would be using regular emulation? and the > pv driver (xenblk_front) could be hda, sda, or xvda and it will choose the one > you''ve chosen in the config? (via xen_platform_pci)? >Yeah, if xen_platform_pci=0 then hda will be emulated, and if xen_platform_pci=1 then xen-blkfront will start and "unplug" the emulated hda, so there''s only xvda. -- Pasi
Op dinsdag 25 juni 2013 20:25:16 schreef Pasi Kärkkäinen:> On Tue, Jun 25, 2013 at 07:21:48PM +0200, AL13N wrote: > > Op dinsdag 25 juni 2013 18:39:06 schreef Pasi Kärkkäinen: > > > On Mon, Jun 24, 2013 at 10:21:48PM +0200, AL13N wrote: > > > > Hi, > > > > > > > > I''m the Mageia XEN packager and during QA, we stumbled into a problem. > > > > > > > > in fact, we wanted to test Mageia 3 installation on a HVM. > > > > > > > > so, we had a sparse image and a iso file: > > > > > > > > [ ''file:/opt/testhvm.img,sda,w'', > > > > ''file:/opt/mageialive.iso,hdb:cdrom,r'' ] > > > > > > > > the live booted, and was able to install to disk, but it never seemed > > > > to > > > > boot after the install... (for some reason) > > > > > > > > in the end, this "worked" when we changed to: > > > > > > > > [ ''file:/opt/testhvm.img,xvda,w'', ''file:/opt/testhvm.img,sda,w'' ] > > > > > > > > apparently ''xvda'' to get grub to boot the kernel; and ''sda'' so that it > > > > could start... > > > > > > > > > > > > any idea as to why it can''t be booted with sda? is there a specific > > > > driver > > > > missing? > > > > > > See here for more info: > > > http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers > > > > > > This config works for both HVM and PVHVM: > > > disk = [ ''phy:/dev/vg01/f16pvhvm-disk0,hda,w'', > > > ''file:/root/iso/Fedora-16-x86_64-DVD.iso,hdc:cdrom,r'' ] > > > > > > You can enable or disable PV drivers with: > > > xen_platform_pci=0|1 > > > > i''m assuming that hda (ide_generic) would be using regular emulation? and > > the pv driver (xenblk_front) could be hda, sda, or xvda and it will > > choose the one you''ve chosen in the config? (via xen_platform_pci)? > > Yeah, if xen_platform_pci=0 then hda will be emulated, and if > xen_platform_pci=1 then xen-blkfront will start and "unplug" the emulated > hda, so there''s only xvda.the pv drivers don''t use hda and sda anymore? only xvda?
On Tue, Jun 25, 2013 at 07:32:42PM +0200, AL13N wrote:> Op dinsdag 25 juni 2013 20:25:16 schreef Pasi Kärkkäinen: > > On Tue, Jun 25, 2013 at 07:21:48PM +0200, AL13N wrote: > > > Op dinsdag 25 juni 2013 18:39:06 schreef Pasi Kärkkäinen: > > > > On Mon, Jun 24, 2013 at 10:21:48PM +0200, AL13N wrote: > > > > > Hi, > > > > > > > > > > I''m the Mageia XEN packager and during QA, we stumbled into a problem. > > > > > > > > > > in fact, we wanted to test Mageia 3 installation on a HVM. > > > > > > > > > > so, we had a sparse image and a iso file: > > > > > > > > > > [ ''file:/opt/testhvm.img,sda,w'', > > > > > ''file:/opt/mageialive.iso,hdb:cdrom,r'' ] > > > > > > > > > > the live booted, and was able to install to disk, but it never seemed > > > > > to > > > > > boot after the install... (for some reason) > > > > > > > > > > in the end, this "worked" when we changed to: > > > > > > > > > > [ ''file:/opt/testhvm.img,xvda,w'', ''file:/opt/testhvm.img,sda,w'' ] > > > > > > > > > > apparently ''xvda'' to get grub to boot the kernel; and ''sda'' so that it > > > > > could start... > > > > > > > > > > > > > > > any idea as to why it can''t be booted with sda? is there a specific > > > > > driver > > > > > missing? > > > > > > > > See here for more info: > > > > http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers > > > > > > > > This config works for both HVM and PVHVM: > > > > disk = [ ''phy:/dev/vg01/f16pvhvm-disk0,hda,w'', > > > > ''file:/root/iso/Fedora-16-x86_64-DVD.iso,hdc:cdrom,r'' ] > > > > > > > > You can enable or disable PV drivers with: > > > > xen_platform_pci=0|1 > > > > > > i''m assuming that hda (ide_generic) would be using regular emulation? and > > > the pv driver (xenblk_front) could be hda, sda, or xvda and it will > > > choose the one you''ve chosen in the config? (via xen_platform_pci)? > > > > Yeah, if xen_platform_pci=0 then hda will be emulated, and if > > xen_platform_pci=1 then xen-blkfront will start and "unplug" the emulated > > hda, so there''s only xvda. > > the pv drivers don''t use hda and sda anymore? only xvda? >yes, the Linux Xen PV drivers (xen-blkfront) only exposes xvd* devices. You can easily verify that with booting Linux HVM guest with xen_platform_pci= and xen_platform_pci=1 and comparing the block devices visible inside the VM. -- Pasi
Possibly Parallel Threads
- preparing for 4.3.1
- ocaml bindings
- CentOS DomU 2.6.18-128.1.6.el5 crashing on boot when xenpv_hvm drivers are loaded / snv_111 Xen 3.1 Dom0
- RFH: loopback & blktap(2) and CDROM
- Xen 4.1.2 PVHVM guest with Linux 3.1.0 network problem, empty MAC address (all zeroes)