Re: [Libvir] Snapshots for Xen and KVM
On Tue, Mar 11, 2008 at 04:13:40PM +, John Levon wrote: On Tue, Mar 11, 2008 at 03:43:51PM +, Richard W.M. Jones wrote: On Tue, Mar 11, 2008 at 12:54:37PM +0200, Gabriel Kaufmann wrote: Does anyone knows if Xen and KVM support snapshots (regardless if Libvirt provides the API for them). It's currently on the Xen to-do list, but apart from some research papers I'm not aware of them implementing it. Perhaps recently. Checkpointing is tricky to get right because you have to take a snapshot of the memory and disk at exactly the same moment. Note that neither Xen's live migration nor the domain save features are real checkpoints, because they both only consider the memory. Why would Xen itself be at all concerned with snapshotting the disk? AIUI, there's hooks in xend so you just plug in your disk snapshotting (ZFS, LVM, vmdk, whatever) to that. I think we discussed that on the list a little bit before, basically the current state both for KVM and for Xen is that if you have a very specific environment, using special filesystems, special hooks, then you may be able to do a working checkpointing. The big problem I see is that from an API point of view there is no way to make that a predictable reliable interface in the current state of the support of the hypervisors. I feel a bit uneasy doing this, maybe I'm wrong we already have APIs where there is an uncertainty about the result of the operation (virDomainShutdown) but in that case it's likely that an undetected failed operation means data corruption, and we just can't detect properly (nor does the hypervisor e.g. iSCSI file systems) that this will fail. So I don't feel the state of support at the hypervisor level allows to export this in good faith at the libvirt level, but maybe I'm wrong and I would accept to be ruled out of course :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] virsh start problem + patch
Actually, there are two different problems here.
One is that a freshly installed xen hvm windows domain is stuck in the
- state, until I reboot Dom0.
The way to reproduce the problematic -- state in xen is to do a
fresh install of windows xp by virt-install.
# virsh list --all
Id Name State
--
0 Domain-0 running
- windows-xen shut off
- windows-xen2 no state
# xm list
NameID Mem VCPUs State
Time(s)
Domain-0 0 3489 4 r-
853.6
windows-xen 1 512 0
-b-s-d 39.4
windows-xen2 4 512 0
-- 22.5
The windows-xen, and windows-xen2 domains were installed the very same
way, except I've had a Dom0 reboot since I've installed windows-xen, so
xen has had the opportunity to sort it's state out, whil the
windows-xen2 domain is a fresh install. Starting and stopping (by xm) a
freshly installed windows hvm domain does not sort out the state, only a
Dom0 reboot (or a xend restart) does.
I have attached the output of xm list --long command.
This problem indeed does look like a Xend bug, but it turns out that it
does not actually affect virsh. (It does affect virt-manager, as I've
written to the other list)
--
The other problem is I am pretty sure, a virsh logic bug, and is
independent of the first one.
Virsh cannot start ANY managed xen domain, wheter it's stuck in --,
or in a completely legal state.
I've added a debug statement to (unpatched virsh) cmdStart here:
if (!(dom = vshCommandOptDomainBy(ctl, cmd, name, NULL, VSH_BYNAME)))
return FALSE;
printf(virDomainGetID(dom) returns %d, virDomainGetID(dom));
if (virDomainGetID(dom) != (unsigned int)-1) {
vshError(ctl, FALSE, %s, _(Domain is already active));
virDomainFree(dom);
return FALSE;
}
and I get this:
./virsh start windows-xen
warnings
error: Domain is already active
virDomainGetID(dom) returns 1
./virsh start windows-xen2
warnings
error: Domain is already active
virDomainGetID(dom) returns 3
so virDomainGetID() does not return -1, but returns the actual xen
domain id of the managed, but inactive xen domain, and I believe this is
what it should do,
as it's job is not to tell us about the state of the domain, but to tell
the id of the domain, regardles of its state.
Xend knows about the domain, so libvirt knows about the domain, it does
have an id despite being inactive, and virDominGetID tells it to us.
That's the way a managed xen domain should work in my opinion.
Back in the day of unmanaged xen domains, this code did the right thing,
as Xend knew only about running domains, but managed domains changed the
semantics,and now defined but inactive domains have domain ids.
So I still think that we do need to check the domain state in cmdStart,
as my patch does.
Actually virsh start should work without any state check, as the lower
layers would throw an error if we tried to start a running domain
anyway, but it would be sloppy.
regards
István Tóth
Daniel P. Berrange wrote:
On Mon, Mar 10, 2008 at 11:37:19AM +, Richard W.M. Jones wrote:
On Sat, Mar 08, 2008 at 09:47:43AM +0100, Toth Istvan wrote:
I've looked into the virsh code, and it seems that it was written with
only only old-style xen in mind, and xen 3.1's managed domains break the
logic.
I don't understand this statement. The current 'cmdStart' code checks
if the domain ID is -1 (ie. a managed domain, but inactive), and that
seems correct.
This sounds very much like a bug in XenD to be be honest. If libvirt has got
an ID of -1 then the domain is definitely dead - libvirt talks directly to
the hypervisor. So if XenD meanwhile things its not dead, then its a XenD
bug.
Dan.
[?1034h(domain
(domid 0)
(on_crash restart)
(uuid ----)
(bootloader_args )
(vcpus 4)
(name Domain-0)
(on_poweroff destroy)
(on_reboot restart)
(bootloader )
(maxmem 16777215)
(memory 3489)
(shadow_memory 0)
(cpu_weight 256)
(cpu_cap 0)
(features )
(on_xend_start ignore)
(on_xend_stop ignore)
(cpu_time 495.244784973)
(online_vcpus 4)
(image (linux (kernel )))
(status 2)
(state r-)
)
(domain
(domid 1)
(on_crash destroy)
(uuid 12951667-5f44-a4a4-79f2-614a4c536722)
(bootloader_args )
(vcpus 1)
(name windows-xen)
(on_poweroff destroy)
(on_reboot destroy)
(bootloader )
(maxmem 512)
(memory
Re: [Libvir] virsh list command of libvirt consumes a lot of CPU in the domain-0
On Tue, Mar 11, 2008 at 04:48:57PM +0100, [EMAIL PROTECTED] wrote: Hi all, I know that this is not a libvirt issue but this badly impacts libvirt usage. Is anyone aware of any status on this issue ? Daniel ? Here is some history I could get from the libvirt mailing list : * October 12, 2006 (Daniel Berrange). I've been trying to track down just why talking to XenD is resulting in so much CPU time being comsumed by both xend xenstored. As a test case, I'm running 'virsh dominfo demo' which results in a single HTTP request to Xend to fetch domain info, eg 'GET /xend/domains/demo' Run this in a tight loop I'll see xenstored taking 50% CPU, and XenD taking another 11% yes this is a serious performance issue in xend. [...] single read in XenD. Now if I monitor the status of 20 domains, once per second that's causing 40 MB of writes 40 MB of reads every second which is utterly ridiculous completely non scalable for enterprise deployment :-( agreed [...] Xen 3.0.3 has a serious performance bug (see http://lists.xensource.com/archives/html/xen-devel/2006-10/msg00487.ht ml) This bug is fixed in Xen 3.0.4 No it isn't. The performance bug is actually at least x2 worse in Xen 3.0.4 I was told that xenstored had been rewritten for the Xen Enterprise version. There is little I can do at that level honnestly, in libvirt we need the xend access only to make the binding between the domain ID and the domain name. All update informations are provided by the hypervisor, including the ID list, something we could do is to try to cache the id - name domain association, this is a bit risky since there is no way libvirt can learn that a binding has changed (either because of an xm rename command or the domain was destroyed and a new domain created with same id). If we keep the association in the daemon and use a timeout flush maybe this could be worked out, but it's really a bad workaround, and the proper thing would be to fix this long standing bug in xenstored, it's a bit depressing that no progress had been made on the open source version. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] Release of libvirt-0.4.1
On Fri, Mar 07, 2008 at 04:23:13PM +0100, Guido Günther wrote:
Hi Daniel.
On Mon, Mar 03, 2008 at 10:13:12AM -0500, Daniel Veillard wrote:
It was really time for a new release, quite a lot of patches had
accumulated
since the previous one ! Available at
ftp://libvirt.org/libvirt
Cool thing! Unfortunatley this release breaks kvm/qemu bridged
networking for me. Namely this commmit:
936dd984eed33813aa69b0377dd46a9ad1e9e014
Set MAC address on TUN device for Xenner compatability
With this applied the vm never sees the dhcp offer from the DHCP
server. When I revert the patch, everything is fine again.
No comments? This is the part of code I've reverted. Didn't find the
time to track down the problem for real:
diff --git a/src/bridge.c b/src/bridge.c
index 6626156..caa6ebf 100644
--- a/src/bridge.c
+++ b/src/bridge.c
@@ -357,18 +355,6 @@ brAddTap(brControl *ctl,
}
if (ioctl(fd, TUNSETIFF, try) == 0) {
-struct ifreq addr;
-memset(addr, 0, sizeof(addr));
-memcpy(addr.ifr_hwaddr.sa_data, macaddr, 6);
-addr.ifr_hwaddr.sa_family = ARPHRD_ETHER;
-
-/* Device actually starts in 'UP' state, but it
- * needs to be down to set the MAC addr
- */
-if ((errno = brSetInterfaceUp(ctl, try.ifr_name, 0)))
-goto error;
-if (ioctl(fd, SIOCSIFHWADDR, addr) != 0)
-goto error;
if ((errno = brAddInterface(ctl, bridge, try.ifr_name)))
goto error;
if ((errno = brSetInterfaceUp(ctl, try.ifr_name, 1)))
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [PATCH] Fix cdrom connect/disconnect for qemu
The attached patch fixes cdrom changing for a live qemu guest. There
were a few issues preventing it from working:
1) It didn't anticipate no source block in the xml.
2) No support for ejecting the media
3) Small bug which prevented the running guest xml from being updated.
I've tested this via virt-manager, and now qemu and xen seem
to have parity wrt cdrom connect/disconnect.
Thanks,
Cole
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index e54da5b..ebbd251 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -594,9 +594,16 @@ static int qemudParseDiskXML(virConnectPtr conn,
}
if (source == NULL) {
-qemudReportError(conn, NULL, NULL, VIR_ERR_NO_SOURCE, target ? %s :
NULL, target);
-goto error;
+/* There is a case without the source
+ * to the CD-ROM device
+ */
+if (!device || STRNEQ((const char *) device, cdrom)) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_NO_SOURCE,
+ target ? %s : NULL, target);
+goto error;
+}
}
+
if (target == NULL) {
qemudReportError(conn, NULL, NULL, VIR_ERR_NO_TARGET, source ? %s :
NULL, source);
goto error;
@@ -630,7 +637,7 @@ static int qemudParseDiskXML(virConnectPtr conn,
goto error;
}
-strncpy(disk-src, (const char *)source, NAME_MAX-1);
+strncpy(disk-src, (source ? (const char *) source : \0), NAME_MAX-1);
disk-src[NAME_MAX-1] = '\0';
strncpy(disk-dst, (const char *)target, NAME_MAX-1);
@@ -1747,9 +1754,15 @@ int qemudBuildCommandLine(virConnectPtr conn,
char dev[NAME_MAX];
char file[PATH_MAX];
if (!strcmp(disk-dst, hdc)
-disk-device == QEMUD_DISK_CDROM)
-snprintf(dev, NAME_MAX, -%s, cdrom);
-else
+disk-device == QEMUD_DISK_CDROM) {
+if (disk-src[0])
+snprintf(dev, NAME_MAX, -%s, cdrom);
+else {
+/* Don't put anything on the cmdline for an empty cdrom*/
+disk = disk-next;
+continue;
+}
+} else
snprintf(dev, NAME_MAX, -%s, disk-dst);
snprintf(file, PATH_MAX, %s, disk-src);
@@ -2906,8 +2919,10 @@ char *qemudGenerateXML(virConnectPtr conn,
types[disk-type], devices[disk-device]) 0)
goto no_memory;
-if (virBufferVSprintf(buf, source %s='%s'/\n,
typeAttrs[disk-type], disk-src) 0)
-goto no_memory;
+if (disk-src[0])
+if (virBufferVSprintf(buf, source %s='%s'/\n,
+ typeAttrs[disk-type], disk-src) 0)
+goto no_memory;
if (virBufferVSprintf(buf, target dev='%s'/\n, disk-dst)
0)
goto no_memory;
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 21f0fed..2b4c2a6 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2223,23 +2223,29 @@ static int qemudDomainChangeCDROM(virDomainPtr dom,
struct qemud_driver *driver = (struct qemud_driver
*)dom-conn-privateData;
char *cmd, *reply, *safe_path;
-/* Migrate to file */
-safe_path = qemudEscapeMonitorArg(newdisk-src);
-if (!safe_path) {
-qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
- out of memory);
-return -1;
-}
-if (asprintf (cmd, change %s \%s\,
- /* XXX qemu may support multiple CDROM in future */
- /* olddisk-dst */ cdrom,
- safe_path) == -1) {
+if (newdisk-src[0]) {
+safe_path = qemudEscapeMonitorArg(newdisk-src);
+if (!safe_path) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ out of memory);
+return -1;
+}
+if (asprintf (cmd, change %s \%s\,
+ /* XXX qemu may support multiple CDROM in future */
+ /* olddisk-dst */ cdrom,
+ safe_path) == -1) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ out of memory);
+free(safe_path);
+return -1;
+}
+free(safe_path);
+
+} else if (asprintf(cmd, eject cdrom) == -1) {
qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
out of memory);
-free(safe_path);
return -1;
}
-free(safe_path);
if (qemudMonitorCommand(driver, vm, cmd, reply) 0) {
qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
cannot change cdrom media);
@@ -2248,7 +2254,7 @@ static int qemudDomainChangeCDROM(virDomainPtr dom,
}
free(reply);
free(cmd);
-strcpy(olddisk-dst, newdisk-dst);
+strcpy(olddisk-src, newdisk-src);
olddisk-type = newdisk-type;
return 0;
}
--
Libvir-list mailing list
Libvir-list@redhat.com
Re: [Libvir] Release of libvirt-0.4.1
On Wed, Mar 12, 2008 at 01:38:05PM +0100, Guido G?nther wrote:
On Fri, Mar 07, 2008 at 04:23:13PM +0100, Guido Günther wrote:
Hi Daniel.
On Mon, Mar 03, 2008 at 10:13:12AM -0500, Daniel Veillard wrote:
It was really time for a new release, quite a lot of patches had
accumulated
since the previous one ! Available at
ftp://libvirt.org/libvirt
Cool thing! Unfortunatley this release breaks kvm/qemu bridged
networking for me. Namely this commmit:
936dd984eed33813aa69b0377dd46a9ad1e9e014
Set MAC address on TUN device for Xenner compatability
With this applied the vm never sees the dhcp offer from the DHCP
server. When I revert the patch, everything is fine again.
No comments? This is the part of code I've reverted. Didn't find the
time to track down the problem for real:
The setting of MAC address was done to help Xenner detect correct TAP
interface. This patch instead explicitly passes the interface name to
Xenner. A corresponding patch to Xenner makes it honour the ifname=
parameter.
Dan.
Index: src/bridge.c
===
RCS file: /data/cvs/libvirt/src/bridge.c,v
retrieving revision 1.9
diff -u -p -r1.9 bridge.c
--- src/bridge.c28 Feb 2008 01:23:14 - 1.9
+++ src/bridge.c12 Mar 2008 18:39:28 -
@@ -313,7 +313,6 @@ brDeleteInterface(brControl *ctl ATTRIBU
int
brAddTap(brControl *ctl,
const char *bridge,
- unsigned char *macaddr,
char *ifname,
int maxlen,
int *tapfd)
@@ -357,18 +356,6 @@ brAddTap(brControl *ctl,
}
if (ioctl(fd, TUNSETIFF, try) == 0) {
-struct ifreq addr;
-memset(addr, 0, sizeof(addr));
-memcpy(addr.ifr_hwaddr.sa_data, macaddr, 6);
-addr.ifr_hwaddr.sa_family = ARPHRD_ETHER;
-
-/* Device actually starts in 'UP' state, but it
- * needs to be down to set the MAC addr
- */
-if ((errno = brSetInterfaceUp(ctl, try.ifr_name, 0)))
-goto error;
-if (ioctl(fd, SIOCSIFHWADDR, addr) != 0)
-goto error;
if ((errno = brAddInterface(ctl, bridge, try.ifr_name)))
goto error;
if ((errno = brSetInterfaceUp(ctl, try.ifr_name, 1)))
Index: src/bridge.h
===
RCS file: /data/cvs/libvirt/src/bridge.h,v
retrieving revision 1.5
diff -u -p -r1.5 bridge.h
--- src/bridge.h28 Feb 2008 01:23:14 - 1.5
+++ src/bridge.h12 Mar 2008 18:39:28 -
@@ -62,7 +62,6 @@ int brDeleteInterface (brContr
int brAddTap(brControl *ctl,
const char *bridge,
- unsigned char *mac,
char *ifname,
int maxlen,
int *tapfd);
Index: src/qemu_conf.c
===
RCS file: /data/cvs/libvirt/src/qemu_conf.c,v
retrieving revision 1.41
diff -u -p -r1.41 qemu_conf.c
--- src/qemu_conf.c 3 Mar 2008 18:11:16 - 1.41
+++ src/qemu_conf.c 12 Mar 2008 18:39:29 -
@@ -1533,7 +1533,6 @@ qemudNetworkIfaceConnect(virConnectPtr c
}
if ((err = brAddTap(driver-brctl, brname,
-net-mac,
ifname, BR_IFNAME_MAXLEN, tapfd))) {
qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
Failed to add tap interface '%s' to bridge '%s' :
%s,
@@ -1541,7 +1540,9 @@ qemudNetworkIfaceConnect(virConnectPtr c
goto error;
}
-snprintf(tapfdstr, sizeof(tapfdstr), tap,fd=%d,script=,vlan=%d, tapfd,
vlan);
+snprintf(tapfdstr, sizeof(tapfdstr),
+ tap,fd=%d,script=,vlan=%d,ifname=%s,
+ tapfd, vlan, ifname);
if (!(retval = strdup(tapfdstr)))
goto no_memory;
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [PATCH] fix and update help.
This patch fix and update help. 1)update virsh domstate, setvcpus supports inactive domain. 2)fix 4 points of adress = address (xgettext needed for regenerate po file) bridge.c |4 ++-- virsh.c |8 2 files changed, 6 insertions(+), 6 deletions(-) Thanks Tatsuro Enokura Atsushi SAKAI fix_and_update_typos.patch Description: Binary data -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
