We can destroy a VDI by VDI.destroy even if the VDI is being used
to VBDs. This patch checks that the VDI is not used to VBDs.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
When the option pci-passthrough-strict-check of
/etc/xen/xend-config.sxp is set to 'no', we don't check the
non-page-aligned MMIO BAR. This could be useful in some cases, e.g.,
when there is only 1 device in the range of the page and we try to
assign the device to pv guest.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Add a new option "description=" to each VM to increase the
manageability of VM, which could be accessed via "xm list -l
MACHINE".e.g add "description='(name, james),(priority 5), (owner
james.song@company.com)'" to configure file, User can get the VM's
attribute easily by "xm list -l Machine" or some tools.
Signed-off-by: James Song<jsong@novell.com>
In XenAPI mode, when we start a VM by using xm create command, VDIs
are always automatically created for VBDs. Once we shut down the
VM, then start the VM again, then VDIs are newly created. As a
result, a vdi.xml file continues to expand.
This patch reuses VDIs if location of the VDIs is same.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
This patch makes the destruction of stubdoms a synchronous event,
therefore it is no longer possible to run out of memory when rebooting
a guest because the stubdom of the old guest is always destroyed
before the creation of the new guest.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This patch adds a new option to xm migrate command. A concept of the
option is inspired from XenServer/XenCenter. The concept is "Change
home server (affinity)." The option name is "change_home_server."
Currently, a config.sxp file of a managed domain is not migrated to a
destination server even if the migration of the managed domain
succeeds. The config.sxp file is kept in a source server.
By the patch, the config.sxp file is migrated with the managed domain.
The config.sxp file is unregistered from the source server, then the
config.sxp file is registered to the destination server.
BTW, should the config.sxp file be always migrated without the option?
If the managed domain is migrated without the option, the managed
domains exist on both the source server and the destination server.
(Of course, the managed domain on the source server is "halted" state,
and the managed domain on the destination server is "running" state.)
Is it good that the managed domains with a same UUID exist on both
servers? (In the patch, I added the option for compatible.)
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Whenever pci_device_configure is called on a guest that has a stubdom,
call pci_device_configure on the stubdom as well.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This patch allows a pci device to be passed through an HVM guest and
its own stubdom at the same time.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
I detected problems of VDI-VBD link again.
- In the case of inactive managed domains, VDI->VBD link was lost
by xend restarting (or host OS rebooting).
- In the case of active domains, both VDI->VBD link and VBD->VDI
link were lost by xend restarting.
When xend is restarted, information of VDI instances is restored from
a vdi.xml file. But the vdi.xml file does not have UUID of VBD
because xend does not write the UUID to the vdi.xml file. Therefore,
VDI->VBD link is lost. When xend is restarted, information of VBD
instances is restored from xenstore. But xenstore does not have UUID
of VDI. Therefore, VBD->VDI link is lost.
This patch solves the problems. VDI instances stop having UUID of
VBD. Instead, xend gathers UUID of VBD each time it's required. The
method is the same as Network->VIF link. Information of VBD instances
is restored not only from xenstore but from a config.sxp file. UUID
of VDI is restored from the config.sxp file.
FYI, VBD->VDI link of inactive managed domains is not lost because
information of VBD instances is restored from the config.sxp file.
UUID of VDI is written by xend to the config.sxp file.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
During testing I discovered that using a bootloader magically clears
the superpage flag out of the config. This small patch fixes that
behavior.
From: Dave McCracken <dcm@mccr.org>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Updated xm setpolicy command to support the loading of flask security
policies.
Signed-off-by : Machon Gregory <mbgrego@tycho.ncsc.mil>
Signed-off-by : George S. Coker, II <gscoker@alpha.ncsc.mil>
Temporary tuple0 python object was not freed at the end of
xspy_set_permissions() in case no error occurred. To reduce code
duplication, this path reuses the cleanup code.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reference counters are not correctly decreased for python object in
several places in python bindings for libxc. Most of them are around
PyList_Append(), which unlike PyList_SetItem() does increment
reference counter of the object being added to a list.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Platform variable 'tsc_native' is saved/restored as a string, so must
be converted to an integer before passing to domain_set_tsc_native().
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
The default is to emulate. Old saved images will be restored with
legacy behaviour however (native TSC, no emulation).
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
VBD information in xend does not have a VDI value if XenAPI mode
is invalid. A new patch confirms the VDI value is valid. So, the new
patch cuts off VDI->VBD links if the VDI value is valid.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
When VBD instances are destroyed by xm delete command, VDI
instances keep linking to the VBD instances unilaterally.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
We cannot get correct records of VDI by VDI.get_record.
The correct records of VDI are gotten by this patch.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
The following error message was shown by xm migrate command.
In fact, I caused the command error by intention. I prepared a
destination server where free memory was insufficient, and then
I tried to migrate a VM to the destination server. As I had
expected, the command error occurred. However the error message
was different from my expectation. I would like to show an error
message from the destination server if an error occurred on the
destination server.
# xm migrate --live vm3 bx339
Error: (107, 'Transport endpoint is not connected')
Usage: xm migrate <Domain> <Host>
Migrate a domain to another machine.
Options:
-h, --help Print this help.
-l, --live Use live migration.
-p=3Dportnum, --port=3Dportnum
Use specified port for migration.
-n=3Dnodenum, --node=3Dnodenum
Use specified NUMA node on target.
-s, --ssl Use ssl connection for migration.
If a destination server sends an error message, this patch shows=20
the error message. For example, the following error message is=20
shown if free memory of the destination server is insufficient.
# xm migrate --live vm3 bx339
Error: I need 262144 KiB, but dom0_min_mem is 716800 and shrinking
to=20
716800 KiB would leave only 50368 KiB free. (from bx339)
Usage: xm migrate <Domain> <Host>
Migrate a domain to another machine.
Options:
-h, --help Print this help.
-l, --live Use live migration.
-p=3Dportnum, --port=3Dportnum
Use specified port for migration.
-n=3Dnodenum, --node=3Dnodenum
Use specified NUMA node on target.
-s, --ssl Use ssl connection for migration.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
When I started a VM by using xm create command, cpus parameter in VM
configuration files was ignored. The problem occurred only when I
used XenAPI. This patch makes the parameter available.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Currently when assigning device to HVM guest, we use the strict check
for HVM guest by default.(For PV guest we use loose check
automatically if necessary.)
When we assign device to HVM guest, if we meet with the co-assignment
issues or the ACS issue (see changeset 20081: 4a517458406f), we could
try changing the option to 'no' -- however, we have to realize this
may incur security issue and we can't make sure the device assignment
could really work properly even after we do this.
The option is located in /etc/xen/xend-config.sxp:
(pci-passthrough-strict-check yes)
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
For those devices not having INTx (like VFs), avoid calling map_pirq,
otherwise the guest cannot be started successfully.
Also avoid calling this hypercall for hvm guest, this is done in the
device model.
Signed-off-by: Qing He <qing.he@intel.com>
To be able to use "bootloader" on drbd devices the following changes
need to be made:
*) Translation of devicename
_parse_uname which is used by blkdev_uname_to_file which is again used
by _configureBootloader in XendDomainInfo needs to be able to resolve
drbd resources to the corresponding blockdevice to feed to the
configured bootloader.
*) Activation of drbd device
If the drbd device isn't in Primary mode when the bootloader tries to
fetch the kernel and initrd, the start of the DomU will fail. To
prevent this the given drbd device will be made Primary before the
bootloader gets executed.
A note on the naming of drbd resouces: drbd uses mostly resource names
in it's userland tools. Because of that drbd VBDs, if configured with
the "drbd:" type, should always use the drbd resource name as
suggested by the drbd documentation at
http://www.drbd.org/users-guide-emb/s-xen-configure-domu.html. My
patches assume that the VBDs are named accordingly.
Signed-off-by: Michael Renner <michael.renner@geizhals.at>
When the guest(pv-on-hvm guest that cannot suspend) reboot in
LiveMigration, the disconnecting of src-side is not transmitted to
dist-side. As a result, the error processing on the dist side is not
executed.
Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
I detected a problem when using XenAPI. When I started a VM by
using xm create command, blocktap disks were not attached to the
VM.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Currently, cpu_weight parameter and cpu_cap parameter in domain=20
configuration files are ignored when using XenAPI.
The parameters are available by this patch.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
This patch supports basic gfx passthrough on xen side:
- add a VGA type for gfx passthrough, and get the size of VGA bios
of passthrouged gfx in hvmloader
- add a config option 'gfx_passthru' for gfx passthrough
Signed-off-by: Ben Lin <ben.y.lin@intel.com>
Signed-off-by: Weidong Han <weidong.han@intel.com>
Attached patch makes error reporting more verbose when
xc.domain_create() fails or raises an Exception.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Changed the way security labels are handled to allow domains to be
labeled with Flask MLS security labels. Changed the error message
generated when an invalid context is submitted to be more useful.
Signed-off-by: Machon B. Gregory <mbgrego@tycho.ncsc.mil>
Signed-off-by: George S. Coker, II <gscoker@alpha.ncsc.mil>
and PV/ramdisk
Add support for 'file:' and 'data:' URI schemes for the parameters
'PV/kernel' and 'PV/ramdisk' in the VM.create() call. The 'data:'
scheme handling enables using a file which is stored inside the
management system (from where the XenAPI call is send) as kernel or
ramdisk.
Notes:
o all included: a detailed description can be found in the xenapi
documentation
o bumped up the version of the API document to 1.0.8 (because of
(minimal) interface extension)
o Future enhancements (like http:, ftp: schemes) fit seamlessly into
the current design / classes
o Unittest cases and xm-test case included
Signed-off-by: Andreas Florath <xen@flonatel.org>
Right now xen will create a new vtpm instance everytime you start up a
domU, even if you specify the instance parameter in your config file.
Each vtpm instance is then given a uuid and the vtpm.db file maps
instance numbers to uuid numbers.
This patch is a hack that lets you explicitly set the uuid of your
vtpm instance. Everytime you boot up your domU now the vtpm will get
that uuid and thus it will always get the same vtpm instance number
instead of being generated a new one.
So for example, in your config file you would do something like this
vtpm = [ 'backend=0,uuid=dcdb124b-9fed-4040-b149-dd2dfd8d094c' ]
Signed-off-by: Matt Fioravante <Matthew.Fioravante@jhuapl.edu>
There were a couple of small bugs in the xapi xm-test:
o outdated XenAPI calls were removed from testcase
(02_xapi-vbd_basic)
o minor problem with XendLocalStorageRepository
is fixed (missed list_images() function - which
is moved from the XenQCoWStroageRepo to the common
base class XendStorageRepository)
which was detected running 02_xapi-vbd_basic.
o XenAPI session handling and connecting is fixed.
o 03_xapi-network_pos was rewritten and now uses
XenAPI.
Signed-off-by: Andreas Florath <xen@flonatel.org>
Keir Fraser