continue to receive watches. This means that it is not necessary to probe
around in the xswatch internals to unregister a watch.
Tidy up the hotplug watch handling, moving the nested function out to a
separate place (I don't think that this was a problem in the end, but it was
making me nervous as I was debugging the recent race condition, and I find it
clearer out of the class in any case. Pass an integer code representing
hotplug status, once it has been parsed from the store, as there are now a few
different places we can detect failure, and it's cleaner to pass a code from
those places.
Small tidy up to XendDomain, removing the unused releaseDomain field.
when given a non-convertible value, as claimed by the comment, as the exception
ValueError is thrown in that situation. TypeError is only thrown on int(None),
which cannot actually take place in this code, because of the explicit check
for None.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
config files (e.g. dom0) don't set info['vcpus'] correctly resulting in
incorrect cpu availablity values in the store. This prevents hotplug
from functioning.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
1. xm vcpu-list now shows info for all vcpus by using
info['max_vcpu_id']+1 as end of the range to query
vcpu_info.
2. Add new vcpu fields, online_vcpus, max_vcpu_id to
XendDomainInfo.sxpr()
3. Remove filter_cpump() which isn't needed now that
the per vcpu cpumap field is correct.
4. Update xm/main.py to use online_vcpus as the number
vcpus to display in list.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
sxpr everywhere broke the use of a boot loader for booting with. The
attached fixes things up so that
a) use of a bootloader ==> kernel not specified in the config file
b) don't cleanup bootloader files until after the domain has booted
c) rerun bootloader on reboot
Signed-off-by: Jeremy Katz <katzj@redhat.com>
This will make the drivers more robust to failure of the other end, and makes
current driver state more visible. It also allows us to bring very similar
pieces of code from the drivers together into the xenbus driver. This should
be the start of a fix to the problem with block and net device hotplugging,
because the code was previously confused about the difference between the
connection state of the kernel device layer, and the state of the xenbus
communication. This confusion is addressed here.
Much of this work is influenced by Rusty Russell's skeleton driver, recently
posted to xen-devel, as that piece made suggestions as to structure and
arrangement that have been taken on board, albeit pushed down into the xenbus
layer.
A new file xenbus_client.c has been added. This file implements the interface
between the xenbus layer and the layer specific to the driver. Access to
lower layers is still allowed for those who do not need all the facilities of
the new driver.
xenbus_dev_error has moved from xenbus_xs.c into xenbus_client.c, and
xenbus_dev_ok has been removed, in favour of xenbus_switch_state.
DevController.py now closes down a device by writing a change to the Closing
state on the backend, to allow the frontend time to close down properly. Its
also writes the frontend and backend details within the same transaction.
The timeout on the hotplug scripts has been cranked down from 2 minutes to 5
seconds.
The diagnose script has been updated to parse the new states.
The blktab and tpm drivers have yet to be ported to this structure.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
just like block device.
e.g. vif=['type=ioemu, mac=01:00:00:00:00:33, bridge=xenbr0']
type=ioemu to specify for vmx NIC device.
nics=4 can specify 4 vmx NIC now.
bridge is passed to device model now.
With this patch, the error
"Error: Device 0 (vif) could not be connected."
will not happen for creating vmx guest
currently, it happens on some linux distribution.
Signed-off-by: Xiaofeng Ling <xiaofeng.ling@intel.com>
change to parsing memory configuration against a store with entries written
by an older Xend.
Added maxmem field to list of things to be read from the store on recreate.
and drive this process from xm create. Architecturally, this separates the
process of domain creation from the process of waiting for devices, allowing
tools to choose when to perform that wait (if at all). This places the waiting
in the same category as the unpause after domain creation, architecturally.
The main advantage to this approach is that it takes waiting for devices out
of the scope of XendDomain's domains_lock. When restarting a domain, the
watch would fire for @releaseDomain while we were waiting for new domains to
come up. This would deadlock the watch thread, as no more new watches could
be delivered. Closes bug #387.
In the longer term, we expect to be able to wait for devices to come up
completely, not simply to wait for the hotplug scripts to run, and so it is
necessary then to move the waiting procedure right out of the server, so that
it can be performed after the domain unpause. Without unpausing the domain,
the frontends will not come up, and so we cannot detect successful device
completion.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
xm now accepts a parameter 'ioports' that accepts a hex ioport
or ioport range, in the form 02f8[-02ff]
Signed-off-by: Jody Belka <knew (at) pimb (dot) org>
xm now accepts a parameter 'ioports' that accepts a hex ioport
or ioport range, in the form 02f8[-02ff]
Signed-off-by: Jody Belka <knew (at) pimb (dot) org>
vnet-create is correct. This is better than throwing IOError, because
IOError's are currently reported as xend communication failures.
Also, fix the IOError handling at the end of the file so we don't get
a stack dump if that path is taken.
Signed-off-by: Dan Smith <danms@us.ibm.com>
on vncserver or remote X. Changeset 7547 added a test of
opts.vals.display when getenv("DISPLAY"); because there is a default
value:localhost:0, that causes the test always to be true.
Signed-off-by: Xiaofeng Ling <xiaofeng.ling@intel.com>
The problem is: There is no mechanism to detect block device setup failure
Network devices have the same problem, and are fixed with this too.
I handling this problem in the way suggested by aliguori:
- hotplug scripts write a "hotplug-status" node on store
- Xend DevController.createDevice() check verify this node and return success
or throw an exception on failure.
- If no changes in "hotplug-status" node after DEVICE_CREATE_TIMEOUT seconds
Xend throw an exception showing the problem with hotplug scripts.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
