Previously, the default "network-script",
/etc/xen/scripts/network-bridge, would attempt to do its horrid work
even if you had already set everything up in /etc/network/interfaces.
Setting up your bridge in /etc/network/interfaces is:
* easy
* required for libxl since libxl never does it for you
* not a fragile piece of lunacy
* properly documented
* the way everyone would expect it to work
In this small patch we make it so that the default config for xend
doesn't mess about on startup if you already have a bridge, and
doesn't mess about on shutdown unless your first-named bridge (eth0 or
xenbr0, normally) doesn't also have a physical interface named
p<whatever> (peth0 or pxenbr0) enslaved to it. The latter test is not
ideal but will hopefully do from now until the time xend finally dies.
We also fix the "documentation" - ie, the comments in the default
xend-config.sxp - to correspond to reality.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Add a new feature for xend-relocation-address option to support
definition by interface name which can be useful for people having
e.g. a cluster environment with multiple network interfaces on all of
the machines with only one reserved to be registered to a private
cluster network. This way they won't need to specify the relocation
address manually on all the machines but just simple providing the
interface name to get the IP address from would do the job (all the
machines have to have this interface named the same to make it
working, of course).
Technically it reads the interface name and gets its IP address using
ioctl call of SIOCGIFADDR and if the interface doesn't have the
address, i.e. if non-existing interface or hostname was provided the
original ifname is returned to preserve the old behaviour.
Signed-off-by: Michal Novotny <minovotn@redhat.com>
The main idea of this patch is:
1) The admin sets aside some memory below 128G for 32-bit paravirtual
domain creation (via dom0_mem=-<value> in kernel comand line).
2) The admin also explicitly states to the tools (i..e xend) how much
memory is supposed to be left untouched by 64-bit domains
3) If a 32-bit pv DomU gets created, no ballooning ought to be
necessary (since if it is, no guarantee can be made about the address
range of the memory ballooned out), and memory gets allocated from the
reserved range.
4) Upon 64-bit (or 32-bit HVM or HVM) DomU creation, the tools
determine the amount of memory to be ballooned out of Dom0 by adding
the amount needed for the new guest and the amount still in the
reserved pool (and then of course subtracting the total amount of
memory the hypervisor has available for guest use).
Signed-off-by: james song (wei) <jsong@novell.com>
Currently when assigning device to HVM guest, we use the strict check
for HVM guest by default.(For PV guest we use loose check
automatically if necessary.)
When we assign device to HVM guest, if we meet with the co-assignment
issues or the ACS issue (see changeset 20081: 4a517458406f), we could
try changing the option to 'no' -- however, we have to realize this
may incur security issue and we can't make sure the device assignment
could really work properly even after we do this.
The option is located in /etc/xen/xend-config.sxp:
(pci-passthrough-strict-check yes)
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
* Change default settings to relative pathes.
* Make xend to prepend install directory if entries have no absolute
* path
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
In some configurations, when dom0 is busy with I/O, it may take
several minutes to complete all hotplug scripts required when a new
domain is being created. As device create timeout is set to 100
seconds, users get "hotplug scripts not working" error instead of a
new domain.
This patch makes both DEVICE_CREATE_TIMEOUT and DEVICE_DESTROY_TIMEOUT
configurable in xend-config.sxp to allow users to easily adapt hotplug
timeouts to their environment.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
When a udev event is received, udevevent.py parses the udev data and
tells XendNode.py to update the physical resource information.
This patch also add a boolean parameter 'xend-udev-event-server', to
let users indicate whether we should enable this function or not.
Signed-off-by: Yosuke Iwamatsu <y-iwamatsu@ab.jp.nec.com>
- The patch does away with the autogenerated xsm.py file and
introduces a config parameter in xend-config.sxp to determine the
security module. The parameter is (xsm_module_name {acm, dummy,
flask}). The default setting/option is dummy. .hgignore is also
updated to stop ignoring xsm.py on commits.
- The patch has created an xsconstant for XS_POLICY_FLASK and updated
the toolchain to check the instance of XS_POLICY_USE. XS_POLICY_USE
evalauates to XS_POLICY_FLASK or XS_POLICY_ACM or XS_POLICY_DUMMY
depending on configuration.
- Flask relies on the current value of ssidref returned by dominfo to
ensure that the label to sid mapping is consistent. ssidref had
been pop'ed from the dominfo object. The patch addresses this
issue.
- Flask python module style cleanups.
Signed-off-by: George Coker <gscoker@alpha.ncsc.mil>
This patch exposes the persistent (aka managed) domain path in xend
configuration file. This option is already supported in XendOptions
but is not annotated in the configuration file.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
This patch makes ssl relocation server listen on 8003 if enabled.
Whether to start ssl relocation server now controlled by
xend-relocation-ssl-server. So ssl and non-ssl relocation server can
run simultaneously. You can also only start ssl server or only start
non-ssl relocation server.
When mix deploy xen 3.2 server (has no ssl support) and 3.3 servers,
start ssl and non-ssl relocation server simultaneously can keep
backward compatibility.
It's also more reasonable to have separate ports for ssl and non-ssl.
In this patch, also renames xend-relocation-tls to xend-relocation-ssl.
Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
* SSL/TLS support is disabled by default, as other server did.
* If "xend-relocation-server-ssl-key-file" and
"xend-relocation-server-ssl-cert-file" exist, SSL/TLS is enabled
automatically.
* "xend-relocation-tls" is used by relocation client only.
Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
I have written a patch to split the current meaning of
"dom0-min-mem = 0" to a new option "enable-dom0-ballooning".
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
This patch adds support to XenD for configuring the previously added
TLS encryption and x509 certificate validation. At this time I have
only enabled this config to be done system-wide via
/etc/xen/xend-config.sxp. Since it requires the admin to add
certificates on the local FS, there's not much point in making it per
VM. The x509 certificates are located in /etc/xen/vnc. Since this
requires a special VNC client program (GTK-VNC,
virt-viewer/virt-manager or VeNCrypt viewer) the use of TLS is
disabled by default. Admins can enable it if they are using a suitable
client.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch triggers a script when a resource's label changes. The xend
config file should provide a variable 'resource-label-change-script'
that can then be launched.
Signed-off-by; Stefan Berger <stefanb@us.ibm.com>
Xen-API and legacy XML-RPC servers to set key and certificate files, and
xm simply needs to be configured use an https rather than an http URL.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
to use PAM, or to be turned off entirely, on a listener by listener basis.
Listen on a different unix domain socket for the Xen-API server, so that it
can co-exist with the others.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
code from the relocation protocol handling and some plumbing. Add a new
configuration entry for the Xen-API server, including use of this mechanism.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
that the VNC server from qemu listens on.
Defaults to only listen on 127.0.0.1
The old behaviour (listen on all interfaces) can be restored, by
- changing the system-wide default in /etc/xen/xend-config.sxp by adding:
(vnc-listen '0.0.0.0')
- changing individual domain config files by adding:
vnclisten="0.0.0.0"
Also allows specifying the hostname associated with an interface to limit
to that interface.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
be under /var/log/xen instead of under /var/log directly. This has
the advantage of cleaning things up a little and also can make it
easier to restrict the permissions needed by xend.
Signed-off-by: Jeremy Katz <katzj@redhat.com>
1) xend can't start due to xend-config.sxp
2) qemu dm option vncunused should be effective only
when vnc is turned on.
Signed-off-by: Xin Li <xin.b.li@intel.com>
drive image or a TPM, to be migrated to a remote machine. The patch
hooks into the checkpointing (XendCheckpoint.py) code and performs
migration in 4 different steps:
In a 1st step (step = 0 in the code) migration of all devices of a
domain is 'tested', that means their driver implementations (blkif.py,
netif.py, tpmif.py, usbif.py, pciif.py) are queried whether migration is
possible at all. Currently all device representations respond with a
'yes' (=0), although probably a VM mounting a hard drive partition
should respond with a 'no' (-1) already. This first step is a quick
check to see whether devices can be migrated.
The 2nd step is to do whatever can be done before the domain is
suspended. At this point migration of the device could be initiated, if
at all possible.
The 3rd step is to migrate a device after the domain has been suspended,
meaning that it is not scheduled anymore and the VM is 'settled'. All
devices are called again and a good implementation would initiate the
migration in a background process to achieve as much concurrency as
possible.
The 4th step is to synchronize with the 3rd step. At this point the
implementor has to make sure that anything that was initiated in step 3
has completed. Once all steps 4 have been processed, the VM will resume
on the remove machine.
I have implemented hooks for migration of a virtual TPM in
xen/xend/server/tpmif.py. These hooks call a configurable external
migration tool using the os.popen() call with a fixed command line
parameter set. The implementation refuses to migrate a VM attached to a
virtual TPM if no tool has been provided for migration.
All other devices do not currently overload the 'migrate' method defined
in the DevController.py and therefore will just let migration happen.
I have added hooks for error recovery such that whatever part of
migration has been initiated can be rolled back when any of the devices
fail to migrate in one of the steps. The interface (in tpmif.py) to the
external application now uses os.popen() to allow error handling by
reading the application's output.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
default network device available no matter the name. It can still
be configured if you want a specific network device.
Patch by Bill Nottingham <notting@redhat.com>.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
hotplug ones. Added evalVariables and findCommand functions to that, which we
use to clarify the handling of variables being passed in as command line
variables.
Make vif-bridge able to find the bridge for itself if only one bridge is in
use. This means that it is not necessary to specify a bridge in many
configurations. Allow the bridge to be specified on the command line, meaning
that a default may be provided in the xend-config.sxp if desired.
Added xenstore_read_default to xen-hotplug-common.sh, which reads from the
store but uses a given default if the path in the store is not present. This
is used by vif-bridge to allow the store details (i.e. those given to xm create)
to override the default value given in the xend-config.sxp.
Remove vif-bridge setting -- the value can be specified on the vif-script
command line if necessary.
Added examples for network-nat/vif-nat.
Added lots of big comments.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
hotplugging stuff was introduced (block-*, console-port-base, console-address)
and introducing entries for options that have been present for ages
(xend-{http,unix,relocation}-server, xend-unix-path, xend-relocation-address,
enable-dump). Remove vif-antispoof, as Vifctl no longer passes this option
down.
Made the xend-relocation-server default to no, as this is a potential security
hole and so must be turned on explicitly.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
This is Kurt Garloff's reworked network-bridge script:
* we got rid of ifconfig
* it works for netdev != eth0
* arp on and off are symmetric as are ifdown and ifup
* ifup will be passed the ifcfg config file name if needed
(the ifup may otherwise figure that the veth0 hardware is
NOT the same as the original ${netdev} and not use the same
config -- this happens on SUSE. Charles Coffing tracked this
one down.)
Plus Kurt's avoid-dash patch:
the network setup scripts on SUSE have trouble with the bridge
name xen-br0; they don't expect the '-'.
Arguably this should be fixed.
But I assume there's more scripts out there which may not like it,
so I suggest the following patch to rename xen-br0 to xenbr0.
Plus Charles Duffy's patch to support multiple bridges:
The attached patch allows the network-bridge script to be used to
generate multiple bridges corresponding to different physical
interfaces. It adds a new parameter, "vifnum", used to refer both to
the loopback interface to be used and to set defaults regarding the
physical interface and bridge name.
Thus, if one wishes to start xenbr0 on eth0 and xenbr1 on eth1, one
need only call:
network-bridge start ## vifnum is 0 by default
network-bridge start vifnum=1
...well, that and set loopback.nloopbacks=2 in the Dom0 kernel
parameters.
Plus renaming of virtnum to vifnum in Charles' patch, as requested by Ian Pratt.
Plus a fix to DevController to allocate vif IDs starting from 0 (i.e. vif2.0
is now domain 2's first vif, as opposed to vif2.1 in the recent past).
Plus tidying up inside network-bridge using some helper variables.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Directly modifying the sysfs entries causes the xenstore state of
a cpu's availability to be incorrect. Also slightly modify the
dom0-cpus description in the xend-config. Rather than specifying which
dom0 vcpus are to be used, it is now a target of how many vcpus to use
as pinvcpu ops are the preferred method for setting which physical cpu a
vcpu uses.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
Although Li Ge has had problems with this script he had trouble with the previous too. I think this new one should work for more people, particularly those using DHCP on their primary dom0 interface.
Debugging is currently enabled ("sh -x") so a log of the script's execution is output to /var/log/xend.log
Signed-off-by: ian@xensource.com
--HG--
rename : tools/examples/network => tools/examples/network-bridge
- Enforce the number of CPUs dom0 will take. See the new variable
"dom0-cpus" in xend-config.sxp (you will want to set this variable to
1 on SMP systems)
- Balloon out dom0 memory when creating domU, if there is not enough
free memory. The lowest level we will balloon out is configured via
the new variable "dom0-min-mem" in xend-config.sxp
I still have a doubt: where to put the code to enforce dom0-cpus. At
the moment I put it into
python/xen/xend/server/SrvDaemon.py, and hopefully that is resonable
enough. Any comment?
Signed-off-by: Nguyen Anh Quynh <aquynh@gmail.com>
Change defaults in /etc/xen/xend-config.sxp :
* xend will now only listen on localhost for conenctions from 'xm'.
* consoles are only available from localhost too
Signed-off-by: ian.pratt@cl.cam.ac.uk
