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>
Not working yet as we are a bit too keen to kill the qemu-dm process,
before we know that the save has been successful.
Signed-off-by: Keir Fraser <keir@xensource.com>
drivers are not present. The feature-foo mechanism does not actually
work after save/restore since the fields do not get rewritten. And it
doesn't work when we actually need the guest to be shutdown through
Xen (e.g., on suspend). Since we can quite reasonably assume that the
only entity to screw with control/shutdown is xend, and since the one
place that does that now explicitly handles unenlightened HVM guests,
we can simply strip all this stuff out.
This has the nice benefit of making HVM save/restore with PV drivers
much more reliable.
Signed-off-by: Keir Fraser <keir@xensource.com>
kfraser@localhost.localdomain