[libvirt] QEMU 1.6 and drive discard parameter
by whitearchey
In QEMU 1.6 parameters of 'drive' option were removed:
QemuOptsList qemu_drive_opts = {
.name = "drive",
.head = QTAILQ_HEAD_INITIALIZER(qemu_drive_opts.head),
.desc = {
/*
* no elements => accept any params
* validation will happen later
*/
{ /* end of list */ }
},
};
But libvirt still checks for QEMU_CAPS_DRIVE_DISCARD using QMP
query-command-line-options:
static struct virQEMUCapsCommandLineProps virQEMUCapsCommandLine[] = {
{ "machine", "mem-merge", QEMU_CAPS_MEM_MERGE },
{ "drive", "discard", QEMU_CAPS_DRIVE_DISCARD },
{ "realtime", "mlock", QEMU_CAPS_MLOCK },
};
...
qemuMonitorGetCommandLineOptionParameters(mon,
virQEMUCapsCommandLine[i].option, &values)
So, when I try to use discard option in domain xml I get this error:
error : qemuBuildDriveStr:3986 : unsupported configuration: discard is not
supported by this QEMU binary
11 years
Re: [libvirt] Unable to provision VM attaching it directly to a OVS bridge
by Lucas Brasilino
Moving this discussion from libvirt-users:
Getting deeper and deeper :)
$ egrep '^int vir*' util/virnetdevopenvswitch.c
int virNetDevOpenvswitchAddPort(const char *brname, const char *ifname,
int virNetDevOpenvswitchRemovePort(const char *brname
ATTRIBUTE_UNUSED, const char *ifname)
int virNetDevOpenvswitchGetMigrateData(char **migrate, const char *ifname)
int virNetDevOpenvswitchSetMigrateData(char *migrate, const char *ifname)
Libvirt by now basically support adding/removing port to a OVS bridge .
Is there some planning on an OVS full support, like bridge creation/destroy,
creating a VM attaching it to a OVS brige, etc, just like
'traditional' Linux bridge ?
If so, Is anybody working on it ?
regards
Lucas Brasilino
MSc Student @ Federal University of Pernambuco (UFPE)
twitter: @lucas_brasilino
2013/10/29 Lucas Brasilino <lrbbs(a)cin.ufpe.br>:
> Hi
>
> Getting deeper, the error is raised by 'virDomainCreateLinux()'.
> Here comes the snippet of the XML argument passed to this call:
>
> (Pdb) print xmlDesc
> <domain type='kvm'>
> <name>vm2</name>
> <uuid>3d713513-e8ee-994a-0eba-51128bd4b42e</uuid>
> [...]
> <interface type='bridge'>
> <source bridge='databr0'/>
> <mac address='00:00:00:00:00:03'/>
> <model type='virtio'/>
> </interface>
> [...]
> </domain>
>
> So libvirt network driver is surely trying to use 'databr0' as the
> common Linux bridge implementation, not an Open vSwitch bridge.
>
> I tried to add an
>
> <virtualport='openvswitch'/>
>
> element in the XML created by virt-install and use 'virsh create' to
> create it but
> seems that libvirt's network driver does not support Open vSwitch when
> creating VM's.
> Is there some planning to support it ?
>
> Thanks!
>
> regards
> Lucas Brasilino
> MSc Student @ Federal University of Pernambuco (UFPE)
> twitter: @lucas_brasilino
>
> 2013/10/28 Lucas Brasilino <lrbbs(a)cin.ufpe.br>:
>> Reposting from virt-tools mailing list:
>>
>> Hi!
>>
>> I'm facing a problem that could be triggered by some lacking
>> of support from libvirt on Open vSwitch (or could be my mistake).
>>
>> I have interests in researching on virtual networks and
>> SDN. To keep things simple, I've decided to use libvirt/virt-tools to
>> manage VM's since my focus is on the network, instead of using a
>> full feature system like OpenStack.
>>
>> I'm quite new with libvirt/virt-tools, but I have a good experience with
>> openvswitch and other virtualizations technologies (which I dropped in
>> libvirt/kvm favor).
>>
>> I'm using Fedora 19 packages
>>
>> openvswitch (1.11.0-1.fc19.x86_64)
>> libvirt (1.0.5.6-3.fc19.x86_64)
>> virt-install (0.10.0-4.fc19.noarch)
>>
>> I've created an OVS bridge (databr0) outside libvirt, and then defined it
>> inside libvirt with:
>>
>> <network>
>> <name>databr0</name>
>> <forward mode='bridge'/>
>> <bridge name='databr0'/>
>> <virtualport type='openvswitch'/>
>> </network>
>>
>> And then 'net-autostart' and 'net-start' it with virsh. Now I've got:
>> # virsh net-list
>> Name State Autostart Persistent
>> ----------------------------------------------------------
>> databr0 active yes yes
>>
>> When I try to provision an VM, if I use the virt-install option
>> "--network=bridge:databr0,model=virtio,mac=00:00:00:00:00:03"
>> I got the following error:
>>
>> # virt-install --connect qemu:///system --virt-type kvm --name vm2
>> --ram 768 --disk path=/home/lucas/local/vm/images/vm2.img --vnc
>> --cdrom /home/lucas/local/vm/fc19-x86_64.iso
>> --network=bridge:databr0,model=virtio,mac=00:00:00:00:00:03
>> --os-type=linux --os-variant fedora19
>>
>> Starting install...
>> ERROR Unable to add bridge databr0 port vnet0: Operation not supported
>> Domain installation does not appear to have been successful.
>> If it was, you can restart your domain by running:
>> virsh --connect qemu:///system start vm2
>> otherwise, please restart your installation.
>>
>> I just managed to create a VM when I use '--nonetworks' option and after
>> I do a 'virtsh edit vm2' and add:
>>
>> <interface type='bridge'>
>> <mac address='00:00:00:00:00:03'/>
>> <source bridge='databr0'/>
>> <virtualport type='openvswitch'/>
>> <model type='virtio'/>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x05'
>> function='0x0'/>
>> </interface>
>>
>> Well, I read elsewhere that openvswitch bridging isn't fully
>> supported. Is it the case or I'm facing another kind of problem ?
>>
>> regards
>>
>> Att
>> Lucas Brasilino
>> MSc Student @ Federal University of Pernambuco (UFPE)
>> twitter: @lucas_brasilino
11 years
[libvirt] [PATCH] LXC: mount /dev/pts/0 to /dev/console
by Gao feng
Now, /dev/console is linked to the /dev/pts/0,
so for the process agetty, the tty device of
agetty is pts/0. this will cause login container
failed.
since pts/0 is not in the /etc/securetty. so
pam module pam_securetty will prevent the root
user logging on the system.
this patch doesn't make /dev/console a symbol but
binds /dev/pts/0 to it. so the tty device of
agetty will be console. root can login the system
successfully.
Signed-off-by: Gao feng <gaofeng(a)cn.fujitsu.com>
---
src/lxc/lxc_container.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 255c711..1cede41 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -1049,12 +1049,19 @@ static int lxcContainerSetupDevices(char **ttyPaths, size_t nttyPaths)
return -1;
}
VIR_FREE(tty);
- if (i == 0 &&
- symlink(ttyPaths[i], "/dev/console") < 0) {
- virReportSystemError(errno,
- _("Failed to symlink %s to /dev/console"),
- ttyPaths[i]);
- return -1;
+ if (i == 0) {
+ if (virFileTouch("/dev/console", 0600) < 0) {
+ virReportSystemError(errno, "%s",
+ _("Failed to create /dev/console"));
+ return -1;
+ }
+
+ if (mount(ttyPaths[0], "/dev/console", NULL, MS_BIND, NULL) < 0) {
+ virReportSystemError(errno,
+ _("Failed to symlink %s to /dev/console"),
+ ttyPaths[i]);
+ return -1;
+ }
}
}
return 0;
--
1.8.3.1
11 years
[libvirt] [PATCH] qemu: fix well-formed migration URI formatting
by Michael Chapman
When adding an automatically allocated port to a well-formed migration
URI, keep it well-formed:
tcp://1.2.3.4/ -> tcp://1.2.3.4/:12345 # wrong
tcp://1.2.3.4/ -> tcp://1.2.3.4:12345/ # fixed
tcp://1.2.3.4 -> tcp://1.2.3.4:12345 # still works
tcp:1.2.3.4 -> tcp:1.2.3.4:12345 # still works (old syntax)
Signed-off-by: Michael Chapman <mike(a)very.puzzling.org>
---
src/qemu/qemu_migration.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 0439ba4..cb59620 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -2535,6 +2535,7 @@ qemuMigrationPrepareDirect(virQEMUDriverPtr driver,
char *uri_str = NULL;
int ret = -1;
virURIPtr uri = NULL;
+ bool well_formed_uri = true;
VIR_DEBUG("driver=%p, dconn=%p, cookiein=%s, cookieinlen=%d, "
"cookieout=%p, cookieoutlen=%p, uri_in=%s, uri_out=%p, "
@@ -2597,6 +2598,7 @@ qemuMigrationPrepareDirect(virQEMUDriverPtr driver,
/* Convert uri_in to well-formed URI with // after tcp: */
if (!(STRPREFIX(uri_in, "tcp://"))) {
+ well_formed_uri = false;
if (virAsprintf(&uri_str, "tcp://%s", p) < 0)
goto cleanup;
}
@@ -2626,9 +2628,17 @@ qemuMigrationPrepareDirect(virQEMUDriverPtr driver,
goto cleanup;
}
- /* Caller frees */
- if (virAsprintf(uri_out, "%s:%d", uri_in, port) < 0)
- goto cleanup;
+ if (well_formed_uri) {
+ uri->port = port;
+
+ /* Caller frees */
+ if (!(*uri_out = virURIFormat(uri)))
+ goto cleanup;
+ } else {
+ /* Caller frees */
+ if (virAsprintf(uri_out, "%s:%d", uri_in, port) < 0)
+ goto cleanup;
+ }
} else {
port = uri->port;
--
1.8.3.1
11 years
[libvirt] [PATCH]virsh: track alias option and improve error message when option duplicate its alias
by Chen Hanxiao
From: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com>
commit 2b172a8effa712aee97a21a64d2d02060958f9b2 allow
alias to expand to opt=value pair.
That means alias may not look alike since then.
With this patch we will also track alias.
If we type command with one option and another marked
as its alias, we will get an error message like:
error: option '--AA' duplicate its alias '--AAA'
Signed-off-by: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com>
---
tools/virsh.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index bad78c9..423e2d8 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -1101,11 +1101,18 @@ vshCmddefGetOption(vshControl *ctl, const vshCmdDef *cmd, const char *name,
if (VIR_STRDUP(*optstr, value + 1) < 0)
goto cleanup;
}
+ *opts_seen |= 1 << i;
continue;
}
if ((*opts_seen & (1 << i)) && opt->type != VSH_OT_ARGV) {
- vshError(ctl, _("option --%s already seen"), name);
- goto cleanup;
+ if ((*opts_seen & (1 << (i - 1)))) {
+ vshError(ctl, _("option '--%s' duplicates its alias '--%s'"),
+ cmd->opts[i].name, cmd->opts[i-1].name);
+ goto cleanup;
+ } else {
+ vshError(ctl, _("option '--%s' already seen"), name);
+ goto cleanup;
+ }
}
*opts_seen |= 1 << i;
*opt_index = i;
--
1.8.2.1
11 years
[libvirt] [PATCH] maint: avoid further typedef accidents
by Eric Blake
To make it easier to forbid future attempts at a confusing typedef
name ending in Ptr that isn't actually a pointer, insist that we
follow our preferred style of 'typedef foo *fooPtr'.
* cfg.mk (sc_forbid_const_pointer_typedef): Enforce consistent
style, to prevent issue fixed in previous storage patch.
* src/conf/capabilities.h (virCapsPtr): Fix offender.
* src/security/security_stack.c (virSecurityStackItemPtr):
Likewise.
* tests/qemucapabilitiestest.c (testQemuDataPtr): Likewise.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
cfg.mk | 4 ++++
src/conf/capabilities.h | 4 ++--
src/security/security_stack.c | 2 +-
tests/qemucapabilitiestest.c | 2 +-
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/cfg.mk b/cfg.mk
index e9da282..1b2fd46 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -471,10 +471,14 @@ sc_correct_id_types:
# "const fooPtr a" is the same as "foo * const a", even though it is
# usually desired to have "foo const *a". It's easier to just prevent
# the confusing mix of typedef vs. const placement.
+# Also requires that all 'fooPtr' typedefs are actually pointers.
sc_forbid_const_pointer_typedef:
@prohibit='(^|[^"])const \w*Ptr' \
halt='"const fooPtr var" does not declare what you meant' \
$(_sc_search_regexp)
+ @prohibit='typedef [^(]+ [^*]\w*Ptr\b' \
+ halt='use correct style and type for Ptr typedefs' \
+ $(_sc_search_regexp)
# Forbid sizeof foo or sizeof (foo), require sizeof(foo)
sc_size_of_brackets:
diff --git a/src/conf/capabilities.h b/src/conf/capabilities.h
index 5bc7bb5..ba99e1a 100644
--- a/src/conf/capabilities.h
+++ b/src/conf/capabilities.h
@@ -1,7 +1,7 @@
/*
* capabilities.h: hypervisor capabilities
*
- * Copyright (C) 2006-2008, 2010, 2012 Red Hat, Inc.
+ * Copyright (C) 2006-2013 Red Hat, Inc.
* Copyright (C) 2006-2008 Daniel P. Berrange
*
* This library is free software; you can redistribute it and/or
@@ -162,7 +162,7 @@ struct _virDomainXMLNamespace {
};
typedef struct _virCaps virCaps;
-typedef virCaps* virCapsPtr;
+typedef virCaps *virCapsPtr;
struct _virCaps {
virObject parent;
diff --git a/src/security/security_stack.c b/src/security/security_stack.c
index ff0f06b..0d42b21 100644
--- a/src/security/security_stack.c
+++ b/src/security/security_stack.c
@@ -30,7 +30,7 @@
typedef struct _virSecurityStackData virSecurityStackData;
typedef virSecurityStackData *virSecurityStackDataPtr;
typedef struct _virSecurityStackItem virSecurityStackItem;
-typedef virSecurityStackItem* virSecurityStackItemPtr;
+typedef virSecurityStackItem *virSecurityStackItemPtr;
struct _virSecurityStackItem {
virSecurityManagerPtr securityManager;
diff --git a/tests/qemucapabilitiestest.c b/tests/qemucapabilitiestest.c
index 28f12e7..d912171 100644
--- a/tests/qemucapabilitiestest.c
+++ b/tests/qemucapabilitiestest.c
@@ -27,7 +27,7 @@
#define VIR_FROM_THIS VIR_FROM_NONE
typedef struct _testQemuData testQemuData;
-typedef testQemuData * testQemuDataPtr;
+typedef testQemuData *testQemuDataPtr;
struct _testQemuData {
virDomainXMLOptionPtr xmlopt;
const char *base;
--
1.8.3.1
11 years
Re: [libvirt] [libvirt-users] bridged networking using VLAN : guest with 2 NIC
by Laine Stump
On 10/30/2013 09:14 PM, Dan Sa wrote:
> I created another Virtual Machine with DHCP enabled 192.168.0.0/16
> <http://192.168.0.0/16> DHCP Range 192.168.0.2 192.168.0.2 (as I want
> same IP to all three guests) Forwarding : NAT to em2
>
> now on host I see two instances of dnsmasq
>
> netstat -anlp | grep -w dnsmasq
> tcp 0 0 192.168.0.1:53 <http://192.168.0.1:53>
> 0.0.0.0:* LISTEN 1907/dnsmasq <<<< is this right ?
> I created
> tcp 0 0 192.168.122.1:53 <http://192.168.122.1:53>
> 0.0.0.0:* LISTEN 6666/dnsmasq <<< default NAT
>
>
> however I am seeing dnsmasq is not Active
>
> systemctl status dnsmasq.service
> dnsmasq.service - DNS caching server.
> Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service;
> enabled)
> Active: failed (Result: exit-code) since Wed, 30 Oct 2013
> 12:30:39 -0600; 41min ago
>
> all my guest are on physical VLAN so how I should go about giving them
> 192.168.0.2 address using dnsmasq ?
1) PLEASE stop top-posting new random information and guesses at
solutions to the top of your old messages. You are quickly creating a
cascade of text that is so large and rambling that nobody will have the
ambition to unscramble it and make a reply.
It is generally accepted good etiquette to post responses to earlier
messages in-line with the original, so that the flow of the conversation
can be easily followed by someone reading just the last message. (If
there is no "flow" to the conversation, then something more fundamental
has gone wrong.)
2) If you've now realized (as I told you in my first response) that you
need to run a system instance of dhcpd or dnsmasq to service dhcp for
the vlan of your guests, then what you have is a networking problem, not
a virtualization problem. There are tutorials for setting up dnsmasq in
various places on the web, or you can simply read the comments in
/etc/dnsmasq.conf to figure out how to make it listen on just a specific
interface, and how to tell it what addresses to serve for that interface.
See below for more comments.
>
> thanks
> dan
>
>
>
>
>
>
> On Wed, Oct 30, 2013 at 11:20 AM, Dan Sa <dreamrider787(a)gmail.com
> <mailto:dreamrider787@gmail.com>> wrote:
>
> UPDATE :
>
> Adding more information about dnsmasq on box running fedora (host)
>
> dispatcher.d]# nmcli nm status
> RUNNING STATE WIFI-HARDWARE WIFI
> WWAN-HARDWARE WWAN
> running connecting enabled enabled
> enabled disabled
>
> nmcli nm status
> RUNNING STATE WIFI-HARDWARE WIFI
> WWAN-HARDWARE WWAN
> running disconnected enabled enabled
> enabled disabled
>
>
> systemctl --all|grep -i network
>
> NetworkManager.service loaded active running Network
> Manager
>
> dnsmasq.d]# ls -al
> total 8
> drwxr-xr-x 2 root root 4096 Nov 20 2012 .
> drwxr-xr-x. 6 root root 4096 Oct 30 08:56 ..
>
>
> dispatcher.d]# ls -al
> total 32
> drwxr-xr-x. 2 root root 4096 Sep 23 12:59 .
> drwxr-xr-x. 6 root root 4096 Oct 30 08:56 ..
> -rwxr-xr-x 1 root root 175 Nov 15 2012 00-netreport
> -rwxr-xr-x. 1 root root 335 Feb 14 2012 04-iscsi
> -rwxr-xr-x. 1 root root 111 Jun 25 2012 10-sendmail
> -rwxr-xr-x 1 root root 933 Jul 10 04:38 11-dhclient
> -rwxr-xr-x. 1 root root 317 Apr 27 2012 20-chrony
> -rwxr-xr-x 1 root root 138 Mar 19 2013 20-squid
>
> cat dnsmasq.conf
>
> all lines are commented only line active is
>
> # Include another lot of configuration options.
> #conf-file=/etc/dnsmasq.more.conf
> conf-dir=/etc/dnsmasq.d <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
*All* of the above is just random data, which says nothing. Please try
to spend more time figuring out what you are trying to do and what has
gone wrong before just pasting random bits into a message to a mailing
list. Remember that the people reading the messages on this list are
doing it for free, and they also have day jobs they need to attend to.
The less excess garbage is in a message, the less time they have to use
up sifting through it for useful information.
>
>
>
>
>
> On Wed, Oct 30, 2013 at 10:10 AM, Dan Sa <dreamrider787(a)gmail.com
> <mailto:dreamrider787@gmail.com>> wrote:
>
> BRCTL SHOW
> bridge name bridge id STP enabled interfaces
> br0 8000.00237de0a132 no em1
> vnet0
> guest1-lan 8000.00237de0a133 no em2.620
> vnet3
> guest1-wan 8000.0022642b6586 no p1p1.110
> guest2-lan 8000.00237de0a133 no em2.619
> guest2-wan 8000.0022642b6586 no p1p1.108
> guest3-lan 8000.00237de0a133 no em2.621
> guest3-wan 8000.0022642b6586 no p1p1.111
>
> virbr0 8000.5254003e19b3 yes virbr0-nic
> vnet2
>
The above list of bridges connected to vlan interfaces implies that, for
some reason, you are putting each interface of each guest on a separate
vlan. Is this really what you think you want to do? Why? How will these
guests connect to the rest of the network? Unless you have a requirement
to isolate each guest entirely from every other guest and force each
guest's traffic to travel through a different path out to the rest of
the network, then I think you've misunderstood when/why vlans should be
used. It is much more common to just setup a single network that many
(or even all) guests will attach to, and generally you don't need a vlan
tag to do this.
(an earlier comment you made implying that a *host* bridge attached to a
host vlan interface *was actually the guest interface* makes me believe
you are confused about the function of each bit and how they all fit
together. I think it would be useful for you to step back from all of
this and just explain how you want your guests to connect to the rest of
the network. Do you have a specific requirement for each to be connected
to a separate vlan on the physical network? Or do they just need to be
connected "somehow"? Do they need to be prevented from communicating
with each other, or was this just a side effect of a mistaken network
configuration?
>
>
> On Wed, Oct 30, 2013 at 10:10 AM, Dan Sa
> <dreamrider787(a)gmail.com <mailto:dreamrider787@gmail.com>> wrote:
>
> Laine,
>
> first thank you very much for your input, it cleared some
> doubts ... please find below the information in the
> desired format.
>
> Versions:
>
> 1) Virtual Machine Manager 0.9.5[root@dsl-test qemu]# uname -a
> 2) Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14
> 01:31:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> 3) Fedora release 17 (Beefy Miracle) Kernel \r on an \m (\l)
>
Fedora 17 is > 1 year old, and thus no longer gets any updates, not even
security updates. You need to upgrade to a newer release of Fedora (F20
is already in beta, so that may be a good choice)
> 4) virsh --version 0.9.11.10
>
Likewise, 0.9.11 is very old. *Many* improvements have been made since
then, which is another good reason to upgrade your OS.
> 5) rpm -qa | grep kvm
> libvirt-daemon-kvm-0.9.11.10-1.fc17.x86_64
> qemu-kvm-1.0.1-6.fc17.x86_64
>
> I have 3 Guest information for guest1 follows : (my
> questions are after that)
>
> virsh dumpxml guest1 :
>
> virsh dumpxml guest1
>
> <domain type='kvm' id='5'>
>
> <name>guest1</name>
>
> <uuid>bcc29de1-ba90-5dd8-81fe-7450852df7f6</uuid>
>
> <memory unit='KiB'>1048576</memory>
>
> <currentMemory unit='KiB'>1048576</currentMemory>
>
> <vcpu>4</vcpu>
>
> <os>
>
> <type arch='x86_64' machine='pc-0.15'>hvm</type>
>
> <boot dev='hd'/>
>
> </os>
>
> <features>
>
> <acpi/>
>
> <apic/>
>
> <pae/>
>
> </features>
>
> <cpu mode='custom' match='exact'>
>
> <model fallback='allow'>Penryn</model>
>
> <vendor>Intel</vendor>
>
> <feature policy='require' name='tm2'/>
>
> <feature policy='require' name='est'/>
>
> <feature policy='require' name='monitor'/>
>
> <feature policy='require' name='osxsave'/>
>
> <feature policy='require' name='ss'/>
>
> <feature policy='require' name='ds'/>
>
> <feature policy='require' name='vme'/>
>
> <feature policy='require' name='dtes64'/>
>
> <feature policy='require' name='ht'/>
>
> <feature policy='require' name='dca'/>
>
> <feature policy='require' name='pbe'/>
>
> <feature policy='require' name='xsave'/>
>
> <feature policy='require' name='tm'/>
>
> <feature policy='require' name='pdcm'/>
>
> <feature policy='require' name='vmx'/>
>
> <feature policy='require' name='ds_cpl'/>
>
> <feature policy='require' name='xtpr'/>
>
> <feature policy='require' name='acpi'/>
>
> </cpu>
>
> <clock offset='utc'/>
>
> <on_poweroff>destroy</on_poweroff>
>
> <on_reboot>restart</on_reboot>
>
> <on_crash>restart</on_crash>
>
> <devices>
>
> <emulator>/usr/bin/qemu-kvm</emulator>
>
> <disk type='file' device='disk'>
>
> <driver name='qemu' type='raw'/>
>
> <source file='/var/lib/libvirt/images/guest1.img'/>
>
> <target dev='vda' bus='virtio'/>
>
> <alias name='virtio-disk0'/>
>
> <address type='pci' domain='0x0000' bus='0x00'
> slot='0x05' function='0x0'/>
>
> </disk>
>
> <controller type='usb' index='0'>
>
> <alias name='usb0'/>
>
> <address type='pci' domain='0x0000' bus='0x00'
> slot='0x01' function='0x2'/>
>
> </controller>
>
> <controller type='virtio-serial' index='0'>
>
> <alias name='virtio-serial0'/>
>
> <address type='pci' domain='0x0000' bus='0x00'
> slot='0x04' function='0x0'/>
>
> </controller>
>
> <interface type='network'>
>
> <mac address='52:54:00:ea:80:df'/>
>
> <source network='default'/>
>
> <target dev='vnet2'/>
>
> <alias name='net0'/>
>
> <address type='pci' domain='0x0000' bus='0x00'
> slot='0x03' function='0x0'/>
>
> </interface>
>
> <interface type='bridge'>
>
> <mac address='52:54:00:d5:1d:01'/>
>
> <source bridge='guest1-lan'/>
>
> <target dev='vnet3'/>
>
> <model type='virtio'/>
>
> <alias name='net1'/>
>
> <address type='pci' domain='0x0000' bus='0x00'
> slot='0x07' function='0x0'/>
>
> </interface>
>
> <serial type='pty'>
>
> <source path='/dev/pts/3'/>
>
> <target port='0'/>
>
> <alias name='serial0'/>
>
> </serial>
>
> <console type='pty' tty='/dev/pts/3'>
>
> <source path='/dev/pts/3'/>
>
> <target type='serial' port='0'/>
>
> <alias name='serial0'/>
>
> </console>
>
> <input type='mouse' bus='ps2'/>
>
> <graphics type='vnc' port='5901' autoport='yes'/>
>
> <video>
>
> <model type='cirrus' vram='9216' heads='1'/>
>
> <alias name='video0'/>
>
> <address type='pci' domain='0x0000' bus='0x00'
> slot='0x02' function='0x0'/>
>
> </video>
>
> <memballoon model='virtio'>
>
> <alias name='balloon0'/>
>
> <address type='pci' domain='0x0000' bus='0x00'
> slot='0x06' function='0x0'/>
>
> </memballoon>
>
> </devices>
>
> <seclabel type='none'/>
>
> </domain>
>
>
>
>
>
> Here is revised BRCTL Show after guest1 is running
>
>
> BRCTL SHOW
>
> bridge name bridge id STP enabled interfaces
>
> br0 8000.00237de0a132
> no em1
>
> vnet0
>
> c1000z-lan 8000.00237de0a133
> no em2.620
>
> vnet3
>
> c1000z-wan 8000.0022642b6586
> no p1p1.110
>
> c2000t-lan 8000.00237de0a133
> no em2.619
>
> c2000t-wan 8000.0022642b6586 no
> p1p1.108
>
> pk5001a-lan 8000.00237de0a133
> no em2.621
>
> pk5001a-wan 8000.0022642b6586
> no p1p1.111
>
> virbr0 8000.5254003e19b3 yes
> virbr0-nic
>
> vnet2
>
The above is obviously *not* the output of brctl on the same host as the
above-listed guest, since that guest connects to a bridge called
"guest1-lan", which isn't even in the brctl output at all.
> ----------------------------------------------------------------------------------------------------------
>
>
> on guest1-lan terminal I see following :
>
>
> route -n
>
> destination gateway genmask flags
> metric ref use iface
>
> 0.0.0.0 192.168.122.1 0.0.0.0 UG
> 100 0 eth0
>
> 192.168.122.0 0.0.0.0 255.255.255.0 U
> 0 0 eth0
>
>
> DHCPDISCOVER on eth 1 to 255.255.255.255 port 67 interval
> 6 then 14, 13, 15
>
> and then sleeping
>
>
> so you are right I am not getting DHCP IP and I have
> "forward mode bridge" so libvirt is ignoring it
>
> I want 192.168.0.2 on this with gateway 192.168.0.1
>
>
> so looks like my problem is DHCP .... how can I able to
> run DHCP for all three guest which are part of em2
>
> interface like em2.629, em2.621 and em2/622
>
Again, WHY do you need a separate vlan for each guest? I think you may
be confused.
>
> awaiting your suggestions....
>
1) stop top-posting.
2) either explain why you need each guest on a separate vlan, or give up
on that idea and just connect all guest interfaces to a single network
(or possible 2 networks - on lan and one wan, which you seen to have
some requirement for).
3) if you really do require the guests to each be on a separate vlan,
and you don't have any other host on the network that already serves
dhcp on those vlans, then read /etc/dnsmasq.conf to learn how to
configure it.
>
> regards
>
> dan
>
>
>
> On Wed, Oct 30, 2013 at 9:56 AM, Dan Sa
> <dreamrider787(a)gmail.com <mailto:dreamrider787@gmail.com>>
> wrote:
>
> Laine,
>
> first thank you very much for your input, it cleared
> some doubts ... please find below the information in
> the desired format.
>
> Versions:
>
> 1) Virtual Machine Manager 0.9.5[root@dsl-test qemu]#
> uname -a
> 2) Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14
> 01:31:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> 3) Fedora release 17 (Beefy Miracle) Kernel \r on an
> \m (\l)
> 4) virsh --version 0.9.11.10
> 5) rpm -qa | grep kvm
> libvirt-daemon-kvm-0.9.11.10-1.fc17.x86_64
> qemu-kvm-1.0.1-6.fc17.x86_64
>
> I have 3 Guest and here is
>
>
>
>
> On Wed, Oct 30, 2013 at 5:19 AM, Laine Stump
> <laine(a)laine.org <mailto:laine@laine.org>> wrote:
>
> (There is no need or advantage to Cc'ing
> individuals who are already
> subscribed to the mailing list.)
>
> On 10/28/2013 05:34 PM, Dan Sa wrote:
> > hello all,
> >
> > I have been trying to set-up bridged network
> with VLAN and not able to
> > succeed as many tutorials address only single NIC.
> >
> > I am trying to setup 2 guests (backtrack
> instance) each guest has NIC1
> > and NIC2. following is snippet for guest1
> >
> > I am not able to get 192.168.0.2 address back on
> guest eth0.
>
>
> See the comment below about <forward
> mode='bridge'>. you'll need some
> other entity on your vlan to run a dhcp server,
> because libvirt won't be
> doing it for you in this case.
>
>
> >
> >
> > VIRT-MANAGER GUI :
> >
> > guest1-lan details radio button
> >
> > left side panel
> >
> > NIC1 ------------------> Virtual Network Interface
> > Source Device :
> Virtual Network "default" NAT
> > Device Model :
> Hypervisor default
> > MAc Address :
> xxxxxxxxxxxxxx
> >
> > NIC2 ------------------> Virtual Network Interface
> > Source Device :
> Specify Shared Device Name
> > Bridge
> name : guest1-lan
> > Device Model : virto
> > MAc Address :
> xxxxxxxxxxxxxx
>
> The output of "virsh dumpxml $guestname" is much
> more useful than a
> transcription of the virt-manager screens.
>
> >
> > HOST MACHINE :
> >
> > brctl show has br0 for bridge
> > and virbr0 with 192.168.122.x address (created
> by default virtual
> > network NAT)
> >
> >
> > /etc/sysconfig/network-scripts/
> >
> > 1) Bridge BR0 (cat ifcfg-br0)
> >
> > DEVICE="br0"
> > TYPE="Bridge"
> > ONBOOT="yes"
> > NM_CONTROLLED="no"
> > BOOTPROTO="static"
> > IPADDR="xx.xx.xx.xx"
> > NETMASK="255.255.254.0"
> > GATEWAY="xx.xx.xx.xx"
> > DNS1="x.y.z.s"
> > DNS2="x.y.q.s"
> >
> > 2) cat ifcfg-em1
> > NM_CONTROLLED="yes"
> > HWADDR="02:12D:E2:B1:32"
> > BOOTPROTO="static"
> > DEVICE="em1"
> > BRIDGE="br0"
> > ONBOOT="yes"
> >
> > 3) ifcfg-em2
> > NM_CONTROLLED="yes"
> > HWADDR="02:24:7e:d0:b1:42"
> > BOOTPROTO="static"
> > DEVICE="em2"
> > ONBOOT="yes"
> >
> > 4) THIS IS GUEST (cat ifcfg-guest1-lan)
>
> I don't understand what you mean by "this is
> guest". It isn't a part of
> the guest; it is a bridge on the host that could
> be *used* by a guest.
>
>
> > DEVICE=guest1-lan
> > TYPE=Bridge
> > ONBOOT=yes
> > BOOTPROTO=static
> > DELAY=1
> >
> > 5) GUEST VLAN (cat ifcfg-em2.620)
> >
> > DEVICE=em2.620
> > VLAN=yes
> > ONBOOT=yes
> > BRIDGE=guest1-lan
> >
> > BRCTL Show Command :
> >
> > br0 8000.00237de0a132 no em1
> >
> vnet0
> > guest1-lan 8000.00237de0a133 no em2.620
> > virbr0 8000.5254003e19b3 yes virbr0-nic
>
>
> From the above, it appears that there is only a
> single guest running,
> and that it is connected via the br0 bridge;
> apparently you took this
> output when neither of your dual-nic guests were
> running, as they should
> have each attached tun devices to both guest1-lan
> and virbr0.
>
>
> >
> >
> > VIRSH :
> >
> > virsh # net-list
> > Name State Autostart
> > -----------------------------------------
> > guest1-lan active yes
> > default active yes
> >
> >
> > virsh # iface-list
> > Name State MAC Address
> > --------------------------------------------
> > br0 active 00:23:7d:e0:a1:32
> > guest1-lan active 00:23:7d:e0:a1:33
> >
> >
> > iface-edit :
> >
> > virsh # iface-edit guest1-lan
> >
> > <interface type='bridge' name='guest1-lan'>
> > <start mode='onboot'/>
> > <bridge delay='1'>
> > <interface type='vlan' name='em2.620'>
> > <vlan tag='620'>
> > <interface name='em2'/>
> > </vlan>
> > </interface>
> > </bridge>
> > </interface>
> >
> >
> ------------------------------------------------------------------
> >
> > /etc/libvirt/qemu/networks
>
>
> (You shouldn't be looking at/modifying the files in
> /etc/libvirt/qemu/networks directly. Instead, use
> "virsh net-dumpxml
> guest1-lan" (for example) to look at the network
> config, and "virsh
> net-edit guest1-lan" to modify it.)
>
>
> >
> > cat guest1-lan.xml
> > <network>
> > <name>guest1-lan</name>
> > <uuid>a12747ec-21c9-0d21-ab06-064ba204bc52</uuid>
> > <forward mode='bridge' dev="br0"/>
> > <bridge name='guest1-lan' />
> > <ip address='192.168.0.1' netmask='255.255.255.0'>
> > <dhcp>
> > <range start='192.168.0.2'
> end='192.168.0.254' />
> > </dhcp>
> > </ip>
>
>
> Any network with <forward mode='bridge'...> is an
> "unmanaged" network
> from libvirt's POV, and thus the <ip> element and
> all its subelements
> are ignored. If you use <forward mode='bridge'>
> then libvirt assumes
> that the bridge device is already configured by
> the base OS config.
>
> As of libvirt-1.0.1, attempts to define an <ip>
> element in a network
> with <forward mode='bridge'> are flagged as an
> error. (It would be
> helpful in future reports if you indicate your 1)
> libvirt version, 2)
> qemu version, 3) distro and version, 4) kernel
> version. Although not
> always applicable, sometime it can help in framing
> the issue.
>
>
> > </network>
> >
> >
> > cat default.xml
> >
> > <network>
> > <name>default</name>
> > <uuid>8778244b-1a0c-c15f-c348-26462a07a639</uuid>
> > <forward mode='nat'/>
> > <bridge name='virbr0' stp='on' delay='0' />
> > <mac address='52:54:00:3E:19:B3'/>
> > <ip address='192.168.122.1'
> netmask='255.255.255.0'>
> > <dhcp>
> > <range start='192.168.122.2'
> end='192.168.122.254' />
> > </dhcp>
> > </ip>
> > </network>
> >
> > any guidance will be appriciated
>
> Since you're defining a vlan tag, I assume that
> the physical network
> attached to your host's em2 is actually using vlan
> 620? If not, and you
> just need a network that's private to your guests
> and the host, I would
> recommend simply defining a libvirt network with
> no <forward> element at
> all. This network *will* be managed by libvirt, so
> libvirt will create a
> bridge and give it an IP address, as well as
> running a dnsmasq instance
> to serve up IP addresses to guests, but the guests
> won't be able to get
> traffic anywhere beyond that bridge via their
> interface connected to the
> bridge.
>
> If you *are* using vlan 620 on the physical
> network, then you'll need to
> setup some other dhcp server somewhere on that
> network (either run a
> system instance of dnsmasq on the host that
> listens on em2.620, or run
> dnsmasq or dhcpd on some other physical host or
> guest that listens on
> its own vlan-tagged interface).
>
>
>
>
>
>
11 years
[libvirt] RFC: using a network device as a destination for a disk snapshot
by Eric Blake
Right now, when creating an external snapshot, the snapshot xml requires
that the destination be in the local file system:
http://libvirt.org/formatsnapshot.html
<domainsnapshot>
...
<disks>
<disk name='vda' snapshot='external'>
<driver type='qcow2'/>
<source file='/path/to/new'/>
</disk>
...
But libvirt already allows for a network device with qcow2 contents,
provided that there is no backing chain:
# qemu-img info gluster://red/vol1/img2
image: gluster://red/vol1/img2
file format: qcow2
virtual size: 10M (10485760 bytes)
disk size: 193K
cluster_size: 65536
# virsh dumpxml dom
<domain type='kvm'>
...
<disk type='network' device='disk'>
<driver name='qemu' type='qcow2'/>
<source protocol='gluster' name='vol1/img2'>
<host name='red'/>
</source>
<target dev='vdc' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x09'
function='0x0'/>
</disk>
...
I'm working on patches to the backing chain code to allow a gluster (or
other network device) with qcow2 contents to have a backing file, but
for the code to be useful, we also need to patch <domainsnapshot> xml to
allow the destination file to be a gluster or other network device,
rather than forcing it to be a local file name.
Here's the XML I think we need to add to domainsnapshot:
<domainsnapshot>
...
<disks>
<disk name='vda' snapshot='external' type='network'>
<driver type='qcow2'/>
<source protocol='gluster' name='vol1/img2'>
<host name='red'/>
</source>
</disk>
that is, add an optional /disk@type attribute (if absent, it defaults to
type='file'), and where if present, the <source> subelement then takes
on alternate forms in the same manner in which //domain/devices/disk
handles alternates (here, allowing a protocol, name, and host
specification).
[Ultimately, we need to fix //domain/devices/disk to specify a full
backing chain, but one step at a time...]
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
11 years
[libvirt] [PATCH 0/6] API documentation improvements
by Claudio Bley
Hi.
It's been a while since I tackled this, but here it goes...
This is version 4 of https://www.redhat.com/archives/libvir-list/2013-January/msg02094.html
exclusive of the already applied patches, of course.
Changes since v3:
* skipped the ECMAScript code highlighting patch[1] in this series
(postponed for now)
* added link generation patch (#6) which I had proposed
seperately back in Jan 2013, too.
* added a reference to an affected API in patch #1 and #4 as per
Eric's comments
* changed the code block XSL processing to avoid cutting off characters
at the beginning of a line
[1] https://www.redhat.com/archives/libvir-list/2013-January/msg02104.html
[2] https://www.redhat.com/archives/libvir-list/2013-January/msg00884.html
Claudio Bley (6):
docs: process code blocks similar to Markdown
docs: add class "description" to div's containing descriptions
docs: define style of code blocks inside descriptions
libvirt.c: add 2 spaces of indentation to example code of
virStreamSend
libvirt.c: indent code of virDomainGetMemoryParameters's
documentation
docs: generate links from plain text documentation
docs/libvirt.css | 7 +++
docs/newapi.xsl | 121 +++++++++++++++++++++++++++++++++++++++-----------
src/libvirt.c | 130 +++++++++++++++++++++++++++---------------------------
3 files changed, 167 insertions(+), 91 deletions(-)
--
1.7.9.5
11 years
