Re: [libvirt] [PATCH] Added new attribute exportfs_type to filesystem element
Hi Daniel, Makes sense, agreed. However, did you get a chance to review the security_model patch? https://www.redhat.com/archives/libvir-list/2010-September/msg00435.html On 10/06/2010 09:59 PM, Daniel P. Berrange wrote: On Wed, Oct 06, 2010 at 06:22:29PM +0200, Daniel Veillard wrote: On Thu, Sep 30, 2010 at 10:30:10PM +0530, Harsh Prateek Bora wrote: This patch introduces a new attribute export_fs to the filesystem element which specifies the type of export. Currently only 'local' type of exported filesystem is supported. More types like NFS, clusterFS, etc. can be added later as required. Note: This patch is based on the following two patches: 1) Daniel's patch to support 9pfs: https://www.redhat.com/archives/libvir-list/2010-September/msg00358.html 2) Another related patch to support 'security_model' attribute: https://www.redhat.com/archives/libvir-list/2010-September/msg00435.html Signed-off-by: Harsh Prateek Boraha...@linux.vnet.ibm.com Okay, I don't understand what's the point of adding that attribute with only one possible value and systematically generated. I think it's better to propose this when there is an actual use case for the attribute, then it will be easier to say if this is the right construct to add or not. I agree and in fact think this extra attribute is almost certainly the wrong approach. The existingfilesystem type='' attribute should be sufficient for our needs. When QEMU supports FS backends which are not 'local', then we will likely add extra values for type='...' to cope with them. So lets just wait until QEMU actually supports some non-local modes. Regards, Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt and nested pagind
Good afternoon!
Searching on the web, I joint some codes and produced those patches.
Now I have a server running perfectly with the following scenario:
AMD Phenom 8400 x3;
Slackware64 13.1 on a slim and custom 2.6.35.2 Linux;
qemu-kvm 0.12.5;
libvirt 0.8.4.
Patch of libvirt 0.8.3:
diff -Naur ../libvirt-0.8.3//docs/schemas/domain.rng
./docs/schemas/domain.rng
--- ../libvirt-0.8.3//docs/schemas/domain.rng 2010-07-29
06:48:30.0 -0300
+++ ./docs/schemas/domain.rng 2010-09-01 16:51:57.710851479 -0300
@@ -1595,6 +1595,11 @@
empty/
/element
/optional
+ optional
+ element name=nesting
+ empty/
+ /element
+ /optional
/interleave
/element
/optional
diff -Naur ../libvirt-0.8.3//src/conf/domain_conf.c ./src/conf/domain_conf.c
--- ../libvirt-0.8.3//src/conf/domain_conf.c2010-08-02
16:16:42.0 -0300
+++ ./src/conf/domain_conf.c2010-09-01 16:51:57.710851479 -0300
@@ -75,7 +75,8 @@
VIR_ENUM_IMPL(virDomainFeature, VIR_DOMAIN_FEATURE_LAST,
acpi,
apic,
- pae)
+ pae,
+ nesting)
VIR_ENUM_IMPL(virDomainLifecycle, VIR_DOMAIN_LIFECYCLE_LAST,
destroy,
diff -Naur ../libvirt-0.8.3//src/conf/domain_conf.h ./src/conf/domain_conf.h
--- ../libvirt-0.8.3//src/conf/domain_conf.h2010-07-29
06:48:30.0 -0300
+++ ./src/conf/domain_conf.h2010-09-01 16:51:57.710851479 -0300
@@ -649,6 +649,7 @@
VIR_DOMAIN_FEATURE_ACPI,
VIR_DOMAIN_FEATURE_APIC,
VIR_DOMAIN_FEATURE_PAE,
+VIR_DOMAIN_FEATURE_NESTING,
VIR_DOMAIN_FEATURE_LAST
};
diff -Naur ../libvirt-0.8.3//src/qemu/qemu_conf.c ./src/qemu/qemu_conf.c
--- ../libvirt-0.8.3//src/qemu/qemu_conf.c 2010-08-04
09:21:27.0 -0300
+++ ./src/qemu/qemu_conf.c 2010-09-01 16:57:47.485469640 -0300
@@ -1190,6 +1190,8 @@
flags |= QEMUD_CMD_FLAG_MEM_PATH;
if (strstr(help, -chardev))
flags |= QEMUD_CMD_FLAG_CHARDEV;
+if (strstr(help, -enable-nesting))
+flags |= QEMUD_CMD_FLAG_NESTING;
if (strstr(help, -balloon))
flags |= QEMUD_CMD_FLAG_BALLOON;
if (strstr(help, -device))
@@ -3907,6 +3909,9 @@
goto error;
}
}
+if ((qemuCmdFlags QEMUD_CMD_FLAG_NESTING)
+(def-features (1 VIR_DOMAIN_FEATURE_NESTING)))
+ADD_ARG_LIT(-enable-nesting);
/*
* NB, -nographic *MUST* come before any serial, or monitor
@@ -6265,6 +6270,8 @@
fullscreen = 1;
} else if (STREQ(arg, -localtime)) {
def-clock.offset = VIR_DOMAIN_CLOCK_OFFSET_LOCALTIME;
+} else if (STREQ(arg, -enable-nesting)) {
+def-features |= (1 VIR_DOMAIN_FEATURE_NESTING);
} else if (STREQ(arg, -kernel)) {
WANT_VALUE();
if (!(def-os.kernel = strdup(val)))
diff -Naur ../libvirt-0.8.3//src/qemu/qemu_conf.h ./src/qemu/qemu_conf.h
--- ../libvirt-0.8.3//src/qemu/qemu_conf.h 2010-07-28
11:18:15.0 -0300
+++ ./src/qemu/qemu_conf.h 2010-09-01 16:58:29.900876561 -0300
@@ -92,6 +92,7 @@
QEMUD_CMD_FLAG_PCI_CONFIGFD = (1LL 36), /* pci-assign.configfd */
QEMUD_CMD_FLAG_NODEFCONFIG = (1LL 37), /* -nodefconfig */
QEMUD_CMD_FLAG_BOOT_MENU = (1LL 38), /* -boot menu=on
support */
+QEMUD_CMD_FLAG_NESTING = (1LL 39), /* Is the
-enable-nesting flag available */
};
/* Main driver state */
Patch of libvirt 0.8.4:
diff -Naur libvirt-0.8.4/docs/schemas/domain.rng
libvirt-0.8.4.edu/docs/schemas/domain.rng
--- libvirt-0.8.4/docs/schemas/domain.rng 2010-08-31
10:44:13.0 -0300
+++ libvirt-0.8.4.edu/docs/schemas/domain.rng 2010-09-28
14:34:40.626234752 -0300
@@ -1619,6 +1619,11 @@
empty/
/element
/optional
+ optional
+ element name=nesting
+ empty/
+ /element
+ /optional
/interleave
/element
/optional
diff -Naur libvirt-0.8.4/src/conf/domain_conf.c
libvirt-0.8.4.edu/src/conf/domain_conf.c
--- libvirt-0.8.4/src/conf/domain_conf.c2010-08-31
10:44:13.0 -0300
+++ libvirt-0.8.4.edu/src/conf/domain_conf.c2010-09-28
14:35:36.069149447 -0300
@@ -75,7 +75,8 @@
VIR_ENUM_IMPL(virDomainFeature, VIR_DOMAIN_FEATURE_LAST,
acpi,
apic,
- pae)
+ pae,
+ nesting)
VIR_ENUM_IMPL(virDomainLifecycle, VIR_DOMAIN_LIFECYCLE_LAST,
destroy,
diff -Naur libvirt-0.8.4/src/conf/domain_conf.h
libvirt-0.8.4.edu/src/conf/domain_conf.h
--- libvirt-0.8.4/src/conf/domain_conf.h2010-08-31
10:44:13.0 -0300
+++ libvirt-0.8.4.edu/src/conf/domain_conf.h2010-09-28
14:36:11.931054102 -0300
@@ -650,6 +650,7 @@
VIR_DOMAIN_FEATURE_ACPI,
VIR_DOMAIN_FEATURE_APIC,
VIR_DOMAIN_FEATURE_PAE,
+VIR_DOMAIN_FEATURE_NESTING,
VIR_DOMAIN_FEATURE_LAST
};
diff -Naur libvirt-0.8.4/src/qemu/qemu_conf.c
libvirt-0.8.4.edu/src/qemu/qemu_conf.c
--- libvirt-0.8.4/src/qemu/qemu_conf.c 2010-09-10 09:38:13.0 -0300
+++
Re: [libvirt] [PATCH] autogen: added glibtool and pkg-config checks
Hi Justin, On 28 Sep 2010, at 07:24, Justin Clift wrote: On 09/16/2010 03:02 AM, Eric Blake wrote: [adding bug-gnulib] On 09/15/2010 06:36 AM, Justin Clift wrote: OSX MacPorts has libtool named as glibtool, with libtoolize named as glibtoolize. This patch adds support for this, and also adds a check for pkg-config, to warn when it is missing. snip So, NACK to this version of the libvirt patch, and instead let me do some gnulib work... Not to mention that Gary is working on some upstream patches to improve bootstrap modularity, and there is also a request to add 'bootstrap --skip-git' that I need to respond to... Hi guys, Any word on how this is going? I'm all but finished with my rewrite, and I've added --skip-git support too. I'll be too busy for the next couple of weeks to finish testing, but I'm aiming to submit upstream with before the middle of Oct. I expect I'll find a few more opportunities for enhancements, and fix a bug or two before then. If anyone wants a copy of the script as is, just send me a request. All I ask in return is for feedback on how it works for you. Just wanting to get an idea when we can drop the simple override patch for Mac OS X? :) If that was directed at me, I wasn't paying enough attention to the rest of the thread to know what that patch is... ;) Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] cpulimit and kvm process
On Fri, 1 Oct 2010 10:03:28 +0300 Mihamina Rakotomandimby miham...@gulfsat.mg wrote: Manao ahoana, Hello, Bonjour, I would like to launch several KVM guests on a multicore CPU. The number of the KVM process is over the number of physical cores. I would like to limit each KVM process to say... 10% of CPU I first use cpulimit Would you know some better way to limit them? it's in order to avoid 4 VM to hog all the 4 hardware cores. I also use all the livbirt tools, if there si any sol Misaotra, Thanks, Merci. You should be able to limit cpu utilization using cgroups -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt and nested pagind
2010/9/28 Eduardo edua...@freedominterface.org: Good afternoon! Searching on the web, I joint some codes and produced those patches. Now I have a server running perfectly with the following scenario: AMD Phenom 8400 x3; Slackware64 13.1 on a slim and custom 2.6.35.2 Linux; qemu-kvm 0.12.5; libvirt 0.8.4. Daniel posted an alternate patch with a more general, less QEMU specific approach to this: https://www.redhat.com/archives/libvir-list/2010-September/msg00344.html Matthias -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] document authentication with PolicyKit-1
I solved it and thought updating the documentation for PolicyKit 1 would be nice. Patch attached. Is this patch still relevant against the latest sources? If so, would you mind resending it, so we can get it into 0.8.5? Kind of thinking we may have fixed this already. The PolicyKit documentation has recently been updated, to reflect the new(er) way of doing things with it: http://libvirt.org/auth.html#ACL_server_polkit and http://wiki.libvirt.org/page/SSHPolicyKitSetup These pages together go more into detail and offer more examples than my patch did. Just checked Gerd's patch, and the PolicyKit-0 stuff seems useful, as well as the example (which I haven't tested). The PolicyKit-0 stuff was in there before, I just kept it and added PolicyKit-1. I don't think we need the PolicyKit-0 documentation anymore, everyone using current libvirt is most probably also using PolicyKit-1. Kind regards, Gerd -- Address (better: trap) for people I really don't want to get mail from: jo...@cactusamerica.com -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] bug: network lock-out
On 10/06/2010 05:23 PM, Laine Stump wrote: On 10/05/2010 03:53 PM, Zdenek Styblik wrote: I've removed dnsmasq because it was giving away IP addresses, although DHCP has not been defined in XML. I've mentioned this some time ago in an e-mail with poetic subj: dnsmasq, dhcp - bug or feature :) I tried changing my default network to remove the dhcp section, restarted the network, and rebooted a guest to try and acquire an address from DHCP - it failed. Can you do ps -AlF | grep dnsmasq at a time when you see this behavior, and send that. Perhaps there was another dnsmasq hanging around listening on that interface? (I think it's possible that dnsmasq sometimes isn't terminated if libvirtd crashes) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list Hanging dnsmasq was either the case or it has been fixed in 0.8.4. I sometimes suspect dnsmasq doesn't get restarted at all, although libvirtd/network does. Another workaround seems to be eg. range 192.168.1.0/24; 192.168.1.1/24 at interface; leases 192.168.1.1-192.168.1.1. This is from ISC DHCPd where you have to provide leases for pool with static (IP:MAC) hosts. Thanks, Zdenek -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: sty...@turnovfree.net jabber: sty...@jabber.turnovfree.net -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] bug: network lock-out
On 10/07/2010 09:56 AM, Zdenek Styblik wrote: On 10/06/2010 05:23 PM, Laine Stump wrote: On 10/05/2010 03:53 PM, Zdenek Styblik wrote: I've removed dnsmasq because it was giving away IP addresses, although DHCP has not been defined in XML. I've mentioned this some time ago in an e-mail with poetic subj: dnsmasq, dhcp - bug or feature :) I tried changing my default network to remove the dhcp section, restarted the network, and rebooted a guest to try and acquire an address from DHCP - it failed. Can you do ps -AlF | grep dnsmasq at a time when you see this behavior, and send that. Perhaps there was another dnsmasq hanging around listening on that interface? (I think it's possible that dnsmasq sometimes isn't terminated if libvirtd crashes) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list Hanging dnsmasq was either the case or it has been fixed in 0.8.4. I sometimes suspect dnsmasq doesn't get restarted at all, although libvirtd/network does. Another workaround seems to be eg. range 192.168.1.0/24; 192.168.1.1/24 at interface; leases 192.168.1.1-192.168.1.1. This is from ISC DHCPd where you have to provide leases for pool with static (IP:MAC) hosts. Thanks, Zdenek I forgot to say it was connected to virt-manager, thus it might have been a virt-manager bug. I've verified most of this by hand and using virsh, so- Zdenek -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: sty...@turnovfree.net jabber: sty...@jabber.turnovfree.net -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] document authentication with PolicyKit-1
On Thu, Oct 07, 2010 at 09:45:28AM +0200, Gerd v. Egidy wrote: I solved it and thought updating the documentation for PolicyKit 1 would be nice. Patch attached. Is this patch still relevant against the latest sources? If so, would you mind resending it, so we can get it into 0.8.5? Kind of thinking we may have fixed this already. The PolicyKit documentation has recently been updated, to reflect the new(er) way of doing things with it: http://libvirt.org/auth.html#ACL_server_polkit and http://wiki.libvirt.org/page/SSHPolicyKitSetup These pages together go more into detail and offer more examples than my patch did. Just checked Gerd's patch, and the PolicyKit-0 stuff seems useful, as well as the example (which I haven't tested). The PolicyKit-0 stuff was in there before, I just kept it and added PolicyKit-1. I don't think we need the PolicyKit-0 documentation anymore, everyone using current libvirt is most probably also using PolicyKit-1. As long as the code for pk0 exists, we should keep the corresponding documentation. I don't want to delete the code yet, because it really hasn't been that long since it was in use Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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 1/5] nwfilter: Extend XML parser and generator to support state attribute
On 10/06/2010 11:38 AM, Daniel Veillard wrote: On Fri, Oct 01, 2010 at 08:28:50PM -0400, Stefan Berger wrote: The patch below extends the XML parser and generator so that every l3 protocol now can have a state attribute. Signed-off-by: Stefan Bergerstef...@us.ibm.com Hum, I don't see that much parsing in there, certainly some XML formatter but the patch loos fine to me, ACK, Pushed this and the rest of the series. Stefan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] [DOCS] nwfilter: Add 2nd example to the html docs
On 10/06/2010 03:14 PM, Eric Blake wrote: On 10/06/2010 12:56 PM, Stefan Berger wrote: + h3a name=nwfwriteexample2ndSecond example custom filter/a/h3 + p + In this example we now want to build a similar filter as in the + example above, but extend the list of requirements with an + ftp server located inside the VM. Further, we will be using features + that have been added in span class=sinceversion 0.8.5/span. + The requirements for this filter shall be: s/shall be/are/ + The 1st solution makes use of the codestate/code attribute of + the TCP protocol that gives us a hook into the connection tracking + framework of the Linux host. For the VM-initiated ftp data connection + (ftp active mode) we use the codeRELATED/code state that allows + us to detect that the VM-initated ftp data connection is a consequence of s/initated/initiated/ + ( or 'has a relationship with' ) an existing ftp control connection, + thus we want to allow it to let packets + pass the firewall. The codeRELATED/code state, however, is only + valid for the very first packet of the outgoing TCP connection for the + ftp data path. Afterwards, the state to compare against is + codeESTABLISHED/code, which then applies equally + to the incoming and outgoing direction. All this is related to the ftp + data traffic origination from TCP port 20 of the VM. This then leads to s/origination/originating/ + p + Before trying out a filter using the codeRELATED/code state, + you have to make sure that the approriate connection tracking module s/approriate/appropriate/ Other than those nits, looks good to me. I corrected the text and pushed it. Stefan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Added new attribute security_model to filesystem element
On Sat, Sep 25, 2010 at 12:04:11AM +0530, Harsh Prateek Bora wrote:
This patch introduces new attribute to filesystem element
to support customizable security_model for mount type.
Valid security_model are: passthrough, mapped and none.
Usage:
filesystem type='mount' security_model='passthrough'
I'd like to think of a different name for this, because
'security_model' is already used in libvirt in the context
of sVirt and I think it'd be better to avoid the same
terminology. I've not got any ideas just yet, but I'll
think of some
source dir='/export/to/guest'/
target dir='mount_tag'/
/filesystem
Note: This patch is based on Daniel's patch to support 9pfs.
It shall be applied after applying Daniel's patch to support 9pfs.
Signed-off-by: Harsh Prateek Bora ha...@linux.vnet.ibm.com
---
docs/schemas/domain.rng |7 +++
src/conf/domain_conf.c | 30 --
src/conf/domain_conf.h | 10 ++
src/qemu/qemu_conf.c| 11 +--
4 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng
index ccb8cf3..43a292d 100644
--- a/docs/schemas/domain.rng
+++ b/docs/schemas/domain.rng
@@ -761,6 +761,13 @@
/choice
optional
ref name=address/
+attribute name=security_model
+choice
+ valuepassthrough/value
+ valuemapped/value
+ valuenone/value
+/choice
+/attribute
/optional
/element
/define
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e05d5d7..a9881d1 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -161,6 +161,12 @@ VIR_ENUM_IMPL(virDomainFS, VIR_DOMAIN_FS_TYPE_LAST,
file,
template)
+VIR_ENUM_IMPL(virDomainFSSecurityModel, VIR_DOMAIN_FS_SECURITY_LAST,
+ passthrough,
+ mapped,
+ none)
+
+
VIR_ENUM_IMPL(virDomainNet, VIR_DOMAIN_NET_TYPE_LAST,
user,
ethernet,
@@ -1847,6 +1853,7 @@ virDomainFSDefParseXML(xmlNodePtr node,
char *type = NULL;
char *source = NULL;
char *target = NULL;
+char *security_model;
if (VIR_ALLOC(def) 0) {
virReportOOMError();
@@ -1864,6 +1871,17 @@ virDomainFSDefParseXML(xmlNodePtr node,
def-type = VIR_DOMAIN_FS_TYPE_MOUNT;
}
+security_model = virXMLPropString(node, security_model);
+if (security_model) {
+if ((def-security_model =
virDomainFSSecurityModelTypeFromString(security_model)) 0) {
+virDomainReportError(VIR_ERR_INTERNAL_ERROR,
+ _(unknown security model '%s'),
security_model);
+goto error;
+}
+} else {
+def-security_model = VIR_DOMAIN_FS_SECURITY_PASSTHROUGH;
+}
+
cur = node-children;
while (cur != NULL) {
if (cur-type == XML_ELEMENT_NODE) {
@@ -5602,6 +5620,7 @@ virDomainFSDefFormat(virBufferPtr buf,
int flags)
{
const char *type = virDomainFSTypeToString(def-type);
+const char *sec_model =
virDomainFSSecurityModelTypeToString(def-security_model);
if (!type) {
virDomainReportError(VIR_ERR_INTERNAL_ERROR,
@@ -5609,9 +5628,16 @@ virDomainFSDefFormat(virBufferPtr buf,
return -1;
}
+ if (!sec_model) {
+virDomainReportError(VIR_ERR_INTERNAL_ERROR,
+ _(unexpected security model %d),
def-security_model);
+return -1;
+}
+
+
virBufferVSprintf(buf,
- filesystem type='%s'\n,
- type);
+ filesystem type='%s' security_model='%s'\n,
+ type, sec_model);
if (def-src) {
switch (def-type) {
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 7195c04..6adf027 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -236,10 +236,20 @@ enum virDomainFSType {
VIR_DOMAIN_FS_TYPE_LAST
};
+/* Filesystem mount security model */
+enum virDomainFSSecurityModel {
+VIR_DOMAIN_FS_SECURITY_PASSTHROUGH,
+VIR_DOMAIN_FS_SECURITY_MAPPED,
+VIR_DOMAIN_FS_SECURITY_NONE,
+
+VIR_DOMAIN_FS_SECURITY_LAST
+};
What is the difference between 'PASSTHROUGH' mode
and 'NONE' ? IIUC, 'PASSTHROUGH' just lets the uid/gid
and mode appear in the guest unchanged, which seems
to be just what 'NONE' would do too.
Daniel
--
|: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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
Re: [libvirt] Using -netdev with qemu/kvm rather than old style
On Wed, Oct 06, 2010 at 12:40:00PM -0600, Pete Ashdown wrote: I have 0.8.3 installed and my net devices are still being defined via -net rather than -netdev. I have found that using the latter allows my ethernet to properly offload and gives a 35% performance gain. Looking through the libvirt code I find in qemu_conf.c: /* Possible combinations * * 1. Old way: -net nic,model=e1000,vlan=1 -net tap,vlan=1 * 2. Semi-new: -device e1000,vlan=1-net tap,vlan=1 * 3. Best way: -netdev type=tap,id=netdev1 -device e1000,id=netdev1 * * NB, no support for -netdev without use of -device */ How do I convince virsh/libvirt to use #3, the Best way? This option remains disabled until QEMU 0.13 is released. We did briefly enable it for QEMU 0.12.x, but then discovered that various aspects of it are broken in that release, in particular hotplug/unplug. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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 v3 01/13] Adding structure and defines for virDomainSet/GetMemoryParameters
On Tue, Sep 28, 2010 at 03:26:15PM +0530, Nikunj A. Dadhania wrote: + +/* Set memory tunables for the domain*/ +int virDomainSetMemoryParameters(virDomainPtr domain, + virMemoryParameterPtr params, + int nparams); +/* Get memory tunables for the domain, caller allocates the params if nparams + * is zero and params is NULL, the domain returns back number of parameters + * supported by the HV. This could be used by the caller to allocate the + * memory and call with params structure allocated. + */ +int virDomainGetMemoryParameters(virDomainPtr domain, + virMemoryParameterPtr params, + int *nparams); We should add an 'unsigned int flags' parameter to both of these, so we can extend their semantics in the future. The comment here can be moved to the libvirt.c file so it gets picked up in the API docs. Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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] RFC: automatic setting of ip_forwarding (or not)
On 10/04/2010 08:13 PM, Laine Stump wrote: On 10/01/2010 04:44 PM, Zdenek Styblik wrote: [...sysclt stuff...] On both RHEL and Fedora, both the network and NetworkManager services (and others, eg see the bug reports a bit further down in this reply) Hm, how to put it. I, for myself, don't like idea of fixing something just because of other buggy applications. But this expression might be wrong - it is probably wrong expression indeed. run sysctl with -p to reload all non-kernel-default settings when they are started, and Fedora puts net.ipv4.ip_forward=0 into /etc/sysctl.conf at install time. So at boot time, both of those Yes, well you can change that, although this would turn on IP forward by default. [...] Exactly one of my points. libvirt really wants (no, *needs*) this to be on for virtual networks, but it's very likely there was a reason for it being turned off, so the admin should at the very least be alerted that it's being turned on, or the fact that it's off should be logged in some way to assure it gets the admin's attention so they can make the proper judgement call. Only thing that popped in my head was: admin should read documentation :( [...more of sysctl.conf...] [...] Two Active bug reports that I'm aware of offhand (one for RHEL and one for Fedora): [...] The first two prompted a short discussion on an internal Red Hat call, first a brief mention of it a month or two ago, and again in a similar call last week, where the main point of the conversation was 1) this is a problem, 2) we should fix it, 3) here's a list of some ideas, 4) we need to post these ideas on libvir-list to start a conversation in the libvirt community about the best course of action. I'm not sure how else we could have proceeded that would have made it less of a surprise to you. (Of course now that I've hopefully better articulated myself, you may be less surprised :-) Reference to these(or anything else) would help. ;) You may be reading more into this than is there - the discussion is newly started, no code has even been written yet (much less patches posted, or pushed), and none of the proposed changes are as sweeping as you may think. Well, I haven't thought about such possibility in the first place. It sounds like we agree on at least a couple of important points: 1) the left hand should know what the right hand is doing and 2) if ip_forward is set to 0, that was likely done for a reason, so we shouldn't silently modify it. it. Beyond that, is a point that is really just a fact, not an opinion: 3) libvirt's virtual networks won't work unless ip_forward is turned on. The current code is only compatible with 1 of those 3; we need to agree on a method to satisfy all of them. Are you voting for my proposal (1) in the original mail? (do nothing), or do you have another idea? To get back to original points/summary: I think the important things to accomplish are: 1) Avoid having networking magically stop working when someone else reloads sysctl.conf I think this can't be guaranteed unless periodical polling. I mean, it doesn't(well doesn't) matter if you modify /etc/sysctl.conf or 'echo 1' into /proc/...; it still can be turned off. More, the point is network can magically stop working whenever I or anybody please. This is not only about /etc/sysctl.conf, I'm afraid. Right, the question is what's better (the best) approach here. echo 1 into /proc/... only when it's needed and note in documentation about this? 2) Make sure that the admin realizes that ip_forward is being turned on (or needs to be turned on). Documentation? 3) If we're going to turn it on, at least don't do it if it's not needed. I agree. 4) Something else we need to consider is the ability to provision a host for proper guest networking purely through the libvirt API, and if we were to stop turning on ip_forward automatically when a network was started, that wouldn't work anymore (unless ip_forward happened to be turned on already). I don't fully understand it, thus - I don't know :) (BTW, the firewall rules added for virtual networks suffer from a similar problem - because they're loaded into the kernel directly with the iptables command, there is no external record of them, and some other process reloading the firewall will flush out all libvirt's rules, leaving the guests with nonworking networking. But that discussion is a bigger one, that probably needs to go outside just libvirt, so I'll avoid that here...) Once again I'm going to troll about this and bundled everything inside one thing. As I've said many times already, I'm pro-external things as DHCP, firewall ... whatever. On the other hand, I realize the point of libvirt might be to ship out-of-the-box solution like it is now. I mean, tell admin what to add if he wants this and that; or make external hooks, or whatever. That's hard to say, because there is no one ultimate solution. I hope this
Re: [libvirt] [PATCH v3 02/13] Adding virDomainSetMemoryParameters and virDomainGetMemoryParameters API
On Tue, Sep 28, 2010 at 03:26:20PM +0530, Nikunj A. Dadhania wrote: diff --git a/src/libvirt.c b/src/libvirt.c index ca383ba..0708e36 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -3000,6 +3000,109 @@ error: } /** + * virDomainSetMemoryParameters: + * @domain: pointer to domain object + * @params: pointer to memory parameter objects + * @nparams: number of memory parameter (this value should be same or + * less than the number of parameters supported) + * + * Change the memory tunables + * This function requires privileged access to the hypervisor. + * FIXME: Should we make changes to the domain configuration file as well? If we add the 'unsigned int flags' parameter, then we can later extend this with flags to specify whether the persistent config is changed at same time as the live config. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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 v3 03/13] Adds xml entries for memory tunables
On Tue, Sep 28, 2010 at 03:26:25PM +0530, Nikunj A. Dadhania wrote: From: Nikunj A. Dadhania nik...@linux.vnet.ibm.com The patch adds xml entries to the domain.rng file. v2: + Fix typo min_guarantee Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com --- docs/schemas/domain.rng | 31 +++ 1 files changed, 31 insertions(+), 0 deletions(-) ACK, looks fine Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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 v3 04/13] XML parsing for memory tunables
On Tue, Sep 28, 2010 at 03:26:30PM +0530, Nikunj A. Dadhania wrote: From: Nikunj A. Dadhania nik...@linux.vnet.ibm.com Adding parsing code for memory tunables in the domain xml file v2: + Fix typo min_guarantee Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com --- src/conf/domain_conf.c | 50 +--- src/conf/domain_conf.h | 12 --- src/esx/esx_vmx.c | 30 +- src/lxc/lxc_controller.c |2 +- src/lxc/lxc_driver.c | 12 +-- src/openvz/openvz_driver.c |8 --- src/qemu/qemu_conf.c |8 --- src/qemu/qemu_driver.c | 18 src/test/test_driver.c | 12 +-- src/uml/uml_conf.c |2 +- src/uml/uml_driver.c | 14 ++-- 11 files changed, 104 insertions(+), 64 deletions(-) ACK, looks fine, though it'd be good to add one or two example data files to tests/qemuxml2xmltest.c to ensure that we roundtrip through the XML parser+formatter correctly. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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 v3 04/13] XML parsing for memory tunables
On Mon, Oct 04, 2010 at 12:47:22PM +0530, Nikunj A. Dadhania wrote: On Mon, 4 Oct 2010 12:16:42 +0530, Balbir Singh bal...@linux.vnet.ibm.com wrote: * Nikunj A. Dadhania nik...@linux.vnet.ibm.com [2010-09-28 15:26:30]: snip +/* Extract other memory tunables */ +if (virXPathULong(string(./memtune/hard_limit), ctxt, + def-mem.hard_limit) 0) +def-mem.hard_limit = 0; + +if (virXPathULong(string(./memtune/soft_limit[1]), ctxt, + def-mem.soft_limit) 0) +def-mem.soft_limit = 0; + +if (virXPathULong(string(./memtune/min_guarantee[1]), ctxt, + def-mem.min_guarantee) 0) +def-mem.min_guarantee = 0; + +if (virXPathULong(string(./memtune/swap_hard_limit[1]), ctxt, + def-mem.swap_hard_limit) 0) +def-mem.swap_hard_limit = 0; + Quick question, does 0 represent invalid values? If configuration file does not provide any value, we set this to 0, we do not call the lower layer calls in this case. I'd presume you'd want to use something like -1. We support unsigned long long for the values to be set (64 bit signed), unlimited translates to 2^63 - 1, is ULong sufficient to represent that value? The unit here is KB, so we can have till 2^42 bytes. So to answer you question, no it does not represent 64 bit signed. I guess this should not be an issue to support if needed. I understand that in case of cgroup unlimited is (-1), but again that would be cgroup specific at this level. I need to think of some way to address this independent of the lower layer. +unsigned long hard_limit; +unsigned long soft_limit; +unsigned long min_guarantee; +unsigned long swap_hard_limit; The hard_limit, soft_limit, swap_hard_limit are s64 and the value is in bytes. What is the unit supported in this implementation? Actually if libvirt is built on 32bit these aren't big enough - make them into 'unsigned long long' data types I reckon. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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 v3 06/13] Implement driver interface domainSetMemoryParamters for QEmu
On Tue, Sep 28, 2010 at 03:26:41PM +0530, Nikunj A. Dadhania wrote: From: Nikunj A. Dadhania nik...@linux.vnet.ibm.com Driver interface for setting memory hard_limit, soft_limit and swap hard_limit. v2: + Use #define string constants for hard_limit, etc. + fix typo: min_guarantee Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com --- src/qemu/qemu_driver.c | 94 +++- 1 files changed, 93 insertions(+), 1 deletions(-) ACK, looks fine. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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] RFC: automatic setting of ip_forwarding (or not)
On 10/07/2010 10:48 PM, Zdenek Styblik wrote: On 10/04/2010 08:13 PM, Laine Stump wrote: snip Exactly one of my points. libvirt really wants (no, *needs*) this to be on for virtual networks, but it's very likely there was a reason for it being turned off, so the admin should at the very least be alerted that it's being turned on, or the fact that it's off should be logged in some way to assure it gets the admin's attention so they can make the proper judgement call. Only thing that popped in my head was: admin should read documentation :( Is this the kind of behavioural thing that we should have a reasonable default for, plus allow for it to be configured differently via libvirtd.conf? were_special_really_really_really_please_dont_enable_ipforwarding = 1 :) Once again I'm going to troll about this and bundled everything inside one thing. As I've said many times already, I'm pro-external things as DHCP, firewall ... whatever. On the other hand, I realize the point of libvirt might be to ship out-of-the-box solution like it is now. I mean, tell admin what to add if he wants this and that; or make external hooks, or whatever. That's hard to say, because there is no one ultimate solution. Using the words hooks here makes me wonder if we could do the needed work through having network hook scripts in place (with appropriate bits to call them), and whether it would be a useful way of doing things. (absolutely no idea if it's even feasible. :) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 08/13] Adding memtunables to qemuSetupCgroup
On Tue, Sep 28, 2010 at 03:26:55PM +0530, Nikunj A. Dadhania wrote: From: Nikunj A. Dadhania nik...@linux.vnet.ibm.com QEmu startup would pick up the memory tunables specified in the domain configuration file. Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com --- src/qemu/qemu.conf |4 ++-- src/qemu/qemu_conf.c |3 ++- src/qemu/qemu_driver.c | 27 +++ 3 files changed, 31 insertions(+), 3 deletions(-) ACK, looks fine. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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 v3 09/13] Adding memtunables to libvirt-lxc command
On Tue, Sep 28, 2010 at 03:27:02PM +0530, Nikunj A. Dadhania wrote: From: Nikunj A. Dadhania nik...@linux.vnet.ibm.com libvirt-lxc now configures the hardlimit, softlimit and swaplimit, if specified in the domain xml file or picks up the defaults. Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com --- src/lxc/lxc_controller.c | 22 ++ 1 files changed, 22 insertions(+), 0 deletions(-) ACK Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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 v3 10/13] Implement driver interface domainSetMemoryParamters for LXC
On Tue, Sep 28, 2010 at 03:27:08PM +0530, Nikunj A. Dadhania wrote: From: Nikunj A. Dadhania nik...@linux.vnet.ibm.com Add support in the lxc driver for various memory controllable parameters v2: + Use #define string constants for hard_limit, etc + fix typo: min_guarantee Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com --- src/lxc/lxc_driver.c | 90 +- 1 files changed, 89 insertions(+), 1 deletions(-) ACK, basically the same as the QEMU impl. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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 v3 12/13] Adding memtune command to virsh tool
On Tue, Sep 28, 2010 at 03:27:19PM +0530, Nikunj A. Dadhania wrote:
From: Nikunj A. Dadhania nik...@linux.vnet.ibm.com
The command helps to control the memory/swap parameters for the system, for
eg. hard_limit (max memory the vm can use), soft_limit (limit during memory
contention), swap_hard_limit(max swap the vm can use)
v3:
+ Added call to virDomainGetMemoryParameters and print them.
+ Added virDomainGetMemoryParameters and virDomainSetMemoryParamters to
libvirt_public.syms
v2:
+ Use #define string constants for hard_limit, etc
Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com
---
src/libvirt_public.syms |6 ++
tools/virsh.c | 130
+++
2 files changed, 136 insertions(+), 0 deletions(-)
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index 849c163..fceb516 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -405,4 +405,10 @@ LIBVIRT_0.8.2 {
virDomainCreateWithFlags;
} LIBVIRT_0.8.1;
+LIBVIRT_0.8.5 {
+global:
+virDomainSetMemoryParameters;
+virDomainGetMemoryParameters;
+} LIBVIRT_0.8.2;
This chunk should actually be with the change to 'src/libvirt.c'
in the second patch.
Daniel
--
|: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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 v3 13/13] Remote protocol changes and implements virDomainSet/GetMemoryParameters
On Tue, Sep 28, 2010 at 03:27:24PM +0530, Nikunj A. Dadhania wrote: From: Nikunj A. Dadhania nik...@linux.vnet.ibm.com v3: * Squased all the remote driver changes to one single big patch and auto-generated is around 40% * Implements domainSetMemoryParameters and domainGetMemoryParameters for remote driver daemon/remote.c src/remote/remote_driver.c * Auto generate the files using rpcgen and helper scripts in daemon/ directory src/remote/remote_protocol.x daemon/remote_dispatch_args.h daemon/remote_dispatch_prototypes.h daemon/remote_dispatch_ret.h daemon/remote_dispatch_table.h src/remote/remote_protocol.c src/remote/remote_protocol.h Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com --- daemon/remote.c | 158 +++ daemon/remote_dispatch_args.h |2 daemon/remote_dispatch_prototypes.h | 16 daemon/remote_dispatch_ret.h|1 daemon/remote_dispatch_table.h | 10 ++ src/remote/remote_driver.c | 148 - src/remote/remote_protocol.c| 84 +++ src/remote/remote_protocol.h| 56 src/remote/remote_protocol.x| 42 + 9 files changed, 514 insertions(+), 3 deletions(-) ACK, looks ok Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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] [libvirt-tck] [RFC] 802.1Qbg test scripts
On Wed, 2010-10-06 at 12:52 +0100, Daniel P. Berrange wrote:
I don't like this approach. JUst add an optional parameter
to the build_domain methods
my $mode = @_ ? shift : bridge;
eg so it default to traditional bridging, but you can pass
in 'vepa' if you desire to change it. Or something like
that.
Thanks for the feedback. The changes are in the attached new versions of
the patches. It would be great if you could push at least
modify_library_functions.patch to the git.
--
Best regards,
Gerhard Stenzel,
---
IBM Deutschland Research Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
Index: libvirt-tck/scripts/nwfilter/300-vsitype.t
===
--- /dev/null
+++ libvirt-tck/scripts/nwfilter/300-vsitype.t
@@ -0,0 +1,71 @@
+# -*- perl -*-
+#
+# Copyright (C) 2010 IBM Corp.
+#
+# This program is free software; You can redistribute it and/or modify
+# it under the GNU General Public License as published by the Free
+# Software Foundation; either version 2, or (at your option) any
+# later version
+#
+# The file LICENSE distributed along with this file provides full
+# details of the terms and conditions
+#
+
+=pod
+
+=head1 NAME
+
+nwfilter/300-vsitype.t - verify VSI informatio
+
+=head1 DESCRIPTION
+
+The test case validates that the corrrect VSI is set in the adjacent switch
+
+=cut
+
+use strict;
+use warnings;
+
+use Test::More tests = 3;
+
+use Sys::Virt::TCK;
+use Sys::Virt::TCK::NetworkHelpers;
+use Test::Exception;
+use Net::SSH::Perl;
+use File::Spec::Functions qw(catfile catdir rootdir);
+
+my $tck = Sys::Virt::TCK-new();
+my $conn = eval { $tck-setup(); };
+BAIL_OUT failed to setup test harness: $@ if $@;
+END {
+$tck-cleanup if $tck;
+}
+
+# creating domain
+my $dom1;
+my $dom_name =tck8021Qbgtest;
+
+# speficy mode=vepa for a direct interface
+$dom1 = prepare_test_disk_and_vm($tck, $conn, $dom_name, vepa);
+$dom1-create();
+
+ok($dom1-get_id() 0, running domain has an ID 0);
+my $xml = $dom1-get_xml_description;
+diag $xml;
+my $mac1 = get_first_macaddress($dom1);
+diag mac is $mac1;
+
+sleep(30);
+
+# check vsi information
+diag Verifying VSI information using lldptool;
+my $lldptool = `/usr/sbin/lldptool -t -i eth2 -V vdp mode`;
+diag $lldptool;
+# check if instance is listed
+ok($lldptool =~ instance, check instance);
+ok($lldptool =~ $mac1, check mac as well);
+
+
+shutdown_vm_gracefully($dom1);
+
+exit 0;
Index: libvirt-tck/lib/Sys/Virt/TCK/DomainBuilder.pm
===
--- libvirt-tck.orig/lib/Sys/Virt/TCK/DomainBuilder.pm
+++ libvirt-tck/lib/Sys/Virt/TCK/DomainBuilder.pm
@@ -410,8 +410,25 @@ sub as_xml {
$w-emptyTag(mac,
address = $interface-{mac});
- $w-emptyTag(source,
- network = $interface-{source});
+
+ if( $interface-{dev}) {
+ $w-emptyTag(source,
+ dev = $interface-{dev},
+ mode = $interface-{mode});
+ } else {
+ $w-emptyTag(source,
+ network = $interface-{source});
+ }
+ if( $interface-{virtualport}) {
+ $w-startTag(virtualport,
+ type = $interface-{virtualport});
+ $w-emptyTag(parameters,
+ managerid = '1',
+ typeid = '2',
+ typeidversion = '3',
+ instanceid = '4000----');
+ $w-endTag(virtualport);
+ }
$w-emptyTag(model,
type = $interface-{model});
if( $interface-{filterref}) {
Index: libvirt-tck/lib/Sys/Virt/TCK/NetworkHelpers.pm
===
--- libvirt-tck.orig/lib/Sys/Virt/TCK/NetworkHelpers.pm
+++ libvirt-tck/lib/Sys/Virt/TCK/NetworkHelpers.pm
@@ -42,6 +42,7 @@ sub build_cdrom_ks_image {
sub build_domain{
my $tck = shift;
my $domain_name = shift;
+my $mode = @_ ? shift : bridge;
my $guest;
my $mac = 52:54:00:11:11:11;
@@ -50,10 +51,19 @@ sub build_domain{
my $filterref = clean-traffic;
my $network = network;
my $source = default;
+my $dev = eth2;
+my $virtualport;
my ($cdrom, $ksurl) = build_cdrom_ks_image($tck);
my $guest = $tck-generic_domain($domain_name);
+
+# change the type of network connection for 802.1Qbg tests
+if ($mode eq vepa) {
+ $network =direct;
+ $virtualport = 802.1Qbg;
+ }
+
# We want a bigger disk than normal
$guest-rmdisk();
my $diskpath = $tck-create_sparse_disk(nwfilter, main.img, 2048);
@@ -79,12 +89,23 @@ sub build_domain{
} else {
diag Do normal boot;
$guest-clear_kernel_initrd_cmdline();
- $guest-interface(type = $network,
- source = $source,
- model = $model,
- mac = $mac,
- filterref = $filterref);
+ if ($mode eq vepa) {
+ $guest-interface(type = $network,
+ source = $source,
+
Re: [libvirt] [PATCH] Added new attribute security_model to filesystem element
On 10/07/2010 10:17 PM, Daniel P. Berrange wrote: On Sat, Sep 25, 2010 at 12:04:11AM +0530, Harsh Prateek Bora wrote: This patch introduces new attribute to filesystem element to support customizable security_model for mount type. Valid security_model are: passthrough, mapped and none. Usage: filesystem type='mount' security_model='passthrough' I'd like to think of a different name for this, because 'security_model' is already used in libvirt in the context of sVirt and I think it'd be better to avoid the same terminology. I've not got any ideas just yet, but I'll think of some mount_security mount_security_type mount_security_mode (mode sounds too similar to model tho maybe) ? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: automatic setting of ip_forwarding (or not)
On Fri, Oct 01, 2010 at 02:46:34PM -0400, Laine Stump wrote: Currently libvirt will turn on net.ipv4.ip_forward by writing 1\n to /proc/sys/net/ipv4/ip_forward whenever a virtual network of with a forward mode of nat or route is started. This is problematic for two reasons: 1) /etc/sysctl.conf is not updated with this information, so any other process reprocessing /etc/sysctl.conf (with sysctl -a -p) will potentially turn ip forward back to 0, leaving libvirt-created virtual networks in a non-working state, and 2) it's possible the administrator turned off ip forwarding on purpose for security reasons, and our silently turning it on leaves them mistakenly believing it is still off. We've discussed a few ways of remedying this situation lately, and I thought I should summarize all the mentioned ideas, and take a poll to try and determine which way we should fix this. 1) Leave it as is. The simplest solution, but has the problems outlines above. 2) Turn it on in the same place, but do it by writing net.ipv4.ip_forward = 1 to /etc/sysctl.conf and calling sysctl -a -p. This gives us the same behavior as currently, but with the advantages that a) our change to the config is documented in /etc/sysctl.conf and b) virtual networked guests won't suddenly have their network fail when some other process runs sysconfig -a -p. However, it seems rather drastic to be turning this on every time a virtual network is started, especially without alerting the admin that this has been done. We have to bear in mind that this functionality has existed in libvirt for 4 years now and as such we really don't want to cause a regression in behaviour for people. Option 1 does have the problem you mention, but for the vast majority of people it has been working for years they'll be annoyed if we break it. To me, this ties back in with the problem of managing the firewall in general. Toggling of ip forward should be something done by the firewall management serviceof which none exists yet. There is current active development work to provide a dynamic firewall management service in Fedora. This is to address the needs of libvirt, NetworkManager, CUPs, System-D all of whom are suffering from the current lack of firewall management. I expect the ip_forward setting will fall under this service. My preference would thus be to leave current libvirt behaviour unchanged and wait to see how the firewall mgmt work plays out 3) Whenever a virtual network that would require ip_forward = 1 to operate properly is started (ie at libvirtd start time, and when a network is newly defined), check if it's currently on, and if not log a warning message, informing the admin that they should turn on ip_forward in sysctl.conf and reload it in order to have properly working networking. This would assure that the admin was informed of the necessity for ip_forward, but eliminate the possibility of two processes fighting over the setting of ip_forward, leaving it up to the admin to make the decision and do the right thing. On the other hand, it would prevent libvirt's networking from just working on a new install. This would be a major regression for anyone upgrading their libvirt install. 4) Turn ip_forward on during libvirt install. This one doesn't make sense to me, because you don't know at the time of libvirt install whether or not the installation if going to end up with any virtual networks that need forwarding. Agreed, this is the wrong time/place. 5) Make ip_forward a tunable in /etc/libvirt/libvirtd.conf, and set it accordingly every time libvirtd is started. I don't know if this makes sense either - if you have NATed or routed virtual networks, you will need ip_forward=1 for them to work properly, and if you don't have them, you don't care, so it's really redundant. Yeah, doesn't make much sense to have to edit a config file to change a variable in a different config file. It is no better than telling people to edit sysctl.conf. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.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] [libvirt-tck] [RFC] 802.1Qbg test scripts
On Thu, Oct 07, 2010 at 02:07:23PM +0200, Gerhard Stenzel wrote:
On Wed, 2010-10-06 at 12:52 +0100, Daniel P. Berrange wrote:
I don't like this approach. JUst add an optional parameter
to the build_domain methods
my $mode = @_ ? shift : bridge;
eg so it default to traditional bridging, but you can pass
in 'vepa' if you desire to change it. Or something like
that.
Thanks for the feedback. The changes are in the attached new versions of
the patches. It would be great if you could push at least
modify_library_functions.patch to the git.
--
Best regards,
Gerhard Stenzel,
---
IBM Deutschland Research Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
Index: libvirt-tck/scripts/nwfilter/300-vsitype.t
===
--- /dev/null
+++ libvirt-tck/scripts/nwfilter/300-vsitype.t
@@ -0,0 +1,71 @@
+# -*- perl -*-
+#
+# Copyright (C) 2010 IBM Corp.
+#
+# This program is free software; You can redistribute it and/or modify
+# it under the GNU General Public License as published by the Free
+# Software Foundation; either version 2, or (at your option) any
+# later version
+#
+# The file LICENSE distributed along with this file provides full
+# details of the terms and conditions
+#
+
+=pod
+
+=head1 NAME
+
+nwfilter/300-vsitype.t - verify VSI informatio
+
+=head1 DESCRIPTION
+
+The test case validates that the corrrect VSI is set in the adjacent switch
+
+=cut
+
+use strict;
+use warnings;
+
+use Test::More tests = 3;
+
+use Sys::Virt::TCK;
+use Sys::Virt::TCK::NetworkHelpers;
+use Test::Exception;
+use Net::SSH::Perl;
+use File::Spec::Functions qw(catfile catdir rootdir);
+
+my $tck = Sys::Virt::TCK-new();
+my $conn = eval { $tck-setup(); };
+BAIL_OUT failed to setup test harness: $@ if $@;
+END {
+$tck-cleanup if $tck;
+}
Since most systems won't yet have lldptool present, you should
surround the entire test from here onwards in a big 'SKIP : {}'
block. eg
SKIP: {
skip lldptool not present, 3 unless -e /usr/sbin/lldptool;
.
+
+# creating domain
+my $dom1;
+my $dom_name =tck8021Qbgtest;
+
+# speficy mode=vepa for a direct interface
+$dom1 = prepare_test_disk_and_vm($tck, $conn, $dom_name, vepa);
+$dom1-create();
+
+ok($dom1-get_id() 0, running domain has an ID 0);
+my $xml = $dom1-get_xml_description;
+diag $xml;
+my $mac1 = get_first_macaddress($dom1);
+diag mac is $mac1;
+
+sleep(30);
+
+# check vsi information
+diag Verifying VSI information using lldptool;
+my $lldptool = `/usr/sbin/lldptool -t -i eth2 -V vdp mode`;
+diag $lldptool;
+# check if instance is listed
+ok($lldptool =~ instance, check instance);
+ok($lldptool =~ $mac1, check mac as well);
+
+
+shutdown_vm_gracefully($dom1);
+
+exit 0;
};
This will ensure that the TCK simply skips over the test
rather than showing a failure
Index: libvirt-tck/lib/Sys/Virt/TCK/DomainBuilder.pm
===
--- libvirt-tck.orig/lib/Sys/Virt/TCK/DomainBuilder.pm
+++ libvirt-tck/lib/Sys/Virt/TCK/DomainBuilder.pm
@@ -410,8 +410,25 @@ sub as_xml {
$w-emptyTag(mac,
address = $interface-{mac});
- $w-emptyTag(source,
- network = $interface-{source});
+
+ if( $interface-{dev}) {
+ $w-emptyTag(source,
+ dev = $interface-{dev},
+ mode = $interface-{mode});
+ } else {
+ $w-emptyTag(source,
+ network = $interface-{source});
+ }
+ if( $interface-{virtualport}) {
+ $w-startTag(virtualport,
+ type = $interface-{virtualport});
+ $w-emptyTag(parameters,
+ managerid = '1',
+ typeid = '2',
+ typeidversion = '3',
+ instanceid = '4000----');
+ $w-endTag(virtualport);
+ }
$w-emptyTag(model,
type = $interface-{model});
if( $interface-{filterref}) {
Index: libvirt-tck/lib/Sys/Virt/TCK/NetworkHelpers.pm
===
--- libvirt-tck.orig/lib/Sys/Virt/TCK/NetworkHelpers.pm
+++ libvirt-tck/lib/Sys/Virt/TCK/NetworkHelpers.pm
@@ -42,6 +42,7 @@ sub build_cdrom_ks_image {
sub build_domain{
my $tck = shift;
my $domain_name = shift;
+my $mode = @_ ? shift : bridge;
my $guest;
my $mac = 52:54:00:11:11:11;
@@ -50,10 +51,19 @@ sub build_domain{
my $filterref = clean-traffic;
my $network = network;
my $source = default;
+my
Re: [libvirt] RFC: automatic setting of ip_forwarding (or not)
On 10/07/2010 01:57 PM, Justin Clift wrote: On 10/07/2010 10:48 PM, Zdenek Styblik wrote: On 10/04/2010 08:13 PM, Laine Stump wrote: snip Exactly one of my points. libvirt really wants (no, *needs*) this to be on for virtual networks, but it's very likely there was a reason for it being turned off, so the admin should at the very least be alerted that it's being turned on, or the fact that it's off should be logged in some way to assure it gets the admin's attention so they can make the proper judgement call. Only thing that popped in my head was: admin should read documentation :( Is this the kind of behavioural thing that we should have a reasonable default for, plus allow for it to be configured differently via libvirtd.conf? were_special_really_really_really_please_dont_enable_ipforwarding = 1 :) Umm I don't know, but this feels as being somewhat out of the context. Ok, I don't think more log bogus will solve anything. Admin should know what software does; software documentation should clearly state what software does and does not. I really don't know what else to say about proposed point :) Once again I'm going to troll about this and bundled everything inside one thing. As I've said many times already, I'm pro-external things as DHCP, firewall ... whatever. On the other hand, I realize the point of libvirt might be to ship out-of-the-box solution like it is now. I mean, tell admin what to add if he wants this and that; or make external hooks, or whatever. That's hard to say, because there is no one ultimate solution. Using the words hooks here makes me wonder if we could do the needed work through having network hook scripts in place (with appropriate bits to call them), and whether it would be a useful way of doing things. (absolutely no idea if it's even feasible. :) Well, it might not be terminus technicus. I also see that I have unfinished point here. What I meant was and is that eg. DCC has in documentation what rules you have/should add into your firewall to make DCC to work. Hooks as external shell or whatever scripts - truly, I don't know, although that was point of some sort. Zdenek -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: sty...@turnovfree.net jabber: sty...@jabber.turnovfree.net -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-tck] [RFC] 802.1Qbg test scripts
On Thu, 2010-10-07 at 13:23 +0100, Daniel P. Berrange wrote:
Since most systems won't yet have lldptool present, you should
surround the entire test from here onwards in a big 'SKIP : {}'
block. eg
cool .. V3 attached
--
Best regards,
Gerhard Stenzel,
---
IBM Deutschland Research Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
Index: libvirt-tck/scripts/nwfilter/300-vsitype.t
===
--- /dev/null
+++ libvirt-tck/scripts/nwfilter/300-vsitype.t
@@ -0,0 +1,74 @@
+# -*- perl -*-
+#
+# Copyright (C) 2010 IBM Corp.
+#
+# This program is free software; You can redistribute it and/or modify
+# it under the GNU General Public License as published by the Free
+# Software Foundation; either version 2, or (at your option) any
+# later version
+#
+# The file LICENSE distributed along with this file provides full
+# details of the terms and conditions
+#
+
+=pod
+
+=head1 NAME
+
+nwfilter/300-vsitype.t - verify VSI informatio
+
+=head1 DESCRIPTION
+
+The test case validates that the corrrect VSI is set in the adjacent switch
+
+=cut
+
+use strict;
+use warnings;
+
+use Test::More tests = 3;
+
+use Sys::Virt::TCK;
+use Sys::Virt::TCK::NetworkHelpers;
+use Test::Exception;
+use Net::SSH::Perl;
+use File::Spec::Functions qw(catfile catdir rootdir);
+
+my $tck = Sys::Virt::TCK-new();
+my $conn = eval { $tck-setup(); };
+BAIL_OUT failed to setup test harness: $@ if $@;
+END {
+$tck-cleanup if $tck;
+}
+
+SKIP: {
+ skip lldptool not present, 3 unless -e /usr/sbin/lldptool;
+
+# creating domain
+ my $dom1;
+ my $dom_name =tck8021Qbgtest;
+
+# speficy mode=vepa for a direct interface
+ $dom1 = prepare_test_disk_and_vm($tck, $conn, $dom_name, vepa);
+ $dom1-create();
+
+ ok($dom1-get_id() 0, running domain has an ID 0);
+ my $xml = $dom1-get_xml_description;
+ diag $xml;
+ my $mac1 = get_first_macaddress($dom1);
+ diag mac is $mac1;
+
+ sleep(30);
+
+# check vsi information
+ diag Verifying VSI information using lldptool;
+ my $lldptool = `/usr/sbin/lldptool -t -i eth2 -V vdp mode`;
+ diag $lldptool;
+# check if instance is listed
+ ok($lldptool =~ instance, check instance);
+ ok($lldptool =~ $mac1, check mac as well);
+
+ shutdown_vm_gracefully($dom1);
+ exit 0;
+
+};
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] [RFC] nwfilter: resolve deadlock between VM operations and filter update
I had trouble applying the patch (I think maybe Thunderbird may have fiddled with the formatting :( ), but after doing it manually, it works excellently. Thanks! -- Soren Hansen Ubuntu Developerhttp://www.ubuntu.com/ OpenStack Developer http://www.openstack.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [TCK][PATCH] nwfilter: implement support for --force flag
On 10/06/2010 09:09 AM, Daniel P. Berrange wrote:
On Mon, Oct 04, 2010 at 09:41:50AM -0400, Stefan Berger wrote:
Implement support for the --force command line option to delete
existing VMs and nwfilters starting with 'tck'. Fix how the --no-attach
flag is handled.
Signed-off-by: Stefan Bergerstef...@us.ibm.com
diff --git a/scripts/nwfilter/nwfilter2vmtest.sh
b/scripts/nwfilter/nwfilter2vmtest.sh
index b527ee8..496c220 100644
--- a/scripts/nwfilter/nwfilter2vmtest.sh
+++ b/scripts/nwfilter/nwfilter2vmtest.sh
@@ -23,6 +23,7 @@ FLAG_ATTACH=$((11))
FLAG_VERBOSE=$((12))
FLAG_LIBVIRT_TEST=$((13))
FLAG_TAP_TEST=$((14))
+FLAG_FORCE_CLEAN=$((15))
failctr=0
passctr=0
@@ -47,6 +48,8 @@ Options:
--verbose : Verbose output
--libvirt-test : Use the libvirt test output format
--tap-test : TAP format output
+ --force: Allow the automatic cleaning of VMs and nwfilters
+ previously created by the TCK test suite
This test will create two virtual machines. The one virtual machine
will use a filter called '${TESTFILTERNAME}', and reference the filter
@@ -498,11 +501,12 @@ function main() {
while [ $# -ne 0 ]; do
case $1 in
--help|-h|-\?) usage ${prgname}; exit 0;;
---noattach) ((flags ^= FLAG_ATTACH ));;
+--noattach) ((flags= ~FLAG_ATTACH ));;
--wait) ((flags |= FLAG_WAIT));;
--verbose) ((flags |= FLAG_VERBOSE ));;
--libvirt-test) ((flags |= FLAG_LIBVIRT_TEST ));;
--tap-test) ((flags |= FLAG_TAP_TEST ));;
+--force)((flags |= FLAG_FORCE_CLEAN ));;
*) usage ${prgname}; exit 1;;
esac
shift 1
@@ -523,12 +527,14 @@ function main() {
exit 0
fi
-for name in `virsh nwfilter-list | awk '{print $2}'`
+for name in `virsh list | awk '{print $2}'`
do
case ${name} in
tck*)
-if [ x${LIBVIRT_TCK_AUTOCLEAN} == x1 ]; then
- res=$(virsh nwfilter-undefine ${name} 21)
+if [ x${LIBVIRT_TCK_AUTOCLEAN} == x1 -o \
+ $((flags FLAG_FORCE_CLEAN)) -ne 0 ]; then
+ res=$(virsh destroy ${name} 21)
+ res=$(virsh undefine ${name} 21)
if [ $? -ne 0 ]; then
echo Bail out! Could not undefine nwfiler ${name}: ${res}
exit 0
@@ -544,8 +550,9 @@ function main() {
do
case ${name} in
tck*)
-if [ x${LIBVIRT_TCK_AUTOCLEAN} == x1 ]; then
- res=$(virsh undefine ${name} 21)
+if [ x${LIBVIRT_TCK_AUTOCLEAN} == x1 -o \
+ $((flags FLAG_FORCE_CLEAN)) -ne 0 ]; then
+ res=$(virsh nwfilter-undefine ${name} 21)
if [ $? -ne 0 ]; then
echo Bail out! Could not undefine domain ${name}: ${res}
exit 1
ACK
Daniel
Pushed.
Stefan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] [TCK] nwfilter: add test data for recently added extensions
This patch adds more test data for the recently added comment and
state attribute.
Signed-off-by: Stefan Berger stef...@us.ibm.com
---
scripts/nwfilter/nwfilterxml2fwallout/comment-test.fwall | 77
+++
scripts/nwfilter/nwfilterxml2fwallout/example-1.fwall| 22
scripts/nwfilter/nwfilterxml2fwallout/example-2.fwall| 20 +++
scripts/nwfilter/nwfilterxml2xmlin/comment-test.xml | 71
+
scripts/nwfilter/nwfilterxml2xmlin/example-1.xml | 24
scripts/nwfilter/nwfilterxml2xmlin/example-2.xml | 37 +++
6 files changed, 251 insertions(+)
Index: libvirt-tck/scripts/nwfilter/nwfilterxml2xmlin/comment-test.xml
===
--- /dev/null
+++ libvirt-tck/scripts/nwfilter/nwfilterxml2xmlin/comment-test.xml
@@ -0,0 +1,71 @@
+filter name='tck-testcase'
+ uuid0a5288ea-612c-834a-6bbf-82a03a1a3244/uuid
+
+ rule action='accept' direction='in'
+ mac protocolid='0x1234' comment='mac rule'/
+ /rule
+
+ rule action='accept' direction='out'
+ ip srcmacaddr='1:2:3:4:5:6' srcmacmask='ff:ff:ff:ff:ff:ff'
+ dstmacaddr='aa:bb:cc:dd:ee:ff' dstmacmask='ff:ff:ff:ff:ff:ff'
+ srcipaddr='10.1.2.3' srcipmask='255.255.255.255'
+ dstipaddr='10.1.2.3' dstipmask='255.255.255.255'
+ protocol='udp'
+ srcportstart='0x123' srcportend='0x234'
+ dstportstart='0x3456' dstportend='0x4567'
+ dscp='0x32' comment='ip rule'/
+ /rule
+
+ rule action='accept' direction='out'
+ ipv6 srcmacaddr='1:2:3:4:5:6' srcmacmask='ff:ff:ff:ff:ff:fe'
+ dstmacaddr='aa:bb:cc:dd:ee:ff' dstmacmask='ff:ff:ff:ff:ff:80'
+ srcipaddr='::10.1.2.3' srcipmask='22'
+ dstipaddr='::10.1.2.3'
+ dstipmask=':::::::8000'
+ protocol='tcp'
+ srcportstart='0x111' srcportend='400'
+ dstportstart='0x' dstportend='65535' comment='ipv6 rule'/
+ /rule
+
+ rule action='accept' direction='out'
+ arp srcmacaddr='1:2:3:4:5:6' srcmacmask='ff:ff:ff:ff:ff:ff'
+ dstmacaddr='aa:bb:cc:dd:ee:ff' dstmacmask='ff:ff:ff:ff:ff:ff'
+ hwtype='0x12'
+ protocoltype='0x56'
+ opcode='Request'
+ arpsrcmacaddr='1:2:3:4:5:6'
+ arpdstmacaddr='a:b:c:d:e:f'
+ comment='arp rule'/
+ /rule
+
+ rule action='accept' direction='out'
+ udp srcmacaddr='1:2:3:4:5:6'
+ dstipaddr='10.1.2.3' dstipmask='255.255.255.255'
+ dscp='0x22'
+ srcportstart='0x123' srcportend='400'
+ dstportstart='0x234' dstportend='0x444'
+ comment='udp rule'/
+ /rule
+
+ rule action='accept' direction='in'
+ tcp-ipv6 srcmacaddr='1:2:3:4:5:6'
+ srcipaddr='a:b:c::' srcipmask='128'
+ dscp='0x40'
+ srcportstart='0x20' srcportend='0x21'
+ dstportstart='0x100' dstportend='0x'
+ comment='tcp/ipv6 rule'/
+ /rule
+
+ rule action='accept' direction='in'
+ udp-ipv6 comment='`ls`;${COLUMNS};$(ls);test;amp;apos;3
spacesapos;'/
+ /rule
+
+ rule action='accept' direction='in'
+ sctp-ipv6 comment='comment with lone apos;, `, , `, \, $x, and two
spaces'/
+ /rule
+
+ rule action='accept' direction='in'
+ ah-ipv6 comment='tmp=`mktemp`; echo ${RANDOM} ${tmp} ; cat lt;
${tmp}; rm -f ${tmp}'/
+ /rule
+
+/filter
Index: libvirt-tck/scripts/nwfilter/nwfilterxml2fwallout/comment-test.fwall
===
--- /dev/null
+++ libvirt-tck/scripts/nwfilter/nwfilterxml2fwallout/comment-test.fwall
@@ -0,0 +1,77 @@
+#ebtables -t nat -L PREROUTING | grep vnet0 | grep -v ^Bridge | grep
-v ^$
+-i vnet0 -j libvirt-I-vnet0
+#ebtables -t nat -L POSTROUTING | grep vnet0 | grep -v ^Bridge | grep
-v ^$
+-o vnet0 -j libvirt-O-vnet0
+#ebtables -t nat -L libvirt-I-vnet0 | grep -v ^Bridge | grep -v ^$
+-p IPv4 -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --ip-src 10.1.2.3 --ip-dst
10.1.2.3 --ip-tos 0x32 --ip-proto udp --ip-sport 291:564 --ip-dport
13398:17767 -j ACCEPT
+-p IPv6 -s 1:2:3:4:5:6/ff:ff:ff:ff:ff:fe -d
aa:bb:cc:dd:ee:80/ff:ff:ff:ff:ff:80 --ip6-src ::/:fc00:: --ip6-dst
::10.1.0.0/:::::::8000 --ip6-proto tcp
--ip6-sport 273:400 --ip6-dport 13107:65535 -j ACCEPT
+-p ARP -s 1:2:3:4:5:6 -d aa:bb:cc:dd:ee:ff --arp-op Request --arp-htype
18 --arp-ptype 0x56 --arp-mac-src 1:2:3:4:5:6 --arp-mac-dst a:b:c:d:e:f
-j ACCEPT
+#ebtables -t nat -L libvirt-O-vnet0 | grep -v ^Bridge | grep -v ^$
+-p 0x1234 -j ACCEPT
+#iptables -L FI-vnet0 -n
+Chain FI-vnet0 (1 references)
+target prot opt source destination
+RETURN udp -- 0.0.0.0/010.1.2.3MAC
01:02:03:04:05:06 DSCP match 0x22/* udp rule */ udp spts:291:400
dpts:564:1092 state NEW,ESTABLISHED
+#iptables -L FO-vnet0 -n
+Chain FO-vnet0 (1 references)
+target prot opt source destination
+ACCEPT udp -- 10.1.2.3
Re: [libvirt] [PATCH] [RFC] nwfilter: resolve deadlock between VM operations and filter update
On Wed, Oct 06, 2010 at 05:56:36PM -0400, Stefan Berger wrote:
V2:
remove the locks from qemudVMFilterRebuild umlVMFilterRebuild
[...]
So, the following code paths exist towards
qemu_driver:qemudVMFilterRebuild where we now want to put a
qemu_driver lock in front of the filter lock.
- nwfilterUndefine() [ locks the filter ]
- virNWFilterTestUnassignDef()
- virNWFilterTriggerVMFilterRebuild()
- qemudVMFilterRebuild()
- nwfilterDefine()
- virNWFilterPoolAssignDef() [ locks the filter ]
- virNWFilterTriggerVMFilterRebuild()
- qemudVMFilterRebuild()
- nwfilterDriverReload()
- virNWFilterPoolLoadAllConfigs()
-virNWFilterPoolObjLoad()
- virNWFilterPoolAssignDef() [ locks the filter ]
- virNWFilterTriggerVMFilterRebuild()
- qemudVMFilterRebuild()
- nwfilterDriverStartup()
- virNWFilterPoolLoadAllConfigs()
-virNWFilterPoolObjLoad()
- virNWFilterPoolAssignDef() [ locks the filter ]
- virNWFilterTriggerVMFilterRebuild()
- qemudVMFilterRebuild()
Qemu is not the only driver using the nwfilter driver, but also the
UML driver calls into it. Therefore qemuVMFilterRebuild() can be
exchanged with umlVMFilterRebuild() along with the driver lock of
qemu_driver that can now be a uml_driver. Further, since UML and
Qemu domains can be running on the same machine, the triggering of a
rebuild of the filter can touch both types of drivers and their
domains.
okay
In the patch below I am now extending each nwfilter callback driver
with functions for locking and unlocking the (VM) driver (UML, QEMU)
and introduce new functions for locking all registered callback
drivers and unlocking them. Then I am distributing the
lock-all-cbdrivers/unlock-all-cbdrivers call into the above call
paths. The last shown callpath starting with nwfilterDriverStart()
is problematic since it is initialize before the Qemu and UML drives
are and thus a lock in the path would result in a NULL pointer
attempted to be locked -- the call to
virNWFilterTriggerVMFilterRebuild() is never called, so we never
lock either the qemu_driver or the uml_driver in that path.
Therefore, only the first 3 paths now receive calls to lock and
unlock all callback drivers. Now that the locks are distributed
where it matters I can remove the qemu_driver and uml_driver lock
from qemudVMFilterRebuild() and umlVMFilterRebuild() and not
requiring the recursive locks.
okay,
For now I want to put this out as an RFC patch. I have tested it by
'stretching' the critical section after the define/undefine
functions each lock the filter so I can (easily) concurrently
execute another VM operation (suspend,start). That code is in this
patch and if you want you can de-activate it. It seems to work ok
and operations are being blocked while the update is being done.
I still also want to verify the other assumption above that locking
filter and qemu_domain always has a preceding qemu_driver lock.
I looked at the patch and the only thing that need to be cleaned up
is the stretching blocki below, otherwise looks fine to me.
+if (true) {
+fprintf(stderr,sleep in %s\n, __FUNCTION__);
+sleep(CRITICAL_SECTION_STRETCH);
+fprintf(stderr,continue in %s\n, __FUNCTION__);
+}
+
It would be good to have some ways to exercise all code paths
in the locking (okay error handling specific paths aside because
it's really hard), before applying.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] [RFC] nwfilter: resolve deadlock between VM operations and filter update
On 10/07/2010 09:06 AM, Soren Hansen wrote: I had trouble applying the patch (I think maybe Thunderbird may have fiddled with the formatting :( ), but after doing it manually, it works excellently. Thanks! Great. I will prepare a V3. I am also shooting a kill -SIGHUP at libvirt once in a while to see what happens (while creating / destroying 2 VMs and modifying their filters). Most of the time all goes well, but occasionally things do get stuck. I get the following debugging output from libvirt and attaching gdb to libvirt I see the following stack traces. Maybe Daniel can interpret this... To me it looks like some of the conditions need to be 'tickled'... 09:47:25.000: error : qemuAutostartDomain:822 : Failed to start job on VM 'dummy-vm1': Timed out during operation: cannot acquire state change lock (gdb) thr ap all bt Thread 9 (Thread 0x7f49bf592710 (LWP 17464)): #0 0x00327680b729 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00435312 in virCondWaitUntil (c=value optimized out, m=value optimized out, whenms=value optimized out) at util/threads-pthread.c:115 #2 0x0043d0ab in qemuDomainObjBeginJobWithDriver (driver=0x1f9c010, obj=0x7f49a00011b0) at qemu/qemu_driver.c:409 #3 0x00458abf in qemuAutostartDomain (payload=value optimized out, name=value optimized out, opaque=0x7f49bf591320) at qemu/qemu_driver.c:818 #4 0x7f49c040ab6a in virHashForEach (table=0x1f9be20, iter=0x458a90 qemuAutostartDomain, data=0x7f49bf591320) at util/hash.c:495 #5 0x0043cdac in qemudAutostartConfigs (driver=0x1f9c010) at qemu/qemu_driver.c:855 #6 0x0043ce2a in qemudReload () at qemu/qemu_driver.c:2003 #7 0x7f49c0450a3e in virStateReload () at libvirt.c:1017 #8 0x004189e1 in qemudDispatchSignalEvent ( watch=value optimized out, fd=value optimized out, events=value optimized out, opaque=0x1f6f830) at libvirtd.c:388 ---Type return to continue, or q return to quit--- #9 0x004186a9 in virEventDispatchHandles () at event.c:479 #10 virEventRunOnce () at event.c:608 #11 0x0041a346 in qemudOneLoop () at libvirtd.c:2217 #12 0x0041a613 in qemudRunLoop (opaque=0x1f6f830) at libvirtd.c:2326 #13 0x003276807761 in start_thread () from /lib64/libpthread.so.0 #14 0x0032760e14ed in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x7f49beb91710 (LWP 17465)): #0 0x00327680b3bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00435336 in virCondWait (c=value optimized out, m=value optimized out) at util/threads-pthread.c:100 #2 0x0041b2e5 in qemudWorker (data=0x7f49b80008c0) at libvirtd.c:1549 #3 0x003276807761 in start_thread () from /lib64/libpthread.so.0 #4 0x0032760e14ed in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x7f49be190710 (LWP 17466)): #0 0x00327680b3bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00435336 in virCondWait (c=value optimized out, m=value optimized out) at util/threads-pthread.c:100 #2 0x004716f6 in qemuMonitorSend (mon=0x7f49a00040b0, ---Type return to continue, or q return to quit--- msg=value optimized out) at qemu/qemu_monitor.c:726 #3 0x00473673 in qemuMonitorCommandWithHandler (mon=0x7f49a00040b0, cmd=0x4c316f info cpus, passwordHandler=0, passwordOpaque=0x0, scm_fd=-1, reply=0x7f49be18e400) at qemu/qemu_monitor_text.c:233 #4 0x0047845e in qemuMonitorTextGetCPUInfo ( mon=value optimized out, pids=0x7f49be18fa18) at qemu/qemu_monitor_text.c:401 #5 0x00455db2 in qemuDetectVcpuPIDs (conn=0x7f49ac036100, driver=0x1f9c010, vm=value optimized out, migrateFrom=0x0, start_paused=false, stdin_fd=-1, stdin_path=0x0) at qemu/qemu_driver.c:2413 #6 qemudStartVMDaemon (conn=0x7f49ac036100, driver=0x1f9c010, vm=value optimized out, migrateFrom=0x0, start_paused=false, stdin_fd=-1, stdin_path=0x0) at qemu/qemu_driver.c:3925 #7 0x00457f6b in qemudDomainCreate (conn=0x7f49ac036100, xml=value optimized out, flags=0) at qemu/qemu_driver.c:4559 #8 0x7f49c04564ab in virDomainCreateXML (conn=0x7f49ac036100, xmlDesc=0x7f49a02b8bf0 domain type='kvm'\n namedummy-vm2/name\n memory32768/memory\n currentMemory32768/currentMemory\n vcpu1/vcpu\n os\n typehvm/type\n boot dev='hd'/\n /os..., flags=0) at libvirt.c:1984 #9 0x00427da8 in remoteDispatchDomainCreateXml ( server=value optimized out, client=value optimized out, ---Type return to continue, or q return to quit--- conn=0x7f49ac036100, hdr=value optimized out, rerr=0x7f49be18fc70, args=value optimized out, ret=0x7f49be18fbc0) at remote.c:1271 #10 0x0042a657 in remoteDispatchClientCall (server=0x1f6f830, client=0x7f49b83f03c0, msg=0x7f49b8453800) at dispatch.c:529 #11 remoteDispatchClientRequest (server=0x1f6f830, client=0x7f49b83f03c0,
Re: [libvirt] [PATCH] [RFC] nwfilter: resolve deadlock between VM operations and filter update
On 10/07/2010 09:52 AM, Daniel Veillard wrote:
On Wed, Oct 06, 2010 at 05:56:36PM -0400, Stefan Berger wrote:
V2:
remove the locks from qemudVMFilterRebuild umlVMFilterRebuild
For now I want to put this out as an RFC patch. I have tested it by
'stretching' the critical section after the define/undefine
functions each lock the filter so I can (easily) concurrently
execute another VM operation (suspend,start). That code is in this
patch and if you want you can de-activate it. It seems to work ok
and operations are being blocked while the update is being done.
I still also want to verify the other assumption above that locking
filter and qemu_domain always has a preceding qemu_driver lock.
I looked at the patch and the only thing that need to be cleaned up
is the stretching blocki below, otherwise looks fine to me.
Yes, I'll remove that.
+if (true) {
+fprintf(stderr,sleep in %s\n, __FUNCTION__);
+sleep(CRITICAL_SECTION_STRETCH);
+fprintf(stderr,continue in %s\n, __FUNCTION__);
+}
+
It would be good to have some ways to exercise all code paths
in the locking (okay error handling specific paths aside because
it's really hard), before applying.
It will take some time, but I'll try to write a TCK test that does
something like Soren was testing:
- concurrently create/destroy 2 vms
- concurrently modify their filters
- plus occasionally shoot a SIGHUP at libvirt ( if possible )
That would test some of the code paths.
Stefan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Added new attribute security_model to filesystem element
On Sat, Sep 25, 2010 at 12:04:11AM +0530, Harsh Prateek Bora wrote: This patch introduces new attribute to filesystem element to support customizable security_model for mount type. Valid security_model are: passthrough, mapped and none. Usage: filesystem type='mount' security_model='passthrough' source dir='/export/to/guest'/ target dir='mount_tag'/ /filesystem Well, there is a missing documentation part in the patch. In what way does having security_model='passthrough', security_model='mapped' or security_model='none' change the behaviour of the library compared to not having the attribute at all. Any patch which modifies the API (and the XML is part of the API) must have a clearly defined semantic, and that definition (and if possible an example) must be provided in the set of patches for the documentation. We cannot accept a patch whose only semantic is add a given QEmu command line argument because it makes impossible to try to support the option on other hypervisor or if QEmu end up changing the command line. What is your patch providing in term of API ? Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 3/5] Extend nwfilter schema to accept comment attributes
On Thu, Sep 30, 2010 at 07:31:56AM -0400, Stefan Berger wrote:
On 09/28/2010 04:06 PM, Stefan Berger wrote:
[...]
you have a printable character. Which goes back to my suggestion of an
inverse charset - rejecting bytes that are known to be non-printable
ASCII, and letting everything else whether or not it is is a printable
byte sequence in the current locale. So what about this idea: exclude
control characters except for tab, and let space and everything after
through (I don't know if it needs to be adjusted to also reject #x00):
[^#x01;-#x08#x0A-#x1F]{0,256}
Fine by me. We may just give the impression of accepting unicode
while the code does not handle it.
... except that xmllint does not like #x01 with or without
preceding ^ (among other things):
xmllint --relaxng ./docs/schemas/nwfilter.rng
tests/nwfilterxml2xmlout/comment-test.xml
./docs/schemas/nwfilter.rng:862: parser error : xmlParseCharRef:
invalid xmlChar value 1
param name=pattern[^#x01;-#x08#x0A-#x1F]{0,256}/param
^
The set of characters allowed in XML documents are defined by the
XML specification:
http://www.w3.org/TR/REC-xml/#NT-Char
It's a subset of Unicode, it refuses 0 et most ASCII control chars.
If comments are really comments embbeded in XML I don't see why
you should try to limit the comment content beside what XML imposes.
On the otehr hand if the comments are exposed somewhere else, we need
to look at the conversion issues, while limiting to ASCII is safe, it
can be really inconvenient in practice.
Do you really need to put any extra restriction ?
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] [RFC] nwfilter: resolve deadlock between VM operations and filter update
On Thu, Oct 07, 2010 at 10:06:55AM -0400, Stefan Berger wrote:
On 10/07/2010 09:52 AM, Daniel Veillard wrote:
On Wed, Oct 06, 2010 at 05:56:36PM -0400, Stefan Berger wrote:
V2:
remove the locks from qemudVMFilterRebuild umlVMFilterRebuild
For now I want to put this out as an RFC patch. I have tested it by
'stretching' the critical section after the define/undefine
functions each lock the filter so I can (easily) concurrently
execute another VM operation (suspend,start). That code is in this
patch and if you want you can de-activate it. It seems to work ok
and operations are being blocked while the update is being done.
I still also want to verify the other assumption above that locking
filter and qemu_domain always has a preceding qemu_driver lock.
I looked at the patch and the only thing that need to be cleaned up
is the stretching blocki below, otherwise looks fine to me.
Yes, I'll remove that.
sure, it was an RFC :-)
+if (true) {
+fprintf(stderr,sleep in %s\n, __FUNCTION__);
+sleep(CRITICAL_SECTION_STRETCH);
+fprintf(stderr,continue in %s\n, __FUNCTION__);
+}
+
It would be good to have some ways to exercise all code paths
in the locking (okay error handling specific paths aside because
it's really hard), before applying.
It will take some time, but I'll try to write a TCK test that does
something like Soren was testing:
- concurrently create/destroy 2 vms
- concurrently modify their filters
- plus occasionally shoot a SIGHUP at libvirt ( if possible )
That would test some of the code paths.
That would be nice, yes
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v3] nwfilter: resolve deadlock between VM operations and filter update
V3: - removed debugging code - I looked through existing code and I could not find any other instances where the filter and domain_lock were locked without a preceding qemu/uml_driver lock. So the 2nd assumption seems to hold and no further changes should be required for this issue. V2: - remove the locks from qemudVMFilterRebuild umlVMFilterRebuild This is from a bug report and conversation on IRC where Soren reported that while a filter update is occurring on one or more VMs (due to a rule having been edited for example), a deadlock can occur when a VM referencing a filter is started. The problem is caused by the two locking sequences of qemu driver, qemu domain, filter # for the VM start operation filter, qemu_driver, qemu_domain# for the filter update operation that obviously don't lock in the same order. The problem is the 2nd lock sequence. Here the qemu_driver lock is being grabbed in qemu_driver:qemudVMFilterRebuild() The following solution is based on the idea of trying to re-arrange the 2nd sequence of locks as follows: qemu_driver, filter, qemu_driver, qemu_domain and making the qemu driver recursively lockable so that a second lock can occur, this would then lead to the following net-locking sequence qemu_driver, filter, qemu_domain where the 2nd qemu_driver lock has been ( logically ) eliminated. The 2nd part of the idea is that the sequence of locks (filter, qemu_domain) and (qemu_domain, filter) becomes interchangeable if all code paths where filter AND qemu_domain are locked have a preceding qemu_domain lock that basically blocks their concurrent execution So, the following code paths exist towards qemu_driver:qemudVMFilterRebuild where we now want to put a qemu_driver lock in front of the filter lock. - nwfilterUndefine() [ locks the filter ] - virNWFilterTestUnassignDef() - virNWFilterTriggerVMFilterRebuild() - qemudVMFilterRebuild() - nwfilterDefine() - virNWFilterPoolAssignDef() [ locks the filter ] - virNWFilterTriggerVMFilterRebuild() - qemudVMFilterRebuild() - nwfilterDriverReload() - virNWFilterPoolLoadAllConfigs() -virNWFilterPoolObjLoad() - virNWFilterPoolAssignDef() [ locks the filter ] - virNWFilterTriggerVMFilterRebuild() - qemudVMFilterRebuild() - nwfilterDriverStartup() - virNWFilterPoolLoadAllConfigs() -virNWFilterPoolObjLoad() - virNWFilterPoolAssignDef() [ locks the filter ] - virNWFilterTriggerVMFilterRebuild() - qemudVMFilterRebuild() Qemu is not the only driver using the nwfilter driver, but also the UML driver calls into it. Therefore qemuVMFilterRebuild() can be exchanged with umlVMFilterRebuild() along with the driver lock of qemu_driver that can now be a uml_driver. Further, since UML and Qemu domains can be running on the same machine, the triggering of a rebuild of the filter can touch both types of drivers and their domains. In the patch below I am now extending each nwfilter callback driver with functions for locking and unlocking the (VM) driver (UML, QEMU) and introduce new functions for locking all registered callback drivers and unlocking them. Then I am distributing the lock-all-cbdrivers/unlock-all-cbdrivers call into the above call paths. The last shown callpath starting with nwfilterDriverStart() is problematic since it is initialize before the Qemu and UML drives are and thus a lock in the path would result in a NULL pointer attempted to be locked -- the call to virNWFilterTriggerVMFilterRebuild() is never called, so we never lock either the qemu_driver or the uml_driver in that path. Therefore, only the first 3 paths now receive calls to lock and unlock all callback drivers. Now that the locks are distributed where it matters I can remove the qemu_driver and uml_driver lock from qemudVMFilterRebuild() and umlVMFilterRebuild() and not requiring the recursive locks. For now I want to put this out as an RFC patch. I have tested it by 'stretching' the critical section after the define/undefine functions each lock the filter so I can (easily) concurrently execute another VM operation (suspend,start). That code is in this patch and if you want you can de-activate it. It seems to work ok and operations are being blocked while the update is being done. I still also want to verify the other assumption above that locking filter and qemu_domain always has a preceding qemu_driver lock. Signed-off-by: Stefan Berger stef...@us.ibm.com --- src/conf/nwfilter_conf.c | 18 ++ src/conf/nwfilter_conf.h |6 ++ src/libvirt_private.syms |2 ++ src/nwfilter/nwfilter_driver.c | 13 + src/qemu/qemu_driver.c | 19 +++ src/uml/uml_driver.c | 18 ++ 6 files changed, 68 insertions(+), 8
Re: [libvirt] [PATCH] Added new attribute security_model to filesystem element
On 10/7/2010 5:13 AM, Justin Clift wrote: On 10/07/2010 10:17 PM, Daniel P. Berrange wrote: On Sat, Sep 25, 2010 at 12:04:11AM +0530, Harsh Prateek Bora wrote: This patch introduces new attribute to filesystem element to support customizable security_model for mount type. Valid security_model are: passthrough, mapped and none. Usage: filesystem type='mount' security_model='passthrough' I'd like to think of a different name for this, because 'security_model' is already used in libvirt in the context of sVirt and I think it'd be better to avoid the same terminology. I've not got any ideas just yet, but I'll think of some mount_security mount_security_type mount_security_mode (mode sounds too similar to model tho maybe) Actually all three sound good.. mount_security is good enough if no objections. - JV ? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Added new attribute security_model to filesystem element
On 10/7/2010 7:20 AM, Daniel Veillard wrote: On Sat, Sep 25, 2010 at 12:04:11AM +0530, Harsh Prateek Bora wrote: This patch introduces new attribute to filesystem element to support customizable security_model for mount type. Valid security_model are: passthrough, mapped and none. Usage: filesystem type='mount' security_model='passthrough' source dir='/export/to/guest'/ target dir='mount_tag'/ /filesystem Well, there is a missing documentation part in the patch. In what way does having security_model='passthrough', security_model='mapped' or security_model='none' change the behaviour of the library compared to not having the attribute at all. I think we can ignore none and stick to mapped and passthrough for now. The security model is a mandatory argument for QEMU to start 9p/virtfs exports Here is the detailed explanation on these security models: Security model: mapped -- Fileserver intercepts and maps all the file object create requests. Files on the fileserver will be created with Fileserver's user credentials and the client-user's credentials are stored in extended attributes. During getattr() server extracts the client-user's credentials from extended attributes and sends to the client. This adds a great deal of security in the cloud environments where the guest's(client) user space is kept completely isolated from host's user space. Security model : passthrough In this security model, Fileserver passes down all requests to the underlying filesystem. File system objects on the fileserver will be created with client-user's credentials. This is done by setting setuid()/setgid() during creation or chmod/chown after file creation. At the end of create protocol request, files on the fileserver will be owned by cleint-user's uid/gid. This model mimic's current NFSv3 level of security. Any patch which modifies the API (and the XML is part of the API) must have a clearly defined semantic, and that definition (and if possible an example) must be provided in the set of patches for the documentation. We cannot accept a patch whose only semantic is add a given QEmu command line argument because it makes impossible to try to support the option on other hypervisor or if QEmu end up changing the command line. Our need for different security models is because of the different domains we or any other paravirtual filesystem may need to serve. mapped model is targeted for domains which demands a complete isolation of guest user domain from that of the hosts hence practically eliminating any security issues related to setuid/setgid and root. This is a very practical use case for certain classes of cloud workloads where multi-tenancy is a requirement. A complete isolation of user domain can practically make two competing customers share the same file system. The passthrough model is to play along with the traditional network file-serving methodologies like NFS and CIFS by sharing user domains of the host and guest. This method edges out by offering flexibility to export the same file system through other network file systems along with VirtFS. What is your patch providing in term of API ? Does my explanation above answers your questions? If not, I guess I am not very clear about this question. The code is already in the QEMU mainline and I don't expect the options to change. I also assume that other hypervisors may have to have some level of security models defined to serve different needs. Thanks, JV Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Ephemeral VM operation
A number of hypervisors have a mode in which changes made to storage are not persisted across a reboot of the VM. qemu uses the -snapshot flag; VMware refers to this functionality as non-persistent disk[1]. Is this functionality something that is interesting to libvirt? Dave [1] http://www.virtuesofvirtualization.com/2006/10/magic-of-nonpersistent-drives-in-vmware.html -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Ephemeral VM operation
On 10/08/2010 09:49 AM, Dave Allan wrote: A number of hypervisors have a mode in which changes made to storage are not persisted across a reboot of the VM. qemu uses the -snapshot flag; VMware refers to this functionality as non-persistent disk[1]. Is this functionality something that is interesting to libvirt? Dave [1] http://www.virtuesofvirtualization.com/2006/10/magic-of-nonpersistent-drives-in-vmware.html From the point of view of giving options to end users then it probably should be. To implement in QEMU/KVM, it sounds like it could be done by using a snapshot(s), plus nuking the snapshot when the vm is shut down? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
