[libvirt-users] libvirt on armhf with selinux driver
by Ivan Gooten
hi,
recently i've been busy with libvirt(d) v1.2.0 on armhf and i see, even
if selinux sec driver is enabled on the configure stage, the driver is
not finally created. these configure parameters are:
--with-selinux
--with-secdriver-selinux
--with-selinux-mount=/sys/fs/selinux
the /sys/fs/selinux is valid, selinux is running in permissive mode, got
also libselinux DEV package installed, so no missing req. headers here.
when trying to run libvirtd, i'm getting:
error : virSecurityDriverLookup:78 : unsupported configuration: Security
driver selinux not enabled
error : lxcSecurityInit:1461 : Failed to initialise security drivers
error : virStateInitialize:854 : Initialisation of LXC state driver
failed: unsupported configuration: Security driver selinux not enabled
error : daemonRunStateInit:909 : Driver state initialisation failed
someone got any clue what may be causing this?
thanks,
ivan gooten
10 years, 10 months
[libvirt-users] migrate interrupted but cannot continue
by leocup
Hello,
I have 2 hosts A and B,the settings of libvirtd are
A:
Compiled against library: libvirt 0.10.2
Using library: libvirt 0.10.2
Using API: QEMU 0.10.2
Running hypervisor: QEMU 0.12.1
B:
Compiled against library: libvir 0.9.4
Using library: libvir 0.9.4
Using API: QEMU 0.9.4
Running hypervisor: QEMU 0.12.1
when I migrate a guest from A to B without storage,I used the command "virsh migrate --live --copy-storage-all --verbose vm qemu+ssh://kvm/system".The first time I succeed and I wantto to emulate the local network is down when I migrate,so I close the terminal (Xshell) when migrating, when I reconnect to the terminal ,use the migration command again,it failed.The libvirtd.log says:
error : qemuMonitorIORead:514 : Unable to read from monitor: Connection reset by peer
warning : qemuMonitorMigrateToFd:1941 : failed to close migration handle
It seems that the migration process has not finished normally and so migration cannot go on. I want to know how to resolve it. thanks.
10 years, 10 months
[libvirt-users] Canceling a live migration via virsh? (QEMU/KVM)
by Scott Sullivan
I am using QEMU/KVM, using Live Migrations like this:
virsh migrate --live ${name} qemu+ssh://${DESTINATION}/system
My question, running this command makes it hang in the foreground. Is
there a way for this to return immediately, so I can just poll for the
migration status? Also, is there a way to _cancel_ a migration? I see
the --timeout option, however if a given timeout is reached I would
rather have the ability to cancel the migration than force the suspend.
I do see there is a QEMU api migrate_cancel..eg:
virsh qemu-monitor-command ${name} --pretty '{"execute":"migrate_cancel"}'
Is that the only way to cancel a migration using libvirt?
10 years, 10 months
[libvirt-users] Ownerships of VMs and Image files
by Christoph Pleger
Hello,
I installed libvirt and qemu/kvm on a machine. I testet a little with
those and found out that all users having an account on that machine can
start every VM of every other user on the machine, in some conditions
even directly access the image file on the real host. What I would like to
have is that every user can only access the VMs and image files he or she
created himself/herself, as long as he/she does not explicitly set other
permissions. Is it possible to achieve that?
Regards
Christoph
10 years, 10 months
[libvirt-users] How to start the linux container's network interface automatically
by WANG Cheng D
Dear all,
I failed to start the linux container's network interface automatically. I have to start it manually each time after the container finishes booting.
I know that in a native fedora, if we want the network interface to start automatically, we should edit "/etc/sysconfig/network-script/ifcfg-eth0 and add the string "ONBOOT=yes".
My host is fedora 16. I used "yum --installroot=/root/fedoralxc --releasever=16 install -y openssh, bridge-utils" to setup the rootfs for my container (Laine thought that my fedora version is a little bit older, I wonder if the newer version fedora container can automatically start its network interface )
After rootfs installation, in the container's file system, there is no sub-directory named "network-scripts" in "/etc/sysconfig" . So, I created this directory manually and added a file named "ifcfg-eth0", but the container's network interface still cannot start automatically.
I tried to add files ".bash_profile" and ".bashrc" in which I added the "ifconfig" in the shell script to try to configure eth0 automatically, but it still doesn't work.
I wonder if there is a ".bashrc" for the root of a container? If there is, where should this file be located?
Any comments will be highly appreciated.
Cheng
10 years, 10 months
[libvirt-users] How to start the container's network interface automatically
by WANG Cheng D
Dear all,
I failed to start the container's network interface automatically. I have to start it manually each time after the container finishes booting.
I know that in a native fedora, if we want the network interface to start automatically, we should edit "/etc/sysconfig/network-script/ifcfg-eth0 and add the string "ONBOOT=yes".
My host is fedora. I used "yum --installroot=/root/fedoralxc --releasever=16 install -y openssh, bridge-utils" to setup the rootfs for my container
After rootfs installation, in the container's file system, there is no sub-directory named "network-scripts" in "/etc/sysconfig" . So, I created this directory manually and added a file named "ifcfg-eth0", but the container's network interface still cannot start automatically.
I tried to add files ".bash_profile" and ".bashrc" in which I added the "ifconfig" in the shell script to try to configure eth0 automatically, but it still doesn't work.
I wonder if there is a ".bashrc" for the root of a container? If there is, where should this file be located?
Any comments will be highly appreciated.
Cheng
10 years, 10 months
[libvirt-users] ANNOUNCE: Oz 0.12.0 release
by Chris Lalancette
All,
I'm pleased to announce release 0.12.0 of Oz. Oz is a program for
doing automated installation of guest operating systems with limited
input from the user. Release 0.12.0 is a bugfix and feature release
for Oz. Some of the highlights between Oz 0.11.0 and 0.12.0 are:
* Fixes to concurrent oz-install invocations
* Python 3 compatibility in the test suites
* Support for Ubuntu 12.04.3
* Support for Mageia
* Allow a MAC address to be passed in (instead of auto-generated)
* Support for RHEL5.10
* Support for Ubuntu 13.10
* Use lxml instead of libxml2 for XML document processing (it has much
better error messages)
* Remove the unused "tunnels" functionality
* Support FreeBSD 10.0
* Remove deprecated functions from the Guest class
* Speed up guest customization on guests that support NetworkManager
* Follow subprocess commands as they are executed (makes debugging easier)
* Ensure that any paths from the user are absolute, otherwise things
don't work properly
* Add support for OpenSUSE 13.1
* Add support for Fedora 20
* Add support for RHEL-7
A tarball and zipfile of this release is available on the Github
releases page: https://github.com/clalancette/oz/releases . Packages
for Fedora-19, Fedora-20, and EPEL-6 have been built in Koji and will
eventually make their way to stable. Instructions on how to get and
use Oz are available at http://github.com/clalancette/oz/wiki .
If you have questions or comments about Oz, please feel free to
contact me at clalancette at gmail.com, or open up an issue on the
github page: http://github.com/clalancette/oz/issues .
Thanks to everyone who contributed to this release through bug
reports, patches, and suggestions for improvement.
Chris Lalancette
10 years, 10 months
Re: [libvirt-users] [libvirt] [RFC] Implementing ftrace support for libvirt
by Mauricio Tavares
On Fri, Jan 3, 2014 at 6:46 AM, yuxh <yuxinghai(a)cn.fujitsu.com> wrote:
> Hi all,
>
> Happy new year!
>
> The existing trace mechanism in libvirt is dtrace. Although the dtrace
> can work, it's not work well enough. Every time we want get information
> from the trace point we must write a systemtap script and run it
> together with libvirt.
>
> That's really unpractical on some occasion, especially on production
> server since the systemtap script can't be executed automatically.
> And some problems may be not easy to reproduce, then it will cost a
> lot of time to get the trace information again.
>
> So I think it is essential to add supporting for record the trace
> information automatically in libvirt to satisfy the user's requirement.
> That's why I'm currently implementing ftrace support in libvirt.
>
> How do you think about my idea? Any comment will be appreciated!
>
How hard/painless it would be to implement it? And, can you have
both and then select which one to use?
> Thanks,
> Yu
>
> --
> libvir-list mailing list
> libvir-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
10 years, 10 months
