xapi-project / xen-api Goto Github PK

Running OpenStack tempest tests, sometimes I see this in the error log:

Failure: ['INTERNAL_ERROR', 'File "xapi_xenops.ml", line 2088, characters 3-9: Assertion failed']

version info:

BUILD_NUMBER='70446c'
PLATFORM_VERSION='1.8.0'
DOM0_VCPUS='4'
INSTALLATION_UUID='4d944fd3-8b48-47a1-9b13-155ae6923a37'
MANAGEMENT_ADDRESS_TYPE='IPv4'
PRODUCT_VERSION_TEXT_SHORT='6.2'
BRAND_CONSOLE='XenCenter'
PRIMARY_DISK='/dev/disk/by-id/scsi-SATA_SAMSUNG_HE253GJ_S2B5J90ZC12322'
PRODUCT_BRAND='XenServer'
INSTALLATION_DATE='2013-08-21 08:05:18.227510'
PLATFORM_NAME='XCP'
COMPANY_NAME_SHORT='Citrix'
PRODUCT_VERSION_TEXT='6.2'
BACKUP_PARTITION='/dev/disk/by-id/scsi-SATA_SAMSUNG_HE253GJ_S2B5J90ZC12322-part2'
PRODUCT_VERSION='6.2.0'
XEN_VERSION='4.1.5'
KERNEL_VERSION='2.6.32.43-0.4.1.xs1.8.0.835.170778xen'
MANAGEMENT_INTERFACE='xenbr0'
DOM0_MEM='752'
COMPANY_NAME='Citrix Systems, Inc.'
PRODUCT_NAME='xenenterprise'
CONTROL_DOMAIN_UUID='4e04643c-0506-408c-9a84-e45fe055ce90'

Reproduced with running this from two terminals in parallel:

cd ~/tempest/
while nosetests tempest.thirdparty.boto.test_ec2_instance_run:InstanceRunTest.test_run_stop_terminate_instance; do echo "OK"; done

When XCP pool upgraded from 0.5 to 1.0.0, after master upgrade and installing upgraded xe-guest-tools to guests, migration from (old) xcp0.5 host to newer xcp1.0 host is impossible.

It looks like:

xe host-evacuate uuid=9116a583-b31f-4925-906c-58386dc598be
You attempted an operation on a VM which requires a more recent version of the PV drivers. Please upgrade your PV drivers.
vm: e315a5b4-9678-0a88-1e65-1e70ccd2fe4c (test7)
major: 1
minor: 0
<extra>: -1

Additional information:

xapi checking pv_drivers_is_up_to_date by comparing reported from xe-guest-tools version against it's own. And here problem: xapi expect version 1.3:

[20110304T19:31:32.605Z|debug|xh5|0 thread_zero|server_init D:694ec593a4ba|startup] task [Logging xapi version info]
[20110304T19:31:32.606Z|debug|xh5|0 thread_zero|server_init D:694ec593a4ba|dummytaskhelper] task Logging xapi version info D:9acad7c8dc05 created by task D:694ec593a4ba
[20110304T19:31:32.606Z|debug|xh5|0 thread_zero|Logging xapi version info D:9acad7c8dc05|xapi] Server configuration:
[20110304T19:31:32.606Z|debug|xh5|0 thread_zero|Logging xapi version info D:9acad7c8dc05|xapi] product_version: 1.0.0
[20110304T19:31:32.606Z|debug|xh5|0 thread_zero|Logging xapi version info D:9acad7c8dc05|xapi] product_brand: XCP
[20110304T19:31:32.606Z|debug|xh5|0 thread_zero|Logging xapi version info D:9acad7c8dc05|xapi] build_number: 42052c
[20110304T19:31:32.606Z|debug|xh5|0 thread_zero|Logging xapi version info D:9acad7c8dc05|xapi] hg changeset:
[20110304T19:31:32.606Z|debug|xh5|0 thread_zero|Logging xapi version info D:9acad7c8dc05|xapi] version: 1.3

Last line shows version 1.3. And if we fake guest tools by reporting to xenstore version 1.3 of guest tools, migration works perfectly.

Context: during a pool upgrade, one usually migrates the VMs from master to another host, then upgrade master, reboot, and migrate the VMs back to master. Then do the same with other hosts in the pool, one by one.

I've been surprised to find out that this process doesn't work if the VMs are stored in a local storage repository.

Here's what happens:

• migrate VMs from master to another host ✔️
• upgrade master with installer ISO image ✔️
• reboot ✔️
• migrate VMs back to master: impossible, with this message: "This operation is not supported during an upgrade"

At this stage, you are stuck. If I read the code correctly, the mismatch in XAPI versions causes it to consider we are doing a Rolling Pool Upgrade and this disables storage motion.

Can you tell me if this analysis is correct, what the reason for this restriction is (can't migrate from higher version to lower inside the pool... But it outside a RPU such migrations between different pools are supported, e.g. XS 7.5 to 7.6), and if there's a better process to do the upgrade?

When receiving files from /export_raw_vdi, the content-length header is not defined, it is really not helping because the reciprocal url /import_raw_vdi absolutely requires the content-length header.

VHD files being potentially big, their handling is generally streamed without intermediate storage, but if the sink of the stream requires a size, the situation becomes complicated.

In digging for the original licence for a nagios/icinga check plugin, I have found that there are two files that have different licences but are mostly the same in terms of contents. These are:

• https://github.com/xapi-project/xen-api/blob/master/ocaml/idl/binding_sanity_checks/tutorial_examples/XenAPI.py
• https://github.com/xapi-project/xen-api/blob/master/scripts/examples/python/XenAPI.py

The second of those files had its licence changed to BSD, the former carries the LGPL v2.1 licence - which is the same as the licence at the base of this repository.

As BSD (2 clause) and LGPL are GPL compatible licences (https://en.wikipedia.org/wiki/License_compatibility#GPL_compatibility) I have a feeling this issue is not a massive one, but thought that you should be aware of it, especially for code which is as prevalent in various places as the XenAPI.py file is.

my full breakdown can be found in this commit message, including the other file which is a derivative of another file in this repository - if I have made a mistake with the licencing, please let me know!

• TBSliver/Icinga-Plugin-XenServer@adaff31

Hi, I am the lead dev of Xen Orchestra and we are investigating the use of JSON-RPC to talk to XAPI in Xen Server Dundee.

We are using our xen-api Node module to talk to XAPI which uses the JSON-RPC 2 implementation json-rpc-protocol.

String identifier in request

A request identifier can be either a string or a number. (source)

Currently, the following error is returned when a request identifier is a string:

<html>
<body>
    <h1>HTTP 500 internal server error</h1>
    An unexpected error occurred; please wait a while and try again. If the problem persists, please contact your support representative.
    <h1> Additional information </h1>
    Jsonrpc.Malformed_method_request(&quot;{\&quot;jsonrpc\&quot;:\&quot;2.0\&quot;,\&quot;method\&quot;:\&quot;session.login_with_password\&quot;,\&quot;params\&quot;:[\&quot;root\&quot;,\&quot;qwerty\&quot;],\&quot;id\&quot;:\&quot;foo bar\&quot;}&quot;)
</body>
</html>

Missing jsonrpc field in response

A response MUST have jsonrpc field equals to '2.0'. (source)

Incorrect result field in error response

The result field of a response MUST NOT exist if there is an error. (source)

If we adopt the design from https://github.com/xapi-project/xen-api/tree/master/doc/futures/distributed-database

Then we should

• improve scalability
• allow hosts to act independently (aka "pools of one")
• prevent races over database records by parallel Tasks

When watching changes with the xapi, all hosts of a pool receive all informations from every other host in that pool.

For example, when a snapshot is made at a slave of a Pool, the slave(s) and the master receive a task like:

{
allowed_operations: []
backtrace: "()"
created: "20190519T19:39:24Z"
current_operations: {}
error_info: []
finished: ""
name_description: ""
name_label: "VM.snapshot"
other_config: {}
progress: 1
resident_on: "OpaqueRef:36d4e8fd-7a8f-49c1-a9e8-4e38940a1302"
result: ""
status: "pending"
subtask_of: "OpaqueRef:NULL"
subtasks: []
type: "<none/>"
uuid: "65ace88c-b425-2b16-e6f8-1f7d407dcfbb"
}

Here - after my opinion - "resident_on" should display on which hosts that task has been started, like the documentation says:
http://xapi-project.github.io/xen-api/classes/task.html
"host ref resident_on - the host on which the task is running"

So "resident_on" should be the OpaqueRef of the slave, but it always shows the OpaqueRef of the master. This way it is not possible to assign the tasks to the right host.

The "resident_on" is working at the VMs and other stuff, but not with the tasks. Why? Is this a bug, or a feature? :D

2.7.9 introduced SSL certificate verification be required in ssl.py

https://www.python.org/downloads/release/python-279/

This causes the following error when connecting to a Xenserver with it's default self-signed cert:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "XenAPI.py", line 198, in <lambda>
    return lambda *params: self._login(name, params)
  File "XenAPI.py", line 164, in _login
    result = _parse_result(getattr(self, 'session.%s' % method)(*params))
  File "/usr/lib/python2.7/xmlrpclib.py", line 1233, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1591, in __request
    verbose=self.__verbose
  File "/usr/lib/python2.7/xmlrpclib.py", line 1273, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1301, in single_request
    self.send_content(h, request_body)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1448, in send_content
    connection.endheaders(request_body)
  File "/usr/lib/python2.7/httplib.py", line 997, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 850, in _send_output
    self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 812, in send
    self.connect()
  File "/usr/lib/python2.7/httplib.py", line 1212, in connect
    server_hostname=server_hostname)
  File "/usr/lib/python2.7/ssl.py", line 350, in wrap_socket
    _context=self)
  File "/usr/lib/python2.7/ssl.py", line 566, in __init__
    self.do_handshake()
  File "/usr/lib/python2.7/ssl.py", line 788, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

To fix:

• date values are incorrectly formatted (19790101T01:01:01Z instead of 1970-01-01T01:01:01Z)

Fixed in Dundee:

• boolean values are integers (0 or 1) instead of booleans
• strings contains tab characters instead of the escape sequences \t
• a method that returns nothing should returns null instead of an empty string which is not a valid JSON value (empty string, not the JSON value for an empty string which is "")
• task.progress is always 1 instead of being a float between 0 and 1

Every VM in this server - singie pool, single master - works fine, but cannot access management via http(port 80) and xencenter.

I tried to restart xapi service, xe-toolstack-restart, but xapi is never listened by xapi service.

According to xensource.log, the starting procedure got stucked after starting up database engine Performing initial DB GC

xensource.log

.......
Sep 26 16:57:24 mxen04a xapi: [debug|mxen04a|0 |server_init D:d8beed11d60d|startup] task [Listening
 unix socket]
Sep 26 16:57:24 mxen04a xapi: [debug|mxen04a|0 |Listening unix socket D:601e9a596ce8|http] Establis
hing Unix domain server on path: /var/lib/xcp/xapi
Sep 26 16:57:24 mxen04a xapi: [ info|mxen04a|0 |Listening unix socket D:601e9a596ce8|xapi] Successf
ully bound socket to: UNIX /var/lib/xcp/xapi
Sep 26 16:57:24 mxen04a xapi: [debug|mxen04a|0 |server_init D:d8beed11d60d|startup] task [starting
thread Metadata VDI liveness monitor]
Sep 26 16:57:24 mxen04a xapi: [debug|mxen04a|0 |server_init D:d8beed11d60d|startup] task [Checking
for non-HA redo-log]
.......
Sep 26 16:57:24 mxen04a xapi: [debug|mxen04a|0 |starting up database engine D:6ce164d4694b|xapi] About to flush database: /var/lib/xcp/state.db
Sep 26 16:57:24 mxen04a xapi: [debug|mxen04a|19 dbflush [/var/lib/xcp/state.db]||sql] In memory DB
flushing thread created [/var/lib/xcp/state.db].
Sep 26 16:57:24 mxen04a xapi: [debug|mxen04a|0 |starting up database engine D:6ce164d4694b|sql] XML backend [/var/lib/xcp/state.db] -- Write buffer flushed. Time: 0.034829
Sep 26 16:57:24 mxen04a xapi: [debug|mxen04a|0 |starting up database engine D:6ce164d4694b|xapi] Performing initial DB GC
Sep 26 16:57:24 mxen04a xapi: [debug|mxen04a|0 |DB GC D:cdc4d773a4e6|db_gc] session_log: active_sessions=0 (0 pool, 0 anon, 0 named - 0 groups)
Sep 26 16:57:24 mxen04a xenopsd-xc: [debug|mxen04a|37 |events|hotplug] Checking to see whether /xapi/9d6380f3-6eac-5f34-4e78-d206525fee91/hotplug/36/vif/0/hotplug
......

And the task-list shows it is hang on somewhere in dbsync.update_env

[root@mxen04a log]# xe task-list
uuid ( RO)                : 10ef57cf-3b62-3174-9ef4-4592713acdfe
          name-label ( RO): dbsync (update_env)
          name-description ( RO):
          status ( RO): pending
          progress ( RO): 0.000

here is result of netstat

tcp6       0      0 :::40769             :::*                    LISTEN      30517/rpc.statd
tcp6       0      0 :::111                 :::*                    LISTEN      30520/rpcbind
tcp6       0      0 :::22                   :::*                    LISTEN      27950/sshd
tcp6       0      0 :::37207             :::*                    LISTEN      -
tcp6       0      0 :::443                 :::*                    LISTEN      3242/stunnel

Please let me know if you need further infomation.

I always appreciate to you guys contribution on this awesome project.

Hi,

I'll drop this here since I now spend quite some time to find it's all hardcoded in the xe binary.

• would like to configure a interface (bonded or not) for live migrations (sanity, proper configuration, monitoring)
• would like to configure to not use stunnel or any ssl (performance/latency impact is massive)
• would like to really configure compression algorithm, ideally turn it off or at least use something modern and multithreaded (performance/latency impact is massive)
• at least!!!! switch to lightest gzip mode (throughput impact is massive, default level 6 is 4-6 times slower than level 1)

Forcing to use stunnel + gzip has made the Xen live migration slower than it even was in 2006, on 2006's hardware.

• Documentation would be cool, too. i.e. XE_STUNNEL env var could be a workaround, just it's not documented anywhere, so one would be stupid using it.
• If able to configure a dedicated interface and port, ssl disabled, compression disabled, infiniband users could use SDP for the migration, meaning 20x+ performance increase over GigE

If you can only do one thing, go for gzip -1
If you can only do two things, go for gzip -1 and documentation.

Hello Jon,
So, I have been hitting my head over this for the past hour or so, and I can't find it mentioned in the docs anyplace. How do I pass over disk-config parameters via the session.xenapi_request ? I have tried using a hash, dict, set, string, int - all without much luck. This is to help me attach an lvmoiscsi device.

Regards
S.

From the API docs:

VM ref migrate_send (session ref, VM ref, (string → string) map, bool, (VDI ref → SR ref) map, (VIF ref → network ref) map, (string → string) map, (VGPU ref → GPU_group ref) map) 

(VGPU ref → GPU_group ref) map vgpu_map | Map of source vGPU to destination GPU group

When the vgpu_map parameter is missing, the migrate_send call is still processed and completes well if there's no vgpu. However a warning appears in the logs ("cannot marshall arguments"):

/var/log/xensource.log.1:35182:Jul 15 15:06:55 <host> xapi: [ warn|<host>|178440 |Async.VM.migrate_send R:3793418e587b|rbac_audit] cannot marshall arguments for the action VM.migrate_send: name and value list lengths don't match. str_names=[session_id,vm,dest,live,vdi_map,vif_map,options,vgpu_map,], xml_values=[S(OpaqueRef:934aaee6-cf8e-436f-8396-ae93d8745db6),S(OpaqueRef:06934e5f-04ca-4ff9-96a8-fe8a244d4fce),{SM:S(http://<ip>/services/SM?session_id=OpaqueRef:2b31dd59-acf2-473c-8c04-c3040b8a1301);host:S(OpaqueRef:076a9aca-5df0-47dc-a050-21fbb96abfda);xenops:S(http://<ip>/services/xenops?session_id=OpaqueRef:2b31dd59-acf2-473c-8c04-c3040b8a1301);session_id:S(OpaqueRef:2b31dd59-acf2-473c-8c04-c3040b8a1301);master:S(http://<ip>/)},B(true),{OpaqueRef:b622ba46-ea56-4a27-80a4-fce6e5e6d7d3:S(OpaqueRef:b9c12444-c03d-4808-980c-d64c220465c4)},{},{force:S(true)},]

From what I understand, either the argument is mandatory and then the API call should fail without it, or it is optional and then an empty map should be added to avoid the error.

Xapi writes /tmp/metadata.old.[0-9]+ and /tmp/metadata.new.[0-9]+ every time it gets update from xenopsd that's different from the cached value in xapi.

Hi - I was just browsing through the documentation to get an overview of the project. The following links are broken and should be removed/fixed as appropriate:

1. The 'Internals of xapi' diagram on the architecture page.
2. The 'Features' and 'Walk-throughs' links in the 'Contents' section of the doc's README file.

Thanks!

XCP 1.6:

If vm (pv) migrated on localhost, every migration raise maxmem_kb limit for domain.

Steps to reproduce:
create and start vm (f.e. test).
get an maxmem_kb value for domain from xc.domain_getinfo()
for a in seq 1 1000;do xe vm-migration vm=test host=hostname;done
recheck maxmem_kb from xc.domain_getinfo()

Expected: same value
Actual: very large value, raising up after every new migration.

Task.get_result seems to return an xmlrpc encoded string of an array of objects, rather than an array of objects directly (as the docs claim). This seems a bit strange, is this intended?

See mirage/mirage#306

It looks like I missed a few spots with my floppy patches.

I got connection refused error after installing xcp-xapi and starting the service.
I'm using Ubuntu 14.04.2 LTS with Xen hypervisor 4.4.

I'm following up the official tutorial => https://help.ubuntu.com/community/Xen
The Log file saying that xenctrl.error operation not permitted

This was not the case in at least 1.1 as I've documented on my blog:

http://www.ha-guru.com/sharing-virtual-disks-between-xenserver-xcp-vms/

I'm looking for documentation/hints as to why this is not working any longer and I'm coming up with nothing

Hi, i was just reading the wiki of xenserver 7. Can you tell me where the code of the Direct Inspect API sets is? Is it in this repository or in others ?
Thanks !

Hello, I'm trying to build the latest xen-api on CentOS5; here's what I got so far:

File "db_actions.ml", line 1293, characters 17-20:
Error: Syntax error
*** omake: 421/2819 targets are up to date                                                                           
*** omake: failed (1.54 sec, 8/56 scans, 7/142 rules, 18/1074 digests)
*** omake: targets were not rebuilt because of errors:                                                               
   <scanner ocaml/autogen/scan-ocaml-db_actions.ml>
make: *** [all] Error 2

Obviously, it's ocaml/idl/ocaml_backend/gen_db_actions.ml:223 which is causing trouble:

221    let open_db_module =
222        "let __t = Context.database_of __context in\n" ^
223            "let module DB = (val (Db_cache.get __t) : Db_interface.DB_ACCESS) in\n"

I'm pretty new to OCaml and can't figure out what's wrong by myself, any hints?

The VHD import url doesn't allow for chunked encoding, but it's the only way in http to post a file whose size is not known. VHD files being big, a lot of handling is streamed without the possibility to know the size when emitting the HTTP headers.

A workaround is to emit a giant content-length (longer than what the file will actually be) in the http headers, but this loophole has been closed in vhd-tool (here: xapi-project/vhd-tool@f978789#diff-a1476b2332c40710d3f1791146a29aeaL484 ).

Is it still recommended to use xenserver-core (which is linked to xenserver-buildroot) and not xenserver-build-env?

Installed xenerver-core on top of vanilla CentOS 6.4 and I can verify that specifying alternative xenguest and qemu-dm values in the platform field of a VM is moot.

This functionality was introduced in djs55@63d41a8

I believe the problem might be that xenopsd-xenlight just doesn't care about xenguest (I tried a suspend).

Also, I don't think /opt/xensource remains the right place to install alternatives. Any docs about that?

Thanks

See [xenserver/buildroot#299]

Is it possible to run standalone xenopsd to perform VM lifecycle operations? I was able to install xenopsd, but it installs as a library. Any pointers on how to run and interact with a standalone xenopsd would be very helpful.

Needs to be updated to support jbuilder.

When a VDI_IO_ERROR happens because of vhd-tool, the xapi only reports the stacktrace of the xapi process down to vhd_tool_wrapper.ml, which is never helpful. The actual error is written by vhd-tool on its stderr.

I think adding the stderr of the vhd-tool subprocess to the field Task.error_info of the Task object related to VDI operations in the case of error would be more helpful.

I suspect that the edit could be done here: https://github.com/xapi-project/xen-api/blob/master/ocaml/xapi/vhd_tool_wrapper.ml#L55

Currently user support is complicated because in the case of VDI_IO_ERROR we have to go explore the xensource.log file, there are 2 stacktraces per error in the file (one for xapi and one for vhd-tool) and customers routinely report only the unhelpful one (it's the lowest one in the file).

A recent patch for Xen Server 6.2 (XS62ESP 1011, 1013, 1014 or 1025) introduce a bug with event.from on large pools: instead of a XML-RPC response I get a HTTP 500 (Server Error).

See julien-f/js-xen-api#2.

I have to say the installation so far was quite problematic, nevertheless the dependencies were installed using OPAM, but still the xapi package fails to build. (using opam install xapi)

OCaml compiler version: 4.01.0

My building environment is Ubuntu 14.04 with everything stock except opam which was build from source. (the current repo version is outdated==1.1.2 and ppa:avsm/ppa breaks the dependencies)

$ make 
omake -j 8 phase1
*** omake: reading OMakefiles
*** omake: finished reading OMakefiles (0.30 sec)
--- Checking for ocamlfind... (found /home/vamitrou/.opam/4.01.0/bin/ocamlfind)
--- Checking for ocamlc.opt... (found /home/vamitrou/.opam/4.01.0/bin/ocamlc.opt)
--- Checking for ocamlopt.opt... (found /home/vamitrou/.opam/4.01.0/bin/ocamlopt.opt)
--- Checking whether ocamlc understands the "z" warnings... (yes)
- build . <phase1>
+ Shell.mkdir(-p /home/vamitrou/.opam/4.01.0/build/xapi.1.9.56/dist /home/vamitrou/.opam/4.01.0/build/xapi.1.9.56/dist/bin)
*** omake: done (0.40 sec, 0/35 scans, 1/106 rules, 1/436 digests)
omake -j 8 phase2
*** omake: reading OMakefiles
*** omake: finished reading OMakefiles (0.23 sec)
- build ocaml/idl/js_backend <js_binding>
+ ./main > api.js
- scan ocaml/xapi scan-ocaml-xapi_globs.ml
+ <compute 2 value dependencies>
- scan ocaml/xapi scan-ocaml-xapi_fist.ml
+ <compute 2 value dependencies>
- scan ocaml/xapi scan-ocaml-features.mli
+ <compute 2 value dependencies>
- scan ocaml/xapi scan-ocaml-features.ml
+ <compute 2 value dependencies>
- build ocaml/autogen aPI.o
+ ocamlfind ocamlopt -syntax camlp4o -package xml-light2,sexpr,http-svr,xcp,rpclib,rpclib.syntax -g -dtypes -bin-annot -thread -warn-error +a-4-6-9-27-28-29 -ccopt -fPIC -I ../idl/ocaml_backend -I ../database -I ../idl -c aPI.ml
- scan ocaml/license scan-ocaml-v6rpc.ml
+ <compute 2 value dependencies>
- scan ocaml/xapi scan-ocaml-xapi_inventory.ml
+ <compute 2 value dependencies>
- build ocaml/idl/js_backend <js_binding>
+ Shell.cp(api.js ../../../js/)
- scan ocaml/xapi scan-ocaml-xapi_globs.ml
+ ocamlfind ocamldep -package oclock,xml-light2,cdrom,pciutil,sexpr,xcp,stunnel,http-svr,xen-utils,netdev,tapctl,rpclib,xenstore-compat,uuid,gzip,sha1,xcp.network,xcp.rrd,xcp.storage,xcp.xen,xcp.memory,tar,tar.unix,oPasswd,xcp-inventory,xenstore-compat,cpuid -native -I ../idl -I ../idl/ocaml_backend -I ../autogen -I ../database/ -I ../xva -I ../util -I ../auth -I ../license -I ../client_records -I ../rfb -I ../gpg -I .. xapi_globs.ml
- scan ocaml/xapi scan-ocaml-xapi_fist.ml
+ ocamlfind ocamldep -package oclock,xml-light2,cdrom,pciutil,sexpr,xcp,stunnel,http-svr,xen-utils,netdev,tapctl,rpclib,xenstore-compat,uuid,gzip,sha1,xcp.network,xcp.rrd,xcp.storage,xcp.xen,xcp.memory,tar,tar.unix,oPasswd,xcp-inventory,xenstore-compat,cpuid -native -I ../idl -I ../idl/ocaml_backend -I ../autogen -I ../database/ -I ../xva -I ../util -I ../auth -I ../license -I ../client_records -I ../rfb -I ../gpg -I .. xapi_fist.ml
- scan ocaml/xapi scan-ocaml-features.mli
+ ocamlfind ocamldep -syntax camlp4o -package oclock,xml-light2,cdrom,pciutil,sexpr,xcp,stunnel,http-svr,xen-utils,netdev,tapctl,rpclib,xenstore-compat,uuid,gzip,sha1,xcp.network,xcp.rrd,xcp.storage,xcp.xen,xcp.memory,tar,tar.unix,oPasswd,xcp-inventory,rpclib.syntax -native -I ../idl -I ../idl/ocaml_backend -I ../autogen -I ../database/ -I ../xva -I ../util -I ../auth -I ../license -I ../client_records -I ../rfb -I ../gpg -I .. features.mli
- scan ocaml/xapi scan-ocaml-features.ml
+ ocamlfind ocamldep -syntax camlp4o -package oclock,xml-light2,cdrom,pciutil,sexpr,xcp,stunnel,http-svr,xen-utils,netdev,tapctl,rpclib,xenstore-compat,uuid,gzip,sha1,xcp.network,xcp.rrd,xcp.storage,xcp.xen,xcp.memory,tar,tar.unix,oPasswd,xcp-inventory,rpclib.syntax -native -I ../idl -I ../idl/ocaml_backend -I ../autogen -I ../database/ -I ../xva -I ../util -I ../auth -I ../license -I ../client_records -I ../rfb -I ../gpg -I .. features.ml
- scan ocaml/license scan-ocaml-v6rpc.ml
+ ocamlfind ocamldep -syntax camlp4o -package xml-light2,stdext,stunnel,http-svr,xcp,rpclib,rpclib.syntax -native -I ../idl/ocaml_backend -I ../idl -I ../autogen -I ../xapi -I ../gpg -I ../util -I .. v6rpc.ml
- scan ocaml/xapi scan-ocaml-xapi_inventory.ml
+ ocamlfind ocamldep -package oclock,xml-light2,cdrom,pciutil,sexpr,xcp,stunnel,http-svr,xen-utils,netdev,tapctl,rpclib,xenstore-compat,uuid,gzip,sha1,xcp.network,xcp.rrd,xcp.storage,xcp.xen,xcp.memory,tar,tar.unix,oPasswd,xcp-inventory,xenstore-compat,cpuid -native -I ../idl -I ../idl/ocaml_backend -I ../autogen -I ../database/ -I ../xva -I ../util -I ../auth -I ../license -I ../client_records -I ../rfb -I ../gpg -I .. xapi_inventory.ml
ocamlfind: Package `tar.unix' not found
ocamlfind: Package `tar.unix' not found
ocamlfind: Package `tar.unix' not found
ocamlfind: Package `tar.unix' not found
ocamlfind: Package `tar.unix' not found
*** omake: 345/382 targets are up to date
*** omake: failed (13.74 sec, 6/52 scans, 2/115 rules, 5/489 digests)
*** omake: targets were not rebuilt because of errors:
   <scanner ocaml/xapi/scan-ocaml-features.ml>
      depends on: ocaml/xapi/features.ml
   <scanner ocaml/xapi/scan-ocaml-features.mli>
      depends on: ocaml/xapi/features.mli
   <scanner ocaml/xapi/scan-ocaml-xapi_fist.ml>
      depends on: ocaml/xapi/xapi_fist.ml
   <scanner ocaml/xapi/scan-ocaml-xapi_globs.ml>
      depends on: ocaml/xapi/xapi_globs.ml
   <scanner ocaml/xapi/scan-ocaml-xapi_inventory.ml>
      depends on: ocaml/xapi/xapi_inventory.ml
make: *** [all] Error 2

It is the same as the opam-coverage job, but without the tests. We should make the opam-coverage job a hard failure instead

Is there any way to include python3 version of XenAPI in my project requirements, so that other people can get it by using pip, or the only option for now is to include XenAPI.py file in project itself? Thanks in advance!

The requirements are specific. It needs to look exactly like this:

Hello everybody.

I am confused about this situation.

I have a host with XenServer 7.0 build 125380c
I downloaded XenServer-7.0.0-SDK.zip from xenserver.org.
I downloaded python 2.7 and paste XenAPI.py and privision.py to python Lib directory.

I use api to connect to host, install test VMs, rename, change memory, etc but I can not resize disk of VMs.

I use this function void resize (session ref, VDI ref, int).
New disk size is the last parameter in bytes. If i wrote 2147483648 to size (2GB) i get this message:
OverflowError: long int exceeds xml-rpc limits.

Overflow... I understand it but i do not how to expand disk more than 1GB.

If you need more information write it down and i collect it.

Thank you for your help.

Environment:

XCP-NG 7.6 updated, fresh install
HP Proliant DL380p Gen8
Mellanox ConnectX-3 Pro card

When I enable SR-IOV on Mellanox ConnectX-3 Pro card (HP Proliant DL380p Gen8), XAPI constantly reboots the process.

Checked with stock drivers and newest Mellanox drivers. Standard and experimental kernel, checked with xapi-core, xapi-xe from updates_testing repository. No change.

when I disable creating virtual functions in driver - everything works correctly again.

The xensource.log looks like this:

Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 |dbsync (update_env) R:9072bd1e6610|xapi] PCI 0000:03:01.4, Mellanox Technologies, MT27500/MT27520 Family [ConnectX-3/ConnectX-3 Pro Virtual Function] created
Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 |dbsync (update_env) R:9072bd1e6610|db_write] create_row PCI (OpaqueRef:2558881f-9933-4f4e-81ef-af3cc2ecdbcc) [(_ref,v),(uuid,v),(class_id,v),(class_name,v),(vendor_id,v),(vendor_name,v),(device_id,v),(device_name,v),(host,v),(pci_id,v),(functions,v),(physical_function,v),(dependencies,v),(other_config,v),(subsystem_vendor_id,v),(subsystem_vendor_name,v),(subsystem_device_id,v),(subsystem_device_name,v),(scheduled_to_be_attached_to,v),(driver_name,v)]
Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 |dbsync (update_env) R:9072bd1e6610|xapi] PCI 0000:03:01.5, Mellanox Technologies, MT27500/MT27520 Family [ConnectX-3/ConnectX-3 Pro Virtual Function] created
Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 |dbsync (update_env) R:9072bd1e6610|db_write] create_row PCI (OpaqueRef:2cc30358-ed61-4030-93fb-1dcbbf4c5919) [(_ref,v),(uuid,v),(class_id,v),(class_name,v),(vendor_id,v),(vendor_name,v),(device_id,v),(device_name,v),(host,v),(pci_id,v),(functions,v),(physical_function,v),(dependencies,v),(other_config,v),(subsystem_vendor_id,v),(subsystem_vendor_name,v),(subsystem_device_id,v),(subsystem_device_name,v),(scheduled_to_be_attached_to,v),(driver_name,v)]
Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 |dbsync (update_env) R:9072bd1e6610|xapi] PCI 0000:03:01.6, Mellanox Technologies, MT27500/MT27520 Family [ConnectX-3/ConnectX-3 Pro Virtual Function] created
Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 |dbsync (update_env) R:9072bd1e6610|redo_log] WriteField(task, OpaqueRef:9072bd1e-6610-4181-8ac5-c7387792280b, progress, 0, 1)
Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 |dbsync (update_env) R:9072bd1e6610|redo_log] WriteField(task, OpaqueRef:9072bd1e-6610-4181-8ac5-c7387792280b, error_info, (), ('INTERNAL_ERROR' 'Not_found'))
Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 |dbsync (update_env) R:9072bd1e6610|redo_log] WriteField(task, OpaqueRef:9072bd1e-6610-4181-8ac5-c7387792280b, backtrace, (), (((process"xapi @ Alpha")(filename list.ml)(line 214))((process"xapi @ Alpha")(filename ocaml/xapi/xapi_pci.ml)(line 218))((process"xapi @ Alpha")(filename list.ml)(line 82))((process"xapi @ Alpha")(filename ocaml/xapi/xapi_pci.ml)(line 216))((process"xapi @ Alpha")(filename ocaml/xapi/xapi_pci.ml)(line 227))((process"xapi @ Alpha")(filename ocaml/xapi/dbsync_slave.ml)(line 239))((process"xapi @ Alpha")(filename ocaml/xapi/dbsync_slave.ml)(line 305))((process"xapi @ Alpha")(filename ocaml/xapi/dbsync.ml)(line 63))((process"xapi @ Alpha")(filename ocaml/xapi/server_helpers.ml)(line 80))))
Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 |dbsync (update_env) R:9072bd1e6610|redo_log] WriteField(task, OpaqueRef:9072bd1e-6610-4181-8ac5-c7387792280b, finished, 19700101T00:00:00Z, 20190330T20:00:24Z)
Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 |dbsync (update_env) R:9072bd1e6610|redo_log] WriteField(task, OpaqueRef:9072bd1e-6610-4181-8ac5-c7387792280b, status, pending, failure)
Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 |dbsync (update_env) R:9072bd1e6610|db_write] delete_row task (OpaqueRef:9072bd1e-6610-4181-8ac5-c7387792280b)
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] dbsync (update_env) R:9072bd1e6610 failed with exception Not_found
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] Raised Not_found
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 1/15 xapi @ Alpha Raised at file list.ml, line 214
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 2/15 xapi @ Alpha Called from file ocaml/xapi/xapi_pci.ml, line 218
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 3/15 xapi @ Alpha Called from file list.ml, line 82
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 4/15 xapi @ Alpha Called from file ocaml/xapi/xapi_pci.ml, line 216
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 5/15 xapi @ Alpha Called from file ocaml/xapi/xapi_pci.ml, line 227
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 6/15 xapi @ Alpha Called from file ocaml/xapi/dbsync_slave.ml, line 239
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 7/15 xapi @ Alpha Called from file ocaml/xapi/dbsync_slave.ml, line 305
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 8/15 xapi @ Alpha Called from file ocaml/xapi/dbsync.ml, line 63
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 9/15 xapi @ Alpha Called from file ocaml/xapi/server_helpers.ml, line 80
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 10/15 xapi @ Alpha Called from file hashtbl.ml, line 194
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 11/15 xapi @ Alpha Called from file lib/debug.ml, line 92
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 12/15 xapi @ Alpha Called from file ocaml/xapi/server_helpers.ml, line 99
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 13/15 xapi @ Alpha Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 14/15 xapi @ Alpha Called from file hashtbl.ml, line 194
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace] 15/15 xapi @ Alpha Called from file lib/debug.ml, line 92
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |starting up database engine D:7d8677d911f0|backtrace]
Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 |starting up database engine D:7d8677d911f0|dbsync] dbsync caught an exception: INTERNAL_ERROR: [ Not_found ]
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] starting up database engine D:7d8677d911f0 failed with exception Not_found
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] Raised Not_found
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 1/19 xapi @ Alpha Raised at file lib/debug.ml, line 240
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 2/19 xapi @ Alpha Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 3/19 xapi @ Alpha Called from file lib/backtrace.ml, line 114
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 4/19 xapi @ Alpha Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 35
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 5/19 xapi @ Alpha Called from file ocaml/xapi/dbsync.ml, line 75
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 6/19 xapi @ Alpha Called from file hashtbl.ml, line 194
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 7/19 xapi @ Alpha Called from file lib/debug.ml, line 92
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 8/19 xapi @ Alpha Called from file ocaml/xapi/dbsync.ml, line 80
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 9/19 xapi @ Alpha Called from file ocaml/xapi/xapi.ml, line 102
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 10/19 xapi @ Alpha Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 11/19 xapi @ Alpha Called from file lib/backtrace.ml, line 114
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 12/19 xapi @ Alpha Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 35
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 13/19 xapi @ Alpha Called from file ocaml/xapi/server_helpers.ml, line 80
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 14/19 xapi @ Alpha Called from file string.ml, line 118
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 15/19 xapi @ Alpha Called from file sexp.ml, line 112
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 16/19 xapi @ Alpha Called from file ocaml/xapi/server_helpers.ml, line 99
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 17/19 xapi @ Alpha Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 18/19 xapi @ Alpha Called from file hashtbl.ml, line 194
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace] 19/19 xapi @ Alpha Called from file lib/debug.ml, line 92
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 |server_init D:319630a43329|backtrace]
Mar 30 21:00:24 Alpha xapi: [ warn|Alpha|0 |server_init D:319630a43329|startup] task [starting up database engine] exception: Not_found
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 ||backtrace] server_init D:319630a43329 failed with exception Not_found
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 ||backtrace] Raised Not_found
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 ||backtrace] 1/1 xapi @ Alpha Raised at file (Thread 0 has no backtrace table. Was with_backtraces called?, line 0
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 ||backtrace]
Mar 30 21:00:24 Alpha xapi: [debug|Alpha|0 ||xapi] xapi top-level caught exception: INTERNAL_ERROR: [ Not_found ]
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 ||backtrace] Raised Not_found
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 ||backtrace] 1/1 xapi @ Alpha Raised at file (Thread 0 has no backtrace table. Was with_backtraces called?, line 0
Mar 30 21:00:24 Alpha xapi: [error|Alpha|0 ||backtrace]

now it looks like the problem is in the xapi_pci.ml .... with dependencies:

let update_dependencies pfs =
let rec update = function
| [] -> ()
| (pref, prec, pci, _) :: remaining ->
let dependencies = List.map
(fun address ->
let r, _, , _ = List.find (fun (, rc, _, _) -> rc.Db_actions.pCI_pci_id = address) pfs
in r)
pci.related
in
Db.PCI.set_dependencies ~__context ~self:pref ~value:dependencies;
update remaining
in
update pfs
in
update_dependencies pfs;

Any pointers how to solve this?

Is there a python 3 version? I don't think the current version 1.2 works with Python 3. I ran into xmlrpclib and httplib issues.

1. create a VDI
2. snapshot this VDI
3. inspect snapshot.snapshot_of: it contains the ref of the parent VDI
4. destroy the VDI
5. after a few minutes, inspect snapshot.snapshot_of: it still contains the ref of the parent VDI

Behaviour observed on XenServer 7.6

Xapi needs the ability to import and export VHDs.

Release gating for xapi 2.0.

Hello,

I am attempting to install new virtual machines using scripts/examples/python/install.py but I am hitting the following error. Could I have some guidance on debugging this please?

Thanks,

Andrew

['BOOTLOADER_FAILED', 'OpaqueRef:eeb23845-bac1-95b8-0a51-3994847e9906', 'UNSUPPORTED_INSTALL_METHOD\nother-config:install-repository was not set to an appropriate value, and this is required for the selected distribution type.\n\n']
Traceback (most recent call last):
File "./install.py", line 134, in
main(session)
File "./install.py", line 89, in main
session.xenapi.VM.start(vm, False, True)
File "/root/xen-api/scripts/examples/python/XenAPI.py", line 245, in call
return self.__send(self.__name, args)
File "/root/xen-api/scripts/examples/python/XenAPI.py", line 149, in xenapi_request
result = _parse_result(getattr(self, methodname)(*full_params))
File "/root/xen-api/scripts/examples/python/XenAPI.py", line 219, in _parse_result
raise Failure(result['ErrorDescription'])
XenAPI.Failure: ['BOOTLOADER_FAILED', 'OpaqueRef:eeb23845-bac1-95b8-0a51-3994847e9906', 'UNSUPPORTED_INSTALL_METHOD\nother-config:install-repository was not set to an appropriate value, and this is required for the selected distribution type.\n\n']

Code file an appeal to the ocaml/xapi/static_vdis.ml produces /etc/init.d/attach-static-vdis script:

(** If we just rebooted and failed to attach our static VDIs then this can be called to reattempt the attach:
    this is necessary for HA to start. *)
let reattempt_on_boot_attach () =
    let script = "attach-static-vdis" in
    try
        ignore(Helpers.call_script "/sbin/service" [ script; "start" ])
    with e ->
        warn "Attempt to reattach static VDIs via '%s start' failed: %s" script (ExnHelper.string_of_exn e)

But the file (scripts/init.d-attach-static-vdis) from which to create the /etc/init.d/attach-static-vdis I do not see. (File /etc/init.d/attach-static-vdis I only found in the archive dom0fs.tar.bz2 at the XenServer-6.2.0-install-cd.iso.)

Are there any plans for this? So that I could hypothetically do:

    res = await session.login_with_password('login', 'password')
    all_vms = await session.xenapi.VM.get_all_records()
    print(all_vms)
    vm_ref = await session.xenapi.VM.get_by_uuid('uuid')
    halt_async = await session.xenapi.Async.VM.shutdown(vm_ref)
    print(halt_async)
    await session.close()

`make api-build' fails with

[...]
======> 1296574192 clone-xen-api.git: acquired /local/matthiasg-local/builds/build-git/obj/repos/xen-api.git.lock
+ GIT=git
+ GIT_URL=git://hg.uk.xensource.com/git
+ REPO_DIR=/local/matthiasg-local/builds/build-git/obj/repos
+ shift
+ MY_REPOS=/local/matthiasg-local/builds/build-git/myrepos
+ shift
+ MANIFEST=/local/matthiasg-local/builds/build-git/obj/manifest
+ shift
+ REPO=xen-api
+ shift
+ MODE=git
+ case "$GIT_BRANCH" in
+ GIT_BRANCH=master
+ CLONE=y
+ repod=/local/matthiasg-local/builds/build-git/obj/repos/xen-api
+ cookie=/local/matthiasg-local/builds/build-git/obj/repos/xen-api.git.cookie
++ dirname /local/matthiasg-local/builds/build-git/obj/repos/xen-api
+ mkdir -p /local/matthiasg-local/builds/build-git/obj/repos
++ grep '^xen-api.git' /local/matthiasg-local/builds/build-git/obj/manifest
++ awk '{print $2}'
+ cset=
+ '[' -d /local/matthiasg-local/builds/build-git/myrepos/xen-api ']'
+ echo xen-api: myrepos override found, linking it in
xen-api: myrepos override found, linking it in
+ '[' -d /local/matthiasg-local/builds/build-git/obj/repos/xen-api ']'
+ '[' '!' -h /local/matthiasg-local/builds/build-git/obj/repos/xen-api ']'
+ '[' '!' -h /local/matthiasg-local/builds/build-git/obj/repos/xen-api ']'
++ git --work-tree /local/matthiasg-local/builds/build-git/obj/repos/xen-api --git-dir /local/matthiasg-local/builds/build-git/obj/repos/xen-api/.git rev-parse HEAD
+ cset=c0ec114bac76b7de6620d109ebeb45562aef01ec
+ modified /local/matthiasg-local/builds/build-git/obj/repos/xen-api
+ git --work-tree /local/matthiasg-local/builds/build-git/obj/repos/xen-api --git-dir /local/matthiasg-local/builds/build-git/obj/repos/xen-api/.git status
+ grep -E '^#[[:space:]]*modified:'
+ return 1
+ islocal=
+ '[' '' = yes ']'
+ update_cookie c0ec114bac76b7de6620d109ebeb45562aef01ec
+ local oldc
+ '[' c0ec114bac76b7de6620d109ebeb45562aef01ec = '' ']'
+ '[' -e /local/matthiasg-local/builds/build-git/obj/repos/xen-api.git.cookie ']'
++ cat /local/matthiasg-local/builds/build-git/obj/repos/xen-api.git.cookie
+ oldc=c0ec114bac76b7de6620d109ebeb45562aef01ec
+ '[' Xc0ec114bac76b7de6620d109ebeb45562aef01ec '!=' Xc0ec114bac76b7de6620d109ebeb45562aef01ec ']'
+ echo Cookie unchanged
Cookie unchanged
+ exit 0
======> 1296574192 clone-v6.hg: acquired /local/matthiasg-local/builds/build-git/obj/repos/v6.hg.lock
v6: myrepos override found, linking it in
Refreshing cookie to: local.1296574193.695652bdb66d+
======> 1296574193 api: Performing build with build-number 0
make clean
rm -f /output/api/PACKAGES.main/xapi.tar.bz2 /output/api/xapi-devel.tar.gz /output/api/SOURCES/xen-api-src.tar.bz2 /output/api/cli-regress.tar.gz /output/api/sdk-html.zip /output/api/sdk.tar.gz
rm -rf /output/api/datamodel /output/api/sdkiso /output/api
make -C /repos/xen-api.hg clean
make: *** /repos/xen-api.hg: No such file or directory.  Stop.
make[4]: *** [clean] Error 2
make[3]: *** [/output/api/cli-regress.tar.gz] Error 2
make[2]: *** [__api-build] Error 1
make[1]: *** [/local/matthiasg-local/builds/build-git/obj/.build-api] Error 2
make: *** [api-build] Error 2

Conditions:

1. PV domain with enabled memory hotplug support
2. Grow beyond static-max limit (It not correct for xapi, but problem not here)
3. non-live migration: xe vm-migrate uuid=... host=samehost

results:

VM terminated (/tmp/xenguest log below). xapi set 'suspended' state for that VM, attempt to resume cause error:
xe vm-resume uuid=3c676a62-b1a3-84bb-b6d0-d5ab3aae2d5e on=samehost
You gave an invalid object reference. The object may have recently been deleted. The class parameter gives the type of reference given, and the handle parameter echoes the bad value given.
class: VDI
handle: OpaqueRef:NULL

/tmp/xenguestDOMID.log:

xenguest helper: debug: Arguments parsed successfully [ /opt/xensource/libexec/xenguest; -controloutfd; 6; -controlinfd; 7; -debuglog; /tmp/xenguest.87.log; -mode; restore; -domid; 87; -fd; 8; -store_port; 1; -console_port; 2; -fork; true ].
xenguest helper: debug: Will fork to capture stdout and stderr from libxenguest
xenguest helper: debug: restore mode selected
xenguest helper: debug: control_write: stderr:xc: detail: d87:xc_domain_restore start: p2m_size = 200000\n
xenguest helper: debug: control_write: stderr:xc: error: d87:Failed to pin batch of 1024 page tables (22 = Invalid argument): Internal error\n
xenguest helper: debug: control_write: stderr:xc: detail: d87:Restore exit with rc=1\n
xenguest helper: debug: Zero-length read on stdout; closing
xenguest helper: debug: Zero-length read on stderr; closing
xenguest helper: debug: Zero-length read on output; closing
xenguest helper: debug: control_write: error:xc_domain_restore 1 d87:Failed to pin batch of 1024 page tables (22 = Invali"

Error during migration:

xe vm-migrate uuid=3c676a62-b1a3-84bb-b6d0-d5ab3aae2d5e host=samehost
The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem.
message: File "xapi_xenops.ml", line 1788, characters 3-9: Assertion failed

I think that situation should be handled gracefully without crashing VM to unworking state.

See #955 for way guest could has more maxmem than static-max.