Re: [libvirt] [PATCH] OpenVZ xml refactoring
On Mon, Jul 28, 2008 at 10:12:49AM -0400, Daniel Veillard wrote: On Mon, Jul 28, 2008 at 05:38:47PM +0400, Evgeniy Sokolov wrote: On Fri, Jul 25, 2008 at 04:44:09PM +0400, Evgeniy Sokolov wrote: In general that looks way cleaner to me, I will give it a few nmore days and apply, unless you suggest another version, fixed patch is attached. Okay, I applied and commited this because it enforces the transition to the new XML format for OpenVZ and any such change should be done as soon as possible. But Dan's point remain, we need to transition to the new reading routines, and virDomainNetDefParseXML will have to be made static again when done. But as I understand you agree with this so it's just an intermediate state of the code :-) This patch doesn't work or compile because it is missing an argument to virXPathNodeSet(). Please make sure you're developing against the latest CVS checkout of libvirt when submitting patches, and run the configure script with the '--enable-compile-warnings=error' argument the catch this sort of problem before submission. Here is the nightly build failure in question: http://builder.virt-manager.org/logs/modules/libvirt--devel-build-output.log Regards, Daniel -- |: Red Hat, Engineering, London -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
Re: [libvirt] [PATCH] OpenVZ xml refactoring
On Tue, Jul 29, 2008 at 08:53:27AM +0100, Daniel P. Berrange wrote: On Mon, Jul 28, 2008 at 10:12:49AM -0400, Daniel Veillard wrote: On Mon, Jul 28, 2008 at 05:38:47PM +0400, Evgeniy Sokolov wrote: On Fri, Jul 25, 2008 at 04:44:09PM +0400, Evgeniy Sokolov wrote: In general that looks way cleaner to me, I will give it a few nmore days and apply, unless you suggest another version, fixed patch is attached. Okay, I applied and commited this because it enforces the transition to the new XML format for OpenVZ and any such change should be done as soon as possible. But Dan's point remain, we need to transition to the new reading routines, and virDomainNetDefParseXML will have to be made static again when done. But as I understand you agree with this so it's just an intermediate state of the code :-) This patch doesn't work or compile because it is missing an argument to virXPathNodeSet(). Please make sure you're developing against the latest CVS checkout of libvirt when submitting patches, and run the configure script with the '--enable-compile-warnings=error' argument the catch this sort of problem before submission. Humpf ... the problem is that I ran autogen between testing both versions of the patch and the --with-openvz vanished. Fixing in CVs, it's trivial, but also activating OpenVZ and LXC support by default, there is no good reason to not do so at this point. Sorry, 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: [libvirt] [PATCH] Fix logical storage pool operation on SLES10-SP2
On Mon, Jul 28, 2008 at 03:35:30PM -0400, David Lively wrote: The attached patch adjusts for a difference in behavior in the LVM utilities 'lvs' and 'vgs'. The SLES10-SP2 versions of these (and presumably others) append a trailing separator. This patch simply adjusts the regexps to allow (but not require) this. I thought just adding the :? to the regexps would do this, but this was leaving the trailing separator in the last group match, so I ended up tweaking the preceding group pattern as well. Yeah, the \S+ is a greedy match, so it'd consume the ':' first. I don't know if POSIX expressions have a non-greedy match modifir like Perl does. That would let you do (\\S+?):? But in any case, your suggested modification is fine, so ACK. BTW, what version of the LVM tools is SLES using - its probably useful to note that in the comment you added, in case the same problem is particular to a version, rather than just SLES Daniel -- |: Red Hat, Engineering, London -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
Re: [libvirt] Libvir on Hardy: file a bug or not?
On Tue, Jul 29, 2008 at 08:53:03AM +0300, Mihamina Rakotomandimby (R12y) wrote:
Hi,
I am using Ubuntu Hardy up to date.
I get:
virsh # start xp
libvir: QEMU error : QEMU quit during console startup
qemu: unknowm parameter 'boot' in
'file=/home/mihamina/xp.img,if=ide,boot=on'
error: Failed to start domain xp
If I change the domain type with qemu, I have no error (and the
virtual machine starts without any problem.
The Ubuntu libvirt had a early version of the patch for supporting
the 'boot=on' parameter - I believe they always use it for any VM
with a domain type of 'kvm'. Since you are using regular QEMU it
is correct that you need to change the domain type to type=qemu
anyway.
This is my installed things:
$ dpkg -l | awk '/(virt|qemu|kvm)/{print $2,$3}'
kvm 1:62+dfsg-0ubuntu8
libvirt-bin 0.4.0-2ubuntu8
libvirt0 0.4.0-2ubuntu8
python-libvirt 0.4.0-2ubuntu8
python-virtinst 0.300.2-0ubuntu6
python-virtkey 0.50ubuntu0.1
qemu 0.9.1-1ubuntu1
virt-manager 0.5.3-0ubuntu10
virt-viewer 0.0.2-1ubuntu1
Is it an upstream bug or a distribution bug?
I believe it is a disto bug - the upstream code for this should be
auto-detecting whether 'boot=on' is supported automatically now.
Who is supposed to be noticed? The packager or the upstream (where please)?
Generally speaking, if you are yusing the libvir packages built by your
OS distributor,then use their bug tracking system. They will forward
bugs to upstream libvirt as required, or fix OS specific bugs directly.
http://libvirt.org/bugs.html
Daniel
--
|: Red Hat, Engineering, London -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
Re: [libvirt] Libvir on Hardy: file a bug or not?
Daniel P. Berrange wrote: The Ubuntu libvirt had a early version of the patch for supporting the 'boot=on' parameter - I believe they always use it for any VM with a domain type of 'kvm'. Since you are using regular QEMU it is correct that you need to change the domain type to type=qemu anyway. My problem if I use qemu as domain type is the guest is slow enough to make me think it doesnt use the kvm. In the beginning, and in Ubuntu documentation, the domain type is qemu as default. So, the question that might solve the problems: How can assume it's realy using kvm (and not just qemu)? Note: when I launch the guest via the kvm command [1], it's faster. [1] e.g.: $ kvm -m 512 -hda foo.img -cdrom bar.iso -boot d -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Libvir on Hardy: file a bug or not?
Quoting Mihamina Rakotomandimby (R12y)
[EMAIL PROTECTED]:
I cannot help you with your problem but in case you want to try the
latest and greatest libvirt, there are 0.4.4 packages available in my
PPA: http://launchpad.net/~pgquiles/+archive (UNOFFICIAL AND
UNSUPPORTED)
Hi,
I am using Ubuntu Hardy up to date.
When defining a domain with:
domain type='kvm' id='1'
namexp/name
uuiddd4618e5-1c48-a481-0671-d75f38f59037/uuid
memory524288/memory
currentMemory524288/currentMemory
vcpu1/vcpu
os
type arch='x86_64' machine='pc'hvm/type
boot dev='hd'/
/os
clock offset='localtime'/
on_poweroffdestroy/on_poweroff
on_rebootdestroy/on_reboot
on_crashdestroy/on_crash
devices
emulator/usr/bin/qemu-system-x86_64/emulator
disk type='file' device='cdrom'
source file='/home/mihamina/xpjohnny.iso'/
target dev='hdc' bus='ide'/
readonly/
/disk
disk type='file' device='disk'
source file='/home/mihamina/xp.img'/
target dev='hda' bus='ide'/
/disk
interface type='bridge'
mac address='00:16:3e:1e:b2:22'/
source bridge='br0'/
target dev='vnet1'/
/interface
input type='tablet' bus='usb'/
input type='mouse' bus='ps2'/
graphics type='vnc' port='5900' listen='127.0.0.1'/
/devices
/domain
I get:
virsh # start xp
libvir: QEMU error : QEMU quit during console startup
qemu: unknowm parameter 'boot' in
'file=/home/mihamina/xp.img,if=ide,boot=on'
error: Failed to start domain xp
If I change the domain type with qemu, I have no error (and the
virtual machine starts without any problem.
This is my installed things:
$ dpkg -l | awk '/(virt|qemu|kvm)/{print $2,$3}'
kvm 1:62+dfsg-0ubuntu8
libvirt-bin 0.4.0-2ubuntu8
libvirt0 0.4.0-2ubuntu8
python-libvirt 0.4.0-2ubuntu8
python-virtinst 0.300.2-0ubuntu6
python-virtkey 0.50ubuntu0.1
qemu 0.9.1-1ubuntu1
virt-manager 0.5.3-0ubuntu10
virt-viewer 0.0.2-1ubuntu1
Is it an upstream bug or a distribution bug?
Who is supposed to be noticed? The packager or the upstream (where please)?
PS: I wrote because I saw
http://www.mail-archive.com/libvir-list@redhat.com/msg06109.html
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Now ESXi is 'free'
Now ESXi is 'free as in beer' would it be appropriate to hack a libvirtd in it? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH]: Add carriage returns to qemudLog
Since qemudLog just maps to fprintf(stderr), add carriage returns every where it
is used, so it's easier on the eyes while debugging.
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
Index: src/qemu_driver.c
===
RCS file: /data/cvs/libvirt/src/qemu_driver.c,v
retrieving revision 1.97
diff -u -r1.97 qemu_driver.c
--- a/src/qemu_driver.c 28 Jul 2008 12:52:38 - 1.97
+++ b/src/qemu_driver.c 29 Jul 2008 09:55:33 -
@@ -88,7 +88,7 @@
return 0;
error:
qemudLog(QEMUD_ERR,
- %s, _(Failed to set close-on-exec file descriptor flag));
+ %s, _(Failed to set close-on-exec file descriptor flag\n));
return -1;
}
@@ -103,7 +103,7 @@
return 0;
error:
qemudLog(QEMUD_ERR,
- %s, _(Failed to set non-blocking file descriptor flag));
+ %s, _(Failed to set non-blocking file descriptor flag\n));
return -1;
}
@@ -148,7 +148,7 @@
!virNetworkIsActive(network)
qemudStartNetworkDaemon(NULL, driver, network) 0) {
virErrorPtr err = virGetLastError();
-qemudLog(QEMUD_ERR, _(Failed to autostart network '%s': %s),
+qemudLog(QEMUD_ERR, _(Failed to autostart network '%s': %s\n),
network-def-name, err-message);
}
@@ -163,7 +163,7 @@
!virDomainIsActive(vm)
qemudStartVMDaemon(NULL, driver, vm, NULL) 0) {
virErrorPtr err = virGetLastError();
-qemudLog(QEMUD_ERR, _(Failed to autostart VM '%s': %s),
+qemudLog(QEMUD_ERR, _(Failed to autostart VM '%s': %s\n),
vm-def-name, err-message);
}
@@ -199,7 +199,7 @@
goto out_of_memory;
} else {
if (!(pw = getpwuid(uid))) {
-qemudLog(QEMUD_ERR, _(Failed to find user record for uid '%d': %s),
+qemudLog(QEMUD_ERR, _(Failed to find user record for uid '%d': %s\n),
uid, strerror(errno));
goto out_of_memory;
}
@@ -210,7 +210,7 @@
if (asprintf (base, %s/.libvirt, pw-pw_dir) == -1) {
qemudLog (QEMUD_ERR,
- %s, _(out of memory in asprintf));
+ %s, _(out of memory in asprintf\n));
goto out_of_memory;
}
}
@@ -266,7 +266,7 @@
out_of_memory:
qemudLog (QEMUD_ERR,
- %s, _(qemudStartup: out of memory));
+ %s, _(qemudStartup: out of memory\n));
VIR_FREE(base);
VIR_FREE(qemu_driver);
return -1;
@@ -293,7 +293,7 @@
if (qemu_driver-iptables) {
qemudLog(QEMUD_INFO,
- %s, _(Reloading iptables rules));
+ %s, _(Reloading iptables rules\n));
iptablesReloadRules(qemu_driver-iptables);
}
@@ -645,7 +645,7 @@
if (safewrite(vm-logfile, buf, strlen(buf)) 0) {
/* Log, but ignore failures to write logfile for VM */
-qemudLog(QEMUD_WARN, _(Unable to log VM console data: %s),
+qemudLog(QEMUD_WARN, _(Unable to log VM console data: %s\n),
strerror(errno));
}
return ret;
@@ -938,15 +938,15 @@
tmp = argv;
while (*tmp) {
if (safewrite(vm-logfile, *tmp, strlen(*tmp)) 0)
-qemudLog(QEMUD_WARN, _(Unable to write argv to logfile %d: %s),
+qemudLog(QEMUD_WARN, _(Unable to write argv to logfile %d: %s\n),
errno, strerror(errno));
if (safewrite(vm-logfile, , 1) 0)
-qemudLog(QEMUD_WARN, _(Unable to write argv to logfile %d: %s),
+qemudLog(QEMUD_WARN, _(Unable to write argv to logfile %d: %s\n),
errno, strerror(errno));
tmp++;
}
if (safewrite(vm-logfile, \n, 1) 0)
-qemudLog(QEMUD_WARN, _(Unable to write argv to logfile %d: %s),
+qemudLog(QEMUD_WARN, _(Unable to write argv to logfile %d: %s\n),
errno, strerror(errno));
ret = virExecNonBlock(conn, argv, vm-pid,
@@ -1007,7 +1007,7 @@
if (safewrite(vm-logfile, buf, ret) 0) {
/* Log, but ignore failures to write logfile for VM */
-qemudLog(QEMUD_WARN, _(Unable to log VM console data: %s),
+qemudLog(QEMUD_WARN, _(Unable to log VM console data: %s\n),
strerror(errno));
}
}
@@ -1021,7 +1021,7 @@
if (!virDomainIsActive(vm))
return;
-qemudLog(QEMUD_INFO, _(Shutting down VM '%s'), vm-def-name);
+qemudLog(QEMUD_INFO, _(Shutting down VM '%s'\n), vm-def-name);
kill(vm-pid, SIGTERM);
@@ -1032,7 +1032,7 @@
virEventRemoveHandle(vm-stderr);
if (close(vm-logfile) 0)
-qemudLog(QEMUD_WARN, _(Unable to close logfile %d: %s),
+qemudLog(QEMUD_WARN, _(Unable to close logfile %d: %s\n),
errno, strerror(errno));
close(vm-stdout);
close(vm-stderr);
@@ -1047,7 +1047,7 @@
[libvirt] [PATCH]: Fix Qemu CD-ROM with no source
The new generic domain re-factor introduced a small regression into the drive
handling code. In particular, if you had a section of XML like:
disk type='file' device='cdrom'
target dev='hdc' bus='ide'/
readonly/
/disk
This used to work with older libvirt, but now fails. This is because we are
actually passing the literal string (null) to the qemu command-line, which qemu
barfs on. This patch fixes it up by making it blank, which allows qemu to
continue on it's merry way.
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
Index: src/qemu_conf.c
===
RCS file: /data/cvs/libvirt/src/qemu_conf.c,v
retrieving revision 1.85
diff -u -r1.85 qemu_conf.c
--- a/src/qemu_conf.c 25 Jul 2008 09:31:24 - 1.85
+++ b/src/qemu_conf.c 29 Jul 2008 09:55:56 -
@@ -888,13 +888,11 @@
goto error;
}
-if (disk-device == VIR_DOMAIN_DISK_DEVICE_CDROM)
-media = media=cdrom,;
-
switch (disk-device) {
case VIR_DOMAIN_DISK_DEVICE_CDROM:
bootable = bootCD;
bootCD = 0;
+media = media=cdrom,;
break;
case VIR_DOMAIN_DISK_DEVICE_FLOPPY:
bootable = bootFloppy;
@@ -907,7 +905,7 @@
}
snprintf(opt, PATH_MAX, file=%s,if=%s,%sindex=%d%s,
- disk-src, bus,
+ disk-src ? disk-src : , bus,
media ? media : ,
idx,
bootable
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemud: move check for polkit before config file check
On Sat, Jul 26, 2008 at 07:02:59PM -0400, Guido G?nther wrote: Hi, Without this patch and without a /etc/libvirt/libvirt.conf config file the default policy for running the daemon as non root user is still polkit which is bad. Please apply. Urgh, yes there's a hidden 'return' statement on the same line as the conditional access check further up causing this to be skipped when no config is present. ACK Daniel -- |: Red Hat, Engineering, London -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
Re: [libvirt] Now ESXi is 'free'
On Tue, Jul 29, 2008 at 11:49:52AM +0200, Stefan de Konink wrote: Now ESXi is 'free as in beer' would it be appropriate to hack a libvirtd in it? I don't see how it being free really makes any significant difference. Someone still needs to actually write a libvirt driver to interact with VMWare's control tools and/or APIs and the difficulity (or not) of doing this hasn't really changed with them making it free. We need a motivated developer who actually uses VMWare to do the work in libvirt. Daniel -- |: Red Hat, Engineering, London -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
Re: [libvirt] [PATCH]: Fix Qemu CD-ROM with no source
Daniel P. Berrange wrote: On Tue, Jul 29, 2008 at 12:07:37PM +0200, Chris Lalancette wrote: The new generic domain re-factor introduced a small regression into the drive handling code. In particular, if you had a section of XML like: disk type='file' device='cdrom' target dev='hdc' bus='ide'/ readonly/ /disk This used to work with older libvirt, but now fails. This is because we are actually passing the literal string (null) to the qemu command-line, which qemu barfs on. This patch fixes it up by making it blank, which allows qemu to continue on it's merry way. Signed-off-by: Chris Lalancette [EMAIL PROTECTED] ACK, looks fine. The other branch for QEMU without -drive, will simply omit the '-cdrom' arg, which is correct behaviour because QEMU adds an implicit CDROM device in that case. Oh, btw: even qemu with -drive implicitly adds and cdrom drive (ide1 master). Unless you configure something else there of course. So you can end up with two virtual cdrom drives even with only one specified on the command line (happens in case you connect the cdrom to something other than ide1 master). And there are some other implicit block devices (floppy and sd card). Try 'info block' on the monitor ;) Just for completeness, in case anyone cares ... cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH]: Fix Qemu CD-ROM with no source
On Tue, Jul 29, 2008 at 12:07:37PM +0200, Chris Lalancette wrote: The new generic domain re-factor introduced a small regression into the drive handling code. In particular, if you had a section of XML like: disk type='file' device='cdrom' target dev='hdc' bus='ide'/ readonly/ /disk This used to work with older libvirt, but now fails. This is because we are actually passing the literal string (null) to the qemu command-line, which qemu barfs on. This patch fixes it up by making it blank, which allows qemu to continue on it's merry way. Signed-off-by: Chris Lalancette [EMAIL PROTECTED] ACK, looks fine. The other branch for QEMU without -drive, will simply omit the '-cdrom' arg, which is correct behaviour because QEMU adds an implicit CDROM device in that case. Daniel -- |: Red Hat, Engineering, London -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
Re: [libvirt] [PATCH/RFC]: hostdev passthrough support
On Mon, Jul 28, 2008 at 09:26:57AM -0400, Daniel Veillard wrote: On Fri, Jul 25, 2008 at 04:17:30PM -0400, Guido Günther wrote: Hi, attached is some basic support for host device passthrough. It enables you to passthrough usb devices in qemu/kvm via: devices hostdev type='usb' vendor='0204' product='6025'/ you meant type='pci' there right ? hostdev type='usb' bus='001' device='007'/ /devices Hum, on the format level I think this need a bit more discussion. the type is better caracterized as a bus informations. Also I'm not sure if we should keep a flat single element or (expecting possible further complex descriptions later) go for a more structured description like Yes, we need deeper XML structure for the source info hostdev type='pci' source vendor='0204' product='6025'/ /hostdev I think an hypervisor could remap the actual port/addresses of a device so a target may make sense in the future (or not). Yes, for SCSI at least we need target info, and if we can query the mapped target address from the underlying hypervisor we should display it. I didn't implement unplug yet since this needs some modifications to qemu/kvm to be able to identify the correct device to unplug. Does this look reasonable? I also think we need to clarify the naming conventions, are numbers provided decimal, if yes then is an 0x hexadecimal version allowed too. I also see how a more high level description might be useful, hostdev type='usb' source vendor='Sennheiser'/ /hostdev or hostdev type='usb' source product='headset'/ /hostdev We should stick to ID numbers in the domain XML - allowing decimal or hex is nice. For descriptive names 'Sennheiser' or 'headset', we should only provide that info in the device enumeration APIs http://www.redhat.com/archives/libvir-list/2008-April/msg5.html Management tools / admins can use this to map to the ID number from a human readable name if relevant. Daniel -- |: Red Hat, Engineering, London -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
Re: [libvirt] [PATCH/RFC]: hostdev passthrough support
On Tue, Jul 29, 2008 at 11:53:46AM +0100, Daniel P. Berrange wrote:
This stuff is obviously going to have a correlation with the host
device enumeration support I'd offered a design for a few months
back. As such I'd like to try and keep a consistent XML format
between the two. For reference the original mesage was here:
http://www.redhat.com/archives/libvir-list/2008-April/msg5.html
There were basically two ways to identify a device. Some devices
are 'physical' mapped straight to a piece of hardware (USB device,
or PCI card) and would have 'bus' element with hardware details.
Oh, one thing I meant to say. Contrary to my message in the thread
above, and my previous reply, we should actually use 'subsys' or
'subsystem' instead of 'bus', to follow the HAL naming.
eg a USB finger print reader appears as:
device
nameusb_device_483_2016_noserial/name
key/org/freedesktop/Hal/devices/usb_device_483_2016_noserial/key
parent/org/freedesktop/Hal/devices/usb_device_0_0__00_1d_3/parent
bus type=usb
eg
subsystem type='usb'
vendor id=1155SGS Thomson Microelectronics/vendor
product id=8214Fingerprint Reader/product
address bus=003 dev=005/
/bus
/device
Other devices are 'logical' devices, which don't have hardware info
directly associated with them. The reason for this is that one piece
of hardware may present many logical devices each with varying
capabilities. As an example, a wifi card typically exports at least
2 network device - one control interface, and one for traffic.
eg a wireless network interface for data traffic
device
namenet_00_13_02_b9_f9_d3_0/name
key/org/freedesktop/Hal/devices/net_00_13_02_b9_f9_d3_0/key
parent/org/freedesktop/Hal/devices/pci_8086_4227/parent
capability type=net
hwaddr00:13:02:b9:f9:d3/hwaddr
nameeth0/name
capability type=80211/
/capability
/device
In this case the unique device identifier is the 'name' field
but this case varying depending on the capability type.
Different virt solutions have different capabilties for device
passthrough. KVM and Xen both support passthrough of physical
devices, either USB or PCI cards. OpenVZ supports passthrough
of logical devices - in particular network interfaces.
We need to allow for both possibilities in the domain XML for
this type of device.
So, to expand on your proposal, I'd like to see the XML format
have a top level attribute indicating whether we're passing a
logical or physical device, and then the capability name or
bus name respectively. The child elements then need to provide
the appropriate naming.
USB has the further annoyance you identified that one could
conceivably do attachment based on USB bus address, or the
vendor+product pair. The downside of former is that a bus
address changes every time you plug a device in. The downside
of the latter is that it is not neccessarily unique. We have
no choice but to allow both I'm afraid :-(
Finally, with some systems we may have the option of specifying
a target address - eg PCI device ID seen in guest.
So, some examples
A USB device by vendor+product
hostdev mode='bus' bus='usb'
hostdev mode='subsystem' type='usb'
source
product id='1155'/
vendor id='8214'/
/source
/hostdev
A USB device by address
hostdev mode='bus' bus='usb'
hostdev mode='subsystem' type='usb'
source
address bus='003' dev='005'/
/source
/hostdev
A PCI device by address
hostdev mode='bus' bus='pci'
hostdev mode='subsystem' type='pci'
source
address domain= bus=00 slot=16 function=3/
/source
/hostdev
A network card by name (ie for OpenVZ)
hostdev mode='capability'
source name='eth0'/
/hostdev
A SCSI device by name (eg, SCSI PV passthrough), also specifying
the target adress
hostdev mode='capability' type='scsi'
source name='sg3'/
target address='0:0:0:0'/
/hostdev
Taking into account the various options we need to cope with
I think we'll need something a little larger, along the lines
of
enum virDomainHostdevMode {
VIR_DOMAIN_HSOTDEV_MODE_BUS,
VIR_DOMAIN_HSOTDEV_MODE_CAPABILITY,
};
enum virDomainHostdevBusType
VIR_DOMAIN_HSOTDEV_BUS_TYPE_PCI,
VIR_DOMAIN_HSOTDEV_BUS_TYPE_USB,
};
s/BUS/SUBSYS/
enum virDomainHostdevCapabilityType {
VIR_DOMAIN_HSOTDEV_CAP_TYPE_NET,
VIR_DOMAIN_HSOTDEV_CAP_TYPE_SCSI,
};
struct _virDomainHostdevDef {
int mode; /* enum virDomainHostdevMode */
union {
struct {
int type; /* enum virDomainHostdevBusType */
union {
struct {
unsigned bus;
unsigned device;
unsigned vendor;
unsigned product;
[libvirt] KVM migration patch (2008-07-29)
This is just a rebase of the KVM migration patch to the latest libvirt CVS: http://www.annexia.org/tmp/libvirt-kvm-migrate-20080729.patch Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH/RFC]: hostdev passthrough support
On Fri, Jul 25, 2008 at 04:17:30PM -0400, Guido G?nther wrote:
Hi,
attached is some basic support for host device passthrough. It enables
you to passthrough usb devices in qemu/kvm via:
devices
hostdev type='usb' vendor='0204' product='6025'/
hostdev type='usb' bus='001' device='007'/
/devices
This stuff is obviously going to have a correlation with the host
device enumeration support I'd offered a design for a few months
back. As such I'd like to try and keep a consistent XML format
between the two. For reference the original mesage was here:
http://www.redhat.com/archives/libvir-list/2008-April/msg5.html
There were basically two ways to identify a device. Some devices
are 'physical' mapped straight to a piece of hardware (USB device,
or PCI card) and would have 'bus' element with hardware details.
eg a USB finger print reader appears as:
device
nameusb_device_483_2016_noserial/name
key/org/freedesktop/Hal/devices/usb_device_483_2016_noserial/key
parent/org/freedesktop/Hal/devices/usb_device_0_0__00_1d_3/parent
bus type=usb
vendor id=1155SGS Thomson Microelectronics/vendor
product id=8214Fingerprint Reader/product
address bus=003 dev=005/
/bus
/device
Other devices are 'logical' devices, which don't have hardware info
directly associated with them. The reason for this is that one piece
of hardware may present many logical devices each with varying
capabilities. As an example, a wifi card typically exports at least
2 network device - one control interface, and one for traffic.
eg a wireless network interface for data traffic
device
namenet_00_13_02_b9_f9_d3_0/name
key/org/freedesktop/Hal/devices/net_00_13_02_b9_f9_d3_0/key
parent/org/freedesktop/Hal/devices/pci_8086_4227/parent
capability type=net
hwaddr00:13:02:b9:f9:d3/hwaddr
nameeth0/name
capability type=80211/
/capability
/device
In this case the unique device identifier is the 'name' field
but this case varying depending on the capability type.
Different virt solutions have different capabilties for device
passthrough. KVM and Xen both support passthrough of physical
devices, either USB or PCI cards. OpenVZ supports passthrough
of logical devices - in particular network interfaces.
We need to allow for both possibilities in the domain XML for
this type of device.
So, to expand on your proposal, I'd like to see the XML format
have a top level attribute indicating whether we're passing a
logical or physical device, and then the capability name or
bus name respectively. The child elements then need to provide
the appropriate naming.
USB has the further annoyance you identified that one could
conceivably do attachment based on USB bus address, or the
vendor+product pair. The downside of former is that a bus
address changes every time you plug a device in. The downside
of the latter is that it is not neccessarily unique. We have
no choice but to allow both I'm afraid :-(
Finally, with some systems we may have the option of specifying
a target address - eg PCI device ID seen in guest.
So, some examples
A USB device by vendor+product
hostdev mode='bus' bus='usb'
source
product id='1155'/
vendor id='8214'/
/source
/hostdev
A USB device by address
hostdev mode='bus' bus='usb'
source
address bus='003' dev='005'/
/source
/hostdev
A PCI device by address
hostdev mode='bus' bus='pci'
source
address domain= bus=00 slot=16 function=3/
/source
/hostdev
A network card by name (ie for OpenVZ)
hostdev mode='capability'
source name='eth0'/
/hostdev
A SCSI device by name (eg, SCSI PV passthrough), also specifying
the target adress
hostdev mode='capability' type='scsi'
source name='sg3'/
target address='0:0:0:0'/
/hostdev
Conceivably we could allow PCI devices by vendor+product, but
I don't see much call for that since PCI device's don't (yet)
appear/disappear on the fly have a consistent address. More
to the point none of our underlying hypervisors use anything
other than the PCI address for PCI device passthrough.
For USB, if we're doing attachment based on vendor+product,
then libvirt needs to query QEMU to find out the actual
device it chose, so we can fill in the address tag. NB I
know QEMU doesn't allow this, but we need it in order todo
unplug reliably, so we'll likely need to do it anyway.
diff --git a/src/domain_conf.h b/src/domain_conf.h
index b438bc8..1aa5c39 100644
--- a/src/domain_conf.h
+++ b/src/domain_conf.h
@@ -257,7 +257,35 @@ struct _virDomainGraphicsDef {
} data;
};
+enum virDomainHostdevType {
+VIR_DOMAIN_HOSTDEV_TYPE_USB,
+VIR_DOMAIN_HOSTDEV_TYPE_PCI,
+VIR_DOMAIN_HOSTDEV_TYPE_LAST
+};
+
+typedef struct _virDomainHostdevDef virDomainHostdevDef;
+typedef virDomainHostdevDef *virDomainHostdevDefPtr;
+struct _virDomainHostdevDef {
+int type;
+union {
+struct {
+
Re: [libvirt] [PATCH/RFC]: hostdev passthrough support
On Tue, Jul 29, 2008 at 11:56:18AM +0100, Daniel P. Berrange wrote: On Mon, Jul 28, 2008 at 09:26:57AM -0400, Daniel Veillard wrote: I also think we need to clarify the naming conventions, are numbers provided decimal, if yes then is an 0x hexadecimal version allowed too. I also see how a more high level description might be useful, hostdev type='usb' source vendor='Sennheiser'/ /hostdev or hostdev type='usb' source product='headset'/ /hostdev We should stick to ID numbers in the domain XML - allowing decimal or hex is nice. For descriptive names 'Sennheiser' or 'headset', we should only provide that info in the device enumeration APIs Well, I was thinking of this as a way to keep the XML file static over a range of potential hardware, potentially allowing some kind of migration in spite of a dependancy to a local hardware device. But that's probably not very realistic, and if turn out possible sometimes then that can be added later. http://www.redhat.com/archives/libvir-list/2008-April/msg5.html Management tools / admins can use this to map to the ID number from a human readable name if relevant. Okay, that solves the problem at creation time, i remember this being discussed no problem. 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
[libvirt] [PATCH] virsh edit command
One thing which is very apparent is that sys admins using libvirt /
virsh have a great deal of difficulty understanding where the
configuration files have gone and how to edit them.
This patch adds a virsh edit domain command which is basically the
equivalent of:
virsh dumpxml dom /tmp/dom.xml
$EDITOR /tmp/dom.xml virsh define /tmp/dom.xml
but with much more sanity checking. The editor is $EDITOR or vi, and
it does the right thing if the user doesn't modify the file, or if
another user edits the configuration at the same time.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
Index: docs/virsh.pod
===
RCS file: /data/cvs/libvirt/docs/virsh.pod,v
retrieving revision 1.16
diff -u -r1.16 virsh.pod
--- docs/virsh.pod 15 May 2008 06:12:32 - 1.16
+++ docs/virsh.pod 29 Jul 2008 12:21:38 -
@@ -277,6 +277,19 @@
Output the domain information as an XML dump to stdout, this format can be
used by the Bcreate command.
+=item Bedit Idomain-id
+
+Edit the XML configuration file for a domain.
+
+This is equivalent to:
+ virsh dumpxml domain domain.xml
+ edit domain.xml
+ virsh define domain.xml
+except that it does some error checking.
+
+The editor used can be supplied by the C$EDITOR environment
+variable, or if that is not defined defaults to Cvi.
+
=item Bmigrate optional I--live Idomain-id Idesturi Imigrateuri
Migrate domain to another host. Add --live for live migration. The Idesturi
Index: src/virsh.c
===
RCS file: /data/cvs/libvirt/src/virsh.c,v
retrieving revision 1.157
diff -u -r1.157 virsh.c
--- src/virsh.c 22 Jul 2008 16:12:01 - 1.157
+++ src/virsh.c 29 Jul 2008 12:21:42 -
@@ -5070,6 +5070,179 @@
}
/*
+ * edit command
+ */
+static vshCmdInfo info_edit[] = {
+{syntax, edit domain},
+{help, gettext_noop(edit XML configuration for a domain)},
+{desc, gettext_noop(Edit the XML configuration for a domain.)},
+{NULL, NULL}
+};
+
+static vshCmdOptDef opts_edit[] = {
+{domain, VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop(domain name, id or
uuid)},
+{NULL, 0, 0, NULL}
+};
+
+static int
+cmdEdit (vshControl *ctl, vshCmd *cmd)
+{
+int ret = FALSE;
+virDomainPtr dom = NULL;
+char *doc = NULL;
+char *tmp = NULL;
+int fd = -1;
+const char *editor;
+char command[100];
+int command_ret;
+char *doc_edited = NULL;
+struct stat statbuf;
+char *doc_reread = NULL;
+
+if (!vshConnectionUsability(ctl, ctl-conn, TRUE))
+goto cleanup;
+
+dom = vshCommandOptDomain (ctl, cmd, domain, NULL);
+if (dom == NULL)
+goto cleanup;
+
+/* Get the XML configuration of the domain. */
+doc = virDomainGetXMLDesc (dom, 0);
+if (!doc)
+goto cleanup;
+
+/* Create and open the temporary file. */
+tmp = tempnam (NULL, virsh);
+if (!tmp) {
+vshError(ctl, FALSE,
+ _(tempnam: failed to create temporary file: %s),
+ strerror (errno));
+goto cleanup;
+}
+fd = open (tmp, O_EXCL|O_CREAT|O_WRONLY, 0600);
+if (fd == -1) {
+vshError(ctl, FALSE,
+ _(open: %s: failed to create temporary file: %s),
+ tmp, strerror (errno));
+goto cleanup;
+}
+
+if (safewrite (fd, doc, strlen (doc)) == -1) {
+vshError(ctl, FALSE,
+ _(write: %s: failed to create temporary file: %s),
+ tmp, strerror (errno));
+goto cleanup;
+}
+if (close (fd) == -1) {
+vshError(ctl, FALSE,
+ _(close: %s: failed to create temporary file: %s),
+ tmp, strerror (errno));
+goto cleanup;
+}
+fd = -1;
+
+/* Start the editor. */
+editor = getenv (EDITOR);
+if (!editor) editor = vi; /* could be cruel default to ed(1) here */
+
+snprintf (command, sizeof command, %s %s, editor, tmp);
+command_ret = system (command);
+
+if (command_ret == -1) {
+vshError(ctl, FALSE,
+ %s: %s,
+ command, strerror (errno));
+goto cleanup;
+}
+if (command_ret != WEXITSTATUS (0)) {
+vshError(ctl, FALSE,
+ _(%s: command exited with non-zero status), command);
+goto cleanup;
+}
+
+/* Read back the edited XML file. */
+fd = open (tmp, O_RDONLY);
+if (fd == -1) {
+vshError(ctl, FALSE,
+ _(open: %s: failed to read temporary file: %s),
+ tmp, strerror (errno));
+goto cleanup;
+}
+if (fstat (fd, statbuf) == -1) {
+vshError(ctl, FALSE,
+ _(stat: %s: failed to read temporary file: %s),
+
Re: [libvirt] Libvir on Hardy: file a bug or not?
Pau Garcia i Quiles wrote: I cannot help you with your problem but in case you want to try the latest and greatest libvirt, there are 0.4.4 packages available in my PPA: http://launchpad.net/~pgquiles/+archive (UNOFFICIAL AND UNSUPPORTED) They doesnt solve the problem. Thank you, anyway. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix logical storage pool operation on SLES10-SP2
On Tue, 2008-07-29 at 09:44 +0100, Daniel P. Berrange wrote: BTW, what version of the LVM tools is SLES using - its probably useful to note that in the comment you added, in case the same problem is particular to a version, rather than just SLES lvm2 2.02.17 (-7.19, x86_64) But it's hard to know (without reading the ChangeLog in detail) how much backporting is hidden in the distro-specific part of the version (-7.19) ... Dave -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] PATCH: Support container XML enhancements
This is something I previously submitted as part of one of the LXC
patches, but I figure it makes sense on its own, since OpenVZ needs
this now too.
This adds two new XML elements to the domain XML format:
- An init block within os allowing specification of the path for
a binary to run when starting the container - aka 'init' by any other
name. First we also specify that all containers will use an OS
type of 'exe' - as in executable - the container equivalent of 'hvm'
os
typeexe/type
init/sbin/init/init
/os
- An filesystem element for specifying how the container's filesystem
is to be provided. This can actually be useful for full-machine virt
too such as KVM which have host filesystem pass-through. There are
various ways to configure it:
eg to use '/some/directory' as the root filesystem for a container
filesystem type='mount'
source dir='/some/directory'/
target dir='/'/
/filesystem
eg to use a template called 'fedora9web' as the root filesystem for
a container
filesystem type='template'
source name='fedora9web'/
target dir='/'/
/filesystem
eg to use a file containing a filesystem as the root filesystem
filesystem type='file'
source file='/some/file.img'/
target dir='/'/
/filesystem
eg to use a disk partition or other block device (eg LVM) containing
a filesystem as the root filesystem
filesystem type='block'
source dev='/dev/VolGroup00/Fedora9Web'/
target dir='/'/
/filesystem
If setting the root filesystem, the target path will be '/', some
container based virt allows the host OS root filesystem to be
used in the guest, and merely specify additive mounts at specific
locations,
eg to override just /home within a container
filesystem type='mount'
source dir='/some/directory'/
target dir='/home'/
/filesystem
I believe this should satisfy all the OpenVZ, LXC and Linux-VServer
drivers' requirements around filesystems
Daniel
diff -r 5614da5fe9ef src/domain_conf.c
--- a/src/domain_conf.c Fri Jul 25 15:38:46 2008 +0100
+++ b/src/domain_conf.c Tue Jul 29 16:03:38 2008 +0100
@@ -86,6 +86,12 @@
virtio,
xen)
+VIR_ENUM_IMPL(virDomainFS, VIR_DOMAIN_FS_TYPE_LAST,
+ mount,
+ block,
+ file,
+ template)
+
VIR_ENUM_IMPL(virDomainNet, VIR_DOMAIN_NET_TYPE_LAST,
user,
ethernet,
@@ -234,6 +240,18 @@
VIR_FREE(def-driverType);
virDomainDiskDefFree(def-next);
+VIR_FREE(def);
+}
+
+void virDomainFSDefFree(virDomainFSDefPtr def)
+{
+if (!def)
+return;
+
+VIR_FREE(def-src);
+VIR_FREE(def-dst);
+
+virDomainFSDefFree(def-next);
VIR_FREE(def);
}
@@ -345,6 +363,7 @@
virDomainGraphicsDefFree(def-graphics);
virDomainInputDefFree(def-inputs);
virDomainDiskDefFree(def-disks);
+virDomainFSDefFree(def-fss);
virDomainNetDefFree(def-nets);
virDomainChrDefFree(def-serials);
virDomainChrDefFree(def-parallels);
@@ -355,6 +374,7 @@
VIR_FREE(def-os.type);
VIR_FREE(def-os.arch);
VIR_FREE(def-os.machine);
+VIR_FREE(def-os.init);
VIR_FREE(def-os.kernel);
VIR_FREE(def-os.initrd);
VIR_FREE(def-os.cmdline);
@@ -620,6 +640,89 @@
error:
virDomainDiskDefFree(def);
+def = NULL;
+goto cleanup;
+}
+
+
+/* Parse the XML definition for a disk
+ * @param node XML nodeset to parse for disk definition
+ */
+static virDomainFSDefPtr
+virDomainFSDefParseXML(virConnectPtr conn,
+ xmlNodePtr node) {
+virDomainFSDefPtr def;
+xmlNodePtr cur;
+char *type = NULL;
+char *source = NULL;
+char *target = NULL;
+
+if (VIR_ALLOC(def) 0) {
+virDomainReportError(conn, VIR_ERR_NO_MEMORY, NULL);
+return NULL;
+}
+
+type = virXMLPropString(node, type);
+if (type) {
+if ((def-type = virDomainFSTypeFromString(type)) 0) {
+virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
+ _(unknown filesystem type '%s'), type);
+goto error;
+}
+} else {
+def-type = VIR_DOMAIN_FS_TYPE_MOUNT;
+}
+
+cur = node-children;
+while (cur != NULL) {
+if (cur-type == XML_ELEMENT_NODE) {
+if ((source == NULL)
+(xmlStrEqual(cur-name, BAD_CAST source))) {
+
+if (def-type == VIR_DOMAIN_FS_TYPE_MOUNT)
+source = virXMLPropString(cur, dir);
+else if (def-type == VIR_DOMAIN_FS_TYPE_FILE)
+source = virXMLPropString(cur, file);
+else if (def-type == VIR_DOMAIN_FS_TYPE_BLOCK)
+source = virXMLPropString(cur, dev);
+else if (def-type == VIR_DOMAIN_FS_TYPE_TEMPLATE)
+source
Re: [libvirt] PATCH: Support container XML enhancements
Daniel P. Berrange пишет: eg to use a template called 'fedora9web' as the root filesystem for a container filesystem type='template' source name='fedora9web'/ target dir='/'/ /filesystem Daniel, OpenVZ also require quota tags quota type=size max=1/ quota type=inodes max=20/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Support container XML enhancements
On Tue, Jul 29, 2008 at 04:20:14PM +0100, Daniel P. Berrange wrote: This is something I previously submitted as part of one of the LXC patches, but I figure it makes sense on its own, since OpenVZ needs this now too. No update to libvirt.rng? Or test cases? os typeexe/type init/sbin/init/init /os Will this be optional? Whilst it doesn't exist in any form now, Solaris Zones has no such concept (it's /always/ init, but it's also completely private to the implementation and should be exposed). filesystem type='mount' source dir='/some/directory'/ target dir='/'/ /filesystem No facility for mount options? I don't think any of the stated options would work for ZFS dataset delegation, though I suppose that could be added later if it happens. What is template? regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Support container XML enhancements
On Tue, Jul 29, 2008 at 07:33:29PM +0400, Evgeniy Sokolov wrote: Daniel P. Berrange ??: eg to use a template called 'fedora9web' as the root filesystem for a container filesystem type='template' source name='fedora9web'/ target dir='/'/ /filesystem Daniel, OpenVZ also require quota tags quota type=size max=1/ quota type=inodes max=20/ I'd like to deal with those in a separate patch from the core filesystem functionality support - since they're just a tuning parameter it isn't critical to have them supported immediately. Daniel -- |: Red Hat, Engineering, London -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
Re: [libvirt] PATCH: Support container XML enhancements
On Tue, Jul 29, 2008 at 04:44:32PM +0100, John Levon wrote: On Tue, Jul 29, 2008 at 04:20:14PM +0100, Daniel P. Berrange wrote: This is something I previously submitted as part of one of the LXC patches, but I figure it makes sense on its own, since OpenVZ needs this now too. No update to libvirt.rng? Or test cases? Mmm, yes need the RNG file at least. We need to have a generic test suite for validating the RNG against the XML files in tests/, as well as ad-hoc XML files we may add os typeexe/type init/sbin/init/init /os Will this be optional? Whilst it doesn't exist in any form now, Solaris Zones has no such concept (it's /always/ init, but it's also completely private to the implementation and should be exposed). Yes it is completely optional - its not required upon input. If the driver has a default value it wants to expose it can set it, so its visible upon XML dump. filesystem type='mount' source dir='/some/directory'/ target dir='/'/ /filesystem No facility for mount options? Not until we have a concrete need for them in one of the drivers. We can add them as attributes on the source tag, or child elements, as we find need for them. I don't think any of the stated options would work for ZFS dataset delegation, though I suppose that could be added later if it happens. What is ZFS dataset delegation ? What is template? Templates are a concept OpenVZ / VServer have to simplify management of container filesystems. Basically a 'canned' filesystem image, that is instantiated for each container on demand. eg, a tar.gz containing the FS, that is extracted once for each container using it. Daniel -- |: Red Hat, Engineering, London -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
Re: [libvirt] [PATCH] virsh edit command
On Tue, Jul 29, 2008 at 02:48:26PM +0100, John Levon wrote: On Tue, Jul 29, 2008 at 01:27:42PM +0100, Richard W.M. Jones wrote: One thing which is very apparent is that sys admins using libvirt / virsh have a great deal of difficulty understanding where the configuration files have gone and how to edit them. .py files and the like were supposed to be human editable. I'm not convinced that libvirt XML is (heck, I certainly can't remember it). Isn't the *right* solution to this problem to finally add property set/get interface for the things people actually want to modify, like boot flags? Do you mean things like the current 'virsh attach-device' / 'virsh detach-device' interface? I'm responding here to a need that sysadmins feel they have -- to edit the configuration file (even if it's XML). Witness an endless series of questions on this subject on the #virt channel yesterday. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh edit command
On Tue, Jul 29, 2008 at 05:00:27PM +0100, Richard W.M. Jones wrote: Isn't the *right* solution to this problem to finally add property set/get interface for the things people actually want to modify, like boot flags? Do you mean things like the current 'virsh attach-device' / 'virsh detach-device' interface? I hope not... that's just as bad as editing the domain XML. I'm responding here to a need that sysadmins feel they have -- to edit the configuration file (even if it's XML). Witness an endless series of questions on this subject on the #virt channel yesterday. Right. But to my mind you're fixing the symptom not the problem. *Why* do they need to edit the XML? I ask this of everybody who complains at me about having to edit XML: 99% of the time it's wanting to change boot flags, but it's also stuff like turning off ACPI, setting on_crash, etc. Editing XML is absolutely not user friendly, and adding 'edit' just papers over the real problems IMHO. regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh edit command
On Tue, Jul 29, 2008 at 05:09:37PM +0100, John Levon wrote: Right. But to my mind you're fixing the symptom not the problem. *Why* do they need to edit the XML? I ask this of everybody who complains at me about having to edit XML: 99% of the time it's wanting to change boot flags, but it's also stuff like turning off ACPI, setting on_crash, etc. Editing XML is absolutely not user friendly, and adding 'edit' just papers over the real problems IMHO. I actually started at one point on a graphical libvirt XML editor, although I fairly quickly realised it would be a Sisyphean task because the format isn't tremendously well defined[1] and it keeps changing. Also because there's a lot of overlap between virt-install and (potential) virt-config-editor. I do genuinely think that having 'virsh edit' is better than the current situation. Currently the advice that everyone gives is to do: virsh dumpxml foo foo.xml vi foo.xml virsh define foo.xml which is of course precisely the same as what 'virsh edit' does :-) Rich. [1] Although it's a great deal better since Dan Berrange started to formalize the way drivers generate and parse the XML. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh edit command
On Tue, Jul 29, 2008 at 05:09:37PM +0100, John Levon wrote: On Tue, Jul 29, 2008 at 05:00:27PM +0100, Richard W.M. Jones wrote: Isn't the *right* solution to this problem to finally add property set/get interface for the things people actually want to modify, like boot flags? Do you mean things like the current 'virsh attach-device' / 'virsh detach-device' interface? I hope not... that's just as bad as editing the domain XML. I'm responding here to a need that sysadmins feel they have -- to edit the configuration file (even if it's XML). Witness an endless series of questions on this subject on the #virt channel yesterday. Right. But to my mind you're fixing the symptom not the problem. *Why* do they need to edit the XML? I ask this of everybody who complains at me about having to edit XML: 99% of the time it's wanting to change boot flags, but it's also stuff like turning off ACPI, setting on_crash, etc. Editing XML is absolutely not user friendly, and adding 'edit' just papers over the real problems IMHO. When I did the storage APIs, I had the traditional commands 'create' and 'define' which took XML documents. I then also add a 'create-as' and 'define-as' command which took a list of named arguments. virsh then turned these into XML docs. eg, to create an LVM backed storage pool from /dev/hda2, you could do something like virsh pool-define-as --source-path /dev/hda2 MyVolGroup lvm And it'd create pool type='lvm' nameMyVolGroup/name source device path='/dev/hda2'/ /source /pool This only deals with creation, or defining a new config, not updating an existing config - in the latter you'd only want to specify the bits which are actually changing - for that we'd want an 'edit-as' command which reads the XML, updates the bits that are changing, and saves the XML back into libvirt We could try todo a similar thing for domains too, though obviously we're going to have a huge number of options to handle to get decent coverage. We'd also need to have an 'edit-as' Daniel -- |: Red Hat, Engineering, London -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
Re: [libvirt] [PATCH] virsh edit command
On Tue, Jul 29, 2008 at 05:17:55PM +0100, Richard W.M. Jones wrote: On Tue, Jul 29, 2008 at 05:09:37PM +0100, John Levon wrote: Right. But to my mind you're fixing the symptom not the problem. *Why* do they need to edit the XML? I ask this of everybody who complains at me about having to edit XML: 99% of the time it's wanting to change boot flags, but it's also stuff like turning off ACPI, setting on_crash, etc. Editing XML is absolutely not user friendly, and adding 'edit' just papers over the real problems IMHO. I actually started at one point on a graphical libvirt XML editor, although I fairly quickly realised it would be a Sisyphean task because the format isn't tremendously well defined[1] and it keeps changing. Also because there's a lot of overlap between virt-install and (potential) virt-config-editor. I do genuinely think that having 'virsh edit' is better than the current situation. Currently the advice that everyone gives is to do: virsh dumpxml foo foo.xml vi foo.xml virsh define foo.xml which is of course precisely the same as what 'virsh edit' does :-) Yes, I think this command is worthwhile adding. We should also try to address the problem that John raises too, but I see that as a parallel task - and a far more involved piece of work to undertake :-) Daniel -- |: Red Hat, Engineering, London -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
Re: [libvirt] [PATCH] virsh edit command
On Tue, Jul 29, 2008 at 05:25:57PM +0100, Daniel P. Berrange wrote: I actually started at one point on a graphical libvirt XML editor, although I fairly quickly realised it would be a Sisyphean task because the format isn't tremendously well defined[1] and it keeps changing. Also because there's a lot of overlap between virt-install and (potential) virt-config-editor. I do genuinely think that having 'virsh edit' is better than the current situation. Currently the advice that everyone gives is to do: virsh dumpxml foo foo.xml vi foo.xml virsh define foo.xml which is of course precisely the same as what 'virsh edit' does :-) Yes, I think this command is worthwhile adding. We should also try to address the problem that John raises too, but I see that as a parallel task - and a far more involved piece of work to undertake :-) Right, and it'll probably never happen if we band-aid over the problem. Ah well. john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Support container XML enhancements
On Tue, Jul 29, 2008 at 04:54:09PM +0100, Daniel P. Berrange wrote: This is something I previously submitted as part of one of the LXC patches, but I figure it makes sense on its own, since OpenVZ needs this now too. No update to libvirt.rng? Or test cases? Mmm, yes need the RNG file at least. We need to have a generic test suite for validating the RNG against the XML files in tests/, as well as ad-hoc XML files we may add Right. I have a small virt-convert test suite, but of course that uses Python. But it's basically just doing xmllint --noout --relaxng doc/libvirt.rng foo.xml I'm a little short on time to do the same for libvirt right now alas. I don't think any of the stated options would work for ZFS dataset delegation, though I suppose that could be added later if it happens. What is ZFS dataset delegation ? It allows you to place an entire ZFS hierarchy under control of a zone, e.g. I can say that the ZFS dataset export/foo is accessible to the zone and it can freely create sub-filesystems, snapshot, etc. It could almost hijack one of the other types if it weren't for the absolute path thing. regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh edit command
On Tue, Jul 29, 2008 at 05:27:09PM +0100, John Levon wrote: On Tue, Jul 29, 2008 at 05:25:57PM +0100, Daniel P. Berrange wrote: I actually started at one point on a graphical libvirt XML editor, although I fairly quickly realised it would be a Sisyphean task because the format isn't tremendously well defined[1] and it keeps changing. Also because there's a lot of overlap between virt-install and (potential) virt-config-editor. I do genuinely think that having 'virsh edit' is better than the current situation. Currently the advice that everyone gives is to do: virsh dumpxml foo foo.xml vi foo.xml virsh define foo.xml which is of course precisely the same as what 'virsh edit' does :-) Yes, I think this command is worthwhile adding. We should also try to address the problem that John raises too, but I see that as a parallel task - and a far more involved piece of work to undertake :-) Right, and it'll probably never happen if we band-aid over the problem. Ah well. Well, I take your point here, and if you really think 'virsh edit' is a bad idea then perhaps we can do something else (give it another name?). Do you think a graphical libvirt XML format editor is a good solution? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh edit command
On Tue, Jul 29, 2008 at 05:46:34PM +0100, Richard W.M. Jones wrote: Right, and it'll probably never happen if we band-aid over the problem. Ah well. Well, I take your point here, and if you really think 'virsh edit' is a bad idea then perhaps we can do something else (give it another name?). Well, I've not really any objection to the proposal as it is. Do you think a graphical libvirt XML format editor is a good solution? This would help enormously. You could even start it from 'virsh edit' if $DISPLAY is set. I've no idea about the general tools out there for generating UI from XML, but there has to be something. regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh edit command
On Tue, Jul 29, 2008 at 05:50:30PM +0100, John Levon wrote: On Tue, Jul 29, 2008 at 05:46:34PM +0100, Richard W.M. Jones wrote: Do you think a graphical libvirt XML format editor is a good solution? This would help enormously. You could even start it from 'virsh edit' if $DISPLAY is set. I've no idea about the general tools out there for generating UI from XML, but there has to be something. DV?? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Support container XML enhancements
On Tue, Jul 29, 2008 at 05:15:02PM +0100, John Levon wrote: On Tue, Jul 29, 2008 at 04:54:09PM +0100, Daniel P. Berrange wrote: I don't think any of the stated options would work for ZFS dataset delegation, though I suppose that could be added later if it happens. What is ZFS dataset delegation ? It allows you to place an entire ZFS hierarchy under control of a zone, e.g. I can say that the ZFS dataset export/foo is accessible to the zone and it can freely create sub-filesystems, snapshot, etc. It could almost hijack one of the other types if it weren't for the absolute path thing. So does 'export/foo' become the root filesystem (/) of the zone ? Or is it sharing the same root filesystem, and more akin to granting permissions over 'export/foo' ? I'm not against to adding other types if it doesn't fit the model of any others I've suggested. Daniel -- |: Red Hat, Engineering, London -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
[libvirt] [PATCH] don't dump core on NULL ifname
Hi,
actually I thought I sent this out already, but it seems I didn't:
Don't dump core on NULL ifname when getting interface statistic.
Not all networking types have a target ifname set
(user,client,server,mcast).
Cheers,
-- Guido
[PATCH] don't dump core on NULL ifname
not all networking types have a target ifname set
(user,client,server,mcast)
---
src/qemu_driver.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index b8fd11c..9d661d2 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -3242,7 +3242,7 @@ qemudDomainInterfaceStats (virDomainPtr dom,
/* Check the path is one of the domain's network interfaces. */
for (net = vm-def-nets; net; net = net-next) {
-if (STREQ (net-ifname, path))
+if (net-ifname STREQ (net-ifname, path))
goto ok;
}
--
1.5.6.3
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH/RFC]: hostdev passthrough support
Hi Daniel, On Mon, Jul 28, 2008 at 09:26:57AM -0400, Daniel Veillard wrote: On Fri, Jul 25, 2008 at 04:17:30PM -0400, Guido Günther wrote: Hi, attached is some basic support for host device passthrough. It enables you to passthrough usb devices in qemu/kvm via: devices hostdev type='usb' vendor='0204' product='6025'/ you meant type='pci' there right ? Qemu support host:bus.device syntax for usb devices (useful for the case of two identical devices). PCI can work like this too of course. hostdev type='usb' bus='001' device='007'/ /devices Hum, on the format level I think this need a bit more discussion. the type is better caracterized as a bus informations. Also I'm not sure if we should keep a flat single element or (expecting possible further complex descriptions later) go for a more structured description like hostdev type='pci' source vendor='0204' product='6025'/ /hostdev I think this looks better. Actually I thought so already after sending the patch. I think an hypervisor could remap the actual port/addresses of a device so a target may make sense in the future (or not). Hopefully it does. It would be nice if we could do that since we'd then have the necessary data for easy unmapping. I didn't implement unplug yet since this needs some modifications to qemu/kvm to be able to identify the correct device to unplug. Does this look reasonable? I also think we need to clarify the naming conventions, are numbers provided decimal, if yes then is an 0x hexadecimal version allowed too. Currently they're all hex as outputet by lsusb. [..snip..] From an implementation perspective, the patch looks very clean to me aside maybe some Hostdev type vs. Bus naming for the enum, but maybe we need to give a bit more thoughs one the format first :-) Sure. I'll see what I can come up with. Thanks for the comments. -- Guido -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Support container XML enhancements
On Tue, Jul 29, 2008 at 05:56:38PM +0100, Daniel P. Berrange wrote: It allows you to place an entire ZFS hierarchy under control of a zone, e.g. I can say that the ZFS dataset export/foo is accessible to the zone and it can freely create sub-filesystems, snapshot, etc. It could almost hijack one of the other types if it weren't for the absolute path thing. So does 'export/foo' become the root filesystem (/) of the zone ? Or is Nope, it's just available (typically it'd get mounted as /export/foo in the zone). You can do the same with the root filesystem of course, but then the config could use an absolute path since it (called 'zonepath' does have to be absolute essentially. over 'export/foo' ? I'm not against to adding other types if it doesn't fit the model of any others I've suggested. OK regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt log
I have a quick question. I am trying to debug a remote access problem and have set the following parameters: # Override the default config file #LIBVIRTD_CONFIG=/etc/libvirt/libvirtd.conf # Listen for TCP/IP connections # NB. must setup TLS/SSL keys prior to using this LIBVIRTD_ARGS=--listen --verbose # Override Kerberos service keytab for SASL/GSSAPI #KRB5_KTNAME=/etc/libvirt/krb5.tab I have not been able to find the libvirtd log. Where is it located? Thanks for your help Steve -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
