Fix wrong python list assignment for "monitor=1". The old assignment
only works when using qemu-dm.debug in configure file.
Signed-off-by: You YongKang <yongkang.you@intel.com>
Signed-off-by: Zhang Xin <xing.z.zhang@intel.com>
Currently it returns supported_bootloaders as a string. This patch
returns supported_bootloaders as a 'string set' - per the spec. The
c-bindings fail to parse response, expecting a set but only finding a
string.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
The xen.xend.server.SrvDomain class provides an op_save method for
saving guests. This just calls into the domain_save method on
xen.xend.XenDomain The latter recently gained an extra 'checkpoint'
argument, but the SrvDomain class is not providing this. The attached
patch simply makes the 'checkpoint' arg default to 'False' if not
provided by the caller which makes old calling convention.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
_storeChanged() was incorrectly comparing a string to an sxpr, thus
always firing and causing unnecessary watches to be fired in the
domU.
Signed-off-by: John Levon <john.levon@sun.com>
In Xen 3.0.3 series release, if one did 'xm create -c someguest' then
you would be shown the pygrub boot menu, allowing one to pick a
kernel. If you didn't use the -c arg, then it'd just pick the default
kernel.
In Xen 3.0.5 testing, xm is forcing the addition of the '-q' flag
whenever the 'bootargs' parameter is not given in the config file. So
if one does not have 'bootargs' specified, and one uses 'xm create -c
someguest' you never get to see the pygrub boot menu.
This patch fixes 'xm create' so that it does not add the '-q' flag
to the bootloader args, if the '-c' flag is given to xm create. This
makes the default user experiance operate closer to user
expectations.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
In XendDomainInfo, BOOTLOADER_LOOPBACK_DEVICE is defined to be
'/dev/xvdp'. However, there is still one place in this file that has
'/dev/xvdp' hard-coded.
Signed-off-by: Charles Coffing <ccoffing@novell.com>
1. XendDomainInfo._createDevices() gets a list of devices to be
created from XendConfig.ordered_device_refs().
On a simple guest, this has 4 devices, vfb, vbd, vif, vkbd - in
that order.
2. It iterates over those devices, creating the appropriate
DevController subclass instance, and then calling createDevice()
on that object.
3. When createDevice() is called on the vfb device, it spawns
xen-vncfb daemon.
4. During startup xen-vncfb writes into the backend paths
/local/domain/0/backend/vfb/0
And
/local/domain/0/backend/vkbd/0
5. When createDevice() is called on the vkbd device in XenD, if the
2nd xenstore path write from step 4 has occurred, then you'll hit
the 'Device 0 (vkbd) is already connected' error. If the 2nd path
write didn't complete yet then everything is fine.
I think the reason it often works once after boot is that loading
xen-vncfb from disk the first time around is just enough of a slow
down to ensure step 5 occurs before the 2nd xenstore write in step 4
has occurred.
The key seems to be to ensure the vkbd device is initialized in
xenstore before the vfb device - this ensures all the xenstored setup
from XenD is complete before the xen-vncfb daemon starts. I'm now able
to create & destroy a domain many times over with this patch & never
hit the error message any more.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The file /var/log/xen/xend-debug.log is currently being created with
executable permission bits set. This is because the os.open() method
defaults to using a mode of 0777 if no third parameter is provided.
The attached patch changes the mode to 0600 to ensure that the file
permissions come out as -rw------- instead of -rwxr-xr-x
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
state of a domain. Should still call _stateSet() to notify others
when you expect the state has changed.
Also some changes to locking in save/suspend, restore/resume and migrate
Passes xm-test against XenAPI...
signed-off-by: Tom Wilkie <tom.wilkie@gmail.com>
Alex Williamson