search for: saucelabs

...ends up "converting" into a cgroup whitelist line in the LXC configuration file? (see https://wiki.archlinux.org/index.php/Linux_Containers#Host_device_access_settingsfor examples of cgroups configuration in a vanilla LXC config file). On Mon, Apr 14, 2014 at 10:44 AM, Filip Maj <fil@saucelabs.com> wrote: > So, if I remove the hostdev element related to the USB device, running > `lsusb` and `usb-devices` inside the container lists the proper device, but > I do not see the appropriate character device bus for the Android device > under /dev/bus/usb. We are not entirely sur...

...34b6157e126fbb455d8f71e0647;hb=e8684eb541f01df9b45e87e0a8ce446c7bc90a17#l334 [2] http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/lxc/lxc_controller.c;h=5ca960f13e53501315b28f9086eaa389475b8feb;hb=e8684eb541f01df9b45e87e0a8ce446c7bc90a17#l1387 On Thu, Apr 17, 2014 at 11:26 AM, Filip Maj <fil@saucelabs.com> wrote: > Ah, nevermind, think my last post may not have been entirely correct. > We've spent some more time correlating the log output from our failed LXC > startup via libvirt [1] with libvirt code from the 1.2.2 tag. > Interestingly, the error we get back is different, an...

...expecting to see the output from [1] in our logs somewhere, given the type of usb mounting we are trying to do? [1] http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/lxc/lxc_controller.c;h=c05dfec6428cad927cd5751004a4f3afc67899de;hb=HEAD#l1396 On Wed, Apr 16, 2014 at 3:58 PM, Filip Maj <fil@saucelabs.com> wrote: > To follow up on this a little bit, tail'ing kern.log while trying to get > our little container up doesn't yield anything with apparmor complaining, > so, unless I'm looking in the wrong spots for apparmor logs (which I don't > think so, as I see other...

I'm seeing this problem with both the virtio and e1000 driver with both linux and windows guests. About 5 - 10% of the VMs I launch have network problems. They seem to always get an IP from the DHCP server (dnsmasq), but afterwards either they can not make an outside network connection or they lose connectivity at a later time. Sometimes the connectivity comes back, sometimes it doesn't.

...abilities’ type=’misc’> <source> <char/dev/mydevice</char> </source> </hostdev> Although I am not sure if my card is a char device, but it really works. If I use “ hostdev mode=’subsystem’”, it will fail to expose the PCIe card. From: Filip Maj [mailto:fil@saucelabs.com] Sent: 2014年4月14日 11:26 To: WANG Cheng D Cc: libvirt-users@redhat.com Subject: RE: [libvirt-users] LXC + USB passthrough = Operation not permitted Hi Chang Weng, Thanks for answering! Could you explain why subsystem=USB does not make sense? I was simply following the documentation for USB d...

...8cc2e34b6157e126fbb455d8f71e0647;hb=e8684eb541f01df9b45e87e0a8ce446c7bc90a17#l342 [11] http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/lxc/lxc_cgroup.c;h=39d955cd8cc2e34b6157e126fbb455d8f71e0647;hb=e8684eb541f01df9b45e87e0a8ce446c7bc90a17#l446 On Wed, Apr 16, 2014 at 5:11 PM, Filip Maj <fil@saucelabs.com> wrote: > Further followups! > > We are correlating DEBUG-level output from libvirt with the libvirt 1.2.2 > code to try to figure out what libvirt is doing under the hood. > > Even though we have the log level set to 1 (info) in our libvirtd.conf, we > are not seeing t...

Yeah, AppArmor is enabled, but I put everything (that I could find) into complain mode: $ sudo apparmor_status apparmor module is loaded. 12 profiles are loaded. 3 profiles are in enforce mode. lxc-container-default lxc-container-default-with-mounting lxc-container-default-with-nesting 9 profiles are in complain mode. /sbin/dhclient /usr/bin/lxc-start

...dev/mydevice</char> > > </source> > > </hostdev> > > Although I am not sure if my card is a char device, but it really works. > > If I use “ hostdev mode=’subsystem’”, it will fail to expose the PCIe card. > > > > *From:* Filip Maj [mailto:fil@saucelabs.com] > *Sent:* 2014年4月14日 11:26 > *To:* WANG Cheng D > *Cc:* libvirt-users@redhat.com > *Subject:* RE: [libvirt-users] LXC + USB passthrough = Operation not > permitted > > > > Hi Chang Weng, > > Thanks for answering! > > Could you explain why subsystem=USB do...

Dear Fil, I am not sure if my answer can help you. I had ever asked a similar question to Daniel and I was using a thirty-party card. As a container uses a shared kernel with the host, so hostdev mode='subsystem' doesn't make sense. Maybe you can try to use hostdev mode='capabilities'. Please see http://libvirt.org/formatdomain.html#elementsHostDevCaps Hope this helps Cheng

...hing with apparmor complaining, so, unless I'm looking in the wrong spots for apparmor logs (which I don't think so, as I see other apparmor-related log entries in kern.log), I am not entirely sure this is an apparmor issue at this point. On Wed, Apr 16, 2014 at 3:25 PM, Filip Maj <fil@saucelabs.com> wrote: > Yeah, AppArmor is enabled, but I put everything (that I could find) into > complain mode: > > $ sudo apparmor_status > apparmor module is loaded. > 12 profiles are loaded. > 3 profiles are in enforce mode. > lxc-container-default > lxc-container-de...

I've seen this error a couple of times over the past month, but it's starting to happen more regularly now (perhaps since VM usage is increasing). The last few times I've seen it when trying to start a VM (virsh start domain): $ virsh start goat Connecting to uri: qemu:///system error: Failed to start domain goat error: internal error cannot parse QEMU version number in ' PC

Are there any recommendations as to how often a new connection should be made versus reused? Right now we create a new connection *every time* we hit libvirt for something. We can easily change this so that a single connection is made for a series of libvirt calls, or even so that a single connection is used for the lifetime of the running application. What are the issues to consider when making

Are there any recommendations as to how often a new connection should be made versus reused? Right now we create a new connection *every time* we hit libvirt for something. We can easily change this so that a single connection is made for a series of libvirt calls, or even so that a single connection is used for the lifetime of the running application. What are the issues to consider when making

Hello, I've started to get these in my logs every now and then: libvirtd: 18:50:29.792: warning : virEventUpdateHandleImpl:149 : Ignoring invalid update watch -1 What does it mean? Thanks! .:. jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20100429/30b2bd60/attachment.htm>

I have over 20 guests running on a particular host and the three longest running ones are missing the network device information in their XML description: <interface type='network'> <mac address='54:52:10::f2:c5'/> <source network='local'/> </interface> Compared to the others which have: <interface

Hello. I just upgraded from libvirt 0.7.0 to 0.7.5 in Ubuntu Lucid and now my application will get into a hung state. I have to kill it at which point I get the following error from the Python bindings: Traceback (most recent call last): File "/usr/local/app/vm.py", line 246, in launch vm.create() File "/usr/lib/python2.6/dist-packages/libvirt.py", line 300, in create

Hello, I'm receiving a lot of these since a couple of days ago: libvirtd: 16:30:10.960: error : qemudDispatchServer:1282 : Too many active clients (20), dropping connection I'm trying to figure out where all these active clients are coming from. I have a daemon running the interacts with libvirtd, but it only creates two long-lived connections (I'm very sure). What constitutes an

Hello, I recently upgraded to libvirt 0.8.3 and qemu 0.12.5 and I'm seeing these messages in syslog: libvirtd: 09:52:34.591: warning : virStorageBackendQEMUImgBackingFormat:623 : Unexpected exit status '1', qemu probably failed libvirtd: 09:52:34.746: warning : qemudParsePCIDeviceStrs:1422 : Unexpected exit status '1', qemu probably failed I'm not having any problems, but

Hi Chang Weng, Thanks for answering! Could you explain why subsystem=USB does not make sense? I was simply following the documentation for USB devices (right above the section you linked to). For what it's worth, I've also tried mounting the specific character device related to the appropriate android device into the container in the way you suggest, with no luck; `adb` still does not

Does the "managed" attribute of the hostdev element for a USB device make a difference? The Domain XML Format docs has the following sentence for the hostdev element: If managed is omitted or "no", and for USB devices, the user is responsible to call virNodeDeviceDettach (or virsh nodedev-dettach) before starting the guest or hot-plugging the device, and virNodeDeviceReAttach