When a suspended managed domain is resumed, the checkpoint file is
removed, but xend retains a reference to the removed file. This
represents a resource leak. Fixed by ensuring that the file reference
is closed correctly.
Signed-off-by: Gary Pennington <gary.pennington@sun.com>
Add get_- and set_other_config methods to the vTPM class. Write the
parameters into the xenstore while the domain is running prefixing it
with 'oc_'. Also I add the methods to the C library as well as the
documentation.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
fetch the currently enforced policy. Assign 'INACCESSIBLE' to the
policy if it cannot be retrieved due to the user not being
privileged.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
I am extending 'xm dumppolicy' to be used via the Xen-API. For this
there are two new functions in the ACM policy class:
- get the currently enforced policy including statistical data from
the hypervisor
- get the ACM 'ssidref' of a Domain. Since this may be a ACM-specific
variable or type (int) I put it into the ACM class.
I extended the Xen-API documentation with the two new functions.
Signed-off-by: Stefan Berger <Stefanb@us.ibm.com>
Changeset 15168:a717cb2fac90 altered check_name() in XendDomainInfo so
that it compares domain IDs instead of UUIDs. This breaks a number of
things
- You can no longer use 'xm new' to define a persistent config file for
a running guest. This breaks the key OS provisioning scenario where
you boot a kenrel+initrd for the installer, and at the same time
define a permanent config with pygrub.
- It lets you define multiple inactive guests with different UUIDs, but
the same name because all inactive guests have a domid of None. So
you can now end up with multiple guests with same name, which is
contrary to the goal implied by the patch which was name uniqueness.
It is unclear from the original commit logs just what scenario it was
trying to protect against, but the original checking of uniqueness
based on UUID was correct & is what was used in previous releases XenD.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Changeset 15951:ad339d88639d split policy_dir_prefix into
security_dir_prefix and policy_dir_prefix in acm code. I think this
needs to be reflected in the dummy module as well (otherwise we blowup
when bootloader.py tries to reference security.security_dir_prefix).
Fixed in below patch.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
When creating domains that specify scheduler parameters with XenAPI,
the specified parameters are not used when starting the domain. This
patch collapses cpu_weight and cpu_cap in XendConfig into the
vcpus_params dictionary. The patch has been tested using xm and
XenAPI on config with and without scheduler parameters.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
physical memory constraints.
If users require domain memory size larger than a physical memory
size, we do not need waiting for ballooning, and should cause
xm create command error right away.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
On systems where the grub bootloader is not available or active the
to-be-activated policy is written a simple textfile. Once xend has
started the contents can be read. Using 'xm setpolicy' the policy can
be activated and the Domain-0 label set (using 'xm addlabel').
I fixed some bugs in the grub bootloader handler on the way and
removed some dead functions.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
I have added CONFIG_PASSTHROUGH in ioemu/Makefile.target and
ioemu/hw/pc.c in attached vtd_tools2.patch. This should turn off
libpci usage by default until user specifically enables it.
This can be safely check-in without breaking builds for people who do
not care about pass-through devices. I will try to think of a better
way to enable this.
Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
I found that xend's memory usage grows considerably when running a
script such as
while true; do xm new foo ; sleep 2s; xm delete foo ; sleep 2s; done
XendAPIStore maintains a list of class instances and in the case of
new/create operation, an associated VMMetrics object is stashed in the
list but never removed on delete/shutdown. This patch removes the
instance by invoking XendBase.destroy() method.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
This patch adds 'type vnc' to vfb device sexpr for HVM guests. PV
guests already contain this entry in sexpr, e.g.
(device
(vfb
(vncunused 1)
...
(type vnc)
...
)
)
Some tools, such as libvirt, look for device/vfb/type in sexpr before
publishing VNC port. More importantly, this patch provides
consistency in vfb device sexpr between HVM and PV guests.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
- Wait time
When xm requests a block device detach to xend, xm makes two
requests. At first, xm requests the block device detach by device
class 'vbd'. Next, xm requests the block device detaching by
device class 'tap'.
As a result, the wait time is 200 seconds because each of
the block device detaching requests causes time-out.
- Misleading error message
Because the last request is by device class 'tap' to xend,
the keyword "(tap)" is included in the error message.
This patch fixes the number of times of the block device detaching
request to one time. At first, xm makes inquiries about device
class of a detaching target device to xend. Then xm requires the
block device detaching by xend returned device class. The wait
time becomes 100 seconds because the block device detaching request
is one time. And the error message is also fixed.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
When I tested xm trigger command with a wrong argument, I saw the
following error message.
# xm trigger vm1 xyz
Error: __init__() takes exactly 2 arguments (3 given)
Usage: xm trigger <Domain> <nmi|reset|init> [<VCPU>]
Send a trigger to a domain.
This patch fixes the error message as follows.
# xm trigger vm1 xyz
Error: Invalid trigger: xyz
Usage: xm trigger <Domain> <nmi|reset|init> [<VCPU>]
Send a trigger to a domain.
The type of "TRIGGER_TYPE" is dictionary. domain_send_trigger()
refers to the keys of "TRIGGER_TYPE" without using keys() currently.
This patch adds keys() there.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
This patch corrects an error in the original XSM tools patch. The
original patch did not rename, relocate and patch the security.py file
from changeset 15730:256160ff19b7. This patch addresses this issue as
well as any updates made to security.py in xen-staging during the
merge of XSM.
Signed-off-by: George Coker <gscoker@alpha.ncsc.mil>
Print the following error when you give a wrong disk type to xm commands:
# xm create /xen/vm1.conf disk='tap:xxx:/xen/root-vm1.img,hda1,w'
Using config file "/xen/vm1.conf".
Error: tap:xxx not a valid disk type
# xm block-attach vm2 tap:yyy:/xen/second.img hdb1 w
Error: tap:yyy not a valid disk type
Usage: xm block-attach <Domain> <BackDev> <FrontDev> <Mode>
[BackDomain]
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Fix the case where the resource label file does not exist but its
contents would be needed for access control evaluations.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
When I tested xm create command, I saw the following error message.
I expected an error message "Error: (12, 'Cannot allocate memory')"
because I intentionally caused a memory shortage on the test.
But the error message was different from my expectation.
# xm create /xen/HVMdomain.1
Using config file "/xen/HVMdomain.1".
Error: an integer is required
I looked at xend.log to examine the cause why the error message was
shown. (Could you see the attached xend.log?)
xend had the error message "Error: (12, 'Cannot allocate memory')"
first. But xend changed the error message to "Error: an integer is
required" halfway. I'm not sure about the cause why an exception
occurred in logging processing. But when I applied an attached patch,
I confirmed that the error message that I expected was shown. The
patch does not call xc.domain_destroy_hook() if self.domid is None.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
The basic problem was that the "image" section of the sxp had a "None"
in it, which means that on the restore (either on the local machine or
remote machine), the vnc server in the qemu device model literally
needed the string "None" to properly connect. This simple patch only
puts a vncpasswd entry in the image if it is *not* None in the python
code, thus avoiding the whole issue.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
