For some slightly-crazy reason the blktap patches changed the name
of the SEXPR block containing the disk definition 'vbd' to 'tap', even
though merely changing the 'uname' fragement was sufficient. eg
(vbd (backend 0) (dev hda:disk) (uname file:/xen/rhel4x86_64.img)
(mode w) )
changes to
(tap (backend 0) (dev hda:disk) (uname tap:aio:/xen/rhel4x86_64.img)
(mode w) )
If you create a domain with xm, then xm runs pygrub client side which
works fine. If you create a domain by feeding a block of SEXPR to Xend
over its network port, then pygrub is run server side. The code in
XenD which decides which disk to run pygrub against only looks for
'device/vbd' in the SEXPR so fails to see any blktap disks.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
that the VNC server from qemu listens on.
Defaults to only listen on 127.0.0.1
The old behaviour (listen on all interfaces) can be restored, by
- changing the system-wide default in /etc/xen/xend-config.sxp by adding:
(vnc-listen '0.0.0.0')
- changing individual domain config files by adding:
vnclisten="0.0.0.0"
Also allows specifying the hostname associated with an interface to limit
to that interface.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
In the current xen-unstable.hg tree tough, XenD will always pass an
explicit '-vnc <display num>' parameter to qemu-dm, regardless of
whether 'vncunused' is set. So the 'vncunused' bit only takes effect
if the explicitly passed display already has something bound to it.
Consider what happens when the host machine has been up for a while -
the Domain ID's start getting very high. This plays havoc with
firewalls - for example an admin may know that only 10 domains will
ever be running at any time, so they should be able to simply open up
ports 5900 -> 5910.
The correct behaviour should be:
- If 'vncdisplay' is set, use that explicit display
- If 'vncunused' is set non-zero, allocate first port about 5900
- Allocate fixed port based on domain-ID
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch fixes an indentation error in main.py. The effect of this
bug is that block-attach does not check labels if the ACM is
active. This bug slipped in with change set 11572_:_ ad22c711ccb7
<http://xenbits.xensource.com/xen-unstable.hg?cs=ad22c711ccb7>.
Signed-off by: Reiner Sailer <sailer@us.ibm.com>
Also update the code in tools to create the device node if udev fails.
The tools now read the sysfs system to find the minor number needed.
Original patch from Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
tapdisk was using a 1msec select() timeout in its main event loop. On
timeout, the loop does nothing except repeat, so the timeout achieves
nothing; worse, on a machine with HZ set to less than 1000, a msec
timeout returns immediately, sending tapdisk into a 100%-CPU-
utilisation loop.
Simply remove the timeout entirely; everything still works fine, and
much more efficiently when idle.
Signed-off-by: Stephen Tweedie <sct@redhat.com>
This patch makes blktap Do The Right Thing(TM). It allows udev to
create the /dev/xen/blktap[0-9] devices.
It creates a sysfs class called "xen". This part may later be placed
someplace else, but currently blktap is the only user so it is placed in
the blktap code.
When blktap is initialized, a blktap0 sysfs class device is made. The
other devices blktapX (X > 0) are made when the BLKTAP_IOCTL_NEWINTF
ioctl is called. This way we don't flood the sysfs and /dev/xen with
unnecessary devices.
I added a rule in the xen-backend.rules to allow for udev to create the
blktap devices.
With this, we can really remove the code to search and create the
/dev/xen/blktap[0-9]*, but I'll leave it in for now. With the use of
udev, we really should remove that code as well as the code for creating
the evtchn device. udev works for both of these now. But that removal
will have to be in another patch.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
blktap currently uses a hardcoded major of 254 for the device. This is
not robust in anyway and needs to be dynamic.
Note: it is better not to have the daemon create the node, and have udev
create it instead. But since the daemon currently creates the node
anyway, it is still the way this is done. That change needs to be made
at another time.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
If a Xen guest has a bootloader configured, then it will fail to start
on a blktap image. The problem is blkdev_uname_to_file, which cannot
parse the "tap:aio:$filename" image strings: it tries to split the
string apart at ":" and assign the result to a 2-tuple, and this
results in a python error if the split results in three or more
strings.
The fix is to split only at the first ":", and then to split again
if we detect "tap:" as the image type.
Signed-off-by: Stephen Tweedie <sct@redhat.com>
Remove try except blocks so that ACMError(s) are properly reported to
the user rather than silently fail.
Signed-off-by: Alastair Tse <atse@xensource.com>
Fixed built-in function name conflict.
Raise correct exceptions for when option is invalid to be properly
reported by xm.
Signed-off-by: Alastair Tse <atse@xensource.com>
Removing try,except block as cfgbootpolicy should allow exceptions to
propagate instead of printing traceback to stdout.
(http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=778)
Changed usage of string.join, string.split when creating security
policy path name.
Signed-off-by: Alastair Tse <atse@xensource.com>
