[libvirt] VMware Workstation/Player support
by Jean-Baptiste Rouault
Hi all,
I'm working on the hynesim project (http://www.hynesim.org
http://blog.hynesim.org).
We are going to add VMware Workstation support to hynesim,
so we would like to contribute to the development of a libvirt driver.
There probably are multiple ways of doing this, one of them could
be to use the VIX C API provided by VMware :
http://www.vmware.com/support/developer/vix-api/
However, the VIX license seems to be quite restrictive :
http://www.vmware.com/download/eula/vixapi_eula.html
I'm not a license expert so I don't know if this license forbids
using the API in software like libvirt.
Another possibility could be to run VMware command line tools
from libvirt to control guests.
As Daniel P. Berrange stated on IRC yesterday, the vmx <-> XML
conversion code can be reused from the ESX driver.
I'd like to have your opinion about the "best" to implement this
VMware Workstation driver.
Regards,
Jean-Baptiste Rouault
13 years, 6 months
[libvirt] process= support for 'qemu-kvm -name' [Bug 576950]
by John Morrissey
I wrote (attached here, and to the bug) a quick patch that sets the process
name to the same value as the window title.
I'm unsure where to go from here. Should I add support for converting
"native" QEMU command lines to libvirt XML? What would that look like, since
I'm not modifying the libvirt format? Should it just drop any ,process= from
the QEMU command line it's parsing? I also imagine the test cases will need
updating.
If someone could give me some high-level guidance, I'd be happy to keep
going on this.
john
--
John Morrissey _o /\ ---- __o
jwm(a)horde.net _-< \_ / \ ---- < \,
www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
13 years, 6 months
[libvirt] New save/restore api proposal
by Jean-Baptiste Rouault
Hello all,
I'd like to add support for save and restore to the OpenVZ and VirtualBox
drivers because I have to support these operations in the application I'm
working on.
However, the save/restore API in its current state doesn't fit well to our
needs. The main problem is that the domain definition is included inside the
save file. This is problematic because between the save and the restore
operations, the names of the network interfaces on the host side are likely to
have changed and we can't modify them before restoring the domain.
To summarize, what we would like to be able to do is:
- save a domain and undefine it
- update the domain definition to use the new names of host side interfaces
- restore the domain
This is why I would like to add two new functions with the following
signatures (better names are probably needed):
int virDomainSaveState(virDomainPtr domain, const char *to);
int virDomainRestoreState(virDomainPtr domain, const char *from);
The first one would do the same as virDomainSave but without prepending the
domain's definition to the save file.
The other function would be able to restore a domain saved by the first one.
What do you think ?
Regards,
Jean-Baptiste
13 years, 6 months
[libvirt] [PATCH 0/2] speed up qemu domain save by increasing dd blocksize
by Laine Stump
These two patches are posted together because applying the 2nd exposes
the bug fixed by the first.
Here are the results of tests I made with various block sizes before
deciding the 1MB really was the best balance (all tests were done on a
paused 512MB domain, saving to local disk on a Lenovo T61 laptop)
BS M:SS save image size
----- ---- ---------------
2048K - 0:56 476135451
1024K - 0:56 475090953
512k - 1:02 474564173
256k - 1:10 474303797
128k - 1:25 474176859
512 - 3:47 474085423 - the original
I didn't bother testing sizes between 512 and 128k, as there was still
significant improvement from 128k to 256k.
13 years, 6 months
[libvirt] Xen string2sexpr and sexpr2string lose quotes?
by Thomas Graves
Hello all,
I am running xen on rhel5 and using libvirt0.7.2 (I also tried 0.7.7) and it
looks like the routines string2sexpr and sexpr2string seem to lose the
quotes around the image args in the configuration.
Has anyone seen this and have a patch for this?
I have the following libvirt config:
<os>
<type>linux</type>
<kernel>/usr/lib/xen/boot/pv-grub-x86_64.gz</kernel>
<cmdline>(hd0,0)/grub/menu.lst</cmdline>
</os>
It generates the xm config info:
(image
(linux
(kernel /usr/lib/xen/boot/pv-grub-x86_64.gz)
(args '(hd0,0)/grub/menu.lst')
(device_model /usr/lib64/xen/bin/qemu-dm)
)
)
I call virDomainSetAutostart on the domain and traced it through and saw
that it gets the string quoted (args '(hd0,0)/grub/menu.lst') from xen then
ends up calling string2sexpr, changes the xend_on_start, and then
sexpr2string, and it ends up without quotes (args (hd0,0)/grub/menu.lst) and
that is what it sends back to xen. Xen then seems to chop it off to (args
('hd0,0'))
Thanks,
Tom
13 years, 7 months
[libvirt] [PATCH] PHYP: Checking for NULL values when building new guest
by Eduardo Otubo
When creating a new gust, the function phypBuildLpar() was not
checking for NULL values, making the driver to have a segmentation
fault.
---
src/phyp/phyp_driver.c | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/src/phyp/phyp_driver.c b/src/phyp/phyp_driver.c
index 251111d..999870e 100644
--- a/src/phyp/phyp_driver.c
+++ b/src/phyp/phyp_driver.c
@@ -3701,6 +3701,25 @@ phypBuildLpar(virConnectPtr conn, virDomainDefPtr def)
int exit_status = 0;
virBuffer buf = VIR_BUFFER_INITIALIZER;
+ if (!def->name) {
+ VIR_ERROR0(_("Field \"<name>\" on the domain XML file missing."));
+ goto err;
+ } else if (!def->memory) {
+ VIR_ERROR0(_
+ ("Field \"<memory>\" on the domain XML file missing."));
+ goto err;
+ } else if (!def->maxmem) {
+ VIR_ERROR0(_
+ ("Field \"<currentMemory>\" on the domain XML file missing."));
+ goto err;
+ } else if (!def->vcpus) {
+ VIR_ERROR0(_("Field \"<vcpu>\" on the domain XML file missing."));
+ goto err;
+ } else if (!def->disks[0]->src) {
+ VIR_ERROR0(_("Field \"<disk>\" on the domain XML file missing."));
+ goto err;
+ }
+
virBufferAddLit(&buf, "mksyscfg");
if (system_type == HMC)
virBufferVSprintf(&buf, " -m %s", managed_system);
--
1.7.0.4
13 years, 7 months
