I get the following warning when running xend start, and a similar warning sometimes when doing xm commands: /usr/lib/python/xen/xend/XendNode.py:26: RuntimeWarning: Python C API version mismatch for module xen.lowlevel.xc: This Python has API version 1012, module xen.lowlevel.xc has version 1011. import xen.lowlevel.xc /usr/lib/python/xen/xend/xenstore/xstransact.py:10: RuntimeWarning: Python C API version mismatch for module xen.lowlevel.xs: This Python has API version 1012, module xen.lowlevel.xs has version 1011. from xen.lowlevel import xs Xend does seem to start ok, and xm seems to run ok. But domU still can''t find its boot disk. In the boot messages I see: xen_blk: Initialising virtual block device driver But following that I see no message like Registering block device major 3 which I normally see on a working system. The non-working system has python 2.3.4 on it. Could this be a problem? My disk config is: disk = [ ''file:/xen/disk-images/dom1.fs,sda1,w''] The strange thing is if I change the filename to something non-existent, the behavior stays the same. The disk image file does exist and is in good shape. Rob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I had a similar problem and was able to rectify it by including the following line: disk = [ ''phy:/dev/sda3,hda1,w'' ] which, as stated in the user doc in section 5.1, will export /dev/sda3 (the partition where my image is) to the domU as hda1. then, my disk config is: disk = [ ''file:/path/to/image,hda1,w'' ] also, the user doc''s example in section 5.1 says that disk = [ ''phy:sda3,hda1,w'' ] would work but it did not unless i put /dev/ in front of sda3, like above. ryan On Tue, 11 Oct 2005, Rob Gardner wrote:> Xend does seem to start ok, and xm seems to run ok. But domU still can''t find > its boot disk. In the boot messages I see: > > xen_blk: Initialising virtual block device driver > > But following that I see no message like Registering block device major 3 > which I normally see on a working system. > > The non-working system has python 2.3.4 on it. Could this be a problem? > > My disk config is: > disk = [ ''file:/xen/disk-images/dom1.fs,sda1,w''] > The strange thing is if I change the filename to something non-existent, the > behavior stays the same. The disk image file does exist and is in good shape. > > > > Rob > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ryan Grimm wrote:> > I had a similar problem and was able to rectify it by including the > following line: > > disk = [ ''phy:/dev/sda3,hda1,w'' ] > > which, as stated in the user doc in section 5.1, will export /dev/sda3 > (the partition where my image is) to the domU as hda1. > > then, my disk config is: > > disk = [ ''file:/path/to/image,hda1,w'' ] > > also, the user doc''s example in section 5.1 says that disk = [ > ''phy:sda3,hda1,w'' ] would work but it did not unless i put /dev/ in > front of sda3, like above. >I don''t understand that. If you have two "disk = " lines, won''t the second simply supercede the first? I tried exporting the partition containing the image like this: disk = [ ''phy:/dev/hda6,hda6,w'', ''file:/xen/disk-images/dom1.fs,sda1,w''] ...but no luck there. Rob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I don''t know what the desired behavior should be, but good point about
the
two disk statements...i am able to now get the desired behavior by using
one like you suggested.
mine now looks like:
disk = [ ''phy:sda3,hda1,w'',
''file:/path/to/image,hda1,w'' ]
so i dont need the /dev in front of sda3 after all...but i think that if
you export hda6 as hda6, you need to specify hda6 instead of sda1. so i
think your disk and root statements should be:
disk = [ ''phy:hda6,hda6,w'',
''file:/xen/disk-images/dom1.fs,hda6,w'']
root = "/dev/hda6 ro"
at least that is what works on my machine :)
ryan
On Tue, 11 Oct 2005, Rob Gardner wrote:
> Ryan Grimm wrote:
>
>>
>> I had a similar problem and was able to rectify it by including the
>> following line:
>>
>> disk = [ ''phy:/dev/sda3,hda1,w'' ]
>>
>> which, as stated in the user doc in section 5.1, will export /dev/sda3
(the
>> partition where my image is) to the domU as hda1.
>>
>> then, my disk config is:
>>
>> disk = [ ''file:/path/to/image,hda1,w'' ]
>>
>> also, the user doc''s example in section 5.1 says that disk = [
>> ''phy:sda3,hda1,w'' ] would work but it did not unless
i put /dev/ in front
>> of sda3, like above.
>>
>
>
> I don''t understand that. If you have two "disk = "
lines, won''t the second
> simply supercede the first? I tried exporting the partition containing the
> image like this:
> disk = [ ''phy:/dev/hda6,hda6,w'',
> ''file:/xen/disk-images/dom1.fs,sda1,w'']
> ...but no luck there.
>
>
> Rob
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ryan Grimm wrote:> > I don''t know what the desired behavior should be, but good point about > the two disk statements...i am able to now get the desired behavior by > using one like you suggested. > > mine now looks like: > > disk = [ ''phy:sda3,hda1,w'', ''file:/path/to/image,hda1,w'' ] > > so i dont need the /dev in front of sda3 after all...but i think that > if you export hda6 as hda6, you need to specify hda6 instead of sda1. > so i think your disk and root statements should be: > > disk = [ ''phy:hda6,hda6,w'', > ''file:/xen/disk-images/dom1.fs,hda6,w''] > root = "/dev/hda6 ro"If you want to export a file to a domain, I don''t think you need to also export the underlying raw disk to the domain. At least you never had to do that before. Anyway, I tried this, and it still does not fix my problem. No matter what I do, the domain does not see any virtual block device and so cannot boot. This must be due to some new behavior of some component. I''ve got an older installation of xen-unstable from Sep. 21 and it works fine with the identical config file. Can anyone suggest a clue to this problem????? Boot messages attached below. Rob [root@localhost xen]# xm create -f /xen/dom1-3.0 vmid=1 -c Using config file "/xen/dom1-3.0". Started domain Rob-VM1 Linux version 2.6.12-xenU (rdg@cordoba) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 SMP Wed Oct 12 09:37:41 MDT 2005 BIOS-provided physical RAM map: Xen: 0000000000000000 - 0000000008000000 (usable) 0MB HIGHMEM available. 128MB LOWMEM available. IRQ lockup detection disabled Built 1 zonelists Kernel command line: ip=15.6.247.101:1.2.3.4:15.6.247.1:255.255.255.0:vm1:eth0:off root=/dev/sda1 ro 4 VMID=1 Initializing CPU#0 PID hash table entries: 1024 (order: 10, 16384 bytes) Xen reported: 2660.168 MHz processor. Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) vmalloc area: c8800000-fb7fe000, maxmem 34000000 Memory: 126336k/131072k available (1771k kernel code, 4476k reserved, 584k data, 140k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Mount-cache hash table entries: 512 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking ''hlt'' instruction... disabled CPU0: Intel(R) Pentium(R) 4 CPU 2.66GHz stepping 09 Total of 1 processors activated (5308.41 BogoMIPS). Brought up 1 CPUs NET: Registered protocol family 16 xen_mem: Initialising balloon driver. Grant table initialized Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Xen virtual console successfully installed as tty1 Event-channel device installed. xen_blk: Initialising virtual block device driver xen_net: Initialising virtual ethernet driver. NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 8Kbytes TCP established hash table entries: 8192 (order: 5, 131072 bytes) TCP bind hash table entries: 8192 (order: 4, 98304 bytes) TCP: Hash tables configured (established 8192 bind 8192) NET: Registered protocol family 1 NET: Registered protocol family 17 IP-Config: Complete: device=eth0, addr=15.6.247.101, mask=255.255.255.0, gw=15.6.247.1, host=vm1, domain=, nis-domain=(none), bootserver=1.2.3.4, rootserver=1.2.3.4, rootpathLooking up port of RPC 100003/2 on 1.2.3.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2005-10-12 at 14:57 -0600, Rob Gardner wrote:> Ryan Grimm wrote: > > > > > I don''t know what the desired behavior should be, but good point about > > the two disk statements...i am able to now get the desired behavior by > > using one like you suggested. > > > > mine now looks like: > > > > disk = [ ''phy:sda3,hda1,w'', ''file:/path/to/image,hda1,w'' ] > > > > so i dont need the /dev in front of sda3 after all...but i think that > > if you export hda6 as hda6, you need to specify hda6 instead of sda1. > > so i think your disk and root statements should be: > > > > disk = [ ''phy:hda6,hda6,w'', > > ''file:/xen/disk-images/dom1.fs,hda6,w''] > > root = "/dev/hda6 ro" >Do not or use any existing designations or reuse any for domU''s. In your case I am assuming you have a /dev/hda. edit the domU fstab to /dev/sda1 for / and dev/sda2 for swap and the domu config accordingly. Do not use sda1 or sda2 for any additional domU''s. I will open up a bug on this shortly, this was bugging me for a while, but with this workaround my domu''s now come up 100% of the time every time. Regards, Ted _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ted Kaczmarek wrote:> >Do not or use any existing designations or reuse any for domU''s. >In your case I am assuming you have a /dev/hda. > >edit the domU fstab to /dev/sda1 for / and dev/sda2 for swap and the >domu config accordingly. > >Do not use sda1 or sda2 for any additional domU''s. > >I will open up a bug on this shortly, this was bugging me for a while, >but with this workaround my domu''s now come up 100% of the time every >time. > >What was the exact failure mode you observed? It doesn''t seem like it''s the same problem I''m seeing... My domU doesn''t get booted to anywhere near the point where fstab would make a difference. After the message: xen_blk: Initialising virtual block device driver There is no message like: Registering block device major xxx Which looks to me like the kernel is simply not finding any block device at all. Presumably this is because xen didn''t provide one for it. Why it does that, I don''t know. But it used to work just fine a few weeks ago. Rob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2005-10-12 at 15:48 -0600, Rob Gardner wrote:> Ted Kaczmarek wrote: > > > > >Do not or use any existing designations or reuse any for domU''s. > >In your case I am assuming you have a /dev/hda. > > > >edit the domU fstab to /dev/sda1 for / and dev/sda2 for swap and the > >domu config accordingly. > > > >Do not use sda1 or sda2 for any additional domU''s. > > > >I will open up a bug on this shortly, this was bugging me for a while, > >but with this workaround my domu''s now come up 100% of the time every > >time. > > > > > > What was the exact failure mode you observed? It doesn''t seem like it''s > the same problem I''m seeing... > > My domU doesn''t get booted to anywhere near the point where fstab would > make a difference. After the message: > xen_blk: Initialising virtual block device driver > There is no message like: > Registering block device major xxx > Which looks to me like the kernel is simply not finding any block device > at all. Presumably this is because xen didn''t provide one for it. Why it > does that, I don''t know. But it used to work just fine a few weeks ago. > > Rob >Mine where failing at unable to mount root device so it is likely you are having something else happen, unless the pollution is related. What changeset are you using? Did your kernel config work before? My Xen domO CONFIG_XEN_PRIVILEGED_GUEST=y CONFIG_XEN_PHYSDEV_ACCESS=y CONFIG_XEN_BLKDEV_BACKEND=y # CONFIG_XEN_BLKDEV_TAP_BE is not set CONFIG_XEN_NETDEV_BACKEND=y # CONFIG_XEN_TPMDEV_FRONTEND is not set # CONFIG_XEN_TPMDEV_BACKEND is not set CONFIG_XEN_BLKDEV_FRONTEND=y # CONFIG_XEN_NETDEV_FRONTEND is not set # CONFIG_XEN_BLKDEV_TAP is not set # CONFIG_XEN_SHADOW_MODE is not set CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_X86=y # CONFIG_XEN_X86_64 is not set CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y My xen domU # CONFIG_XEN_PRIVILEGED_GUEST is not set # CONFIG_XEN_PHYSDEV_ACCESS is not set # CONFIG_XEN_TPMDEV_FRONTEND is not set # CONFIG_XEN_TPMDEV_BACKEND is not set CONFIG_XEN_BLKDEV_FRONTEND=y CONFIG_XEN_NETDEV_FRONTEND=y # CONFIG_XEN_NETDEV_FRONTEND_PIPELINED_TRANSMITTER is not set # CONFIG_XEN_BLKDEV_TAP is not set # CONFIG_XEN_SHADOW_MODE is not set CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_X86=y # CONFIG_XEN_X86_64 is not set CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y Might also help to try a loop image as well and see if that will play nice. Regards, Ted _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ted Kaczmarek wrote:> >What changeset are you using? > >4e335372ace8 Note that I got this by just doing ''hg clone http://xenbits.xensource.com/xen-unstable.hg'' I did not change a thing, just did a make world and installed the stuff. (Am I wrong to assume that this procedure will produce a xen that works?)>Did your kernel config work before? > >I had no special config, just was using whatever the default is in the repository I cloned.>My Xen domO > >CONFIG_XEN_PRIVILEGED_GUEST=y >CONFIG_XEN_PHYSDEV_ACCESS=y >CONFIG_XEN_BLKDEV_BACKEND=y ># CONFIG_XEN_BLKDEV_TAP_BE is not set >CONFIG_XEN_NETDEV_BACKEND=y ># CONFIG_XEN_TPMDEV_FRONTEND is not set ># CONFIG_XEN_TPMDEV_BACKEND is not set >CONFIG_XEN_BLKDEV_FRONTEND=y ># CONFIG_XEN_NETDEV_FRONTEND is not set ># CONFIG_XEN_BLKDEV_TAP is not set ># CONFIG_XEN_SHADOW_MODE is not set >CONFIG_XEN_SCRUB_PAGES=y >CONFIG_XEN_X86=y ># CONFIG_XEN_X86_64 is not set >CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y > >My xen dom0: CONFIG_XEN_PRIVILEGED_GUEST=y CONFIG_XEN_PHYSDEV_ACCESS=y CONFIG_XEN_BLKDEV_BACKEND=y # CONFIG_XEN_BLKDEV_TAP_BE is not set CONFIG_XEN_NETDEV_BACKEND=y # CONFIG_XEN_TPMDEV_FRONTEND is not set # CONFIG_XEN_TPMDEV_BACKEND is not set CONFIG_XEN_BLKDEV_FRONTEND=y CONFIG_XEN_NETDEV_FRONTEND=y # CONFIG_XEN_NETDEV_FRONTEND_PIPELINED_TRANSMITTER is not set # CONFIG_XEN_BLKDEV_TAP is not set # CONFIG_XEN_SHADOW_MODE is not set CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_X86=y # CONFIG_XEN_X86_64 is not set CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y> >My xen domU > ># CONFIG_XEN_PRIVILEGED_GUEST is not set ># CONFIG_XEN_PHYSDEV_ACCESS is not set ># CONFIG_XEN_TPMDEV_FRONTEND is not set ># CONFIG_XEN_TPMDEV_BACKEND is not set >CONFIG_XEN_BLKDEV_FRONTEND=y >CONFIG_XEN_NETDEV_FRONTEND=y ># CONFIG_XEN_NETDEV_FRONTEND_PIPELINED_TRANSMITTER is not set ># CONFIG_XEN_BLKDEV_TAP is not set ># CONFIG_XEN_SHADOW_MODE is not set >CONFIG_XEN_SCRUB_PAGES=y >CONFIG_XEN_X86=y ># CONFIG_XEN_X86_64 is not set >CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y > > >My xen domU: # CONFIG_XEN_PRIVILEGED_GUEST is not set # CONFIG_XEN_PHYSDEV_ACCESS is not set # CONFIG_XEN_TPMDEV_FRONTEND is not set # CONFIG_XEN_TPMDEV_BACKEND is not set CONFIG_XEN_BLKDEV_FRONTEND=y CONFIG_XEN_NETDEV_FRONTEND=y # CONFIG_XEN_NETDEV_FRONTEND_PIPELINED_TRANSMITTER is not set # CONFIG_XEN_BLKDEV_TAP is not set # CONFIG_XEN_SHADOW_MODE is not set CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_X86=y # CONFIG_XEN_X86_64 is not set CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y>Might also help to try a loop image as well and see if that will play >nice. > >That''s what I''m doing. My config file looks like this: ...snip... xm_vars.check() kernel = "/boot/vmlinuz-2.6.12-xenU" memory = 128 name = "Rob-VM%d" % vmid cpu = vmid # set based on vmid (mod number of CPUs) nics=1 disk = [ ''file:/xen/disk-images/dom1.fs,sda1,w''] ip = add_offset_to_ip(get_current_ipaddr(),vmid) netmask = get_current_ipmask() gateway = get_current_ipgw() hostname= "vm%d" % vmid root = "/dev/sda1 ro" extra = "4 VMID=%d" % vmid Here''s another bit of info... running ''xm block-list'' on the domU that doesn''t boot successfully gives: (2065 ((virtual-device 2065) (backend-id 0) (backend /local/domain/0/backend/vbd/1/2065) (ring-ref 8) (event-channel 6) (error ''2 reading backend fields at /local/domain/0/backend/vbd/1/2065''))) Rob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel