September 2011 - Devel - libvirt List Archives

[libvirt] [PATCH 1/3] PIIX3 USB controller is on function 2
by Marc-André Lureau 05 Sep '11

05 Sep '11

Current code reserves slot 1 function 2 even if there is a user defined PIIX3 USB controller there. --- src/qemu/qemu_command.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 6ff1b2c..e4bdb57 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -1181,7 +1181,8 @@ qemuAssignDevicePCISlots(virDomainDefPtr def, qemuDomainPCIAddressSetPtr addrs) * hardcoded slot=1, multifunction device */ for (function = 0; function < QEMU_PCI_ADDRESS_LAST_FUNCTION; function++) { - if (function == 1 && (reservedIDE || reservedUSB)) + if ((function == 1 && reservedIDE) || + (function == 2 && reservedUSB)) /* we have reserved this pci address */ continue; -- 1.7.6

2 4

Re: [libvirt] migration of vnlink VMs
by Oved Ourfalli 05 Sep '11

05 Sep '11

----- Original Message ----- > From: "Laine Stump" <lstump(a)redhat.com> > To: "Oved Ourfalli" <ovedo(a)redhat.com> > Cc: "Ayal Baron" <abaron(a)redhat.com>, "Barak Azulay" <bazulay(a)redhat.com>, "Shahar Havivi" <shaharh(a)redhat.com>, > "Itamar Heim" <iheim(a)redhat.com>, "Dan Kenigsberg" <danken(a)redhat.com> > Sent: Thursday, April 28, 2011 10:20:35 AM > Subject: Re: migration of vnlink VMs > Oved, > > Would it be okay to repost this message to the thread on libvir-list > so > that other parties can add their thoughts? > Of course. I'm sending my answer to the libvirt list. > On 04/27/2011 09:58 AM, Oved Ourfalli wrote: > > Laine, hello. > > > > We read your proposal for abstraction of guest<--> host network > > connection in libvirt. > > > > You has an open issue there regarding the vepa/vnlink attributes: > > "3) What about the parameters in the<virtualport> element that are > > currently used by vepa/vnlink. Do those belong with the host, or > > with the guest?" > > > > The parameters for the virtualport element should be on the guest, > > and not the host, because a specific interface can run multiple > > profiles, > > Are you talking about host interface or guest interface? If you mean > that multiple different profiles can be used when connecting to a > particular switch - as long as there are only a few different > profiles, > rather than each guest having its own unique profile, then it still > seems better to have the port profile live with the network definition > (and just define multiple networks, one for each port profile). > The profile names can be changed regularly, so it looks like it will be better to put them in the guest level, so that the network host file won't have to be changed on all hosts once something has changed in the profiles. Also, you will have a duplication of data, writing all the profile name on all the hosts that are connected to the vn-link/vepa switch. > > > so it will be a mistake to define a profile to be interface > > specific on the host. Moreover, putting it in the guest level will > > enable us in the future (if supported by libvirt/qemu) to migrate > > a vm from a host with vepa/vnlink interfaces, to another host with > > a bridge, for example. > > It seems to me like doing exactly the opposite would make it easier to > migrate to a host that used a different kind of switching (from vepa > to > vnlink, or from a bridged interface to vepa, etc), since the port > profile required for a particular host's network would be at the host > waiting to be used. You are right, but we would want to have the option to prevent that from happening in case we wouldn't want to allow it. We can make the ability to migrate between different network types configurable, and we would like an easy way to tell libvirt - "please allow/don't allow it". > > > So, in the networks at the host level you will have: > > <network type='direct'> > > <name>red-network</name> > > <source mode='vepa'> > > <pool> > > <interface> > > <name>eth0</name> > > ..... > > </interface> > > <interface> > > <name>eth4</name> > > ..... > > </interface> > > <interface> > > <name>eth18</name> > > ..... > > </interface> > > </pool> > > </source> > > </network> > > > > And in the guest you will have (for vepa): > > <interface type='network'> > > <source network='red-network'/> > > <virtualport type="802.1Qbg"> > > <parameters managerid="11" typeid="1193047" typeidversion="2" > > instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/> > > </virtualport> > > </interface> > > > > Or (for vnlink): > > <interface type='network'> > > <source network='red-network'/> > > <virtualport type="802.1Qbh"> > > <parameters profile_name="profile1"/> > > </virtualport> > > </interface> > > This illustrates the problem I was wondering about - in your example > it > would not be possible for the guest to migrate from the host using a > vepa switch to the host using a vnlink switch (and it would be > possible You are right. When trying to migrate between vepa and vnlink there will be missing attributes in each in case we leave it on the host. > to migrate to a host using a standard bridge only if the virtualport > element was ignored). If the virtualport element lived with the > network > definition of red-network on each host, it could be migrated without > problem. > > The only problematic thing would be if any of the attributes within > <parameters> was unique for each guest (I don't know anything about > the > individual attributes, but "instanceid" sounds like it might be > different for each guest). > > > Then, when migrating from a vepa/vnlink host to another vepa/vnlink > > host containing red-network, the profile attributes will be > > available at the guest domain xml. > > In case the target host has a red-network, which isn't vepa/vnlink, > > we want to be able to choose whether to make the use of the profile > > attributes optional (i.e., libvirt won't fail in case of migrating > > to a network of another type), or mandatory (i.e., libvirt will fail > > in case of migration to a non-vepa/vnlink network). > > > > We have something similar in CPU flags: > > <cpu match="exact"> > > <model>qemu64</model> > > <topology sockets="S" cores="C" threads="T"/> > > <feature policy="require/optional/disable......" > > name="sse2"/> > > </cpu> > > In this analogy, does "CPU flags" == "mode (vepa/vnlink/bridge)" or > does > "CPU flags" == "virtualport parameters" ? It seems like what you're > wanting can be satisfied by simply not defining "red-network" on the > hosts that don't have the proper networking setup available (maybe > what > you *really* want to call it is "red-vnlink-network"). What I meant to say in that is that we would like to have the ability to say if an attribute must me used, or not. The issues you mention are indeed interesting. I'm cc-ing libvirt-list to see what other people think. Putting it on the guest will indeed make it problematic to migrate between networks that need different parameters (vnlink/vepa for example). Oved

7 11

[libvirt] [BUG] Xen->libvirt: localtime reported as UTC
by Philipp Hahn 05 Sep '11

05 Sep '11

Hello, just a report, no fix for that bug yet. If I create a domain and set <clock offset='localtime'/>, that information is correctly translated to Xends sxpr data, but on reading it back I get it reported as 'utc': # virsh dumpxml 85664d3f-68dd-a4c2-4d2f-be7f276b95f0 | grep clock <clock offset='utc'/> # gfind localtime ./85664d3f-68dd-a4c2-4d2f-be7f276b95f0/config.sxp: (platform ((device_model /usr/lib64/xen/bin/qemu-dm) (localtime 1))) ./85664d3f-68dd-a4c2-4d2f-be7f276b95f0/config.sxp: (localtime 1) BYtE Philipp -- Philipp Hahn Open Source Software Engineer hahn(a)univention.de Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/

3 6

[libvirt] [PATCH] Add directsync cache mode support for disk driver
by Osier Yang 05 Sep '11

05 Sep '11

Newer QEMU introduced cache=directsync for -drive, this patchset is to expose it in libvirt layer. * Introduced a new QEMU capability flag ($prefix_CACHE_DIRECTSYNC), As even $prefix_CACHE_V2 is set, we can't known if directsync is supported. --- docs/formatdomain.html.in | 2 +- docs/schemas/domain.rng | 1 + src/conf/domain_conf.c | 3 ++- src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 6 +++++- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 29 ++++++++++++++++++++++------- tests/qemuargv2xmltest.c | 1 + tests/qemuxml2argvtest.c | 3 +++ tools/virsh.pod | 3 ++- 10 files changed, 39 insertions(+), 11 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index f46771d..6cb36d3 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -976,7 +976,7 @@ <li> The optional <code>cache</code> attribute controls the cache mechanism, possible values are "default", "none", - "writethrough" and "writeback". + "writethrough", "writeback", and "directsync". <span class="since">Since 0.6.0</span> </li> <li> diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index dd8c41a..e43b17d 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -829,6 +829,7 @@ <value>none</value> <value>writeback</value> <value>writethrough</value> + <value>directsync</value> </choice> </attribute> </define> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 00212db..a2de8df 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -160,7 +160,8 @@ VIR_ENUM_IMPL(virDomainDiskCache, VIR_DOMAIN_DISK_CACHE_LAST, "default", "none", "writethrough", - "writeback") + "writeback", + "directsync") VIR_ENUM_IMPL(virDomainDiskErrorPolicy, VIR_DOMAIN_DISK_ERROR_POLICY_LAST, "default", diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 8382d28..0abb75e 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -165,6 +165,7 @@ enum virDomainDiskCache { VIR_DOMAIN_DISK_CACHE_DISABLE, VIR_DOMAIN_DISK_CACHE_WRITETHRU, VIR_DOMAIN_DISK_CACHE_WRITEBACK, + VIR_DOMAIN_DISK_CACHE_DIRECTSYNC, VIR_DOMAIN_DISK_CACHE_LAST }; diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index f665de4..631d683 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -125,6 +125,7 @@ VIR_ENUM_IMPL(qemuCaps, QEMU_CAPS_LAST, "sga", "virtio-blk-pci.event_idx", "virtio-net-pci.event_idx", + "cache-directsync", ); struct qemu_feature_flags { @@ -902,8 +903,11 @@ qemuCapsComputeCmdFlags(const char *help, if (strstr(help, "-drive")) { qemuCapsSet(flags, QEMU_CAPS_DRIVE); if (strstr(help, "cache=") && - !strstr(help, "cache=on|off")) + !strstr(help, "cache=on|off")) { qemuCapsSet(flags, QEMU_CAPS_DRIVE_CACHE_V2); + if (strstr(help, "directsync")) + qemuCapsSet(flags, QEMU_CAPS_DRIVE_CACHE_DIRECTSYNC); + } if (strstr(help, "format=")) qemuCapsSet(flags, QEMU_CAPS_DRIVE_FORMAT); if (strstr(help, "readonly=")) diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index 13af0b9..c01d438 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -100,6 +100,7 @@ enum qemuCapsFlags { QEMU_CAPS_SGA = 62, /* Serial Graphics Adapter */ QEMU_CAPS_VIRTIO_BLK_EVENT_IDX = 63, /* virtio-blk-pci.event_idx */ QEMU_CAPS_VIRTIO_NET_EVENT_IDX = 64, /* virtio-net-pci.event_idx */ + QEMU_CAPS_DRIVE_CACHE_DIRECTSYNC = 65, /* Is cache=directsync supported? */ QEMU_CAPS_LAST, /* this must always be the last item */ }; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 44a553b..fa52dc0 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -64,14 +64,16 @@ VIR_ENUM_DECL(qemuDiskCacheV2) VIR_ENUM_IMPL(qemuDiskCacheV1, VIR_DOMAIN_DISK_CACHE_LAST, "default", "off", - "off", /* writethrough not supported, so for safety, disable */ - "on"); /* Old 'on' was equivalent to 'writeback' */ + "off", /* writethrough not supported, so for safety, disable */ + "on", /* Old 'on' was equivalent to 'writeback' */ + "off"); /* directsync not supported, for safety, disable */ VIR_ENUM_IMPL(qemuDiskCacheV2, VIR_DOMAIN_DISK_CACHE_LAST, "default", "none", "writethrough", - "writeback"); + "writeback", + "directsync"); VIR_ENUM_DECL(qemuVideo) @@ -1516,10 +1518,21 @@ qemuBuildDriveStr(virDomainDiskDefPtr disk, } if (disk->cachemode) { - const char *mode = - qemuCapsGet(qemuCaps, QEMU_CAPS_DRIVE_CACHE_V2) ? - qemuDiskCacheV2TypeToString(disk->cachemode) : - qemuDiskCacheV1TypeToString(disk->cachemode); + const char *mode = NULL; + + if (qemuCapsGet(qemuCaps, QEMU_CAPS_DRIVE_CACHE_V2)) { + mode = qemuDiskCacheV2TypeToString(disk->cachemode); + + if (disk->cachemode == VIR_DOMAIN_DISK_CACHE_DIRECTSYNC && + !qemuCapsGet(qemuCaps, QEMU_CAPS_DRIVE_CACHE_DIRECTSYNC)) { + qemuReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("disk cache mode 'directsync' is not " + "supported by this QEMU")); + goto error; + } + } else { + mode = qemuDiskCacheV1TypeToString(disk->cachemode); + } virBufferAsprintf(&opt, ",cache=%s", mode); } else if (disk->shared && !disk->readonly) { @@ -5211,6 +5224,8 @@ qemuParseCommandLineDisk(virCapsPtr caps, def->cachemode = VIR_DOMAIN_DISK_CACHE_WRITEBACK; else if (STREQ(values[i], "writethrough")) def->cachemode = VIR_DOMAIN_DISK_CACHE_WRITETHRU; + else if (STREQ(values[i], "directsync")) + def->cachemode = VIR_DOMAIN_DISK_CACHE_DIRECTSYNC; } else if (STREQ(keywords[i], "werror") || STREQ(keywords[i], "rerror")) { if (STREQ(values[i], "stop")) diff --git a/tests/qemuargv2xmltest.c b/tests/qemuargv2xmltest.c index c2b6cf2..91f15af 100644 --- a/tests/qemuargv2xmltest.c +++ b/tests/qemuargv2xmltest.c @@ -168,6 +168,7 @@ mymain(void) DO_TEST("disk-drive-cache-v2-wt"); DO_TEST("disk-drive-cache-v2-wb"); DO_TEST("disk-drive-cache-v2-none"); + DO_TEST("disk-drive-cache-directsync"); DO_TEST("disk-drive-network-nbd"); DO_TEST("disk-drive-network-rbd"); DO_TEST("disk-drive-network-sheepdog"); diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 6e8da5e..b009bf3 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -338,6 +338,9 @@ mymain(void) QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_CACHE_V2, QEMU_CAPS_DRIVE_FORMAT); DO_TEST("disk-drive-cache-v2-none", false, QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_CACHE_V2, QEMU_CAPS_DRIVE_FORMAT); + DO_TEST("disk-drive-cache-directsync", false, + QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_CACHE_V2, + QEMU_CAPS_DRIVE_CACHE_DIRECTSYNC, QEMU_CAPS_DRIVE_FORMAT); DO_TEST("disk-drive-network-nbd", false, QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_FORMAT); DO_TEST("disk-drive-network-rbd", false, diff --git a/tools/virsh.pod b/tools/virsh.pod index b90c26e..5ac2c5c 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -1099,7 +1099,8 @@ floppy device; consider using B<update-device> for this usage instead. I<mode> can specify the two specific mode I<readonly> or I<shareable>. I<persistent> indicates the changes will affect the next boot of the domain. I<sourcetype> can indicate the type of source (block|file) -I<cache> can be one of "default", "none", "writethrough" or "writeback". +I<cache> can be one of "default", "none", "writethrough", "writeback", or +"directsync". I<serial> is the serial of disk device. I<shareable> indicates the disk device is shareable between domains. I<address> is the address of disk device in the form of pci:domain.bus.slot.function, -- 1.7.6

3 6

Re: [libvirt] [RFC] block I/O throttling: how to enable in libvirt
by Zhi Yong Wu 05 Sep '11

05 Sep '11

On Fri, Sep 02, 2011 at 08:34:19AM -0500, Adam Litke wrote: >From: Adam Litke <agl(a)us.ibm.com> >To: Zhi Yong Wu <wuzhy(a)linux.vnet.ibm.com> >Cc: libvir-list(a)redhat.com >Subject: Re: [libvirt] [RFC] block I/O throttling: how to enable in libvirt >Message-ID: <20110902133419.GW15683(a)aglitke.rchland.ibm.com> >References: <20110901050531.GB17963(a)f15.cn.ibm.com> > <20110902021447.GD19143(a)f15.cn.ibm.com> >MIME-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >In-Reply-To: <20110902021447.GD19143(a)f15.cn.ibm.com> >User-Agent: Mutt/1.5.21 (2010-09-15) >X-Brightmail-Tracker: AAAAAA== >X-Xagent-From: agl(a)us.ibm.com >X-Xagent-To: wuzhy(a)linux.vnet.ibm.com >X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGENTU8 at VMSDVMA) > >On Fri, Sep 02, 2011 at 10:14:48AM +0800, Zhi Yong Wu wrote: >> On Thu, Sep 01, 2011 at 01:05:31PM +0800, Zhi Yong Wu wrote: >> HI, Adam, >> Now stefan, Daniel, and Gui all suggest extending blkiotune to keep libivrt unified interface. What do you think of it? > >It seems like it would be nice to extend the blkiotune API for this use case, >but there is one problem. The blkiotune interface operates at the VM level and >the QEMU throttling is at the disk level. So if you want per-disk throttling >granularity the blkiotune API may not be suitable. I see 3 possible paths >forward: > >1) Accept the blkiotune limitation of a global setting and add a throttle option >that assigns the same throttle value to all disks. > > <blkiotune> > <shares>250</shares> > <throttle>1024</throttle> > </blkiotune> > > + Nice for simplicity and ease of implementation > - May be too simplistic (can't set different throttling for different disks) > > >2) Extend the blkiotune API to allow per-disk tunings: > > <blkiotune> > <shares>250</shares> > <throttle device='virtio-disk0'>1024</throttle> > </blkiotune> > > + Use an existing API > - Unfortunately it doesn't look like this can be done cleanly > > >3) Use a new API virDomainSetBlkDevParameters() to set device specific >tuning parameters: > ><blkiotune> > <shares>250</shares> ></blkiotune> >... ><disk type='file' device='disk'> > <driver name='qemu' type='raw'/> > <source file='...'/> > <target dev='vda' bus='virtio'/> > <blkdevtune> > <throttle>1024</throttle> Several I/O throttling tags should be supported, such as thrbps, thrbpsrd, thrbpswr, thriops, etc. > </blkdevtune> ></disk> > > + Throttle can be specified with the disk it is effecting > - Proliferation of tuning APIs > > >Obviously #1 is the best if you can accept the limitations of the API. #2 would #1 is not accepted by us. If it is adopted, the advantage of QEMU I/O throttling is not used fully. >be nice if we could figure out how to extend virTypedParameter to represent a I guess that #2 is less extendable than #3. >(disk, param) pair. I see #3 as a last resort. Did I miss any other solutions. To be honest, i prefer to #3. At first, i plan to check how blkiotune works currently. >Did I just manage to completely over-complicate this? :) NO, they are nice. thanks. Regards, Zhiyong Wu > >-- >Adam Litke <agl(a)us.ibm.com> >IBM Linux Technology Center

1 0

[libvirt] [test-API][PATCH] Add 2 methods to generate cdrom & floppy XML for test
by Nan Zhang 05 Sep '11

05 Sep '11

add the following 2 functions to utils/Python/xmlbuilder.py * build_cdrom() * build_floppy() --- utils/Python/xmlbuilder.py | 47 +++++++++++++++++++++++++++++++++++++++++- utils/Python/xmlgenerator.py | 15 +++++++------ 2 files changed, 54 insertions(+), 8 deletions(-) diff --git a/utils/Python/xmlbuilder.py b/utils/Python/xmlbuilder.py index 78230da..5a0f8c8 100644 --- a/utils/Python/xmlbuilder.py +++ b/utils/Python/xmlbuilder.py @@ -112,6 +112,33 @@ class XmlBuilder: self.write_toxml(disk) return disk.toxml() + def build_cdrom(self, params): + if params.get('hdmodel', None) == None: + params['hdmodel'] = 'ide' + + if params['hdmodel'] == 'ide': + target_dev = 'hdc' + elif params['hdmodel'] == 'scsi': + target_dev = 'sdc' + else: + print 'Wrong cdrom model.' + + cdrom = xmlgenerator.disk_xml(params, True) + if params['guesttype'] == 'xenpv': + cdrom.getElementsByTagName("target")[0].setAttribute("dev", "xvdc") + else: + cdrom.getElementsByTagName("target")[0].setAttribute("dev", + target_dev) + if __DEBUG__: + self.write_toxml(cdrom) + return cdrom.toxml() + + def build_floppy(self, params): + floppy = xmlgenerator.floppy_xml(params) + if __DEBUG__: + self.write_toxml(floppy) + return floppy.toxml() + def build_interface(self, params): interface = xmlgenerator.interface_xml(params) if __DEBUG__: @@ -177,11 +204,29 @@ if __name__ == "__main__": print '=' * 30, 'disk xml', '=' * 30 params['guesttype'] = 'kvm' params['guestname'] = 'foo' - params['imagepath'] = '/images' params['hdmodel'] = 'virtio' diskxml = xmlobj.build_disk(params) + #--------------------- + # get cdrom xml string + #--------------------- + print '=' * 30, 'cdrom xml', '=' * 30 + params['guesttype'] = 'kvm' + params['guestname'] = 'foo' + params['hdmodel'] = 'ide' + params['bootcd'] = '/tmp/cdrom.img' + + cdromxml = xmlobj.build_cdrom(params) + + #--------------------- + # get floppy xml string + #--------------------- + print '=' * 30, 'floppy xml', '=' * 30 + params['floppysource'] = '/tmp/floppy.img' + + floppyxml = xmlobj.build_floppy(params) + #-------------------------- # get interface xml string #-------------------------- diff --git a/utils/Python/xmlgenerator.py b/utils/Python/xmlgenerator.py index c59ca9e..d57dd33 100644 --- a/utils/Python/xmlgenerator.py +++ b/utils/Python/xmlgenerator.py @@ -308,7 +308,7 @@ def disk_xml(params, cdrom = False): params['guestname'] elif hypertype == 'xen': params['imagepath'] = '/var/lib/xen/images' - params['fullimagepath'] = '/var/lib/xen/images' + '/' + \ + params['fullimagepath'] = params['imagepath'] + '/' + \ params['guestname'] else: print 'DO NOT supported hypervisor.' @@ -367,14 +367,15 @@ def disk_xml(params, cdrom = False): def floppy_xml(params): # Disk element floppy = xml.dom.minidom.Document() - disk_element = floppy.createElement('disk') - disk_element.setAttribute('device', 'floppy') - floppy.appendChild(disk_element) + floppy_element = floppy.createElement('disk') + floppy_element.setAttribute('type', 'file') + floppy_element.setAttribute('device', 'floppy') + floppy.appendChild(floppy_element) # Source element source_element = floppy.createElement('source') source_element.setAttribute('file', params['floppysource']) - disk_element.appendChild(source_element) + floppy_element.appendChild(source_element) # Target element target_element = floppy.createElement('target') @@ -384,11 +385,11 @@ def floppy_xml(params): target_element.setAttribute('dev', 'fda') target_element.setAttribute('bus', 'fdc') - disk_element.appendChild(target_element) + floppy_element.appendChild(target_element) # Readonly readonly = floppy.createElement('readonly') - disk_element.appendChild(readonly) + floppy_element.appendChild(readonly) return floppy -- 1.7.4.4

2 1

[libvirt] [PATCH] libvirtd: create run dir when running at non-root user
by xuhj＠linux.vnet.ibm.com 05 Sep '11

05 Sep '11

From: Xu He Jie <xuhj(a)linux.vnet.ibm.com> Signed-off-by: Xu He Jie <xuhj(a)linux.vnet.ibm.com> When libvirtd is running at non-root user, it won't create ${HOME}/.libvirt. It will show error message: 17:44:16.838: 7035: error : virPidFileAcquirePath:322 : Failed to open pid file --- daemon/libvirtd.c | 46 ++++++++++++++++++++++++++++++++-------------- 1 files changed, 32 insertions(+), 14 deletions(-) diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c index 423c3d7..e0004c7 100644 --- a/daemon/libvirtd.c +++ b/daemon/libvirtd.c @@ -1249,6 +1249,7 @@ int main(int argc, char **argv) { bool privileged = geteuid() == 0 ? true : false; bool implicit_conf = false; bool use_polkit_dbus; + char *run_dir = NULL; struct option opts[] = { { "verbose", no_argument, &verbose, 1}, @@ -1403,21 +1404,35 @@ int main(int argc, char **argv) { /* Ensure the rundir exists (on tmpfs on some systems) */ if (privileged) { - const char *rundir = LOCALSTATEDIR "/run/libvirt"; - mode_t old_umask; - - old_umask = umask(022); - if (mkdir (rundir, 0755)) { - if (errno != EEXIST) { - char ebuf[1024]; - VIR_ERROR(_("unable to create rundir %s: %s"), rundir, - virStrerror(errno, ebuf, sizeof(ebuf))); - ret = VIR_DAEMON_ERR_RUNDIR; - umask(old_umask); - goto cleanup; - } + run_dir = strdup(LOCALSTATEDIR "/run/libvirt"); + if (!run_dir) { + VIR_ERROR(_("Can't allocate memory")); + goto cleanup; + } + } + else { + char *user_dir = NULL; + + if (!(user_dir = virGetUserDirectory(geteuid()))) { + VIR_ERROR(_("Can't determine user directory")); + goto cleanup; + } + + if (virAsprintf(&run_dir, "%s/.libvirt/", user_dir) < 0) { + VIR_ERROR(_("Can't allocate memory")); + VIR_FREE(user_dir); + goto cleanup; } - umask(old_umask); + + VIR_FREE(user_dir); + } + + if (virFileMakePath(run_dir) < 0) { + char ebuf[1024]; + VIR_ERROR(_("unable to create rundir %s: %s"), run_dir, + virStrerror(errno, ebuf, sizeof(ebuf))); + ret = VIR_DAEMON_ERR_RUNDIR; + goto cleanup; } /* Try to claim the pidfile, exiting if we can't */ @@ -1571,6 +1586,9 @@ cleanup: VIR_FREE(sock_file_ro); VIR_FREE(pid_file); VIR_FREE(remote_config_file); + if (run_dir) + VIR_FREE(run_dir); + daemonConfigFree(config); virLogShutdown(); -- 1.7.4.1

3 3

[libvirt] [PATCH 1/2] Fix error detection in device change
by Philipp Hahn 03 Sep '11

03 Sep '11

According to qemu-kvm/qerror.c all messages start with a capital "Device ", but the current code only scans for the lower case "device ". This results in "virDomainUpdateDeviceFlags()" to not detect locked CD-ROMs and reporting success even in the case of a failure: # virsh qemu-monitor-command "$VM" change\ drive-ide0-0-0\ \"/var/lib/libvirt/images/ucs_2.4-0-sec4-20110714145916-dvd-amd64.iso\" Device 'drive-ide0-0-0' is locked # virsh update-device "$VM" /dev/stdin <<<"<disk type='file' device='cdrom'><driver name='qemu' type='raw'/><source file='/var/lib/libvirt/images/ucs_2.4-0-sec4-20110714145916-dvd-amd64.iso'/><target dev='hda' bus='ide'/><readonly/><alias name='ide0-0-0'/><address type='drive' controller='0' bus='0' unit='0'/></disk>" Device updated successfully Signed-off-by: Philipp Hahn <hahn(a)univention.de> --- src/qemu/qemu_monitor_text.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c index 52d924a..98d9169 100644 --- a/src/qemu/qemu_monitor_text.c +++ b/src/qemu/qemu_monitor_text.c @@ -1064,7 +1064,7 @@ int qemuMonitorTextChangeMedia(qemuMonitorPtr mon, /* If the command failed qemu prints: * device not found, device is locked ... * No message is printed on success it seems */ - if (strstr(reply, "device ")) { + if (c_strcasestr(reply, "device ")) { qemuReportError(VIR_ERR_OPERATION_FAILED, _("could not change media on %s: %s"), devname, reply); goto cleanup; -- 1.7.1

2 4

[libvirt] [v3 00/14] USB improvements and new redirdev
by Marc-André Lureau 03 Sep '11

03 Sep '11

Hei, Here we go with the third version of this patch series that leads to support for various USB controllers, USB hubs, and USB redirection devices. Major change since v2 is the creation of a new element 'redirdev' instead of reusing the existing 'hostdev'. Marc-André Lureau (14): Add various USB devices QEMU_CAPS Split virDomainControllerModel to virDomainControllerModelSCSI Add USB controller models Add a new controller type 'usb' with optionnal 'model' USB controller can have a PCI address child element USB devices gain a new USB address child element Add USB companion controllers support Add USB hub device Modify USB port to be defined as a port path qemu: don't reserve slot 1 if a PIIX3 USB controller is defined there qemu: Don't append 0 at usb id, so that it is compatible with legacy -usb Add a usb1 & usb2 qemuxml2argv test Add "redirdev" redirection device Learn to use spicevmc as a redirection type for usb-redir docs/formatdomain.html.in | 105 +++++- docs/schemas/domain.rng | 100 ++++- src/conf/domain_audit.c | 65 +++ src/conf/domain_audit.h | 5 + src/conf/domain_conf.c | 443 +++++++++++++++++++- src/conf/domain_conf.h | 104 +++++- src/esx/esx_driver.c | 8 +- src/libvirt_private.syms | 11 +- src/qemu/qemu_capabilities.c | 28 ++ src/qemu/qemu_capabilities.h | 9 + src/qemu/qemu_command.c | 342 ++++++++++++++- src/qemu/qemu_command.h | 14 +- src/qemu/qemu_driver.c | 7 + src/qemu/qemu_hotplug.c | 55 +++- src/qemu/qemu_hotplug.h | 3 + src/vmx/vmx.c | 32 +- tests/qemuhelptest.c | 17 +- .../qemuxml2argv-input-usbmouse-addr.args | 1 + .../qemuxml2argv-input-usbmouse-addr.xml | 27 ++ .../qemuxml2argv-usb-controller.args | 1 + .../qemuxml2argv-usb-controller.xml | 16 + tests/qemuxml2argvdata/qemuxml2argv-usb-hub.args | 1 + tests/qemuxml2argvdata/qemuxml2argv-usb-hub.xml | 19 + .../qemuxml2argv-usb-ich9-companion.args | 6 + .../qemuxml2argv-usb-ich9-companion.xml | 30 ++ .../qemuxml2argv-usb-ich9-ehci-addr.args | 1 + .../qemuxml2argv-usb-ich9-ehci-addr.xml | 18 + .../qemuxml2argv-usb-piix3-controller.args | 1 + .../qemuxml2argv-usb-piix3-controller.xml | 16 + tests/qemuxml2argvdata/qemuxml2argv-usb-ports.args | 1 + tests/qemuxml2argvdata/qemuxml2argv-usb-ports.xml | 31 ++ tests/qemuxml2argvdata/qemuxml2argv-usb-redir.args | 10 + tests/qemuxml2argvdata/qemuxml2argv-usb-redir.xml | 40 ++ tests/qemuxml2argvdata/qemuxml2argv-usb1-usb2.args | 15 + tests/qemuxml2argvdata/qemuxml2argv-usb1-usb2.xml | 74 ++++ tests/qemuxml2argvtest.c | 30 ++ tests/qemuxml2xmltest.c | 2 + tests/xml2vmxtest.c | 2 +- 38 files changed, 1598 insertions(+), 92 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-input-usbmouse-addr.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-input-usbmouse-addr.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-controller.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-controller.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-hub.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-hub.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-ich9-companion.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-ich9-companion.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-ich9-ehci-addr.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-ich9-ehci-addr.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-piix3-controller.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-piix3-controller.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-ports.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-ports.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-redir.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-redir.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb1-usb2.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb1-usb2.xml -- 1.7.6

5 26

[libvirt] [PATCH 0/8] Report disk latency info
by Osier Yang 02 Sep '11

02 Sep '11

This patch series introduces a new API to report the disk latency related information, which is supported by upstream QEMU just a few days ago (commit c488c7f649, Thu Aug 25). Per previous dicussion on the ABI compatiblity, and API design principle, the new API is defined with style: typedef struct _virDomainBlockStatsFlags virDomainBlockStatsFlagsStruct; typedef virDomainBlockStatsFlagsStruct *virDomainBlockStatsFlagsPtr; struct _virDomainBlockStatsFlags { char field[VIR_DOMAIN_BLOCK_STATS_FIELD_LENGTH]; long long value; }; int virDomainBlockStatsFlags (virDomainPtr dom, const char *path, virDomainBlockStatsFlagsPtr params, int *nparams, unsigned int flags) Other points: 1) With the new API, output of virsh command "domblkstat" is different, this might affect the existed scripts. But considering we are even introducing new feilds, so this can be fine? 2) qemuMonitorJSONGetBlockStatsInfo set "*errs = 0" before, it will cause "domblkstat" always print things like "vda errs 0". However, QEMU doesn't support this field. Fixed it in these patches (*errs = -1). And new API qemuDomainBlockStatsFlags won't even set a field for "errs". 3) Is it deserved to update gendispatch.pl to generate remote codes for functions take argument like "virNodeCPUStatsPtr params", "virNodeMemoryStatsPtr params"? All of these argument points to structs has same structure. Perhaps we can define an alias for these structs and generate the remote codes just like for "virTypedParameterPtr params". [PATCH 1/8] latency: Define new public API and structure [PATCH 2/8] latency: Define the internal driver callback [PATCH 3/8] latency: Implemente the public API [PATCH 4/8] latency: Wire up the remote protocol [PATCH 5/8] latency: Update monitor functions for new latency fields [PATCH 6/8] latency: Implemente internal API for qemu driver [PATCH 7/8] latency: Expose the new API for Python binding [PATCH 8/8] latency: Update cmdBlkStats to use new API Regards, Osier

3 24