[libvirt] [PATCH 0/3] Fix aliasing rules warnings with gcc-4.4
by Mark McLoughlin
Hi,
It seems gcc's strict aliasing rules got stricter with gcc-4.4.
The basic rule is that two pointers of different types can't be
used to reference the same address in memory. One exception is
using a char* and another is when different types are members
of a union.
I've used unions to fix all the warnings I see with current
CVS HEAD. I can't say I like the solution all that much, so
if anyone has better ideas ...
Cheers,
Mark.
16 years, 2 months
[libvirt] [PATCH] avoid two test failures induced by today's error-reporting changes
by Jim Meyering
I'm applying these fixes to avoid "make check" failures:
>From f41517a4250db0961482e097813eb39da5bea963 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering(a)redhat.com>
Date: Mon, 9 Feb 2009 16:25:36 +0100
Subject: [PATCH] avoid two test failures induced by today's error-reporting changes
* tests/cpuset: Adjust expected diagnostic to match new behavior.
* tests/undefine: Likewise.
---
tests/cpuset | 4 ++--
tests/undefine | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/cpuset b/tests/cpuset
index 75303e3..eeb0ee2 100755
--- a/tests/cpuset
+++ b/tests/cpuset
@@ -1,7 +1,7 @@
#!/bin/sh
# ensure that defining with an invalid vCPU cpuset elicits a diagnostic
-# Copyright (C) 2008 Free Software Foundation, Inc.
+# Copyright (C) 2008-2009 Free Software Foundation, Inc.
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -36,8 +36,8 @@ sed "s/vcpu>/vcpu cpuset='aaa'>/" xml > xml-invalid || fail=1
# Require failure and a diagnostic.
virsh --connect test:///default define xml-invalid > out 2>&1 && fail=1
cat <<\EOF > exp || fail=1
-libvir: Domain Config error : failed Xen syscall topology cpuset syntax error
error: Failed to define domain from xml-invalid
+error: failed Xen syscall topology cpuset syntax error
EOF
compare exp out || fail=1
diff --git a/tests/undefine b/tests/undefine
index 48e8356..fafdae7 100755
--- a/tests/undefine
+++ b/tests/undefine
@@ -1,7 +1,7 @@
#!/bin/sh
# exercise virsh's "undefine" command
-# Copyright (C) 2008 Free Software Foundation, Inc.
+# Copyright (C) 2008-2009 Free Software Foundation, Inc.
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -29,8 +29,8 @@ fail=0
virsh -q -c test:///default undefine test > out 2>&1
test $? = 1 || fail=1
cat <<\EOF > exp || fail=1
-libvir: Test error : internal error Domain 'test' is still running
error: Failed to undefine domain test
+error: internal error Domain 'test' is still running
EOF
compare exp out || fail=1
--
1.6.2.rc0.173.g5e148
16 years, 2 months
[libvirt] Domain comment/description string?
by Jan Kasprzak
Hello,
I use KVM+qemu for testing various distributions and playing
with different versions of software. Now I would like to migrate
my virtual machines to libvirt. One of the problems is that I would like
to have some sort of comment or description of the machine, which would
be displayed in "virsh list" or in virt-manager together with
the machine hostname. Example:
<name>rei</name>
<comment>Fedora rawhide/32bit</comment>
or
<name>konata</name>
<comment>Gentoo x86_64 with KDE 4</comment>
Does the libvirt XML format support something like
this? Embedding comment inside the <name>...</name> tag does not work.
Does libvirt support something like that? Thanks,
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ |
>> If you find yourself arguing with Alan Cox, you’re _probably_ wrong. <<
>> --James Morris in "How and Why You Should Become a Kernel Hacker" <<
16 years, 2 months
[libvirt] libvirtd and LVM snapshots
by Nick Moffitt
I'm working on an existing system that creates, manages, and destroys
Xen guests on a pool of host systems, and I use LVM copy-on-write
snapshots to keep creation rapid.
http://libvirt.org/storage.html describes logical volume pools, for
which you simply supply the name of a volume group and it allocates
volumes from that. By my reading, it appears one can even provide a
list of block devices and they will be carved into extents and pooled
into a VG for you.
Is there any interface to libvirtd that allows it to create volumes that
are snapshots of existing volumes? If not, does anyone have advice for
doing so manually in a way that plays smoothly with libvirt?
--
Support your droogs! Nick Moffitt
nick(a)zork.net
16 years, 2 months
[libvirt] Getting error "libvir: QEMU error : Domain not found"
by M. Mohan Kumar
Hi,
When I try to run vm-install on a OpenSuse 11.1 machine, vm-install displays
the following message "libvir: QEMU error : Domain not found". How ever the
functionality is not affected.
I don't think its really an error. It could be just an warning/information
message. Is there any plan to change this message as warning/information from
error level?
Note: I am not in the mailing list, so please cc me while replying.
--
Regards,
M. Mohan Kumar
16 years, 2 months
[libvirt] [Patch] enable --checkpoint option in 'virsh save'
by Matt McCowan
Folks.
I'm working on a scenario where I would like to provide my backup subsystems with a clean disk and ram state of any given VM, without necessitating shutting down the a VM.
Xen's 'xm save' function with the '-c' (checkpoint) argument made sense in that I could checkpoint save the VM, take a snapshot of the LV containing the domain and its 'save' dump then resume the domain. Unfortunately out-of-the-box the Xen implementation did not pause the domain after the checkpoint, but resumed it automatically. Fastforward to using kvm ...
Qemu/kvm with it's 'migrate' command by default left the domain paused after creating a state dump - just what I was looking for. A look at the libvirt code revealed that 'virsh save' carried out a migrate, then shut the domain down. So I have tried implementing a --checkpoint option into the save function using the --live option to the 'virsh migrate' function as a bit of a template.
I'm a sysadmin, not a coder, so please forgive any oversights and all the other coding rules that may be broken. As mentioned before I did try to simply copy how the migrate --live option is used throughout.
Patch (against 0.6.0) attached. I have also filed a feature request under bugzilla. If the additional feature is seen as warranted, please let me know what I can do to help implement it if the patch is not the way to go about it.
Thankyou very much for Libvirt
Regards
Matt McCowan
16 years, 2 months
[libvirt] libvirt and the lowest common denominator
by John Levon
I wanted to bring this topic out of a patch review thread.
Dan recently stated that only patches that use "upstream" facilities are
acceptable, meaning the xend delivered by XenSource. I'd like to make a
few points on this note:
1. I'd like to hear from the other core maintainers if they agree with
this rule.
2. I'd like to hear a rationale for this rule.
3. The Sun repository *is* the upstream for xend on Solaris for a number
of reasons:
a. The 3.1.x series is only maintained by us, there is no other 3.1 upstream
b. The XenSource upstream does not, and cannot, work on Solaris
c. XenSource have no interest in xend at all and it's effectively
unmaintained (with the exception of Novell I think).
4. I've seen stated a number of times that libvirt is designed to avoid
becoming a lowest common denominator interface. I cannot reconcile that
claim with this rule: all xend implementations must apparently be the
same, and no enhancements are allowed.
5. This rule further restricts innovation in that XenSource must agree
to any changes. This has a rather obvious chilling effect. The distro
type/variant recording changes are a perfect example: this is essential
information, and recording it in xend was pre-NAKed by XenSource a long
time ago.
6. As a thought experiment: if someone re-wrote xend in C, what then? Is
that upstream, or not? In case it's not clear, all of Sun's Xen changes
are open source and easily available.
7. Any change that involves *incompatibility* is clearly different, and
IMHO not acceptable. This is only about changes that in no way
negatively affect behaviour with an upstream Linux xend.
8. I hope it's clear to everyone that I'm motivated to merge changes
upstream wherever feasible. I'm not seeking some kind of get-out clause
from being a responsible maintainer.
9. Practically, we will have to carry these changes in our libvirt no
matter what. I'd rather not.
10. I would note that Red Hat own the upstream for the code they care
about, thus this rule can only cause trouble for other people.
My personal opinion, not Sun's.
regards,
john
16 years, 2 months
[libvirt] saving virtual machine state when rebooting the server machine
by Itamar Reis Peixoto
is possible to save virtual machine state when rebooting the server machine ?
https://help.ubuntu.com/8.04/serverguide/C/libvirt.html
The state of virtual machines can be saved to a file in order to be
restored later. The following will save the virtual machine state into
a file named according to the date:
virsh -c qemu:///system save web_devel web_devel-022708.state
Once saved the virtual machine will no longer be running.
A saved virtual machine can be restored using:
virsh -c qemu:///system restore web_devel-022708.state
--
------------
Itamar Reis Peixoto
e-mail/msn: itamar(a)ispbrasil.com.br
sip: itamar(a)ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599
16 years, 2 months
[libvirt] [PATCH ] (type ioem) adding qemu nic configuration option in to libvirt (XEN)
by Gihan Munasinghe
Guys
I have added a new attribute with with in <interface > tag called "qemu"
which can be either true or false..
Indicating if the user wants XEN to create qeum net device or not.. This
will fix the problem with PV net drivers with XEN..
Check the following examples
e.g 1) Interface tag with qemu attribute set to false
<interface type='bridge' qemu='false'>
<mac address='00:16:3e:00:a5:01'/>
<source bridge='eth0'/>
<target dev='vif1.0'/>
</interface>
qemu-dm output
---------------------
/usr/lib64/xen/bin/qemu-dm -d 60 -domain-name benchmark1 -k en-gb -vnc
0.0.0.0:1 -vcpus 2 -boot c -serial pty -acpi -usb -net none -M xenfv
XEND has configured the hvm guest not to have network card via qemu
e.g 2) Interface tag with qemu attribute set to true with qemu supported
nic model
<interface type='bridge' qemu='true'>
<mac address='00:16:3e:00:a5:01'/>
<source bridge='eth0'/>
<target dev='vif1.0'/>
<model type='e1000'/>
</interface>
qemu-dm output
---------------------
/usr/lib64/xen/bin/qemu-dm -d 61 -domain-name benchmark1 -k en-gb -vnc
0.0.0.0:1 -vcpus 2 -boot c -serial pty -acpi -usb -net
nic,vlan=1,macaddr=00:16:3e:00:a5:01,model=e1000 -net
tap,vlan=1,ifname=tap61.0,bridge=eth0 -M xenfv
Now XEND have configured the hvm guest to have emulated nic of the model
"e1000"
Therefore now, via libvirt configuration I have the ability ask xen to
either to configure qemu network card or not (when I have pv divers
installed with in my VM )
I have attached the patch files, Let me know what you guys think.
Thanks
Gihan
--
Gihan Munasinghe
R&D Team Leader
XCalibre Communications Ltd.
www.flexiscale.com
--- domain_conf.h.back 2008-12-04 15:31:38.000000000 +0000
+++ domain_conf.h 2008-12-04 20:28:16.000000000 +0000
@@ -127,9 +127,17 @@
VIR_DOMAIN_NET_TYPE_NETWORK,
VIR_DOMAIN_NET_TYPE_BRIDGE,
- VIR_DOMAIN_NET_TYPE_LAST,
+ VIR_DOMAIN_NET_TYPE_LAST
};
+/*Holds the values that can be passed as qemu attribute in <inteface >*/
+enum virDomainNetQemuAllocateType{
+ VIR_DOMAIN_NET_QEMU_ALLOC_TRUE,
+ VIR_DOMAIN_NET_QEMU_ALLOC_FALSE,
+
+ VIR_DOMAIN_NET_QEMU_ALLOC_LAST
+
+};
/* Stores the virtual network interface configuration */
typedef struct _virDomainNetDef virDomainNetDef;
@@ -156,6 +164,8 @@
} bridge;
} data;
char *ifname;
+ int qemu_allocate;/* This is set so that the users can ask xen not give vm's a network card
+ maily to with the (type none)/(type ieoum) tags wchi will be send to xend*/
};
enum virDomainChrSrcType {
@@ -608,5 +618,5 @@
VIR_ENUM_DECL(virDomainInput)
VIR_ENUM_DECL(virDomainInputBus)
VIR_ENUM_DECL(virDomainGraphics)
-
+VIR_ENUM_DECL(virDomainNetQemuAllocate)
#endif /* __DOMAIN_CONF_H */
--- domain_conf.c.back 2008-12-04 15:31:40.000000000 +0000
+++ domain_conf.c 2008-12-04 20:30:31.000000000 +0000
@@ -142,6 +142,10 @@
"usb",
"pci")
+VIR_ENUM_IMPL(virDomainNetQemuAllocate, VIR_DOMAIN_NET_QEMU_ALLOC_LAST,
+ "true",
+ "false")
+
#define virDomainReportError(conn, code, fmt...) \
virReportErrorHelper(conn, VIR_FROM_DOMAIN, code, __FILE__, \
__FUNCTION__, __LINE__, fmt)
@@ -787,6 +791,7 @@
char *address = NULL;
char *port = NULL;
char *model = NULL;
+ char *qemu_alloc = NULL;
if (VIR_ALLOC(def) < 0) {
virDomainReportError(conn, VIR_ERR_NO_MEMORY, NULL);
@@ -800,6 +805,17 @@
_("unknown interface type '%s'"), type);
goto error;
}
+ qemu_alloc = virXMLPropString(node, "qemu");
+ if( qemu_alloc!=NULL){
+ if ((def->qemu_allocate = virDomainNetQemuAllocateTypeFromString(qemu_alloc)) < 0) {
+ virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
+ _("unknown qemu alloc '%s'"), qemu_alloc);
+ goto error;
+ }
+
+ }else{
+ def->qemu_allocate = VIR_DOMAIN_NET_QEMU_ALLOC_TRUE; // by default the aloocation will be true
+ }
} else {
def->type = VIR_DOMAIN_NET_TYPE_USER;
}
@@ -818,6 +834,7 @@
(def->type == VIR_DOMAIN_NET_TYPE_BRIDGE) &&
(xmlStrEqual(cur->name, BAD_CAST "source"))) {
bridge = virXMLPropString(cur, "bridge");
+
} else if ((dev == NULL) &&
(def->type == VIR_DOMAIN_NET_TYPE_ETHERNET) &&
xmlStrEqual(cur->name, BAD_CAST "source")) {
--- xend_internal.c.back 2008-12-04 15:31:38.000000000 +0000
+++ xend_internal.c 2008-12-04 21:05:49.000000000 +0000
@@ -1773,10 +1773,9 @@
if (VIR_ALLOC(net) < 0)
goto no_memory;
- if ((tmp2 && strstr(tmp2, "bridge")) || tmp) {
- net->type = VIR_DOMAIN_NET_TYPE_BRIDGE;
- /* XXX virtual network reverse resolve */
-
+ if ((tmp2 && (strstr(tmp2, "bridge") )) || tmp) {
+ net->type = VIR_DOMAIN_NET_TYPE_BRIDGE;
+ /* XXX virtual network reverse resolve */
if (tmp &&
!(net->data.bridge.brname = strdup(tmp)))
goto no_memory;
@@ -5153,10 +5152,15 @@
/*
* apparently (type ioemu) breaks paravirt drivers on HVM so skip this
- * from Xen 3.1.0
+ * from Xen 3.1.0 This happence as XEN try to allocate a network card via qemu
*/
- if ((hvm) && (xendConfigVersion < 4))
- virBufferAddLit(buf, "(type ioemu)");
+// if ((hvm) && (xendConfigVersion < 4) )
+ if ((hvm) && (def->qemu_allocate==VIR_DOMAIN_NET_QEMU_ALLOC_FALSE)){ /* If we have asked the qemu not to allocte a net work for hvm guest.
+ This way you would not have a problem with PV drivers on HVM guests*/
+ virBufferAddLit(buf, "(type none)");
+ }else {
+ virBufferAddLit(buf, "(type ioemu)");
+ }
if (!isAttach)
virBufferAddLit(buf, ")");
16 years, 2 months
