I'm following the NetBSD/Xen HOWTO. Domain0 is running NetBSD CURRENT. $ xm list Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 64 0 r---- 7.5 My config file is at the end of this E-mail. I initialize the kernel's memory disk: # mdsetimage /netbsd-INSTALL_XENU \ /import/CURRENT/src/distrib/i386/floppies/ramdisk-big/obj/ramdisk-big.fs and then when I type: # xm create -c green Using config file "/etc/xen/green". the computer locks up with no indication of what is occurring. Does this look familiar to anyone? Config file "green": # -*- mode: python; -*- #============================================================================ # Python defaults setup for 'xm create'. # Edit this file to reflect the configuration of your system. #============================================================================ #---------------------------------------------------------------------------- # Kernel image file. This kernel will be loaded in the new domain. #kernel = "/netbsd-XENU" kernel = "/netbsd-INSTALL_XENU" # Memory allocation (in megabytes) for the new domain. memory = 128 # A handy name for your new domain. This will appear in 'xm list', # and you can use this as parameters for xm in place of the domain # number. All domains must have different names. # name = "green" # Which CPU to start domain on (only relevant for SMP hardware). CPUs # numbered starting from ``0''. # cpu = -1 # leave to Xen to pick #---------------------------------------------------------------------------- # Define network interfaces for the new domain. # Number of network interfaces (must be at least 1). Default is 1. nics = 1 # Define MAC and/or bridge for the network interfaces. # # The MAC address specified in ``mac'' is the one used for the interface # in the new domain. The interface in domain0 will use this address XOR'd # with 00:00:00:01:00:00 (i.e. aa:00:00:51:02:f0 in our example). Random # MACs are assigned if not given. # # ``bridge'' is a required parameter, which will be passed to the # vif-script called by xend(8) when a new domain is created to configure # the new xvif interface in domain0. # # In this example, the xvif is added to bridge0, which should have been # set up prior to the new domain being created -- either in the # ``network'' script or using a /etc/ifconfig.bridge0 file. # vif = [ 'mac=aa:00:00:00:00:06, bridge=bridge0' ] #---------------------------------------------------------------------------- # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # # Each disk entry is of the form: # # phy:DEV,VDEV,MODE # # where DEV is the device, VDEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. You can also create # file-backed domains using disk entries of the form: # # file:PATH,VDEV,MODE # # where PATH is the path to the file used as the virtual disk, and VDEV # and MODE have the same meaning as for ``phy'' devices. # # VDEV doesn't really matter for a NetBSD guest OS, but it does for Linux. # Worse, the device has to exists in /dev/ of domain0, because xm will # try to stat() it. This means that in order to load a Linux guest OS # from a NetBSD domain0, you'll have to create /dev/hda1, /dev/hda2, ... # on domain0, with the major/minor from Linux :(#disk = [ 'phy:/dev/wd0g,wd0d,w', 'phy:/dev/ld0a,ld0d,w', 'phy:/dev/ld0f,ld1d,w', 'phy:/dev/ld0h,ld2d,w' ]
disk = [ 'phy:/dev/wd0g,wd0d,w' ] #---------------------------------------------------------------------------- # Set the kernel command line for the new domain. # Set root device. This one does matter for NetBSD root = "/dev/wd0d" # extra parameters passed to the kernel #extra = "" #---------------------------------------------------------------------------- # Set according to whether you want the domain restarted when it exits. # The default is False. #autorestart = True# end of nbsd config file ====================================================
-- John R. Shannon
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature