- Devel - libvirt List Archives

Re: [libvirt] [openstack-dev] [nova] live-snapshot/cloning of virtual machines
by Andres Lagar-Cavilla 16 Aug '13

16 Aug '13

> On Fri, Aug 16, 2013 at 11:05:19AM +0100, Daniel P. Berrange wrote: >> On Wed, Aug 14, 2013 at 04:53:01PM -0700, Vishvananda Ishaya wrote: >>> Hi Everyone, >>> >>> I have been trying for some time to get the code for the live-snapshot blueprint[1] >>> in. Going through the review process for the rpc and interface code[2] was easy. I >>> suspect the api-extension code[3] will also be relatively trivial to get in. The >>> main concern is with the libvirt driver implementation[4]. I'd like to discuss the >>> concerns and see if we can make some progress. >>> >>> Short Summary (tl;dr) >>> ===================== >>> >>> I propose we merge live-cloning as an experimental feature for havanna and have the >>> api extension disabled by default. >>> >>> Overview >>> ======== >>> >>> First of all, let me express the value of live snapshoting. The >>> slowest part of the vm provisioning process is generally booting >>> of the OS. > > Like Dan I'm dubious about this whole plan. But this ^^ statement in > particular. I would like to see hard data to back this up. What we need to keep in mind is that "boot" is a small part of the picture, at least "boot" as commonly referred to in Linux. Consider a web sphere-like Java bundle of code. These things take a while to load. JiT-ed methods provide a tremendous performance boost. Nevermind if the the server constructs secondary indices to perform fast lookups of data. That is just Linux. Windows is well known for pounding storage fabrics with thousands of small reads during boot storms. Certainly a boot Windows sequence has baked in a lot of service startup sequences that prime a lot of memory content for performance objectives. Boot here means "ready to rock-n-roll", not "Cirros is up." We have live deployments that are based on bypassing the entire *application startup* sequence and have a server ready to provide high-performance responses to queries once spawned from a live saved image. > > You should be able to boot an OS pretty quickly, and furthermore it's > (a) much safer for all the reasons Dan outlines, and (b) improvements > that you make to boot times help everyone. > > [...] >>> 2. Security Concerns >>> ==================== >>> >>> There are a number of security issues with loading state from another vm. Here is a >>> short list of things that need to be done just to make a cloned vm usable: >>> >>> a) mac address needs to be recreated >>> b) entropy pool needs to be reset >>> c) host name must be reset >>> d) host keys bust be regenerated >>> >>> There are others, and trying to clone a running application as well may expose other >>> sensitive data, especially if users are snaphsoting vms and making them public. > > Are we talking about cloning VMs that you already trust, or cloning > random VMs and allowing random other users to use them? These would > lead to very different solutions. In the first case, you only care > about correctness, not security. In the second case, you care about > security as well as correctness. Case number one. The correctness issues are a hard problem, and a particularly hard one in Windows, but it is pragmatically solvable. For a common scenario in Linux, renewing dhcp leases and leveling your entropy pool are what you need. > > I highly doubt the second case is possible because scrubbing the disk > is going to take far too long for any supposed time-saving to matter. That would be very counter-productive, so yes, focusing on the first case. > > As Dan says, even the first case is dubious because it won't be correct. > >> The libguestfs project provide tools to perform offline cloning of >> VM disk images. Its virt-sysprep knows how to delete alot (but by >> no means all possible) sensitive file data for common Linux & >> Windows OS. It still has to be combined with use of the >> virt-sparsify tool though, to ensure the deleted data is actually >> purged from the VM disk image as well as the filesystem, by >> releasing all unused VM disk sectors back to the host storage (and >> not all storage supports that). > > Links to the tools that Dan mentions: > > http://libguestfs.org/virt-sysprep.1.html > http://libguestfs.org/virt-sparsify.1.html Virt-sparsify is not strictly relevant here. The disk side of live images is carried out with qcow2. Virt-sysprep is great work and highly relevant. But virt-sysprep allows us to see the argument in a different light. Have you noticed nova does not run virt-sysprep before booting an ephemeral instance from an image? (AFAIK, could be wrong, not even regenerating host ssh keys is part of the assured workflow). Furthermore, one can create arbitrary (cold, non-live) images at any time, from live instances This isn't necessarily wrong. It underpins massive deployments, it pragmatically adds value. The fundamental semantics at play with live-instances are the same: know what you are doing, ephemeral instances, bound to your tenant. So as long as we take care of not weakening cryptographic foundations and correctly reconfiguring the identity, all the principles above still apply: know what you are doing, ephemeral instances, bound to your tenant. We are working on proof-of-concept using the qemu guest agent to undertake all these tasks. It is PoC to show it's doable. It's neither clean nor asking for mainline merge (at the moment). It's not the only solution for the guest side problem. An one final very important note for the libvirt list and those who may be tuning in just now: no changes to libvirt are being asked for here. This is a nova-side tech preview feature. Best, Andres > > Note these tools can only be used on offline machines. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > virt-top is 'top' for virtual machines. Tiny program with many > powerful monitoring features, net stats, disk stats, logging, etc. > http://people.redhat.com/~rjones/virt-top

1 0

Re: [libvirt] [openstack-dev] [nova] live-snapshot/cloning of virtual machines
by Daniel P. Berrange 16 Aug '13

16 Aug '13

On Wed, Aug 14, 2013 at 04:53:01PM -0700, Vishvananda Ishaya wrote: > Hi Everyone, > > I have been trying for some time to get the code for the live-snapshot blueprint[1] > in. Going through the review process for the rpc and interface code[2] was easy. I > suspect the api-extension code[3] will also be relatively trivial to get in. The > main concern is with the libvirt driver implementation[4]. I'd like to discuss the > concerns and see if we can make some progress. > > Short Summary (tl;dr) > ===================== > > I propose we merge live-cloning as an experimental feature for havanna and have the > api extension disabled by default. > > Overview > ======== > > First of all, let me express the value of live snapshoting. The slowest part of the > vm provisioning process is generally booting of the OS. The advantage of live- > snapshotting is that it allows the possibility of bringing up application servers > while skipping the overhead of vm (and application startup). For Linux at least I think bootup time is a problem that is being solved by the distros. It is possible to boot up many modern Linux distros in a couple of seconds even in physical hardware - VMs can be even faster since they don't have such stupid BIOS to worry about & have a restricted set of possible hardware. This is on a par with, or better than, the overheads imposed by Nova itself in the boot up process. Windows may be a different story, but I've not used it in years so don't know what its boot performance is like. > I recognize that this capability comes with some security concerns, so I don't expect > this feature to go in and be ready to for use in production right away. Similarly, > containers have a lot of the same benefit, but have had their own security issues > which are gradually being resolved. My hope is that getting this feature in would > allow people to start experimenting with live-booting so that we could uncover some > of these security issues. > > There are two specific concerns that have been raised regarding my patch. The first > concern is related to my use of libvirt. The second concern is related to the security > issues above. Let me address them separately. > > 1. Libvirt Issues > ================= > > The only feature I require from the hypervisor is to load memory/processor state for > a vm from a file. Qemu supports this directly. The only way that libvirt exposes this > functionality is via its restore command which is specifically for restoring the > previous state of an existing vm. "Cloning", or restoring the memory state of a > cloned vm is considered unsafe (which I will address in the second point, below). > > The result of the limited api is that I must include some hacks to make the restore > command actually allow me to restore the state of the new vm. I recognize that this > is using an undocumented libvirt api and isn't the ideal solution, but it seemed > "better" then avoiding libvirt and talking directly to qemu. > > This is obviously not ideal. It is my hope that this 0.1 version of the feature will > allow us to iteratively improve the live-snapshot/clone proccess and get the security > to a point where the libvirt maintainers would be willing to accept a patch to directly > expose an api to load memory from a file. To characterize this as a libvirt issue is somewhat misleading. The reason why libvirt does not explicitly allow this, is that from discussions with the upstream QEMU/KVM developers, the recommendation/advise that this is not a safe operation and should not be exposed to application developers. The expectation is that the functionality in QEMU is only targetted for taking point in time snapshots & allowing rollback of a VM to those snapshots, not creating clones of active VMs. > 2. Security Concerns > ==================== > > There are a number of security issues with loading state from another vm. Here is a > short list of things that need to be done just to make a cloned vm usable: > > a) mac address needs to be recreated > b) entropy pool needs to be reset > c) host name must be reset > d) host keys bust be regenerated > > There are others, and trying to clone a running application as well may expose other > sensitive data, especially if users are snaphsoting vms and making them public. > > The only issue that I address on the driver side is the mac addresses. This is the > minimum that needs to be done just to be able to access the vm over the network. This > is implemented by unplugging all network devices before the snapshot and plugging new > network devices in on clone. This isn't the most friendly thing to guest applications, > but it seems like the safest option for the first version of this feature. This is not really as safe as you portray. When restoring from the snapshot the VM will initially be running with virtual NIC with a different MAC address from the one associated with the in memory OS kernel state. Even if you hotunplug the device and plug in a new one, you still have a period where the virtual hardware exposed to the guest does not match the memory state of the guest OS. Perhaps you will be lucky and not hit problems with some OS, but equally you can be unlucky and do bad things to the OS kernel or application state. Relying on luck in this way does not lead to a supportable solution IMHO. There are other unique identifiers exposed in the virtual hardware that will/should change when you clone VMs too, the host UUID, the storage serial keys and you cannot easily fix those by just unplugging hardware & replugging it. > So cloning vms must be done with care. Sensitive data must be removed from the vm > pre-clone and new data needs to be generated post-clone. Ultimately this should all > be done via guest-agent of some sort. I have found some volunteers to make the guest > agent a reality, but it will take a bit of time to get something workable, and it > will be much more difficult if there isn't a way to test the feature. Note that even if you think you have removed security data from a VM's filesystem, it is quite likely that the data will still in fact exist in the unallocated sectors of VM's block devices and can be fairly easily recovered from them. The libguestfs project provide tools to perform offline cloning of VM disk images. Its virt-sysprep knows how to delete alot (but by no means all possible) sensitive file data for common Linux & Windows OS. It still has to be combined with use of the virt-sparsify tool though, to ensure the deleted data is actually purged from the VM disk image as well as the filesystem, by releasing all unused VM disk sectors back to the host storage (and not all storage supports that). > Conclusion > ========== > > There are obviously problems to be solved with the whole idea of live cloning, but > I think it enables some important new ways of deploying applications. Imagine for > example a PaaS built on fast-cloning vms instead of containers. This is clearly a > long term project but if we block it now it may never get the support it needs to > become a real option. > > Proposal > ======== > > I propose we allow the patch in and we leave the live-snapshot extension disabled > by default. Deployers can turn on the extension to experiment with the feature. > This will allow other hypervisors do do an implementation, and the community in > general to improve the security and usefulness of live-cloned virtual machines. > > I'm very interested in your thoughts and feedback. Thank you to everyone who made > it this far. I don't think it is a good idea to add a feature which is considered to be unsupportable by the developers of the virt platform. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

2 1

[libvirt] [test-API][PATCH] Fix the repeating display of testcase name issue when generating log.xml
by Hongming Zhang 16 Aug '13

16 Aug '13

modified: src/log_generator.py --- src/log_generator.py | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/log_generator.py b/src/log_generator.py index de18654..7685da7 100644 --- a/src/log_generator.py +++ b/src/log_generator.py @@ -70,7 +70,8 @@ class LogGenerator(object): valuedict = test_procedure[casename] test_casename = self.doc.createElement('action') - test_casename.setAttribute('name', casename) + casenamexml = casename[:casename.rfind(":")] + test_casename.setAttribute('name', casenamexml) for arg in valuedict.keys(): test_arg = self.doc.createElement('arg') -- 1.7.1

3 2

[libvirt] [PATCH] virsh-domain: Fix memleak in cmdCPUBaseline
by Peter Krempa 16 Aug '13

16 Aug '13

https://bugzilla.redhat.com/show_bug.cgi?id=997765 ==1349431== 8 bytes in 1 blocks are definitely lost in loss record 11 of 760 ==1349431== at 0x4C2A554: calloc (vg_replace_malloc.c:593) ==1349431== by 0x4E9AA3E: virAllocN (in /usr/lib64/libvirt.so.0.1001.1) ==1349431== by 0x4EF28C4: virXPathNodeSet (in /usr/lib64/libvirt.so.0.1001.1) ==1349431== by 0x130B83: cmdCPUBaseline (in /usr/bin/virsh) ==1349431== by 0x12C608: vshCommandRun (in /usr/bin/virsh) ==1349431== by 0x12889A: main (in /usr/bin/virsh) --- Pushed as trivial. tools/virsh-domain.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index ab3804a..18fcb3e 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -6238,6 +6238,7 @@ cleanup: } VIR_FREE(list); VIR_FREE(buffer); + VIR_FREE(node_list); return ret; -- 1.8.3.2

2 1

[libvirt] tests: add qemu startupPolicy testcase
by Guannan Ren 16 Aug '13

16 Aug '13

Add a group of testcase of startupPolicy features for CDROM and Harddisk. It compares the output xml string after checking the presence of disk and applying startupPolicy with expected xml string. New file: tests/qemustartuppolicytest.c TestData: tests/qemustartuppolicytestdata/ Guannan Ren(4) tests: add qemustartuppolicy testcase tests: add startuppolicy testcases for cdrom tests: add startuppolicy testcases for single harddisk tests: add startuppolicy testcase for multiple mixed harddisks tests/Makefile.am | 10 ++++- tests/qemustartuppolicytest.c | 230 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/qemustartuppolicytestdata/domain-input-cdrom-absent-policy-mandatory.xml | 28 ++++++++++++++ tests/qemustartuppolicytestdata/domain-input-cdrom-absent-policy-optional.xml | 28 ++++++++++++++ tests/qemustartuppolicytestdata/domain-input-cdrom-absent-policy-requisite.xml | 28 ++++++++++++++ tests/qemustartuppolicytestdata/domain-input-cdrom-present-policy-optional.xml | 28 ++++++++++++++ tests/qemustartuppolicytestdata/domain-input-disk-absent-policy-mandatory.xml | 27 +++++++++++++ tests/qemustartuppolicytestdata/domain-input-disk-absent-policy-optional.xml | 27 +++++++++++++ tests/qemustartuppolicytestdata/domain-input-disk-present-policy-none.xml | 27 +++++++++++++ tests/qemustartuppolicytestdata/domain-input-mixed-multiple-disks-absent-policy-mandatory.xml | 36 +++++++++++++++++ tests/qemustartuppolicytestdata/domain-input-mixed-multiple-disks-absent-policy-optional.xml | 36 +++++++++++++++++ tests/qemustartuppolicytestdata/domain-input-multiple-disks-absent-policy-optional.xml | 36 +++++++++++++++++ tests/qemustartuppolicytestdata/domain-output-cdrom-absent-policy-optional.xml | 29 ++++++++++++++ tests/qemustartuppolicytestdata/domain-output-cdrom-absent-policy-requisite.xml | 29 ++++++++++++++ tests/qemustartuppolicytestdata/domain-output-cdrom-present-policy-optional.xml | 29 ++++++++++++++ tests/qemustartuppolicytestdata/domain-output-disk-absent-policy-optional.xml | 22 +++++++++++ tests/qemustartuppolicytestdata/domain-output-disk-present-policy-none.xml | 28 ++++++++++++++ tests/qemustartuppolicytestdata/domain-output-mixed-multiple-disks-absent-policy-mandatory.xml | 36 +++++++++++++++++ tests/qemustartuppolicytestdata/domain-output-mixed-multiple-disks-absent-policy-optional.xml | 27 +++++++++++++ tests/qemustartuppolicytestdata/domain-output-multiple-disks-absent-policy-optional.xml | 22 +++++++++++ 20 files changed, 761 insertions(+), 2 deletions(-)

1 4

[libvirt] [PATCHv3 0/4] write separate module for hostdev passthrough
by cyliu＠suse.com 16 Aug '13

16 Aug '13

From: Chunyan Liu <cyliu(a)suse.com> These patches implements a separate module for hostdev passthrough so that it could be shared by different drivers and can maintain a global state of a host device. Plus, add passthrough to libxl driver, and change qemu driver and lxc driver to use hostdev common library instead of their own hostdev APIs. --- Changes to v2: * add patches for qemu driver and lxc driver, use common library APIs instead of their own hostdev APIs. * add APIs for nodedev-detach and nodedev-reattach calling. * rename functions to use unified prefix 'virHostdev' * use VIR_ONCE_GLOBAL_INIT() as others instead of previous Init and Cleanup. * use VIR_STRDUP instead of strdup * rebase to latest code v2 is here: https://www.redhat.com/archives/libvir-list/2013-June/msg00263.html Chunyan Liu (4): add hostdev passthrough common library add pci passthrough to libxl driver change qemu driver to use hostdev common library change lxc driver to use hostdev common library po/POTFILES.in | 3 +- src/Makefile.am | 3 +- src/libvirt_private.syms | 22 + src/libxl/libxl_conf.c | 65 ++ src/libxl/libxl_conf.h | 5 +- src/libxl/libxl_driver.c | 250 +++++++- src/lxc/lxc_conf.h | 4 - src/lxc/lxc_driver.c | 45 +- src/lxc/lxc_hostdev.c | 413 ------------ src/lxc/lxc_hostdev.h | 43 -- src/lxc/lxc_process.c | 21 +- src/qemu/qemu_command.c | 1 - src/qemu/qemu_conf.h | 9 +- src/qemu/qemu_driver.c | 72 +-- src/qemu/qemu_hostdev.c | 1289 ----------------------------------- src/qemu/qemu_hostdev.h | 72 -- src/qemu/qemu_hotplug.c | 127 ++-- src/qemu/qemu_process.c | 34 +- src/util/virhostdev.c | 1683 ++++++++++++++++++++++++++++++++++++++++++++++ src/util/virhostdev.h | 123 ++++ src/util/virpci.c | 21 +- src/util/virpci.h | 7 +- src/util/virscsi.c | 22 +- src/util/virscsi.h | 8 +- src/util/virusb.c | 23 +- src/util/virusb.h | 8 +- 26 files changed, 2341 insertions(+), 2032 deletions(-) delete mode 100644 src/lxc/lxc_hostdev.c delete mode 100644 src/lxc/lxc_hostdev.h delete mode 100644 src/qemu/qemu_hostdev.c delete mode 100644 src/qemu/qemu_hostdev.h create mode 100644 src/util/virhostdev.c create mode 100644 src/util/virhostdev.h

3 10

[libvirt] [PATCH] maint: fix typo for 'switch'
by Eric Blake 15 Aug '13

15 Aug '13

* src/util/virnetdevvportprofile.c: Fix typo. * src/conf/domain_conf.c: Likewise. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Pushing under the trivial rule. src/conf/domain_conf.c | 2 +- src/util/virnetdevvportprofile.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 7309877..12b68ea 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -2603,7 +2603,7 @@ virDomainDeviceInfoIterateInternal(virDomainDefPtr def, } /* This switch statement is here to trigger compiler warning when adding - * a new device type. When you are adding a new field to the swtich you + * a new device type. When you are adding a new field to the switch you * also have to add a iteration statement above. Otherwise the switch * statement has no real function here and should be optimized out by the * compiler. */ diff --git a/src/util/virnetdevvportprofile.c b/src/util/virnetdevvportprofile.c index 01ba399..07155b9 100644 --- a/src/util/virnetdevvportprofile.c +++ b/src/util/virnetdevvportprofile.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2012 Red Hat, Inc. + * Copyright (C) 2009-2013 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -1114,7 +1114,7 @@ cleanup: * @vmOp : The VM operation (i.e., create, no-op) * @setlink_only : Only set the link - dont wait for the link to come up * - * Associate a port on a swtich with a profile. This function + * Associate a port on a switch with a profile. This function * may notify a kernel driver or an external daemon to run * the setup protocol. If profile parameters were not supplied * by the user, then this function returns without doing -- 1.8.3.1

1 0

[libvirt] [PATCH 0/2] gnulib update
by Eric Blake 15 Aug '13

15 Aug '13

I'll probably push this in another 24 hours if I don't get a review (I'm not pushing it now, because I want to test it on a few more machines first...). Eric Blake (2): maint: avoid bootstrap warning maint: update gnulib submodule .gnulib | 2 +- bootstrap | 35 +++++++++++++++++------------------ bootstrap.conf | 6 ++---- 3 files changed, 20 insertions(+), 23 deletions(-) -- 1.8.3.1

1 3

[libvirt] [PATCH v3] xml: introduce startupPolicy for chardev device
by Seiji Aguchi 15 Aug '13

15 Aug '13

[Problem] Currently, guest OS's messages can be logged to a local disk of host OS by creating chadevs with options below. -chardev file,id=charserial0,path=<log file's path> -device isa-serial,chardev=chardevserial0,id=serial0 When a hardware failure happens in the disk, qemu-kvm can't create the chardevs. In this case, guest OS doesn't boot up. Actually, there are users who don't desire that guest OS goes down due to a hardware failure of a log disk only. Therefore, qemu should offer some way to boot guest OS up even if the log disk is broken. [Solution] This patch supports startupPolicy for chardev. The starupPolicy is introduced just in cases where chardev is "file" because this patch aims for making guest OS boot up when a hardware failure happens. In other cases (pty, dev, pipe and unix) it is not introduced because they don't access to hardware. The policy works as follows. - If the value is "optional", guestOS boots up by dropping the chardev. - If other values are specified, guestOS fails to boot up. (the default) Description about original startupPolicy attribute: http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=e5a84d74a278 Signed-off-by: Seiji Aguchi <seiji.aguchi(a)hds.com> Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Change from v2 - To pass "make check", add followings. - Add serial source optional testing. - check if startupPolicy is NULL in virDomainChrSourceDefParseXML(). - Add xml format of startupPolicy in virDomainChrSourceDefFormat(). Patch v2 and comment from Eric Blake - https://www.redhat.com/archives/libvir-list/2013-May/msg01814.html - https://www.redhat.com/archives/libvir-list/2013-May/msg01943.html --- docs/formatdomain.html.in | 16 ++++++++- docs/schemas/domaincommon.rng | 3 ++ src/conf/domain_conf.c | 22 +++++++++++- src/conf/domain_conf.h | 1 + src/qemu/qemu_process.c | 25 +++++++++++++- .../qemuxml2argv-serial-source-optional.args | 9 +++++ .../qemuxml2argv-serial-source-optional.xml | 35 ++++++++++++++++++++ tests/qemuxml2argvtest.c | 2 + tests/qemuxml2xmltest.c | 1 + tests/virt-aa-helper-test | 3 ++ 10 files changed, 113 insertions(+), 4 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-source-optional.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-source-optional.xml diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 7601aaa..5c9d4fb 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -4281,13 +4281,27 @@ qemu-kvm -net nic,model=? /dev/null <p> A file is opened and all data sent to the character device is written to the file. + <span class="since">Since 1.0.6</span>, it is possible to define + policy on what happens if the file is not accessible when + booting or migrating. This is done by + a <code>startupPolicy</code> attribute: </p> + <ul> + <li>If the value is "mandatory" (the default), the guest fails + to boot or migrate if the file is not found.</li> + <li>If the value is "optional", a missing file is at boot or + migration is substituted with /dev/null, so the guest still sees + the device but the host no longer tracks guest data on the device.</li> + <li>If the value is "requisite", the file is required for + booting, but optional on migration.</li> + </ul> + <pre> ... <devices> <serial type="file"> - <source path="/var/log/vm/vm-serial.log"/> + <source path="/var/log/vm/vm-serial.log" startupPolicy="optional"/> <target port="1"/> </serial> </devices> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 745b959..10b3365 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -2817,6 +2817,9 @@ </optional> <optional> <attribute name="path"/> + <optional> + <ref name="startupPolicy"/> + </optional> </optional> <optional> <attribute name="host"/> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 10cb7f6..279ff9e 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -6819,6 +6819,7 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr def, char *path = NULL; char *mode = NULL; char *protocol = NULL; + char *startupPolicy = NULL; int remaining = 0; while (cur != NULL) { @@ -6839,6 +6840,9 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr def, !(flags & VIR_DOMAIN_XML_INACTIVE))) path = virXMLPropString(cur, "path"); + if (startupPolicy == NULL && + def->type == VIR_DOMAIN_CHR_TYPE_FILE) + startupPolicy = virXMLPropString(cur, "startupPolicy"); break; case VIR_DOMAIN_CHR_TYPE_UDP: @@ -6911,6 +6915,13 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr def, def->data.file.path = path; path = NULL; + + if (startupPolicy) { + def->data.file.startupPolicy = + virDomainStartupPolicyTypeFromString(startupPolicy); + startupPolicy = NULL; + } + break; case VIR_DOMAIN_CHR_TYPE_STDIO: @@ -15014,8 +15025,15 @@ virDomainChrSourceDefFormat(virBufferPtr buf, if (def->type != VIR_DOMAIN_CHR_TYPE_PTY || (def->data.file.path && !(flags & VIR_DOMAIN_XML_INACTIVE))) { - virBufferEscapeString(buf, " <source path='%s'/>\n", - def->data.file.path); + virBufferEscapeString(buf, " <source path='%s'", + def->data.file.path); + + if (def->data.file.path && def->data.file.startupPolicy) { + const char *policy = +virDomainStartupPolicyTypeToString(def->data.file.startupPolicy); + virBufferAsprintf(buf, " startupPolicy='%s'", policy); + } + virBufferAddLit(buf, "/>\n"); } break; diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index f265966..0899556 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1102,6 +1102,7 @@ struct _virDomainChrSourceDef { /* no <source> for null, vc, stdio */ struct { char *path; + int startupPolicy; /* enum virDomainStartupPolicy */ } file; /* pty, file, pipe, or device */ struct { char *host; diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index a46d944..35d63d5 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2511,7 +2511,30 @@ qemuProcessPrepareChardevDevice(virDomainDefPtr def ATTRIBUTE_UNUSED, virReportSystemError(errno, _("Unable to pre-create chardev file '%s'"), dev->source.data.file.path); - return -1; + if (dev->source.data.file.startupPolicy != + VIR_DOMAIN_STARTUP_POLICY_OPTIONAL) { + return -1; + } + VIR_FREE(dev->source.data.file.path); + /* + * Change a destination to /dev/null to boot guest OS up + * even if a log disk is broken. + */ + VIR_WARN("Switch the destination to /dev/null"); + dev->source.data.file.path = strdup("/dev/null"); + + if (!(dev->source.data.file.path)) { + virReportOOMError(); + return -1; + } + + if ((fd = open(dev->source.data.file.path, + O_CREAT | O_APPEND, S_IRUSR|S_IWUSR)) < 0) { + virReportSystemError(errno, + _("Unable to pre-create chardev file '%s'"), + dev->source.data.file.path); + return -1; + } } VIR_FORCE_CLOSE(fd); diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-source-optional.args b/tests/qemuxml2argvdata/qemuxml2argv-serial-source-optional.args new file mode 100644 index 0000000..9ffe8de --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-source-optional.args @@ -0,0 +1,9 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu \ +-S -M \ +pc -m 214 -smp 1 -nographic -nodefconfig -nodefaults \ +-chardev socket,id=charmonitor,path=/tmp/test-monitor,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=readline \ +-no-acpi -boot c -usb -hdc /tmp/idedisk.img \ +-chardev file,id=charserial0,path=/tmp/serial.log \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-source-optional.xml b/tests/qemuxml2argvdata/qemuxml2argv-serial-source-optional.xml new file mode 100644 index 0000000..1aeb82a --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-source-optional.xml @@ -0,0 +1,35 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='file' device='disk'> + <source file='/tmp/idedisk.img'/> + <target dev='hdc' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='2'/> + </disk> + <controller type='usb' index='0'/> + <controller type='ide' index='0'/> + <controller type='pci' index='0' model='pci-root'/> + <serial type='file'> + <source path='/tmp/serial.log' startupPolicy='optional'/> + <target port='0'/> + </serial> + <console type='file'> + <source path='/tmp/serial.log' startupPolicy='optional'/> + <target type='serial' port='0'/> + </console> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 0f96eef..588c922 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -728,6 +728,8 @@ mymain(void) QEMU_CAPS_CHARDEV, QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG); DO_TEST("console-compat-chardev", QEMU_CAPS_CHARDEV, QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG); + DO_TEST("serial-source-optional", + QEMU_CAPS_CHARDEV, QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG); DO_TEST("channel-guestfwd", QEMU_CAPS_CHARDEV, QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG); diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c index 77cac3f..9faca1f 100644 --- a/tests/qemuxml2xmltest.c +++ b/tests/qemuxml2xmltest.c @@ -234,6 +234,7 @@ mymain(void) DO_TEST("console-virtio-many"); DO_TEST("channel-guestfwd"); DO_TEST("channel-virtio"); + DO_TEST("serial-source-optional"); DO_TEST("hostdev-usb-address"); DO_TEST("hostdev-pci-address"); diff --git a/tests/virt-aa-helper-test b/tests/virt-aa-helper-test index af91c61..7172fd6 100755 --- a/tests/virt-aa-helper-test +++ b/tests/virt-aa-helper-test @@ -255,6 +255,9 @@ testme "0" "disk (empty cdrom)" "-r -u $valid_uuid" "$test_xml" sed -e "s,###UUID###,$uuid,g" -e "s,###DISK###,$disk1,g" -e "s,</devices>,<serial type='file'><source path='$tmpdir/serial.log'/><target port='0'/></serial></devices>,g" "$template_xml" > "$test_xml" testme "0" "serial" "-r -u $valid_uuid" "$test_xml" +sed -e "s,###UUID###,$uuid,g" -e "s,###DISK###,$disk1,g" -e "s,</devices>,<serial type='file'><source path='$tmpdir/serial.log' startupPolicy='optional'/><target port='0'/></serial></devices>,g" "$template_xml" > "$test_xml" +testme "0" "serial" "-r -u $valid_uuid" "$test_xml" + sed -e "s,###UUID###,$uuid,g" -e "s,###DISK###,$disk1,g" -e "s,</devices>,<serial type='pty'><target port='0'/></serial></devices>,g" "$template_xml" > "$test_xml" testme "0" "serial (pty)" "-r -u $valid_uuid" "$test_xml" -- 1.7.1

3 5

[libvirt] [PATCH] libxl: unref DomainObjPrivate on error path
by Jim Fehlig 15 Aug '13

15 Aug '13

There is a potential leak of a newly created libxlDomainObjPrivate when subsequent allocation of the object's chrdev field fails. Unref the object on such an error so that it is properly disposed. --- src/libxl/libxl_driver.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index ddd7943..f09ad61 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -454,8 +454,10 @@ libxlDomainObjPrivateAlloc(void) if (!(priv = virObjectLockableNew(libxlDomainObjPrivateClass))) return NULL; - if (!(priv->devs = virChrdevAlloc())) + if (!(priv->devs = virChrdevAlloc())) { + virObjectUnref(priv); return NULL; + } return priv; } -- 1.8.1.4

2 2