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>
list is passed rather than a single string. This expands the config-file
interface so that parameters may be passed to the network scripts from the
config file.
Fix XendRoot._logError (missing asterisk before args parameter).
In XendRoot, allow an empty configuration file. This makes it easier to unit
test code reliant on XendRoot.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
for the command line parsing code in xm create. To make it easier to test,
create.py has changed in structure around the main(argv) function, adding a new
parseCommandLine function.
Remove a large number of useless parameters, where the opts structure was being
passed all over the place, just to eventually log through it. Instead two
methods -- err and warn -- have been broken out from the Opts class, and there
is now no need to pass the opts value everywhere.
Change the parsing inside make_config to remove lots of cut-and-pasted cruft.
Change the documentation to the vif command to indicate that the bridge can be
auto-detected.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
