libvirtError: internal error process exited while connecting to monitor: char device redirected to /dev/pts/13

hi.

can you post more information about your platform and how you are running nova (particularly the flags file?)

I assume you're using using the LibvirtOpenVswitchDriver?

hi.

    You are right. I deploy a single node with diablo and adopt quantum to achieve virtual network service.And quantum need openvswitch support,so I install openvswitch. When I create instance,the nova-compute.log show the information that mentioned above.
   Please help me,thank you!

are you running ubuntu, centos/RHEL, something else?

Sorry,I forget telling you that I running SUSE 11 SP2

I've never run openstack on suse, but my guess is that are are running into an issue that is similar to something I have seen on RHEL.

The current open vswitch vif-plugging mechanism creates a tap device for each VM NIC, then has libvirt use that tap using an <interface type="ethernet" device="tapX">

This works fine on Ubuntu, but some distros have things locked down a bit more, which seems to prevent libvirt from using these tap devices.

I've seen some success working around this issue on RHEL by doing some combination of the following changes to "/etc/libvirt/qemu.conf" and then restarting libvirt:

Uncomment the line:

cgroup_controllers = [ "cpu", "devices", "memory" ]

Uncomment the following lines and add the reference to "/dev/net/tun":
cgroup_device_acl = [
    "/dev/null", "/dev/full", "/dev/zero",
    "/dev/random", "/dev/urandom",
    "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
    "/dev/rtc", "/dev/hpet", "/dev/net/tun"
]

uncomment and set
clear_emulator_capabilities=0

Also change the user to run as root
user = "root"
group = "root"

That said, if you're thinking about using this in production, you will have to put some time into exploring whether these changes are something you are comfortable with, as I believe the implication is that a malicious user that finds a way to break out of the KVM isolation would have root on your box, rather than just the permissions of the libvirt user.

It may also be the case that some of these problems go away if we instead set the permissions on the tap device to correspond to the libvirt user after creating it... I'm not really sure.

If you have any luck exploring this or have suggestions on how we can change the vif-plugging to work better on SUSE, let me know.

hi,

I have no experience in libvirt + SUSE so I may not be much of help here, but I just wanted to add that one possibility might be an issue with apparmor's libvirt profile setting. If apparmor is enabled, it might be worth a look. When I tweaked around with libvirt on Ubuntu, and this type of permission error came up, it was often solved by configuring its apparmor settings(although in my case, they were not networking related). Sorry that I can't be much of assistance here. I'm also very curious to see how vif-plugging runs on non-Ubuntu systems.

The problem still exist.I modify the qemu.conf,please help me

Hi Qirui,

The two platforms that OpenStack in general and Quantum in particular are tested on are Ubuntu and RHEL. I know SUSE recently announced that they are joining OpenStack, so perhaps contacting them directly about this problem could help. We'd be happy to work with them on this.

Its worth noting that I suspect this issue can be reproduced just with libvirt itself, without openstack, so you might also try reproducing the problem with libvirt alone when asking the SUSE folks for help. Particularly, you need to be able to:

Create a tap device using (must be root):

ip tuntap add tap-001 mode tap

This will create a device tap-001.

Then start a VM with a type=ethernet interface that uses that tap device:

        <interface type='ethernet'>
            <target dev='tap-001' />
            <mac address='ca:fe:de:ad:be:ef' />
            <script path='' />
        </interface>

Hi
    I can run instance.I install OVS bridge compatibility mode by following INSTALL.bridge and create a fake bridge for each VLAN you want available.I use these command:

ovs-brcompatd --pidfile --detach
     ovs-vsctl add-br br101 br0 101

   Thank you for your help. I think my problem is that tap can not communicate with openvswitch. But your proposal is also very useful.
   I have other problem,please help me. I use command "euca-describe-availability-zones verbose"
the result is:

   AVAILABILITYZONE nova available
AVAILABILITYZONE |- linux-cma03
AVAILABILITYZONE | |- nova-volume enabled XXX 2011-11-29 02:28:30
AVAILABILITYZONE | |- nova-network enabled XXX 2011-11-29 02:28:30
AVAILABILITYZONE | |- nova-scheduler enabled XXX 2011-11-29 02:28:30
AVAILABILITYZONE | |- nova-compute enabled XXX 2011-11-29 02:28:29
AVAILABILITYZONE |- linux_cma03
AVAILABILITYZONE | |- nova-volume enabled :-) 2011-11-29 07:59:59
AVAILABILITYZONE | |- nova-network enabled :-) 2011-11-29 07:59:59
AVAILABILITYZONE | |- nova-scheduler enabled :-) 2011-11-29 07:59:59
AVAILABILITYZONE | |- nova-compute enabled :-) 2011-11-29 07:59:59

I delete the table "services" of nova database,this problem solved.

I delete information about 2011-11-29 02:28:29 of "services",and implement
command "euca-describe-availability-zones verbose":
AVAILABILITYZONE nova available
AVAILABILITYZONE |- linux_cma03
AVAILABILITYZONE | |- nova-volume enabled :-) 2011-11-30 08:42:56
AVAILABILITYZONE | |- nova-network enabled :-) 2011-11-30 08:42:56
AVAILABILITYZONE | |- nova-scheduler enabled :-) 2011-11-30 08:42:56
AVAILABILITYZONE | |- nova-compute enabled :-) 2011-11-30 08:42:56