June 2012 - Devel - libvirt List Archives

Re: [libvirt] [Qemu-devel] [PATCH v2 0/4] file descriptor passing using passfd
by Kevin Wolf 13 Jun '12

13 Jun '12

Am 08.06.2012 17:42, schrieb Corey Bryant: > libvirt's sVirt security driver provides SELinux MAC isolation for > Qemu guest processes and their corresponding image files. In other > words, sVirt uses SELinux to prevent a QEMU process from opening > files that do not belong to it. > > sVirt provides this support by labeling guests and resources with > security labels that are stored in file system extended attributes. > Some file systems, such as NFS, do not support the extended > attribute security namespace, and therefore cannot support sVirt > isolation. > > A solution to this problem is to provide fd passing support, where > libvirt opens files and passes file descriptors to QEMU. This, > along with SELinux policy to prevent QEMU from opening files, can > provide image file isolation for NFS files stored on the same NFS > mount. > > This patch series adds the passfd QMP monitor command, which allows > an fd to be passed via SCM_RIGHTS, and returns the received file > descriptor. Support is also added to the block layer to allow QEMU > to dup the fd when the filename is of the /dev/fd/X format. This > is useful if MAC policy prevents QEMU from opening specific types > of files. > > One nice thing about this approach is that no new SELinux policy is > required to prevent open of NFS files (files with type nfs_t). The > virt_use_nfs boolean type simply needs to be set to false, and open > will be prevented (and dup will be allowed). For example: > > # setsebool virt_use_nfs 0 > # getsebool virt_use_nfs > virt_use_nfs --> off > > Corey Bryant (4): > qapi: Convert getfd and closefd > qapi: Add passfd QMP command > osdep: Enable qemu_open to dup pre-opened fd > block: Convert open calls to qemu_open > > block/raw-posix.c | 18 +++++++++--------- > block/raw-win32.c | 4 ++-- > block/vdi.c | 5 +++-- > block/vmdk.c | 21 +++++++++------------ > block/vpc.c | 2 +- > block/vvfat.c | 21 +++++++++++---------- > hmp-commands.hx | 6 ++---- > hmp.c | 18 ++++++++++++++++++ > hmp.h | 2 ++ > monitor.c | 36 ++++++++++++++++++++---------------- > osdep.c | 13 +++++++++++++ > qapi-schema.json | 44 ++++++++++++++++++++++++++++++++++++++++++++ > qmp-commands.hx | 33 +++++++++++++++++++++++++++++---- > 13 files changed, 163 insertions(+), 60 deletions(-) Looks good to me. If Luiz is okay with the QMP part, I'm going to apply this to the block branch. Corey, please make sure to check the host_floppy problem and send a patch if necessary. Kevin

2 1

Re: [libvirt] [Qemu-devel] [PATCH v2 4/4] block: Convert open calls to qemu_open
by Kevin Wolf 13 Jun '12

13 Jun '12

Am 08.06.2012 17:42, schrieb Corey Bryant: > This patch converts all block layer open calls to qemu_open. This > enables all block layer open paths to dup(X) a pre-opened file > descriptor if the filename is of the format /dev/fd/X. This is > useful if QEMU is restricted from opening certain files. > > Note that this adds the O_CLOEXEC flag to the changed open paths > when the O_CLOEXEC macro is defined. > > v2: > -Convert calls to qemu_open instead of file_open (kwolf(a)redhat.com) > -Mention introduction of O_CLOEXEC (kwolf(a)redhat.com) > > Signed-off-by: Corey Bryant <coreyb(a)linux.vnet.ibm.com> > @@ -950,7 +950,7 @@ static int floppy_probe_device(const char *filename) > if (strstart(filename, "/dev/fd", NULL)) > prio = 50; Good to have this context here. I think this has to be removed in another patch or all our file descriptors will become host_floppy... > > - fd = open(filename, O_RDONLY | O_NONBLOCK); > + fd = qemu_open(filename, O_RDONLY | O_NONBLOCK); > if (fd < 0) { > goto out; > } Kevin

2 1

[libvirt] [PATCH 00/12] rpc: Fix several issues with keepalive messages
by Jiri Denemark 13 Jun '12

13 Jun '12

So far, we were dropping non-blocking calls whenever sending them would block. In case a client is sending lots of stream calls (which are not supposed to generate any reply), the assumption that having other calls in a queue is sufficient to get a reply from the server doesn't work. I tried to fix this in b1e374a7ac56927cfe62435179bf0bba1e08b372 but failed and reverted that commit. While working on the proper fix, I discovered several other issues we had in handling keepalive messages in client RPC code. See individual patches for more details. As a nice bonus, the fixed version is shorter by one line than the current broken version :-) Jiri Denemark (12): client rpc: Improve debug messages in virNetClientIO client rpc: Use event loop for writing client rpc: Don't drop non-blocking calls client rpc: Just queue non-blocking call if another thread has the buck client rpc: Drop unused return value of virNetClientSendNonBlock rpc: Refactor keepalive timer code rpc: Add APIs for direct triggering of keepalive timer client rpc: Separate call creation from running IO loop rpc: Do not use timer for sending keepalive responses rpc: Remove unused parameter in virKeepAliveStopInternal server rpc: Remove APIs for manipulating filters on locked client client rpc: Send keepalive requests from IO event loop src/libvirt_probes.d | 2 +- src/rpc/virkeepalive.c | 233 ++++++++++++-------------- src/rpc/virkeepalive.h | 7 +- src/rpc/virnetclient.c | 368 +++++++++++++++++++++++------------------- src/rpc/virnetserverclient.c | 127 +++++++-------- 5 files changed, 368 insertions(+), 369 deletions(-) -- 1.7.10.2

3 31

[libvirt] [PATCH] build: fix 'make dist' on virgin checkout
by Eric Blake 13 Jun '12

13 Jun '12

'make dist' was depending on *protocol-structs files, which are stored in git but in turn depended on generated files. We still want to ship the protocol-structs files, but by renaming the tests to something not matching a file name, we separate 'make check' (which depends on the generated file) from 'make dist' (which only depends on the git files). After all, the tarball should never depend on a generated file not stored in git. I found one more case of a git file depending on a generated file, in a bogus virkeycode.c listing; but at least this one had no associated rules so it never broke 'make dist'. Reported by Wen Congyang. Latent bug has been present since commit 62dee6f, but only recently exposed by commit 7bff56a. * src/Makefile.am ($(srcdir)/util/virkeycode.c): Drop useless dependency. (BUILT_SOURCES): ...and build virkeymaps.h sooner. (PROTOCOL_STRUCTS): Rather than depend on the struct file... (check-local): ...convert things into a phony target of... (check-protocol): ...a new check. ($(srcdir)/remote_protocol-struct): Rename to isolate the distributed file from the conditional test. (PDWTAGS): Deal with rename. Swap to compare 'expected actual'. --- Posting now for a review. I'm still planning on running a 'make distcheck' on a virgin repository, if that passes and correctly runs the protocol syntax checks, then I will check this in under the build-breaker rule. Or, if someone ACKs this first... src/Makefile.am | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 60f5442..2bcebcf 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -113,12 +113,12 @@ UTIL_SOURCES = \ EXTRA_DIST += $(srcdir)/util/virkeymaps.h $(srcdir)/util/keymaps.csv \ $(srcdir)/util/virkeycode-mapgen.py +BUILT_SOURCES += $(srcdir)/util/virkeymaps.h + $(srcdir)/util/virkeymaps.h: $(srcdir)/util/keymaps.csv \ $(srcdir)/util/virkeycode-mapgen.py $(AM_V_GEN)$(PYTHON) $(srcdir)/util/virkeycode-mapgen.py <$(srcdir)/util/keymaps.csv >$@ -$(srcdir)/util/virkeycode.c: $(srcdir)/util/virkeycode.h $(srcdir)/util/virkeymaps.h - EXTRA_DIST += util/threads-pthread.c util/threads-win32.c # Internal generic driver infrastructure @@ -293,7 +293,7 @@ PDWTAGS = \ -e '}' \ < $(@F)-t1 > $(@F)-t3; \ case $$? in 8) rm -f $(@F)-t?; exit 0;; 0) ;; *) exit 1;; esac;\ - diff -u $(@F)-t3 $@; st=$$?; rm -f $(@F)-t?; exit $$st; \ + diff -u $(@)s $(@F)-t3; st=$$?; rm -f $(@F)-t?; exit $$st; \ fi; \ else \ echo 'WARNING: you lack pdwtags; skipping the $@ test' >&2; \ @@ -306,21 +306,24 @@ PROTOCOL_STRUCTS = \ $(srcdir)/virnetprotocol-structs \ $(srcdir)/virkeepaliveprotocol-structs if WITH_REMOTE +check-protocol: $(PROTOCOL_STRUCTS) $(PROTOCOL_STRUCTS:structs=struct) + # The .o file that pdwtags parses is created as a side effect of running # libtool; but from make's perspective we depend on the .lo file. -$(srcdir)/%_protocol-structs: libvirt_driver_remote_la-%_protocol.lo - $(PDWTAGS) -$(srcdir)/virnetprotocol-structs: libvirt_net_rpc_la-virnetprotocol.lo +$(srcdir)/remote_protocol-struct $(srcdir)/qemu_protocol-struct: \ + $(srcdir)/%-struct: libvirt_driver_remote_la-%.lo $(PDWTAGS) -$(srcdir)/virkeepaliveprotocol-structs: libvirt_net_rpc_la-virkeepaliveprotocol.lo +$(srcdir)/virnetprotocol-struct $(srcdir)/virkeepaliveprotocol-struct: \ + $(srcdir)/%-struct: libvirt_net_rpc_la-%.lo $(PDWTAGS) else !WITH_REMOTE -# These generated files must live in git, because they cannot be re-generated -# when configured --without-remote. -$(PROTOCOL_STRUCTS): +# The $(PROTOCOL_STRUCTS) files must live in git, because they cannot be +# re-generated when configured --without-remote. +check-protocol: endif EXTRA_DIST += $(PROTOCOL_STRUCTS) -check-local: $(PROTOCOL_STRUCTS) +check-local: check-protocol +.PHONY: check-protocol $(PROTOCOL_STRUCTS:structs=struct) # Mock driver, covering domains, storage, networks, etc TEST_DRIVER_SOURCES = \ -- 1.7.10.2

1 1

[libvirt] [PATCH] virsh: Honor reedit opts printing to a function
by Michal Privoznik 13 Jun '12

13 Jun '12

When printing reedit options we make stdin raw. However, this results in stdout being raw as well. Therefore we need to return carriage when doing new line. Unfortunately, '\r' cannot be part of internationalized messages hence we must move them to formatting string which then in turn become huge and disarranged. To solve this, a new function is introduced which takes variable string arguments and prepend each with "\r\n" just before printing. --- tools/virsh.c | 25 +++++++++++++++++++++---- 1 files changed, 21 insertions(+), 4 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index 90ea43d..6840b92 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -655,6 +655,21 @@ vshReconnect(vshControl *ctl) ctl->useSnapshotOld = false; } +static void +vshPrintRaw(vshControl *ctl, ...) +{ + va_list ap; + char *key; + + va_start(ap, ctl); + while ((key = va_arg(ap, char *)) != NULL) { + vshPrint(ctl, "\r\n%s", key); + } + vshPrint(ctl, "\r\n"); + + va_end(ap); +} + /** * vshAskReedit: * @msg: Question to ask user @@ -690,10 +705,12 @@ vshAskReedit(vshControl *ctl, const char *msg) c = c_tolower(getchar()); if (c == '?') { - vshPrint(ctl, "\r\n%s", _("y - yes, start editor again\n" - "n - no, throw away my changes\n" - "f - force, try to redefine again\n" - "? - print this help\n")); + vshPrintRaw(ctl, + _("y - yes, start editor again"), + _("n - no, throw away my changes"), + _("f - force, try to redefine again"), + _("? - print this help"), + NULL); continue; } else if (c == 'y' || c == 'n' || c == 'f') { break; -- 1.7.8.5

2 1

[libvirt] [RFC] Filtering SG_IO commands using cgroups
by Paolo Bonzini 13 Jun '12

13 Jun '12

While we wait for Al's answer, it seems to me that filtering CDBs with cgroups is a pretty natural extension of filtering devices with cgroups. So here is a possible specification for such a cgroup. [CCing the libvirt mailing list since they could be one of the first clients] Paolo SG_IO Filter Controller ("cdb") 1. Description The cdb cgroup implement a way to filter allowed SCSI commands according to one or more Berkeley Packet Filter programs associated to the cgroup and its parents. BPF programs have access to the CDB and various ancillary data about the device. To be allowed, a command must be allowed by at least one program for each cgroup from the current task's to the root. In addition, as a general rule it must pass the regular check on privileged commands that is done even without cgroups. Groups with no programs are handled specially so that the default configuration is the same as without cgroups. Privileged tasks may install programs that bypass the usual check on "dangerous" SCSI commands. Non-privileged tasks in the same cgroup will also be able to bypass the check, but they may not widen their privileged abilities beyond what the cgroup already has. Administrators can replace the current entries, or add new ones. Replacing the entries in a cgroup will never affect those that are inherited from the parent. However when a parent cgroup is changed, the new filters will also apply to the children. 2. Operation The BPF program can return one of the following values: * 0: the CDB is denied. Another program in the cgroup will be tried, or the SG_IO ioctl will return with EPERM if there are none. * 1: the CDB is allowed; it should be subject to the bitmap that is used in the absence of cgroups. * 2: the CDB is allowed, and the generic filter may be bypassed. Programs that return 2 or the value of the accumulator are called privileged in the remainder of this document. BPF programs used with the cdb cgroup have access to the following ancillary values: * ANC_MAJOR (45): the major number of the device * ANC_MINOR (46): the minor number of the device * ANC_BLOCK (47): 1 if the device is a block device, 0 if it is a character device * ANC_PART (48): the partition number of the device; 0 if it is a character device * ANC_MODE (49): one of O_RDONLY/O_WRONLY/O_RDWR depending on how the file was opened. * ANC_RAWIO (50): 1 if the current process has CAP_SYS_RAWIO, 0 otherwise. Evaluation goes through all filters in each cgroup and picks the most permissive (largest) value. It also goes through all cgroups from the current task's up to the root, and executes filters in there; but here it picks the most restrictive value. In other words the result from multiple filters is "ORed", while the result from multiple cgroups is "ANDed". Cgroups with no filters are skipped, with one exception: if the current task is in a cgroup with no filters, it will behave as if it had this special filter: pseudocode: | BPF: if capable(CAP_SYS_RAWIO) | ANC RAWIO return 2 | ADD #1 else | RET A return 1 | This has two effects: 1) when a non-privileged task is moved from a privileged cgroup to a new cgroup, it will be subject to the generic filter; 2) when a task is in the root cgroup, and the root cgroup has no filters, it behaves as if the cdb cgroup did not exist at all. This maps to the following algorithm: privileged = YES allowed = YES for each cgroup C from the current task cdb cgroup to the root if no filters in C if C is the current task cdb cgroup privileged &= capable(CAP_SYS_RAWIO) continue privileged_this_cgroup = NO allowed_this_cgroup = NO for each filter F in C ret = run_filter(F, cdb) if ret != 0 then allowed_this_cgroup = YES if ret == 2 then privileged_this_cgroup = YES privileged &= privileged_this_cgroup allowed &= allowed_this_cgroup if !allowed then return EPERM if !privileged then test CDB against bitmap execute CDB (Of course some short-circuiting is possible). 3. User Interface The cgroup provides three files: * cdb.filter: entries are modified using this file. Entries are added if the file was opened with O_APPEND, otherwise they are replaced. Opening the file with O_TRUNC immediately removes all filters. These rules are chosen so that shell redirections (including ":>cdb.filter") will do the right thing. Adding or replacing programs requires CAP_SYS_ADMIN. Adding privileged programs *in addition* requires CAP_SYS_RAWIO. An entry is represented by multiple occurrences of the following structure, which must all be written with a single system call: struct bpf_insn { u16 code; u8 jt; u8 jf; u32 k; }; in the native endianness of the running architecture. A zero-length write will do nothing if the file was opened with O_APPEND, and remove all entries if it wasn't. * cdb.list: entries are retrieved using this file. All filters are preceded by a 32-bit value counting the number of bpf_insn structs in the program, and concatenated. * cdb.priv: returns 1 if the cgroup is privileged (has at least one privileged filter). This is true if at least one filter includes a "RET #2" or "RET A" instruction. 4. Security Filters that include the "RET A" or "RET #2" instructions can only be added by a task that has CAP_SYS_RAWIO; thus only tasks with CAP_SYS_RAWIO, who could bypass the bitmap themselves, can also let other processes do so. Such cgroups are marked as privileged; CAP_SYS_RAWIO is required to attach a process to a privileged cgroup. The privileged status is visible in the "cdb.priv" file. While such filters let non-privileged processes and their children bypass the bitmap, this only holds as long as the non-privileged process does none of the following operations (which by themselves require CAP_SYS_ADMIN): * replace all filters from the cgroup * create a new sub-cgroup and move itself to it Because in either case, the empty cgroup will behave as if it had "RET #1". In addition, new filters added to the cgroup will never widen the privileged abilities of the process, because filters with "RET #2" or "RET A" will not be allowed. 5. Examples of filters 5.1. Persistent reservations This filter lets a program use persistent reservations, plus any other command that is allowed without CAP_SYS_RAWIO: LD_B 0 ; A = cdb[0] JGT #0x5f, Lpass, 1f ; pass if > PR OUT 1: JGE #0x5e, Lpr, Lpass ; pass if < PR IN Lpass: RET #1 ; go to bitmap check Lpr: RET #2 ; bypass bitmap check A program could put itself in a new cgroup, add this filter and then drop CAP_SYS_RAWIO/CAP_SYS_ADMIN. 5.2. Arbitrary bitmap This filter could be used as a template to convert a 256-bit bitmap to a BPF program. LD_B 0 AND #31 TAX ; X = cdb[0] & 31 LD #1 LSH X TAX ; X = 1 << (cdb[0] & 31) LD_B 0 ; A = cdb[0] JSET #128, L1xx, L0xx ; Decode bit 7 of the opcode L0xx: JSET #64, L01x, L00x ; Decode bit 6 L1xx: JSET #64, L11x, L10x L00x: JSET #32, L001, L000 ; Decode bit 5 L01x: JSET #32, L011, L010 L10x: JSET #32, L101, L100 L11x: JSET #32, L111, L110 L000: TXA; JSET #..., Lpass, Lfail ; fill in bitmap values here L001: TXA; JSET #..., Lpass, Lfail L010: TXA; JSET #..., Lpass, Lfail L011: TXA; JSET #..., Lpass, Lfail L100: TXA; JSET #..., Lpass, Lfail L101: TXA; JSET #..., Lpass, Lfail L110: TXA; JSET #..., Lpass, Lfail L111: TXA; JSET #..., Lpass, Lfail Lpass: RET #1 ; could also be RET #2 Lfail: RET #0

1 0

[libvirt] [PATCH] build: silence gettext warning
by Eric Blake 13 Jun '12

13 Jun '12

Otherwise, 'make dist' gives multiple warnings like: libvirt.pot:20814: warning: internationalized messages should not contain the `\r' escape sequence * tools/virsh.c (vshAskReedit): Avoid \r in _(). --- Pushing under the trivial rule. tools/virsh.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index 744b629..90ea43d 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -690,10 +690,10 @@ vshAskReedit(vshControl *ctl, const char *msg) c = c_tolower(getchar()); if (c == '?') { - vshPrint(ctl, "\r\n%s", _("y - yes, start editor again\r\n" - "n - no, throw away my changes\r\n" - "f - force, try to redefine again\r\n" - "? - print this help\r\n")); + vshPrint(ctl, "\r\n%s", _("y - yes, start editor again\n" + "n - no, throw away my changes\n" + "f - force, try to redefine again\n" + "? - print this help\n")); continue; } else if (c == 'y' || c == 'n' || c == 'f') { break; -- 1.7.10.2

2 1

[libvirt] [PATCH 1/2] drop the removed module check
by Wanlong Gao 13 Jun '12

13 Jun '12

check.py has been dropped and functions moved into utils.py. Signed-off-by: Wanlong Gao <gaowanlong(a)cn.fujitsu.com> --- repos/domain/balloon_memory.py | 1 - 1 file changed, 1 deletion(-) diff --git a/repos/domain/balloon_memory.py b/repos/domain/balloon_memory.py index 5879d15..7051a0a 100644 --- a/repos/domain/balloon_memory.py +++ b/repos/domain/balloon_memory.py @@ -13,7 +13,6 @@ from libvirt import libvirtError from src import sharedmod from utils import utils -from utils import check required_params = ('guestname', 'memorypair',) optional_params = {} -- 1.7.11.rc0

2 10

[libvirt] make dist failed
by Wen Congyang 13 Jun '12

13 Jun '12

make dist failed with the following error: make[1]: Entering directory `/home/wency/source/libvirt/src' GEN rpc/virnetprotocol.h GEN rpc/virnetprotocol.c GEN rpc/virkeepaliveprotocol.h GEN rpc/virkeepaliveprotocol.c GEN remote/remote_protocol.h GEN remote/remote_protocol.c GEN remote/qemu_protocol.h GEN remote/qemu_protocol.c GEN remote/qemu_client_bodies.h GEN util/virkeymaps.h CC libvirt_driver_remote_la-remote_protocol.lo In file included from ./remote/remote_protocol.h:17, from ./remote/remote_protocol.c:7: ./internal.h:300:31: error: libvirt_probes.h: No such file or directory

3 11

Re: [libvirt] Error while installing a guest
by Pankaj Rawat 13 Jun '12

13 Jun '12

#qemu-img info /var/lib/libvirt/images/g2 image: /var/lib/libvirt/images/g2 file format: qcow2 virtual size: 8.0G (8589934592 bytes) disk size: 136K cluster_size: 65536 [root@localhost libvirt-0.9.11]# ifconfig | grep br0 br0 Link encap:Ethernet HWaddr 00:1A:4B:B9:E2:50 virbr0 Link encap:Ethernet HWaddr C6:F4:2E:7A:4C:25 I tried prompt option but it does'nt work # /usr/sbin/virt-install --accelerate --hvm --connect qemu:///system --name g3 --vcpu=1 --ram 1024 --os-type=linux --os-variant=rhel6 --network bridge:br0 --disk /var/lib/libvirt/images/g2 --disk=/opt/SL-62-x86_64-2012-02-06-Install-DVD.iso,device=cdrom,perms=ro --location=/mnt/ --nographics --serial pty --extra-args=console=ttyS0,115200n8 --keymap=en --force --prompt Starting install... Retrieving file .treeinfo... | 768 B 00:00 ... Retrieving file vmlinuz... | 7.5 MB 00:00 ... Retrieving file initrd.img... | 59 MB 00:00 ... ERROR internal error Process exited while reading console log output: Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///system start g3 otherwise, please restart your installation. On 06/12/2012 05:55 PM, Pankaj Rawat wrote: Ok I am attaching the file. Please check your guest image size by qemu-img info or ll -h, for example: qemu-img info /var/lib/libvirt/images/g2, and run 'ifconfig | grep br0' then paste output in here, thanks. In addition, you may also use interactive virt-install to install a guest with --prompt option then step by step. Regards Pankaj Rawat -----Original Message----- From: Alex Jia [mailto:a...@redhat.com] Sent: Tuesday, June 12, 2012 11:38 AM To: Pankaj Rawat Cc: libvir-list(a)redhat.com Subject: Re: [libvirt] Error while installing a guest Hi Pankaj, Could you attach your virt-install.log as an attachment? it locals in ~/.virtinst/virt-install.log. Or Is it okay if you also upgrade your python-virtinst? Thanks, Alex ----- Original Message ----- From: "Pankaj Rawat" <pankaj.ra...(a)nechclst.in> To: libvir-list(a)redhat.com Sent: Tuesday, June 12, 2012 1:56:05 PM Subject: [libvirt] Error while installing a guest Hi all , I have SL6.2 x86_64 Installed on my system I updated libvirt version from 0.9.4 to 0.9.11, I had removed previous libvirt via yum I done this by compiling the source. I started libvirt daemon created by compiling source : # ./root/libvirt_0.9.11/build/daomen/libvirtd Now I tried to create a guest:- [root@localhost libvirt-0.9.11]# /usr/sbin/virt-install --accelerate --hvm --connect qemu:///system --name g3 --vcpu=1 --ram 1024 --os-type=linux --os-variant=rhel6 --network bridge:br0 --disk /var/lib/libvirt/images/g2 --disk=/opt/SL-62-x86_64-2012-02-06-Install-DVD.iso,device=cdrom,perms=ro --location=/mnt/ --nographics --serial pty --extra-args=console=ttyS0,115200n8 --keymap=en --force The command line above normally works fine (I have created many vm by using same above command) But here Following error comes Starting install... Retrieving file .treeinfo... | 768 B 00:00 ... Retrieving file vmlinuz... | 7.5 MB 00:00 ... Retrieving file initrd.img... 100% [=====================================================] 11 MB/s | 29 MB --:-- ETA Retrieving file initrd.img... | 59 MB 00:09 ... ERROR internal error Process exited while reading console log output: Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///system start g3 otherwise, please restart your installation. at libvirtd console following output comes: 2012-06-12 13:58:55.239+0000: 17800: error : qemuProcessReadLogOutput:1298 : internal error Process exited while reading console log output: 2012-06-12 14:04:12.120+0000: 17802: warning : qemuDomainObjTaint:1227 : Domain id=3 name='g3' uuid=fec6cb5a-d4ea-d2c9-505c-611227fb4f4c is tainted: high-privileges 2012-06-12 13:58:55.239+0000: 17800: error : qemuProcessReadLogOutput:1298 : internal error Process exited while reading console lo I dont know how to resolve this . Regards Pankaj Rawat DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . ----------------------------------------------------------------------------------------------------------------------- -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . -----------------------------------------------------------------------------------------------------------------------

2 1