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>
rather than in frontend store directory. Two advantages are that the
frontend cannot mess with the config information; also an
ioemu-specific vif does nto need a frontend directory at all. This
avoids confusing netfront pv-on-hvm driver.
Signed-off-by: Keir Fraser <keir@xensource.com>
On each rtc time update from the hvm domain, we send an ioreq request
to qemu which then updates the time offset xenstore entry. The time
offset is preserved across reboot and can be set on domain creation
by setting the rtc_timeoffset variable in a config file.
From: Andrei Petrov <andrei.petrov@xensource.com>
Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com>
If a domain fails to restore, report back an error and close the
connection. This still leaves a confusing error from 'xm migrate' in
many cases, but it's much better than just sitting there.
Signed-off-by: John Levon <john.levon@sun.com>
Tom Wilkie