May 2014 - Devel - libvirt List Archives

[libvirt] [PATCH v5] bhyve: implement PCI address allocation
by Roman Bogorodskiy 01 Jun '14

01 Jun '14

Changes from v4: - Qemu-related part of sharing the common code is complete and pushed, so patch lives on its own now - virBhyveProcessBuildBhyveCmd() modified to loop over disks and nets and call bhyveBuildDiskArgStr() and bhyveBuildNetArgStr() for an individual device to make the latter more readable - Fix double assing / double semicolon typo - Fix spelling in virReportError() for disks - Make bhyveAssignDevicePCISlots() assign nets before disks to reproduce the old behaviour when one net and one disk were supported - Make persistentAddrs of _bhyveDomainObjPrivate bool. Roman Bogorodskiy (1): bhyve: implement PCI address allocation po/POTFILES.in | 1 + src/Makefile.am | 4 + src/bhyve/bhyve_command.c | 112 +++++++------ src/bhyve/bhyve_device.c | 174 +++++++++++++++++++++ src/bhyve/bhyve_device.h | 38 +++++ src/bhyve/bhyve_domain.c | 75 +++++++++ src/bhyve/bhyve_domain.h | 39 +++++ src/bhyve/bhyve_driver.c | 12 +- .../bhyvexml2argvdata/bhyvexml2argv-acpiapic.args | 2 +- tests/bhyvexml2argvdata/bhyvexml2argv-acpiapic.xml | 2 + tests/bhyvexml2argvdata/bhyvexml2argv-base.args | 2 +- tests/bhyvexml2argvdata/bhyvexml2argv-base.xml | 2 + tests/bhyvexml2argvdata/bhyvexml2argv-console.args | 4 +- tests/bhyvexml2argvdata/bhyvexml2argv-console.xml | 2 + .../bhyvexml2argv-disk-virtio.args | 2 +- .../bhyvexml2argv-disk-virtio.xml | 2 + tests/bhyvexml2argvdata/bhyvexml2argv-macaddr.args | 2 +- tests/bhyvexml2argvdata/bhyvexml2argv-macaddr.xml | 2 + tests/bhyvexml2argvdata/bhyvexml2argv-serial.args | 4 +- tests/bhyvexml2argvdata/bhyvexml2argv-serial.xml | 2 + 20 files changed, 416 insertions(+), 67 deletions(-) create mode 100644 src/bhyve/bhyve_device.c create mode 100644 src/bhyve/bhyve_device.h create mode 100644 src/bhyve/bhyve_domain.c create mode 100644 src/bhyve/bhyve_domain.h -- 1.9.0

2 6

[libvirt] [PATCH] docs: bhyve driver documentation improvements
by Roman Bogorodskiy 01 Jun '14

01 Jun '14

- Document 'domxml-to-native' command - Mention that the nmdm console support needs an appropriate kernel module loaded --- docs/drvbhyve.html.in | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/docs/drvbhyve.html.in b/docs/drvbhyve.html.in index 603be80..ecd7c0c 100644 --- a/docs/drvbhyve.html.in +++ b/docs/drvbhyve.html.in @@ -98,6 +98,9 @@ the following to the domain XML (Since 1.2.4): </devices> ...</pre> + +Make sure to load the <code>nmdm</code> kernel module if you plan to use that. + Then <code>virsh console</code> command can be used to connect to the text console of a guest. @@ -110,6 +113,24 @@ to let a guest boot or start a guest using: <pre>start --console domname</pre> +<h3><a name="xmltonative">Converting from domain XML to Bhyve args</a></h3> + + +The <code>virsh domxml-to-native</code> command allows to preview the actual <code>bhyve</code> commands +that will be executed for a given domain. It outputs two lines, the first line is a <code>bhyveload</code> +command and the second is a <code>bhyve</code> command. + + +Please note that the <code>virsh domxml-to-native</code> doesn't do any real actions but printing the command, +for example, it doesn't try to find a proper TAP interface and create it, like it's done when starting a domain, and +always returns <code>tap0</code> for the network interface. So if you're going to run these commands manually, most likely +you might want to tweak them. + +<pre> +# virsh -c "bhyve:///system" domxml-to-native --format bhyve-argv --xml /path/to/bhyve.xml +/usr/sbin/bhyveload -m 214 -d /home/user/vm1.img vm1 +/usr/sbin/bhyve -c 2 -m 214 -A -I -H -P -s 0:0,hostbridge -s 3:0,virtio-net,tap0,mac=52:54:00:5d:74:e3 -s 2:0,virtio-blk,/home/user/vm1.img -s 1,lpc -l com1,/dev/nmdm0A vm1 +</pre> </body> </html> -- 1.9.0

3 3

[libvirt] [PATCHv2 0/4] qemu: fix broken RTC_CHANGE event when clock offset='variable'
by Laine Stump 01 Jun '14

01 Jun '14

(the cover letter from V1 has been preserved here with small updates) This patch series is all about: https://bugzilla.redhat.com/show_bug.cgi?id=964177 which points out a flaw in qemu's RTC_CHANGE event when the base for the guest's real time clock was given as an explicit date (rather than as 'utc' or 'localtime'). Patch 3/4 explains what qemu does, and how this patch fixes it (for the case of basis='utc' - an additional fix to properly support basis='localtime', both for RTC_CHANGE and when migrating across timezone/DST boundaries, is in Patch 4/4). (NB: the flawed RTC_CHANGE offset has been in QEMU for so long now that it has been documented and cannot be changed, so libvirt must work around it) In the meantime, the fix for basis='localtime' required that we learn the offset of localtime from utc, and that seems like something we might want to do for other reasons, so Patch 1/4 adds a new utility function do get that value that is (I hope!) POSIX compliant. Since the original patch to fix this problem was incorrect, and the new patch doesn't use any of its code, Patch 2/4 reverts that patch completely. Note that I have tested this patch by starting a domain with several variations of <clock> parameters (in a locale that is currently at UTC+3) and using the following short script to add and remove seconds from the guest's RTC while watching both the <clock> line in /var/run/libvirt/qemu/$domain.xml and the offset value sent in libvirt's VIR_DOMAIN_EVENT_ID_RTC_CHANGE event (using examples/domain-events/events-c/event-test from a libvirt source tree that has been built). All cases appear to maintain the adjustment in the status properly, as well as sending the correct value to any event handler. Here is the script I used to add/remove time from the RTC: #!/bin/sh old=$(hwclock --show | cut -f1-7 -d' ') oldabs=$(date +%s --date="$old") newabs=$(expr $oldabs + $1) new=$(date --date="@$newabs") echo Old: $oldabs $old echo New: $newabs $new hwclock --set --date="@$newabs" Laine Stump (4): util: new function virTimeLocalOffsetFromUTC Revert "qemu: Report the offset from host UTC for RTC_CHANGE event" qemu: fix RTC_CHANGE event for <clock offset='variable' basis='utc'/> qemu: fix <clock offset='variable' basis='localtime'/> src/conf/domain_conf.c | 32 +++++++++++++------------------- src/conf/domain_conf.h | 8 +++++--- src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 43 ++++++++++++++++++++++++++++++------------- src/qemu/qemu_process.c | 34 +++++++++++++++++++--------------- src/util/virtime.c | 41 ++++++++++++++++++++++++++++++++++++++++- src/util/virtime.h | 5 +++-- tests/virtimetest.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ 8 files changed, 155 insertions(+), 53 deletions(-) -- 1.9.0

9 42

[libvirt] [PATCH] build: avoid compiler warning on 32-bit platform
by Eric Blake 30 May '14

30 May '14

On a 32-bit platform: virstringtest.c: In function 'mymain': virstringtest.c:673: warning: this decimal constant is unsigned only in ISO C90 I already had a comment in the file about the 64-bit counterpart; the easiest fix was to make both sites use the standardized macro that is guaranteed to work. * tests/virstringtest.c (mymain): Minimum signed integers are a pain. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Pushing under the build-breaker rule. tests/virstringtest.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/tests/virstringtest.c b/tests/virstringtest.c index 1e330f9..96c3784 100644 --- a/tests/virstringtest.c +++ b/tests/virstringtest.c @@ -670,7 +670,7 @@ mymain(void) -1LL, 0, 18446744073709551615ULL, 0); TEST_STRTOL("-2147483647", NULL, -2147483647, 0, 2147483649U, 0, -2147483647LL, 0, 18446744071562067969ULL, 0); - TEST_STRTOL("-2147483648", NULL, -2147483648, 0, 2147483648U, 0, + TEST_STRTOL("-2147483648", NULL, INT32_MIN, 0, 2147483648U, 0, -2147483648LL, 0, 18446744071562067968ULL, 0); TEST_STRTOL("-2147483649", NULL, 0, -1, 2147483647U, 0, -2147483649LL, 0, 18446744071562067967ULL, 0); @@ -680,10 +680,8 @@ mymain(void) -4294967296LL, 0, 18446744069414584320ULL, 0); TEST_STRTOL("-9223372036854775807", NULL, 0, -1, 0U, -1, -9223372036854775807LL, 0, 9223372036854775809ULL, 0); - /* Bah, stupid gcc warning about -9223372036854775808LL being an - * unrepresentable integer constant */ TEST_STRTOL("-9223372036854775808", NULL, 0, -1, 0U, -1, - 0x8000000000000000LL, 0, 9223372036854775808ULL, 0); + INT64_MIN, 0, 9223372036854775808ULL, 0); TEST_STRTOL("-9223372036854775809", NULL, 0, -1, 0U, -1, 0LL, -1, 9223372036854775807ULL, 0); TEST_STRTOL("-18446744073709551615", NULL, 0, -1, 0U, -1, -- 1.9.3

1 0

[libvirt] [PATCH] libxl: add support for cache=directsync to to libxl_device_disk
by Olaf Hering 30 May '14

30 May '14

Up to now xend and libxl did not have any way and need to specify a cache= mode for block devices. At least the libxl driver did just ignore the cachemode value. With xen-4.5 a new knob was added to libxl which instructs qemu to use threads=native cache=directsync in the qdisk driver. This mode was disabled early due to a pvops kernel bug. As a workaround cache=writeback was set as default. The kernel bug is long fixed. I assume the forward ported xenlinux kernel never had this bug. This change exposes the knob to libvirt. If cache=directsync is set qemu is instructed to use native AIO. This change also lays the ground work to set cache=unsafe at some point. It is currently under investigation whether libxl should expose such knob. Signed-off-by: Olaf Hering <olaf(a)aepfle.de> --- src/libxl/libxl_conf.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 4cb062e..79f4a82 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -739,6 +739,20 @@ libxlDiskSetDiscard(libxl_device_disk *x_disk, int discard) #endif } +static void +libxlDiskSetCacheMode(libxl_device_disk *x_disk, int cachemode) +{ + switch (cachemode) { +#if defined(LIBXL_HAVE_DEVICE_DISK_DIRECT_IO_SAFE) + case VIR_DOMAIN_DISK_CACHE_DIRECTSYNC: + x_disk->direct_io_safe = 1; + break; +#endif + default: + break; + } +} + int libxlMakeDisk(virDomainDiskDefPtr l_disk, libxl_device_disk *x_disk) @@ -855,6 +869,7 @@ libxlMakeDisk(virDomainDiskDefPtr l_disk, libxl_device_disk *x_disk) x_disk->readwrite = !l_disk->readonly; x_disk->is_cdrom = l_disk->device == VIR_DOMAIN_DISK_DEVICE_CDROM ? 1 : 0; libxlDiskSetDiscard(x_disk, l_disk->discard); + libxlDiskSetCacheMode(x_disk, l_disk->cachemode); /* An empty CDROM must have the empty format, otherwise libxl fails. */ if (x_disk->is_cdrom && !x_disk->pdev_path) x_disk->format = LIBXL_DISK_FORMAT_EMPTY;

2 1

[libvirt] Libvrt Migrate an Offline VM
by Sijo Jose 30 May '14

30 May '14

Hi, Is it possible to migrate an Offline VM using libvirt API ? Regards Sijo Jose

2 1

[libvirt] [libvirt-python PATCH] fix leak in memoryStats with older python
by Martin Kletzander 30 May '14

30 May '14

libvirt_virDomainMemoryStats() function creates a dictionary without any checks whether the additions were successful, whether the python objects were created and, most importantly, without decrementing the reference count on the objects added to the dictionary. This is somehow not an issue with current upstream versions, however with python 2.6 this exposes a leak in our bindings. The following patch works on both old and new CPython versions and is already used in other parts of the code, so it's also most straightforward. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- libvirt-override.c | 68 +++++++++++++++++++++++++++++++++++------------------- 1 file changed, 44 insertions(+), 24 deletions(-) diff --git a/libvirt-override.c b/libvirt-override.c index a7a6213..8fd856b 100644 --- a/libvirt-override.c +++ b/libvirt-override.c @@ -734,6 +734,7 @@ libvirt_virDomainMemoryStats(PyObject *self ATTRIBUTE_UNUSED, PyObject *args) { size_t i; virDomainMemoryStatStruct stats[VIR_DOMAIN_MEMORY_STAT_NR]; PyObject *info; + PyObject *key = NULL, *val = NULL; if (!PyArg_ParseTuple(args, (char *)"O:virDomainMemoryStats", &pyobj_domain)) return NULL; @@ -749,31 +750,50 @@ libvirt_virDomainMemoryStats(PyObject *self ATTRIBUTE_UNUSED, PyObject *args) { return VIR_PY_NONE; for (i = 0; i < nr_stats; i++) { - if (stats[i].tag == VIR_DOMAIN_MEMORY_STAT_SWAP_IN) - PyDict_SetItem(info, libvirt_constcharPtrWrap("swap_in"), - libvirt_ulonglongWrap(stats[i].val)); - else if (stats[i].tag == VIR_DOMAIN_MEMORY_STAT_SWAP_OUT) - PyDict_SetItem(info, libvirt_constcharPtrWrap("swap_out"), - libvirt_ulonglongWrap(stats[i].val)); - else if (stats[i].tag == VIR_DOMAIN_MEMORY_STAT_MAJOR_FAULT) - PyDict_SetItem(info, libvirt_constcharPtrWrap("major_fault"), - libvirt_ulonglongWrap(stats[i].val)); - else if (stats[i].tag == VIR_DOMAIN_MEMORY_STAT_MINOR_FAULT) - PyDict_SetItem(info, libvirt_constcharPtrWrap("minor_fault"), - libvirt_ulonglongWrap(stats[i].val)); - else if (stats[i].tag == VIR_DOMAIN_MEMORY_STAT_UNUSED) - PyDict_SetItem(info, libvirt_constcharPtrWrap("unused"), - libvirt_ulonglongWrap(stats[i].val)); - else if (stats[i].tag == VIR_DOMAIN_MEMORY_STAT_AVAILABLE) - PyDict_SetItem(info, libvirt_constcharPtrWrap("available"), - libvirt_ulonglongWrap(stats[i].val)); - else if (stats[i].tag == VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON) - PyDict_SetItem(info, libvirt_constcharPtrWrap("actual"), - libvirt_ulonglongWrap(stats[i].val)); - else if (stats[i].tag == VIR_DOMAIN_MEMORY_STAT_RSS) - PyDict_SetItem(info, libvirt_constcharPtrWrap("rss"), - libvirt_ulonglongWrap(stats[i].val)); + switch (stats[i].tag) { + case VIR_DOMAIN_MEMORY_STAT_SWAP_IN: + key = libvirt_constcharPtrWrap("swap_in"); + break; + case VIR_DOMAIN_MEMORY_STAT_SWAP_OUT: + key = libvirt_constcharPtrWrap("swap_out"); + break; + case VIR_DOMAIN_MEMORY_STAT_MAJOR_FAULT: + key = libvirt_constcharPtrWrap("major_fault"); + break; + case VIR_DOMAIN_MEMORY_STAT_MINOR_FAULT: + key = libvirt_constcharPtrWrap("minor_fault"); + break; + case VIR_DOMAIN_MEMORY_STAT_UNUSED: + key = libvirt_constcharPtrWrap("unused"); + break; + case VIR_DOMAIN_MEMORY_STAT_AVAILABLE: + key = libvirt_constcharPtrWrap("available"); + break; + case VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON: + key = libvirt_constcharPtrWrap("actual"); + break; + case VIR_DOMAIN_MEMORY_STAT_RSS: + key = libvirt_constcharPtrWrap("rss"); + break; + default: + continue; + } + val = libvirt_ulonglongWrap(stats[i].val); + + if (!key || !val || PyDict_SetItem(info, key, val) < 0) { + Py_DECREF(info); + info = NULL; + goto cleanup; + } + Py_DECREF(key); + Py_DECREF(val); + key = NULL; + val = NULL; } + + cleanup: + Py_XDECREF(key); + Py_XDECREF(val); return info; } -- 1.9.3

2 2

[libvirt] Host OS, Storage Info
by Sijo Jose 30 May '14

30 May '14

Hi, Is there any way to get host OS information and host Storage in formations using libvirt API...? Rgds -Sijo

3 6

[libvirt] [libvirt-glib] [PATCH] GVirDomainSnapshot: add gvir_domain_snapshot_delete
by Timm Bäder 30 May '14

30 May '14

--- libvirt-gobject/libvirt-gobject-domain-snapshot.c | 21 +++++++++++++++++++++ libvirt-gobject/libvirt-gobject-domain-snapshot.h | 3 +++ libvirt-gobject/libvirt-gobject.sym | 5 +++++ 3 files changed, 29 insertions(+) diff --git a/libvirt-gobject/libvirt-gobject-domain-snapshot.c b/libvirt-gobject/libvirt-gobject-domain-snapshot.c index ab23342..f46c99b 100644 --- a/libvirt-gobject/libvirt-gobject-domain-snapshot.c +++ b/libvirt-gobject/libvirt-gobject-domain-snapshot.c @@ -206,3 +206,24 @@ GVirConfigDomainSnapshot *gvir_domain_snapshot_get_config free(xml); return conf; } + +/** + * gvir_domain_snapshot_delete: + * @snapshot: the domain_snapshot + * @error: (allow-none): Place-holder for error or NULL + */ +void gvir_domain_snapshot_delete(GVirDomainSnapshot *snapshot, GError **error) +{ + GVirDomainSnapshotPrivate *priv; + int status; + + g_return_if_fail(GVIR_IS_DOMAIN_SNAPSHOT (snapshot)); + g_return_if_fail(error == NULL || *error == NULL); + + priv = snapshot->priv; + status = virDomainSnapshotDelete(priv->handle, 0); + if (status < 0) { + gvir_set_error_literal(error, GVIR_DOMAIN_SNAPSHOT_ERROR, 0, + "Unable to delete snapshot"); + } +} diff --git a/libvirt-gobject/libvirt-gobject-domain-snapshot.h b/libvirt-gobject/libvirt-gobject-domain-snapshot.h index 5bd827c..575f56f 100644 --- a/libvirt-gobject/libvirt-gobject-domain-snapshot.h +++ b/libvirt-gobject/libvirt-gobject-domain-snapshot.h @@ -69,6 +69,9 @@ GVirConfigDomainSnapshot *gvir_domain_snapshot_get_config guint flags, GError **err); +void gvir_domain_snapshot_delete (GVirDomainSnapshot *snapshot, GError **error); + + G_END_DECLS #endif /* __LIBVIRT_GOBJECT_DOMAIN_SNAPSHOT_H__ */ diff --git a/libvirt-gobject/libvirt-gobject.sym b/libvirt-gobject/libvirt-gobject.sym index f2419ac..5d12a6a 100644 --- a/libvirt-gobject/libvirt-gobject.sym +++ b/libvirt-gobject/libvirt-gobject.sym @@ -234,4 +234,9 @@ LIBVIRT_GOBJECT_0.1.5 { gvir_connection_open_read_only_finish; } LIBVIRT_GOBJECT_0.1.4; +LIBVIRT_GOBJECT_0.1.9 { + global: + gvir_domain_shapshot_delete; +} LIBVIRT_GOBJECT_0.1.5; + # .... define new API here using predicted next version number .... -- 1.9.3

2 1

[libvirt] GSoC student introduction and work plan
by Taowei Luo 30 May '14

30 May '14

Hi, everyone, My name is Taowei Luo. I'm one of the students working for GSoC this summer. My project is rewriting the vbox driver. Before coding, I really need some discussions about how to implement it. Here I post my first version of plan. I had show as much details as I thought about in this plan. If anyone have ideas or suggestions about my work, I would like to hear. My nick name in #virt IRC channel is uaedante (or dante I used before). If I am offline in IRC, please contract me with my email address uaedante(a)gmail.com. Regards, Taowei. Plan to rewrite vbox driver Introduction: The existing vbox driver codes use vbox API directly. But the vbox API is incompatible between different versions. To support all vbox API versions, the vbox_tmpl.c file provides a template to implement all vbox drivers. Each specified version of vbox driver includes the vbox_tmpl.c file, with the definition in the corresponding head file, they work well. As the vbox API defined in head files is conflict between different versions, even some behavior of vbox APIs are changed. The vbox_tmpl.c contains lots of codes such as “#if VBOX_API_VERSION < 4001000”. These codes is hard to manage or adding new features. Plan: The core idea of my rewriting work is to add a middle layer to uniform the API changes. This modification will not change any functions’ behavior or sematic. The middle layer has a global structure which contains API changes. Like this: struct vboxUniformedAPI { A (*funcA)(A1 a, ….); B (*funcB)(B1 a, ….); } If there is a code segment: #if VBOX_API_VERSION < 4001000 adapter->vtbl->GetHostInterface(adapter, &hostIntUtf16); #else /* VBOX_API_VERSION >= 4001000 */ adapter->vtbl->GetBridgedInterface(adapter, &hostIntUtf16); #endif /* VBOX_API_VERSION >= 4001000 */ This will result to a variable in vboxUniformedAPI structure: RetType (*GetInterface)(INetworkAdapter *a, PRUnichar *b) When using the vbox under 4.1, this variable will points to a function that calls GetHostInterface. When using the vbox later than 4.1 and the variable will points to a function which calls GetBridgedInterface. When replace these code segments with a single function, we need to do living variable analyze and find out what is used and what is changed in these codes. I plan to do these analyze manually. All conflict in function prototype or function implementation will be fixed up though this method. When meeting a conflict in variable type, like: #if VBOX_API_VERSION < 4001000 TypeA var; #else /* VBOX_API_VERSION >= 4001000 */ TypeB var; #endif /* VBOX_API_VERSION >= 4001000 */ I will add a union like this: Union TypeC{ TypeA a;// used in some versions TypeB b;// used in some other versions } If there is any operation using variables with such a union type (or functions use it as an argument or return value), I will add a new function in vboxUniformedAPI to handle this operation. These functions use TypeC as parameter type, dispatch it depends on the vbox version and return TypeC value to conceal type conflict. We still have another kind of conflict. There are some versions have more variables, operations or function calls than other versions. I will reserve all variables even though they may not be used in some situation. And put an empty function if they have nothing to do in the specified function step. (I have a backup solution here. That is adding some flags to indicate whether the procession is necessary in the API version and prevent upper layer from calling a nonexistent function.) Expected result: After rewriting with the rules above, we will have a new vbox_tmpl.c. It gathers version specified code and common code respectively. The common codes use stable vbox API or functions in vboxUniformedAPI. A function named InstallvboxUnifromedAPI will fill the vboxUniformedAPI structure depends on the current vbox API version. In final step, I will put all vbox APIs into the vboxUniformedAPI and make the vbox driver codes use my API only. If this is done, the vbox driver will not be complied for each version anymore. Implementation: First, define the vboxUniformedAPI structure in vbox_tmpl.c, and write the InstallvboxUnifromedAPI function for every vbox API version. Next, rewrite the functions which have conflict codes one by one. Each time rewrite a new function, we can do some tests (here, I am not sure what kind of tests is enough). When rewriting one function in vbox_tmpl.c, the others will not change. At this point, there will split version specified codes and common codes But we still need to build the whole vbox_tmpl.c for each vbox API version. If we want a single object file be generated by vbox_tmpl.c, we need to prevent vbox_tmpl.c from calling vbox API directly. This could be done by putting all of the vbox API calls into the middle vboxUniformedAPI layer, and moving common codes into vbox_common.c. The vbox_common.c should only use APIs in vboxUniformedAPI and will be complied only once.

2 2