August 2013 - openSUSE Virtual - openSUSE Mailing Lists

[opensuse-virtual] xen* update DISables `xencommons` and `xendomains` systemd services. should it?
by ar16 30 Aug '13

30 Aug '13

After each xen-libs/tools update, both `xencommons` and `xendomains` systemd services are DISabled, requiring: systemctl enable xencommons.service ln -s '/usr/lib/systemd/system/xencommons.service' '/etc/systemd/system/multi-user.target.wants/xencommons.service' systemctl enable xendomains.service ln -s '/usr/lib/systemd/system/xendomains.service' '/etc/systemd/system/multi-user.target.wants/xendomains.service' to straighten things out. Is that intentional? Are updates typically supposed to modify service state? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

3 6

[opensuse-virtual] why is usbredirection not enabled in qemu
by Rob Verduijn 23 Aug '13

23 Aug '13

Hello, Does anybody know why qemu is build without usbredirection ? I personally have build it with usbredirection and find the option to use my local usb devices in my remote vm very usefull. Just imagine what the use could be if your local usb-hub would be redirected to the virtual machine that you use as a desktop at home while you are at work via ssh or some other vpn. (or ofcourse the other way around when you need to do stuff at work that you couldn't be bothered to make the journey for :-) I've been using the usbredir with ssh encrypted tunnels for some time now, and am very happy with it. Cheers Rob -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 2

[opensuse-virtual] is there a clever way to shrink qcow2 images
by Rob Verduijn 21 Aug '13

21 Aug '13

Hello all, I'm looking for a clever way to shrink qcow2 images. what I do now is : 1 in the vm delete the files I don't need (tempfiles, spoolfiles, junkfiles, etc, etc) 2 fill the empty space with zeros dd if=/dev/zero of=bigfile bs=1024k ; sync ; rm bigfile ; sync 3 shut down the vm 4 convert the qcow2 to a fresh new qcow2 qemu-img convert -c -O qcow2 orig.qcow2 shrunk.qcow2 mv orig.qcow2 orig.qcow2.bak mv shrunk.qcow2 orig.qcow2 5 test the vm 6 delete the backup if it works Now this is fine if you got plenty space and just want to tidy up a bit before it turns bad. But what if there is no space, and adding extra partitions is not that easy. (imagine an offsite, far off location that is a real pain to get into due to serious security hassle) Or if you are me and are seriously annoyed by the cumbersome exercise above and have a gut feeling that there should be a more elegant way (preferably one without downtime) The above exercise requires to be done on all the partitions of the qcow2 image if there is more than one, adding to my irritation of the exercise. Does anybody have any ideas on a more elegant solution ? cheers Rob -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 3

Re: [opensuse-virtual] is there a clever way to shrink qcow2 images
by Rob Verduijn 20 Aug '13

20 Aug '13

oops I meant ofcourse online defragmenting filesystem like btrfs. silly me 2013/8/20 Tony Su <tonysu(a)su-networking.com>: > But as I noted you can write zeroes in blocks bigger than 1MB and as you > make your blocks bigger that last unwritten block will also get bigger and > possibly contain data which isn't compressable. > > Tony > > On Tuesday, August 20, 2013, Rob Verduijn <rob.verduijn(a)gmail.com> wrote: >> Hi, >> >> Indeed, you fill up the last blocks that are not big enough for my >> defined blocksize. >> But those blocks are very likely to be empty, also the loss of max >> 1024k - 1 of datastorage isn't really bothering me. >> >> The requirement to fill out the empty space with zeroes and then take >> down the vm to create a new qcow2 image is what bothers me. >> I wish to reclaim the empty space from a qcow2 image in a more >> efficient way, preferably without creating a new qcow2 image. >> (no downtime would be a nice bonus) >> >> Rob >> >> 2013/8/20 Tony Su <tonysu(a)su-networking.com>: >>> Haven't tried the following to zero a virtual disk, but the following >>> should >>> be fast, make the bs as big as you want (maybe 10x for very large disks). >>> Of >>> course, the bigger you make zero.big.file the longer it <might> take to >>> create zero.file. My code zeroes all bytes in 2 steps whereas yours >>> doesn't >>> zero all. >>> >>> dd if=/dev/zero of=zero.big.file bs=1024 count=102400 >>> cat /dev/zero > zero.file >>> rm zero.big.file >>> rm zero.file >>> >>> Tony >>> >>> On Aug 20, 2013 1:39 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> Using separate images for partitions makes the script a tiny bit less >>>> complex. >>>> >>>> I've already been scripting the exercise, the use off multiple >>>> partition images makes it only a tiny bit more complex. >>>> qemu-nbd simply adds another device for each additional partition. >>>> >>>> #!/binbash >>>> modprobe nbd max_part=16 #number off partitions >>>> qemu-nbd -c --nocache --aio=native /path/to/image.qcow2 >>>> mount /dev/nbd0 /mnt # I didn't partiotion the image, just >>>> formated the image as ext4 >>>> dd if=/dev/zero of=/mnt/bigfile bs=1024k; sync; rm /mnt/bigfile; rm >>>> bigfile; sync; rm /mnt/bigfile; sync >>>> sleep 2 >>>> umount /dev/nbd0 # umount the device >>>> qemu-nbd /dev/nbd0 # clean up nbd devices or they will bite you >>>> qemu-img convert -c -O qcow2 /path/to/image.qcow2 /path/to/shrunk.qcow2 >>>> mv /path/to/image.qcow2 /path/to/image.qcow2.bak >>>> mv /path/to/shrunk.qcow2 /path/to/image.qcow2 >>>> >>>> The performance of qemu-nbd is rather poor, using writeback cache is >>>> not really an option since you always need to wait for the zeroes to >>>> be actually written to the hd. >>>> Also writeback is very hazardous if you use a script to umount and >>>> disconnect the nbd device, image corruption is very likely to happen >>>> since sync doesn't apply to nbd0 devices and blockdev --flushbufs >>>> /dev/nbd0 isn't foolproof either when scripting. >>>> (ctrl-c the script at the wrong time and you are in for a recovery) >>>> >>>> So the script isn't that difficult, neither is the use of multiple >>>> partitions in an image. >>>> The biggest drawback is, downtime, filling the image with zeroes takes >>>> even longer offline than online. >>>> Ok you could have a cronjob in the vm that does that nightly, but I >>>> can imagine issues when the hd of a vm is at filled to the max at >>>> regular intervals (once a month ??), even at expected times and only >>>> for a short moment. >>>> Also that would mean the shrinking cronjob is required on the host (I >>>> want the shrinking done as soon as possible after the zeroing) >>>> This has to be timed properly with the zero cronjob of the guest, this >>>> becomes rather complex with every additional guest. >>>> >>>> Regards >>>> Rob >>>> >>>> >>>> 2013/8/19 Tony Su <tonysu(a)su-networking.com>: >>>> > Not specific to qcow >>>> > In the past if I wanted to partition files I'd deploy multiple disks >>>> > instead >>>> > of partitions. I don't knowi if there a significant overhead diff but >>>> > I >>>> > found performance did not suffer. Once on separate disks, should be >>>> > trivial >>>> > to script the procedure. >>>> > >>>> > You can execute your conversion on any storage, just as fast as >>>> > possible. >>>> > So, for instance can even be cheap temporary attached storage. >>>> > >>>> > And AFAIK has to be done offline although I suppose a fancy live >>>> > migraation >>>> > could be implemented so you're not offline. >>>> > Tony >>>> > >>>> > On Aug 19, 2013 11:50 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> >>>> > wrote: >>>> >> >>>> >> Hello all, >>>> >> >>>> >> I'm looking for a clever way to shrink qcow2 images. >>>> >> >>>> >> what I do now is : >>>> >> >>>> >> 1 in the vm delete the files I don't need (tempfiles -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

1 0

Re: [opensuse-virtual] is there a clever way to shrink qcow2 images
by Rob Verduijn 20 Aug '13

20 Aug '13

True, Bigger blocks are faster written on a disc, and if the disk is not to heavily fragmented this will save time. However you have to remember that the disk is a virtual disk image on another disc. Fragmentation on the host disk also matters. If the virtual disk image itself is fragmented on the host disk, then your speed gain is lost again with bigger block sizes. I'm not sure if experimenting for the optimal size is worth the time and effort. Maybe using an automatically defragmenting filesystem like btrfs for the host to store the images. However I have no idea what the impact is on an automatically defragmenting filesystem has on the sparse properties of the qcow2 image. Rob 2013/8/20 Tony Su <tonysu(a)su-networking.com>: > But as I noted you can write zeroes in blocks bigger than 1MB and as you > make your blocks bigger that last unwritten block will also get bigger and > possibly contain data which isn't compressable. > > Tony > > On Tuesday, August 20, 2013, Rob Verduijn <rob.verduijn(a)gmail.com> wrote: >> Hi, >> >> Indeed, you fill up the last blocks that are not big enough for my >> defined blocksize. >> But those blocks are very likely to be empty, also the loss of max >> 1024k - 1 of datastorage isn't really bothering me. >> >> The requirement to fill out the empty space with zeroes and then take >> down the vm to create a new qcow2 image is what bothers me. >> I wish to reclaim the empty space from a qcow2 image in a more >> efficient way, preferably without creating a new qcow2 image. >> (no downtime would be a nice bonus) >> >> Rob >> >> 2013/8/20 Tony Su <tonysu(a)su-networking.com>: >>> Haven't tried the following to zero a virtual disk, but the following >>> should >>> be fast, make the bs as big as you want (maybe 10x for very large disks). >>> Of >>> course, the bigger you make zero.big.file the longer it <might> take to >>> create zero.file. My code zeroes all bytes in 2 steps whereas yours >>> doesn't >>> zero all. >>> >>> dd if=/dev/zero of=zero.big.file bs=1024 count=102400 >>> cat /dev/zero > zero.file >>> rm zero.big.file >>> rm zero.file >>> >>> Tony >>> >>> On Aug 20, 2013 1:39 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> Using separate images for partitions makes the script a tiny bit less >>>> complex. >>>> >>>> I've already been scripting the exercise, the use off multiple >>>> partition images makes it only a tiny bit more complex. >>>> qemu-nbd simply adds another device for each additional partition. >>>> >>>> #!/binbash >>>> modprobe nbd max_part=16 #number off partitions >>>> qemu-nbd -c --nocache --aio=native /path/to/image.qcow2 >>>> mount /dev/nbd0 /mnt # I didn't partiotion the image, just >>>> formated the image as ext4 >>>> dd if=/dev/zero of=/mnt/bigfile bs=1024k; sync; rm /mnt/bigfile; rm >>>> bigfile; sync; rm /mnt/bigfile; sync >>>> sleep 2 >>>> umount /dev/nbd0 # umount the device >>>> qemu-nbd /dev/nbd0 # clean up nbd devices or they will bite you >>>> qemu-img convert -c -O qcow2 /path/to/image.qcow2 /path/to/shrunk.qcow2 >>>> mv /path/to/image.qcow2 /path/to/image.qcow2.bak >>>> mv /path/to/shrunk.qcow2 /path/to/image.qcow2 >>>> >>>> The performance of qemu-nbd is rather poor, using writeback cache is >>>> not really an option since you always need to wait for the zeroes to >>>> be actually written to the hd. >>>> Also writeback is very hazardous if you use a script to umount and >>>> disconnect the nbd device, image corruption is very likely to happen >>>> since sync doesn't apply to nbd0 devices and blockdev --flushbufs >>>> /dev/nbd0 isn't foolproof either when scripting. >>>> (ctrl-c the script at the wrong time and you are in for a recovery) >>>> >>>> So the script isn't that difficult, neither is the use of multiple >>>> partitions in an image. >>>> The biggest drawback is, downtime, filling the image with zeroes takes >>>> even longer offline than online. >>>> Ok you could have a cronjob in the vm that does that nightly, but I >>>> can imagine issues when the hd of a vm is at filled to the max at >>>> regular intervals (once a month ??), even at expected times and only >>>> for a short moment. >>>> Also that would mean the shrinking cronjob is required on the host (I >>>> want the shrinking done as soon as possible after the zeroing) >>>> This has to be timed properly with the zero cronjob of the guest, this >>>> becomes rather complex with every additional guest. >>>> >>>> Regards >>>> Rob >>>> >>>> >>>> 2013/8/19 Tony Su <tonysu(a)su-networking.com>: >>>> > Not specific to qcow >>>> > In the past if I wanted to partition files I'd deploy multiple disks >>>> > instead >>>> > of partitions. I don't knowi if there a significant overhead diff but >>>> > I >>>> > found performance did not suffer. Once on separate disks, should be >>>> > trivial >>>> > to script the procedure. >>>> > >>>> > You can execute your conversion on any storage, just as fast as >>>> > possible. >>>> > So, for instance can even be cheap temporary attached storage. >>>> > >>>> > And AFAIK has to be done offline although I suppose a fancy live >>>> > migraation >>>> > could be implemented so you're not offline. >>>> > Tony >>>> > >>>> > On Aug 19, 2013 11:50 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> >>>> > wrote: >>>> >> >>>> >> Hello all, >>>> >> >>>> >> I'm looking for a clever way to shrink qcow2 images. >>>> >> >>>> >> what I do now is : >>>> >> >>>> >> 1 in the vm delete the files I don't need (tempfiles -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

1 0

Re: [opensuse-virtual] is there a clever way to shrink qcow2 images
by Rob Verduijn 20 Aug '13

20 Aug '13

Hi, Indeed, you fill up the last blocks that are not big enough for my defined blocksize. But those blocks are very likely to be empty, also the loss of max 1024k - 1 of datastorage isn't really bothering me. The requirement to fill out the empty space with zeroes and then take down the vm to create a new qcow2 image is what bothers me. I wish to reclaim the empty space from a qcow2 image in a more efficient way, preferably without creating a new qcow2 image. (no downtime would be a nice bonus) Rob 2013/8/20 Tony Su <tonysu(a)su-networking.com>: > Haven't tried the following to zero a virtual disk, but the following should > be fast, make the bs as big as you want (maybe 10x for very large disks). Of > course, the bigger you make zero.big.file the longer it <might> take to > create zero.file. My code zeroes all bytes in 2 steps whereas yours doesn't > zero all. > > dd if=/dev/zero of=zero.big.file bs=1024 count=102400 > cat /dev/zero > zero.file > rm zero.big.file > rm zero.file > > Tony > > On Aug 20, 2013 1:39 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> wrote: >> >> Hi, >> >> Using separate images for partitions makes the script a tiny bit less >> complex. >> >> I've already been scripting the exercise, the use off multiple >> partition images makes it only a tiny bit more complex. >> qemu-nbd simply adds another device for each additional partition. >> >> #!/binbash >> modprobe nbd max_part=16 #number off partitions >> qemu-nbd -c --nocache --aio=native /path/to/image.qcow2 >> mount /dev/nbd0 /mnt # I didn't partiotion the image, just >> formated the image as ext4 >> dd if=/dev/zero of=/mnt/bigfile bs=1024k; sync; rm /mnt/bigfile; rm >> bigfile; sync; rm /mnt/bigfile; sync >> sleep 2 >> umount /dev/nbd0 # umount the device >> qemu-nbd /dev/nbd0 # clean up nbd devices or they will bite you >> qemu-img convert -c -O qcow2 /path/to/image.qcow2 /path/to/shrunk.qcow2 >> mv /path/to/image.qcow2 /path/to/image.qcow2.bak >> mv /path/to/shrunk.qcow2 /path/to/image.qcow2 >> >> The performance of qemu-nbd is rather poor, using writeback cache is >> not really an option since you always need to wait for the zeroes to >> be actually written to the hd. >> Also writeback is very hazardous if you use a script to umount and >> disconnect the nbd device, image corruption is very likely to happen >> since sync doesn't apply to nbd0 devices and blockdev --flushbufs >> /dev/nbd0 isn't foolproof either when scripting. >> (ctrl-c the script at the wrong time and you are in for a recovery) >> >> So the script isn't that difficult, neither is the use of multiple >> partitions in an image. >> The biggest drawback is, downtime, filling the image with zeroes takes >> even longer offline than online. >> Ok you could have a cronjob in the vm that does that nightly, but I >> can imagine issues when the hd of a vm is at filled to the max at >> regular intervals (once a month ??), even at expected times and only >> for a short moment. >> Also that would mean the shrinking cronjob is required on the host (I >> want the shrinking done as soon as possible after the zeroing) >> This has to be timed properly with the zero cronjob of the guest, this >> becomes rather complex with every additional guest. >> >> Regards >> Rob >> >> >> 2013/8/19 Tony Su <tonysu(a)su-networking.com>: >> > Not specific to qcow >> > In the past if I wanted to partition files I'd deploy multiple disks >> > instead >> > of partitions. I don't knowi if there a significant overhead diff but I >> > found performance did not suffer. Once on separate disks, should be >> > trivial >> > to script the procedure. >> > >> > You can execute your conversion on any storage, just as fast as >> > possible. >> > So, for instance can even be cheap temporary attached storage. >> > >> > And AFAIK has to be done offline although I suppose a fancy live >> > migraation >> > could be implemented so you're not offline. >> > Tony >> > >> > On Aug 19, 2013 11:50 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> wrote: >> >> >> >> Hello all, >> >> >> >> I'm looking for a clever way to shrink qcow2 images. >> >> >> >> what I do now is : >> >> >> >> 1 in the vm delete the files I don't need (tempfiles, spoolfiles, >> >> junkfiles, etc, etc) >> >> 2 fill the empty space with zeros >> >> dd if=/dev/zero of=bigfile bs=1024k ; sync ; rm bigfile ; sync >> >> 3 shut down the vm >> >> 4 convert the qcow2 to a fresh new qcow2 >> >> qemu-img convert -c -O qcow2 orig.qcow2 shrunk.qcow2 >> >> mv orig.qcow2 orig.qcow2.bak >> >> mv shrunk.qcow2 orig.qcow2 >> >> 5 test the vm >> >> 6 delete the backup if it works >> >> >> >> Now this is fine if you got plenty space and just want to tidy up a >> >> bit before it turns bad. >> >> >> >> But what if there is no space, and adding extra partitions is not that >> >> easy. >> >> (imagine an offsite, far off location that is a real pain to get into >> >> due to serious security hassle) >> >> >> >> Or if you are me and are seriously annoyed by the cumbersome exercise >> >> above and have a gut feeling that there should be a more elegant way >> >> (preferably one without downtime) >> >> >> >> The above exercise requires to be done on all the partitions of the >> >> qcow2 image if there is more than one, adding to my irritation of the >> >> exercise. >> >> >> >> Does anybody have any ideas on a more elegant solution ? >> >> >> >> cheers >> >> Rob >> >> -- >> >> To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org >> >> To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org >> >> >> > -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

1 0

Re: [opensuse-virtual] is there a clever way to shrink qcow2 images
by Rob Verduijn 20 Aug '13

20 Aug '13

Hi, Using separate images for partitions makes the script a tiny bit less complex. I've already been scripting the exercise, the use off multiple partition images makes it only a tiny bit more complex. qemu-nbd simply adds another device for each additional partition. #!/binbash modprobe nbd max_part=16 #number off partitions qemu-nbd -c --nocache --aio=native /path/to/image.qcow2 mount /dev/nbd0 /mnt # I didn't partiotion the image, just formated the image as ext4 dd if=/dev/zero of=/mnt/bigfile bs=1024k; sync; rm /mnt/bigfile; rm bigfile; sync; rm /mnt/bigfile; sync sleep 2 umount /dev/nbd0 # umount the device qemu-nbd /dev/nbd0 # clean up nbd devices or they will bite you qemu-img convert -c -O qcow2 /path/to/image.qcow2 /path/to/shrunk.qcow2 mv /path/to/image.qcow2 /path/to/image.qcow2.bak mv /path/to/shrunk.qcow2 /path/to/image.qcow2 The performance of qemu-nbd is rather poor, using writeback cache is not really an option since you always need to wait for the zeroes to be actually written to the hd. Also writeback is very hazardous if you use a script to umount and disconnect the nbd device, image corruption is very likely to happen since sync doesn't apply to nbd0 devices and blockdev --flushbufs /dev/nbd0 isn't foolproof either when scripting. (ctrl-c the script at the wrong time and you are in for a recovery) So the script isn't that difficult, neither is the use of multiple partitions in an image. The biggest drawback is, downtime, filling the image with zeroes takes even longer offline than online. Ok you could have a cronjob in the vm that does that nightly, but I can imagine issues when the hd of a vm is at filled to the max at regular intervals (once a month ??), even at expected times and only for a short moment. Also that would mean the shrinking cronjob is required on the host (I want the shrinking done as soon as possible after the zeroing) This has to be timed properly with the zero cronjob of the guest, this becomes rather complex with every additional guest. Regards Rob 2013/8/19 Tony Su <tonysu(a)su-networking.com>: > Not specific to qcow > In the past if I wanted to partition files I'd deploy multiple disks instead > of partitions. I don't knowi if there a significant overhead diff but I > found performance did not suffer. Once on separate disks, should be trivial > to script the procedure. > > You can execute your conversion on any storage, just as fast as possible. > So, for instance can even be cheap temporary attached storage. > > And AFAIK has to be done offline although I suppose a fancy live migraation > could be implemented so you're not offline. > Tony > > On Aug 19, 2013 11:50 AM, "Rob Verduijn" <rob.verduijn(a)gmail.com> wrote: >> >> Hello all, >> >> I'm looking for a clever way to shrink qcow2 images. >> >> what I do now is : >> >> 1 in the vm delete the files I don't need (tempfiles, spoolfiles, >> junkfiles, etc, etc) >> 2 fill the empty space with zeros >> dd if=/dev/zero of=bigfile bs=1024k ; sync ; rm bigfile ; sync >> 3 shut down the vm >> 4 convert the qcow2 to a fresh new qcow2 >> qemu-img convert -c -O qcow2 orig.qcow2 shrunk.qcow2 >> mv orig.qcow2 orig.qcow2.bak >> mv shrunk.qcow2 orig.qcow2 >> 5 test the vm >> 6 delete the backup if it works >> >> Now this is fine if you got plenty space and just want to tidy up a >> bit before it turns bad. >> >> But what if there is no space, and adding extra partitions is not that >> easy. >> (imagine an offsite, far off location that is a real pain to get into >> due to serious security hassle) >> >> Or if you are me and are seriously annoyed by the cumbersome exercise >> above and have a gut feeling that there should be a more elegant way >> (preferably one without downtime) >> >> The above exercise requires to be done on all the partitions of the >> qcow2 image if there is more than one, adding to my irritation of the >> exercise. >> >> Does anybody have any ideas on a more elegant solution ? >> >> cheers >> Rob >> -- >> To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org >> To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org >> > -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

1 0

[opensuse-virtual] Xen43 guest lockups under high-load (BUG: soft lockup - CPU#2 stuck) after recent Xen43 updates
by ar16 20 Aug '13

20 Aug '13

I run Opensuse 12.3 in a number of Xen VPS guests (@ Linode); Been running stable for a long time. After recent Xen client updates over the last couple of days, to rpm -qa | grep -i xen | sort ipset-kmp-xen-6.19_k3.7.10_1.1-32.1.x86_64 kernel-xen-3.7.10-1.16.1.x86_64 xen-libs-4.3.0_09-266.1.x86_64 xen-tools-domU-4.3.0_09-266.1.x86_64 xtables-addons-kmp-xen-2.3_k3.7.10_1.1-83.1.x86_64 under high-load (e.g. a src build) the client is fairly frequently, but randomly locking up. THe only notice I have is that my SSH session to the VPS simply disconnects ... no errors in the shell, or in system message. @ the attached admin Serial console I see only the sudden onest of, ... [ 484.176059] BUG: soft lockup - CPU#2 stuck for 22s! [sh:21413] [ 512.176064] BUG: soft lockup - CPU#2 stuck for 23s! [sh:21413] [ 548.176060] BUG: soft lockup - CPU#2 stuck for 22s! [sh:21413] [ 576.176074] BUG: soft lockup - CPU#2 stuck for 22s! [sh:21413] [ 604.176055] BUG: soft lockup - CPU#2 stuck for 22s! [sh:21413] [ 632.176060] BUG: soft lockup - CPU#2 stuck for 22s! [sh:21413] ... and then it just loops/repeats continuously, requiring a hard-restart of the VPS to get out of the loop, and recover. Guest boot config is unchanged, and quite simple cat /boot/grub/menu.lst default 0 timeout 1 title PVGRUB root (hd0) kernel /boot/vmlinuz-xen root=/dev/xvdc noresume xencons=hvc0 kbdtype=us text nofb selinux=0 apparmor=0 edd=off noshell showopts splash=verbose initrd /boot/initrd-xen Appears to be a frequent xen-related issue https://www.google.com/search?q=BUG+"soft+lockup"+xen with not much conclusive resolution. but since this just started with recent updates, I wanted to explore what's changed that might affect this, rather than random attempts from search. -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 1

[opensuse-virtual] "EVTCHNOP failure" @ OS 12.3 + Xen 4.3 boot for some Guests; launch manually OK
by ar16 16 Aug '13

16 Aug '13

I've recently upgraded pkgs an Opensuse 12.3 + XEN 4.3 (xen-4.3.0_08-264.1.x86_64) server. It's got two guests set for auto-launch @ boot. It's been working fine for awhile. The guest cfg's have not changed in ages. Just the upgrade has occured recently. Now, reproducibly after boot, one Guest is missing, xl list Name ID Mem VCPUs State Time(s) (null) 0 985 4 r----- 44.2 <====== Why "(null)" here? systemd? test2 2 1024 4 -b---- 13.3 but launches manually xl create /etc/xen/auto/test1.cfg xl list Name ID Mem VCPUs State Time(s) (null) 0 985 4 r----- 48.2 test2 2 1024 4 -b---- 13.8 test1 3 768 2 -b---- 2.3 and functions normally. checking xen boot logs, I find these, new failures xl dmesg ... [ OK ] Started Haveged Entropy Gathering Daemon. [ OK ] Started Restore Sound Card State. [ OK ] Started LSB: irqbalance daemon providing irq balancing on MP-machines. [ OK ] Started LSB: Framebuffer setup. [ 35.614880] Event-channel device installed. [ 35.677851] usbcore: registered new interface driver usbback [ 35.711552] pciback: backend is vpci [ 35.748410] blktap_device_init: blktap device major 252 Welcome to openSUSE 12.3 "Dartmouth" - Kernel 3.7.10-1.16-xen (xvc0). testsvr login: (XEN) [2013-08-15 01:42:22] event_channel.c:233:d0 EVTCHNOP failure: domain 2, error -22 (XEN) [2013-08-15 01:42:22] event_channel.c:233:d0 EVTCHNOP failure: domain 2, error -22 (XEN) [2013-08-15 01:42:22] event_channel.c:233:d0 EVTCHNOP failure: domain 2, error -22 (XEN) [2013-08-15 01:42:22] event_channel.c:233:d0 EVTCHNOP failure: domain 2, error -22 (XEN) [2013-08-15 01:42:22] event_channel.c:233:d0 EVTCHNOP failure: domain 2, error -22 (XEN) [2013-08-15 01:42:22] event_channel.c:233:d0 EVTCHNOP failure: domain 2, error -22 (XEN) [2013-08-15 01:42:22] event_channel.c:233:d0 EVTCHNOP failure: domain 2, error -22 (XEN) [2013-08-15 01:42:22] event_channel.c:233:d0 EVTCHNOP failure: domain 2, error -22 (XEN) [2013-08-15 01:42:22] event_channel.c:233:d0 EVTCHNOP failure: domain 2, error -22 (XEN) [2013-08-15 01:42:22] event_channel.c:233:d0 EVTCHNOP failure: domain 2, error -22 [ OK ] Started LSB: Configure network interfaces and set up routing. [ OK ] Reached target Network. Starting Command Scheduler... ... Those "event_channel.c:233:d0 EVTCHNOP failure: domain 2, error -22" errors are new to me. Looks like a XEN issue. I've seen recent work on event channel deadlock on the dev list, but my xen's logs don't mention anything evtchn-related since ~ Nov 2011. Before deciding to file a bug, I need to do some local troubleshooting. Any suggestions as to what this might be about, or specific additional info that might be enlightening? AR -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

5 41

[opensuse-virtual] What the status of lxc-opensuse ?
by Per Jessen 11 Aug '13

11 Aug '13

I'm just getting started with lxc, and tried to use the lxc-opensuse script: [big snip - download stuff etc] Scanning scripts ... Resolve dependencies ... Install symlinks in /lib/mkinitrd/setup ... Install symlinks in /lib/mkinitrd/boot ... Kernel image: /boot/vmlinuz-3.7.10-1.16-debug Initrd image: /boot/initrd-3.7.10-1.16-debug Kernel Modules: <not available> Could not find map -k/boot/System.map, please specify a correct file with -M. There was an error generating the initrd (9) [snip] Resolve dependencies ... Install symlinks in /lib/mkinitrd/setup ... Install symlinks in /lib/mkinitrd/boot ... Kernel image: /boot/vmlinuz-3.7.10-1.16-debug Initrd image: /boot/initrd-3.7.10-1.16-debug device node not found root device (/dev/cciss/c0d0p2) not found There was an error generating the initrd (1) warning: %posttrans(mkinitrd-2.7.2-3.2.1.x86_64) scriptlet failed, exit status 1 removing nis flags from /var/cache/lxc/opensuse/partial-x86_64/etc/nsswitch.conf... now finalizing build dir... warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? warning: Failed to read auxiliary vector, /proc not mounted? Download complete. Copy /var/cache/lxc/opensuse/rootfs-x86_64 to /srv/lxc/myfirstone/rootfs ... Copying rootfs to /srv/lxc/myfirstone/rootfs ... Please change root-password ! BAD PASSWORD: it is too short BAD PASSWORD: is too simple grep: /srv/lxc/myfirstone/config: No such file or directory -- Per Jessen, Zürich (18.0°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 4