[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH DOCDAY] introduce an xl man page in pod format
On Fri, 28 Oct 2011, Ian Campbell wrote: > On Thu, 2011-10-27 at 17:19 +0100, Stefano Stabellini wrote: > > This is the initial version of an xl man page, based on the old xm man > > page. > > Almost every command implemented in xl should be present, a notable > > exception are the tmem commands that are currently missing. > > I think it's worth enumerating all the commands, even with a TBD, since > it marks what is missing. the only ones that are missing are the tmem commands so I am going to add them > > Further improvements and clarifications to this man page are very welcome. > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> > > > > diff -r 39aa9b2441da docs/man/xl.pod.1 > > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > > +++ b/docs/man/xl.pod.1 Thu Oct 27 15:59:03 2011 +0000 > > @@ -0,0 +1,805 @@ > > +=head1 NAME > > + > > +XL - Xen management tool, based on LibXenlight > > + > > +=head1 SYNOPSIS > > + > > +B<xl> I<subcommand> [I<args>] > > B<xl> [I<global-args>] I<subcommand> [I<args>] > > The interesting global-args are -v (verbose, can be used repeatedly) and > -N (dry-run). OK > > + > > +=head1 DESCRIPTION > > + > > +The B<xl> program is the new tool for managing Xen guest > > +domains. The program can be used to create, pause, and shutdown > > +domains. It can also be used to list current domains, enable or pin > > +VCPUs, and attach or detach virtual block devices. > > +The old B<xm> tool is deprecated and should not be used. > > + > > +The basic structure of every B<xl> command is almost always: > > + > > +=over 2 > > + > > +B<xl> I<subcommand> [I<OPTIONS>] I<domain-id> > > + > > +=back > > + > > +Where I<subcommand> is one of the subcommands listed below, I<domain-id> > > +is the numeric domain id, or the domain name (which will be internally > > +translated to domain id), and I<OPTIONS> are subcommand specific > > +options. There are a few exceptions to this rule in the cases where > > +the subcommand in question acts on all domains, the entire machine, > > +or directly on the Xen hypervisor. Those exceptions will be clear for > > +each of those subcommands. > > + > > +=head1 NOTES > > + > > +Most B<xl> operations rely upon B<xenstored> and B<xenconsoled>: make > > +sure you start the script B</etc/init.d/xencommons> at boot time to > > +initialize all the daemons needed by B<xl>. > > + > > +In the most common network configuration, you need to setup a bridge in > > dom0 > > +named B<xenbr0> in order to have a working network in the guest domains. > > +Please refer to the documentation of your Linux distribution to know how to > > +setup the bridge. > > + > > +Most B<xl> commands require root privileges to run due to the > > +communications channels used to talk to the hypervisor. Running as > > +non root will return an error. > > + > > +=head1 DOMAIN SUBCOMMANDS > > + > > +The following subcommands manipulate domains directly. As stated > > +previously, most commands take I<domain-id> as the first parameter. > > + > > +=over 4 > > + > > +=item B<create> [I<OPTIONS>] I<configfile> > > The I<configfile> is optional and if it present it must come before the > options. > In addition to the normal --option stuff you can also pass key=value to > provide options as if they were written in a configuration file, these > override whatever is in the config file. OK > While checking this I noticed that before processing arguments > main_create() does: > > if (argv[1] && argv[1][0] != '-' && !strchr(argv[1], '=')) { > filename = argv[1]; > argc--; argv++; > } > > that use of argv[1] without checking argc is a little dubious (ok if > argc<1 then argc==0 and therefore argv[argc+1]==NULL, but still...). > > > + > > +The create subcommand requires a config file: see L<xldomain.cfg> for > > +full details of that file format and possible options. > > + > > +I<configfile> can either be an absolute path to a file, or a relative > > +path to a file located in /etc/xen. > > This isn't actually true for xl. Arguably that's a bug in xl rather than > this doc but I seem to recall that someone had a specific reason for not > doing this. OK, I am going to update the doc > > + > > +Create will return B<as soon> as the domain is started. This B<does > > +not> mean the guest OS in the domain has actually booted, or is > > +available for input. > > + > > +B<OPTIONS> > > + > > +=over 4 > > + > > +=item B<-q>, B<--quiet> > > + > > +No console output. > > + > > +=item B<-f=FILE>, B<--defconfig=FILE> > > + > > +Use the given configuration file. > > + > > +=item B<-n>, B<--dryrun> > > + > > +Dry run - prints the resulting configuration in SXP but does not create > > +the domain. > > + > > +=item B<-p> > > + > > +Leave the domain paused after it is created. > > + > > +=item B<-c> > > + > > +Attach console to the domain as soon as it has started. This is > > +useful for determining issues with crashing domains. > > ... and just as a general convenience since you often want to watch the > domain boot. OK > > + > > +=back > > + > > +B<EXAMPLES> > > + > > +=over 4 > > + > > +=item I<with config file> > > + > > + xl create DebianLenny > > + > > +This creates a domain with the file /etc/xen/DebianLenny, and returns as > > +soon as it is run. > > + > > +=back > > + > > +=item B<console> I<domain-id> > > + > > +Attach to domain I<domain-id>'s console. If you've set up your domains to > > +have a traditional log in console this will look much like a normal > > +text log in screen. > > + > > +Use the key combination Ctrl+] to detach the domain console. > > This takes -t [pv|serial] and -n (num) options. I'll add those options > > + > > +=item B<vncviewer> [I<OPTIONS>] I<domain-id> > > + > > +Attach to domain's VNC server, forking a vncviewer process. > > + > > +B<OPTIONS> > > + > > +=over 4 > > + > > +=item I<--autopass> > > + > > +Pass VNC password to vncviewer via stdin. > > What is the behaviour if you don't do this? I am not sure. Maybe Ian knows. > Are the sub-commands intended to be in some sort of order. In general > they seem to be alphabetical but in that case vncviewer does not belong > here. I'll order them alphabetically. > [...] > > +=item B<list> [I<OPTIONS>] [I<domain-id> ...] > > + > > +Prints information about one or more domains. If no domains are > > +specified it prints out information about all domains. > > + > > + > > +B<OPTIONS> > > + > > +=over 4 > > + > > +=item B<-l>, B<--long> > > + > > +The output for B<xl list> is not the table view shown below, but > > +instead presents the data in SXP compatible format. > > + > > +=item B<-Z>, B<--context> > > +Also prints the security labels. > > + > > +=item B<-v>, B<--verbose> > > + > > +Also prints the domain UUIDs, the shutdown reason and security labels. > > + > > +=back > > + > > +B<EXAMPLE> > > + > > +An example format for the list is as follows: > > + > > + Name ID Mem VCPUs State > > Time(s) > > + Domain-0 0 750 4 r----- > > 11794.3 > > + win 1 1019 1 r----- > > 0.3 > > + linux 2 2048 2 r----- > > 5624.2 > > + > > +Name is the name of the domain. ID the numeric domain id. Mem is the > > +desired amount of memory to allocate to the domain (although it may > > +not be the currently allocated amount). VCPUs is the number of > > +virtual CPUs allocated to the domain. State is the run state (see > > +below). Time is the total run time of the domain as accounted for by > > +Xen. > > + > > +B<STATES> > > + > > +The State field lists 6 states for a Xen domain, and which ones the > > +current domain is in. > > + > > +=over 4 > > + > > +=item B<r - running> > > + > > +The domain is currently running on a CPU. > > + > > +=item B<b - blocked> > > + > > +The domain is blocked, and not running or runnable. This can be caused > > +because the domain is waiting on IO (a traditional wait state) or has > > +gone to sleep because there was nothing else for it to do. > > + > > +=item B<p - paused> > > + > > +The domain has been paused, usually occurring through the administrator > > +running B<xl pause>. When in a paused state the domain will still > > +consume allocated resources like memory, but will not be eligible for > > +scheduling by the Xen hypervisor. > > + > > +=item B<s - shutdown> > > + > > +FIXME: Why would you ever see this state? > > This is XEN_DOMINF_shutdown which just says "/* The guest OS has shut > down. */". It is set in response to the guest calling SCHEDOP_shutdown. > I think it corresponds to the period between the guest shutting down and > the toolstack noticing and beginning to tear it down (when it moves to > dying). OK > > +=item B<c - crashed> > > + > > +The domain has crashed, which is always a violent ending. Usually > > +this state can only occur if the domain has been configured not to > > +restart on crash. See L<xldomain.cfg> for more info. > > + > > +=item B<d - dying> > > + > > +The domain is in process of dying, but hasn't completely shutdown or > > +crashed. > > + > > +FIXME: Is this right? > > I think so. This is XEN_DOMINF_dying which says "/* Domain is scheduled > to die. */" OK > > + > > +=item B<migrate> [I<OPTIONS>] I<domain-id> I<host> > > + > > +Migrate a domain to another host machine. By default B<xl> relies on ssh > > as a > > +transport mechanism between the two hosts. > > + > > +B<OPTIONS> > > + > > +=over 4 > > + > > +=item B<-s> I<sshcommand> > > + > > +Use <sshcommand> instead of ssh. String will be passed to sh. If empty, > > run > > +<host> instead of ssh <host> xl migrate-receive [-d -e]. > > + > > +=item B<-e> > > + > > +On the new host, do not wait in the background (on <host>) for the death > > of the > > +domain. > > Would be useful to reference the equivalent option to "xl create" here > just to clarify that they mean the same. Yes, good idea. > > +=item B<reboot> [I<OPTIONS>] I<domain-id> > > + > > +Reboot a domain. This acts just as if the domain had the B<reboot> > > +command run from the console. > > This relies on PV drivers, I think. yes, I'll add that > Not all guests have the option of typing "reboot" on the console but I > suppose it is clear enough what you mean. > > > The command returns as soon as it has > > +executed the reboot action, which may be significantly before the > > +domain actually reboots. > > + > > +The behavior of what happens to a domain when it reboots is set by the > > +B<on_reboot> parameter of the xldomain.cfg file when the domain was > > +created. > > + > > +=item B<restore> [I<OPTIONS>] [I<ConfigFile>] I<CheckpointFile> > > + > > +Build a domain from an B<xl save> state file. See B<save> for more info. > > + > > +B<OPTIONS> > > + > > +=over 4 > > + > > +=item B<-p> > > + > > +Do not unpause domain after restoring it. > > + > > +=item B<-e> > > + > > +Do not wait in the background for the death of the domain on the new host. > > Reference xl create? > yep > > + > > +=item B<-d> > > + > > +Enable debug messages. > > + > > +=back > > + > > +=item B<save> [I<OPTIONS>] I<domain-id> I<CheckpointFile> [I<ConfigFile>] > > + > > +Saves a running domain to a state file so that it can be restored > > +later. Once saved, the domain will no longer be running on the > > +system, unless the -c option is used. > > +B<xl restore> restores from this checkpoint file. > > +Passing a config file argument allows the user to manually select the VM > > config > > +file used to create the domain. > > + > > + > > +=over 4 > > + > > +=item B<-c> > > + > > +Leave domain running after creating the snapshot. > > + > > +=back > > + > > + > > +=item B<shutdown> [I<OPTIONS>] I<domain-id> > > + > > +Gracefully shuts down a domain. This coordinates with the domain OS > > +to perform graceful shutdown, so there is no guarantee that it will > > +succeed, and may take a variable length of time depending on what > > +services must be shutdown in the domain. The command returns > > +immediately after signally the domain unless that B<-w> flag is used. > > Does this rely on pv drivers or does it inject ACPI events etc on HVM? Yes, it requires PV drivers, I'll add that. > > + > > +The behavior of what happens to a domain when it reboots is set by the > behaviour ? > > > +B<on_shutdown> parameter of the xldomain.cfg file when the domain was > > +created. > > + > > +B<OPTIONS> > > + > > +=over 4 > > + > > +=item B<-w> > > + > > +Wait for the domain to complete shutdown before returning. > > + > > +=back > > + > > +=item B<sysrq> I<domain-id> I<letter> > > + > > +Send a I<Magic System Request> signal to the domain. For more > > +information on available magic sys req operations, see sysrq.txt in > > +your Linux Kernel sources. > > It would be nice to word this in a more generic fashion and point out > that the specific implementation on Linux behaves like sysrq. Other > guests might do other things? > > Relies on PV drivers. OK > > [...] > > + > > +=item B<vcpu-set> I<domain-id> I<vcpu-count> > > + > > +Enables the I<vcpu-count> virtual CPUs for the domain in question. > > +Like mem-set, this command can only allocate up to the maximum virtual > > +CPU count configured at boot for the domain. > > + > > +If the I<vcpu-count> is smaller than the current number of active > > +VCPUs, the highest number VCPUs will be hotplug removed. This may be > > +important for pinning purposes. > > + > > +Attempting to set the VCPUs to a number larger than the initially > > +configured VCPU count is an error. Trying to set VCPUs to < 1 will be > > +quietly ignored. > > + > > +Because this operation requires cooperation from the domain operating > > +system, there is no guarantee that it will succeed. This command will > > +not work with a full virt domain. > > I thought we supported some VCPU hotplug for HVM (using ACPI and such) > these days? Yes you are right, I'll remove it. > [...] > > +=item B<button-press> I<domain-id> I<button> > > + > > +Indicate an ACPI button press to the domain. I<button> is may be 'power' or > > +'sleep'. > > HVM only? yes > > + > > +=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep> [I<VCPU>] > > + > > +Send a trigger to a domain, where the trigger can be: nmi, reset, init, > > power > > +or sleep. Optionally a specific vcpu number can be passed as an argument. > > HVM only? nmi might work for PV, not sure about the rest. I think the current implementation is HVM only > > +=item B<getenforce> > > + > > +Returns the current enforcing mode of the Flask Xen security module. > > + > > +=item B<setenforce> I<1|0|Enforcing|Permissive> > > + > > +Sets the current enforcing mode of the Flask Xen security module > > + > > +=item B<loadpolicy> I<policyfile> > > + > > +Loads a new policy int the Flask Xen security module. > > I suppose flask is something which needs to go onto the "to be > documented" list such that we can reference it from here. I am going to add a TO BE DOCUMENTED section at the end > > +=back > > + > > +=head1 XEN HOST SUBCOMMANDS > > + > > +=over 4 > > + > > +=item B<debug-keys> I<keys> > > + > > +Send debug I<keys> to Xen. > > The same as pressing the Xen "conswitch" (Ctrl-A by default) three times > and then pressing "keys". I'll add that > > + > > +=item B<dmesg> [B<-c>] > > + > > +Reads the Xen message buffer, similar to dmesg on a Linux system. The > dmesg(1) ^Unix or ;-) > > > +buffer contains informational, warning, and error messages created > > +during Xen's boot process. If you are having problems with Xen, this > > +is one of the first places to look as part of problem determination. > > + > > +B<OPTIONS> > > + > > +=over 4 > > + > > +=item B<-c>, B<--clear> > > + > > +Clears Xen's message buffer. > > + > > +=back > > + > > +=item B<info> [B<-n>, B<--numa>] > > + > > +Print information about the Xen host in I<name : value> format. When > > +reporting a Xen bug, please provide this information as part of the > > +bug report. > > I'm not sure this is useful people reporting bugs will look for > information on reporting bugs (which should include this info) rather > than scanning the xl man page for options which say "please include.." > > I have added the need for this to > http://wiki.xen.org/xenwiki/ReportingBugs OK > > + > > +Sample output looks as follows (lines wrapped manually to make the man > > +page more readable): > > > + > > + host : talon > > + release : 2.6.12.6-xen0 > > Heh. Perhaps a more up to date example if one is needed at all? Good point > > + version : #1 Mon Nov 14 14:26:26 EST 2005 > > + machine : i686 > > + nr_cpus : 2 > > + nr_nodes : 1 > > + cores_per_socket : 1 > > + threads_per_core : 1 > > + cpu_mhz : 696 > > + hw_caps : 0383fbff:00000000:00000000:00000040 > > + total_memory : 767 > > + free_memory : 37 > > + xen_major : 3 > > + xen_minor : 0 > > + xen_extra : -devel > > + xen_caps : xen-3.0-x86_32 > > + xen_scheduler : credit > > + xen_pagesize : 4096 > > + platform_params : virt_start=0xfc000000 > > + xen_changeset : Mon Nov 14 18:13:38 2005 +0100 > > + 7793:090e44133d40 > > + cc_compiler : gcc version 3.4.3 (Mandrakelinux > > + 10.2 3.4.3-7mdk) > > + cc_compile_by : sdague > > + cc_compile_domain : (none) > > + cc_compile_date : Mon Nov 14 14:16:48 EST 2005 > > + xend_config_format : 4 > > + > > +B<FIELDS> > > + > > +Not all fields will be explained here, but some of the less obvious > > +ones deserve explanation: > > + > > +=over 4 > > + > > +=item B<hw_caps> > > + > > +A vector showing what hardware capabilities are supported by your > > +processor. This is equivalent to, though more cryptic, the flags > > +field in /proc/cpuinfo on a normal Linux machine. > > Does this correspond to some cpuid output somewhere? That might be a > good thing to reference. > > (checks, hmm, it all very processor specific) Yes, they do. I'll add a reference to that. > > +=back > > + > > +B<OPTIONS> > > + > > +=over 4 > > + > > +=item B<-n>, B<--numa> > > + > > +List host NUMA topology information > > + > > +=back > [...] > > > +=item B<pci-list-assignable-devices> > > + > > +List all the assignable PCI devices. > > Perhaps add: > That is, though devices in the system which are configured to be > available for passthrough and are bound to a suitable PCI > backend driver in domain 0 rather than a real driver. OK > > +=head1 CPUPOOLS COMMANDS > > + > > +Xen can group the physical cpus of a server in cpu-pools. Each physical > > CPU is > > +assigned at most to one cpu-pool. Domains are each restricted to a single > > +cpu-pool. Scheduling does not cross cpu-pool boundaries, so each cpu-pool > > has > > +an own scheduler. > > +Physical cpus and domains can be moved from one pool to another only by an > > +explicit command. > > + > > +=over 4 > > + > > +=item B<cpupool-create> [I<OPTIONS>] I<ConfigFile> > > + > > +Create a cpu pool based an I<ConfigFile>. > > + > > +B<OPTIONS> > > + > > +=over 4 > > + > > +=item B<-f=FILE>, B<--defconfig=FILE> > > + > > +Use the given configuration file. > > + > > +=item B<-n>, B<--dryrun> > > + > > +Dry run - prints the resulting configuration. > > Is this deprecated in favour of global -N option? I think it should be. Yeah, there is no point since we have a global option. > > + > > +=back > > + > > +=item B<cpupool-list> [I<-c|--cpus> I<cpu-pool>] > > + > > +List CPU pools on the host. > > +If I<-c> is specified, B<xl> prints a list of CPUs used by I<cpu-pool>. > > Is cpu-pool a name or a number, or both? (this info would be useful in > the intro to the section I suppose). I think it is a name, but I would need a confirmation from Juergen. > > + > > +=item B<cpupool-destroy> I<cpu-pool> > > + > > +Deactivates a cpu pool. > > + > > +=item B<cpupool-rename> I<cpu-pool> <newname> > > + > > +Renames a cpu pool to I<newname>. > > + > > +=item B<cpupool-cpu-add> I<cpu-pool> I<cpu-nr|node-nr> > > + > > +Adds a cpu or a numa node to a cpu pool. > > + > > +=item B<cpupool-cpu-remove> I<cpu-nr|node-nr> > > + > > +Removes a cpu or a numa node from a cpu pool. > > + > > +=item B<cpupool-migrate> I<domain-id> I<cpu-pool> > > + > > +Moves a domain into a cpu pool. > > + > > +=item B<cpupool-numa-split> > > + > > +Splits up the machine into one cpu pool per numa node. > > + > > +=back > > + > > +=head1 VIRTUAL DEVICE COMMANDS > > + > > +Most virtual devices can be added and removed while guests are > > +running. > > ... assuming the necessary support exists in the guest. > OK > > The effect to the guest OS is much the same as any hotplug > > +event. > > + > > +=head2 BLOCK DEVICES > > + > > +=over 4 > > + > > +=item B<block-attach> I<domain-id> I<disc-spec-component(s)> ... > > + > > +Create a new virtual block device. This will trigger a hotplug event > > +for the guest. > > Should add a reference to the docs/misc/xl-disk-configuration.txt doc to > your SEE ALSO section. OK > > + > > +B<OPTIONS> > > + > > +=over 4 > > + > > +=item I<domain-id> > > + > > +The domain id of the guest domain that the device will be attached to. > > + > > +=item I<disc-spec-component> > > + > > +A disc specification in the same format used for the B<disk> variable in > > +the domain config file. See L<xldomain.cfg>. > > + > > +=back > > + > > +=item B<block-detach> I<domain-id> I<devid> [B<--force>] > > + > > +Detach a domain's virtual block device. I<devid> may be the symbolic > > +name or the numeric device id given to the device by domain 0. You > > +will need to run B<xl block-list> to determine that number. > > + > > +Detaching the device requires the cooperation of the domain. If the > > +domain fails to release the device (perhaps because the domain is hung > > +or is still using the device), the detach will fail. The B<--force> > > +parameter will forcefully detach the device, but may cause IO errors > > +in the domain. > > + > > +=item B<block-list> I<domain-id> > > + > > +List virtual block devices for a domain. > > + > > +=item B<cd-insert> I<domain-id> I<VirtualDevice> I<be-dev> > > + > > +Insert a cdrom into a guest domain's cd drive. Only works with HVM domains. > > + > > +B<OPTIONS> > > + > > +=over 4 > > + > > +=item I<VirtualDevice> > > + > > +How the device should be presented to the guest domain; for example > > /dev/hdc. > > + > > +=item I<be-dev> > > + > > +the device in the backend domain (usually domain 0) to be exported; it can > > be a > > +path to a file (file://path/to/file.iso). See B<disk> in L<xldomain.cfg> > > for the > > +details. > > + > > +=back > > + > > +=item B<cd-eject> I<domain-id> I<VirtualDevice> > > + > > +Eject a cdrom from a guest's cd drive. Only works with HVM domains. > > +I<VirtualDevice> is the cdrom device in the guest to eject. > > + > > +=back > > + > > +=head2 NETWORK DEVICES > > + > > +=over 4 > > + > > +=item B<network-attach> I<domain-id> I<network-device> > > + > > +Creates a new network device in the domain specified by I<domain-id>. > > +I<network-device> describes the device to attach, using the same format as > > the > > +B<vif> string in the domain config file. See L<xldomain.cfg> for the > > +description. > > I sent out a patch to add docs/misc/xl-network-configuration.markdown as > well. I'll add a reference to it > > + > > +=item B<network-detach> I<domain-id> I<devid|mac> > > + > > +Removes the network device from the domain specified by I<domain-id>. > > +I<devid> is the virtual interface device number within the domain > > +(i.e. the 3 in vif22.3). Alternatively the I<mac> address can be used to > > +select the virtual interface to detach. > > + > > +=item B<network-list> I<domain-id> > > + > > +List virtual network interfaces for a domain. > > + > > +=back > > + > > +=head2 PCI PASS-THROUGH > > + > > +=over 4 > > + > > +=item B<pci-attach> I<domain-id> I<BDF> > > + > > +Hot-plug a new pass-through pci device to the specified domain. > > +B<BDF> is the PCI Bus/Device/Function of the physical device to > > pass-through. > > + > > +=item B<pci-detach> [I<-f>] I<domain-id> I<BDF> > > + > > +Hot-unplug a previously assigned pci device from a domain. B<BDF> is the > > PCI > > +Bus/Device/Function of the physical device to be removed from the guest > > domain. > > + > > +If B<-f> is specified, B<xl> is going to forcefully remove the device even > > +without guest's collaboration. > > + > > +=item B<pci-list> I<domain-id> > > + > > +List pass-through pci devices for a domain. > > + > > +=back > > + > > +=head1 SEE ALSO > > + > > +B<xldomain.cfg>(5), B<xentop>(1) > > + > > +=head1 AUTHOR > > + > > + Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> > > + Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx> > > + Ian Jackson <ian.jackson@xxxxxxxxxxxxx> > > + Ian Campbell <Ian.Campbell@xxxxxxxxxx> > > This list seems so incomplete/unlikely to be updated that it may as well > not be included. (also I think AUTHOR in a man page refers to the author > of the page, not the authors of the software) OK, I'll remove it > > +=head1 BUGS > > + > > +Send bugs to xen-devel@xxxxxxxxxxxxxxxxxxxx > > Reference http://wiki.xen.org/xenwiki/ReportingBugs > Sure _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |