- openSUSE Virtual

[opensuse-virtual] xen - anyone using pypxeboot as bootloader?
by Per Jessen 31 Jan '14

31 Jan '14

I'm trying to set up a DomU with pypxeboot with the following: bootloader= "/usr/lib64/xen/bin/pypxeboot" bootloader_args= ['mac=11:22:33:00:01:0f'] When I do "xl create config", all I get is the usage() output from pypxeboot :-( All hints appreciated. -- Per Jessen, Zürich (-0.1°C) http://www.dns24.ch/ - your free DNS, 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

1 1

[opensuse-virtual] Issues building Xen on ARM
by Andrew Wafaa 24 Jan '14

24 Jan '14

Hi, I'm trying to package Xen for both armv7l and aarch64 architectures, and have managed to fix a couple of issues (max_cpu differes on ARM to x86 and xenalyze is x86 specific). Problem is I'm now stuck at the install stage. The current error I'm getting is: [ 597s] install -m0644 -p /home/abuild/rpmbuild/BUILD/xen-4.4.0-testing/xen/xen-syms /home/abuild/rpmbuild/BUILDROOT/xen-4.4.0_02-0.arm/boot/xen-syms-4.4.0_02-0 [ 598s] if [ -r /home/abuild/rpmbuild/BUILD/xen-4.4.0-testing/xen/xen.efi -a -n '' ]; then \ [ 598s] [ -d /home/abuild/rpmbuild/BUILDROOT/xen-4.4.0_02-0.arm ] || install -d -m0755 -p /home/abuild/rpmbuild/BUILDROOT/xen-4.4.0_02-0.arm; \ [ 598s] install -m0644 -p /home/abuild/rpmbuild/BUILD/xen-4.4.0-testing/xen/xen.efi /home/abuild/rpmbuild/BUILDROOT/xen-4.4.0_02-0.arm/xen-4.4.0_02-0.efi; \ [ 598s] ln -sf xen-4.4.0_02-0.efi /home/abuild/rpmbuild/BUILDROOT/xen-4.4.0_02-0.arm/xen-4.4.efi; \ [ 598s] ln -sf xen-4.4.0_02-0.efi /home/abuild/rpmbuild/BUILDROOT/xen-4.4.0_02-0.arm/xen-4.efi; \ [ 598s] ln -sf xen-4.4.0_02-0.efi /home/abuild/rpmbuild/BUILDROOT/xen-4.4.0_02-0.arm/xen.efi; \ [ 598s] if [ -n '/boot/efi' -a -n '' ]; then \ [ 598s] install -m0644 -p /home/abuild/rpmbuild/BUILD/xen-4.4.0-testing/xen/xen.efi /home/abuild/rpmbuild/BUILDROOT/xen-4.4.0_02-0.arm/boot/efi/efi//xen-4.4.0_02-0.efi; \ [ 598s] elif [ "/home/abuild/rpmbuild/BUILDROOT/xen-4.4.0_02-0.arm" = "/home/abuild/rpmbuild/BUILDROOT/xen-4.4.0_02-0.arm" ]; then \ [ 598s] echo 'EFI installation only partially done (EFI_VENDOR not set)' >&2; \ [ 598s] fi; \ [ 598s] fi [ 598s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/xen-4.4.0-testing/xen' [ 598s] make: Leaving directory '/home/abuild/rpmbuild/BUILD/xen-4.4.0-testing/xen' [ 598s] + install_xen [ 598s] + local ext= [ 598s] + '[' -n '' ']' [ 598s] + rm /home/abuild/rpmbuild/BUILDROOT/xen-4.4.0_02-0.arm/boot/xen-4.4.gz [ 598s] rm: cannot remove '/home/abuild/rpmbuild/BUILDROOT/xen-4.4.0_02-0.arm/boot/xen-4.4.gz': No such file or directory Looking at the spec file, the section in question has: %ifarch x86_64 %arm aarch64 make -C xen install \ %if %{?with_gcc46}0 CC=gcc-4.6 \ %endif max_phys_cpus=%{max_cpus} debug=n crash_debug=n DESTDIR=$RPM_BUILD_ROOT %{?_smp_mflags} make -C xen clean install_xen() { local ext="" if [ -n "$1" ]; then ext="-$1" mv $RPM_BUILD_ROOT/boot/xen-%{version}-%{release}.gz \ $RPM_BUILD_ROOT/boot/xen${ext}-%{version}-%{release}.gz mv $RPM_BUILD_ROOT/boot/xen-syms-%{version}-%{release} \ $RPM_BUILD_ROOT/boot/xen-syms${ext}-%{version}-%{release} fi rm $RPM_BUILD_ROOT/boot/xen-%{xvers}.gz rm $RPM_BUILD_ROOT/boot/xen-%{xvermaj}.gz rm $RPM_BUILD_ROOT/boot/xen.gz # Do not link to links; grub cannot follow. ln -s xen${ext}-%{version}-%{release}.gz $RPM_BUILD_ROOT/boot/xen${ext}-%{xvers}.gz ln -s xen${ext}-%{version}-%{release}.gz $RPM_BUILD_ROOT/boot/xen${ext}-%{xvermaj}.gz ln -s xen${ext}-%{version}-%{release}.gz $RPM_BUILD_ROOT/boot/xen${ext}.gz ln -sf xen-syms${ext}-%{version}-%{release} $RPM_BUILD_ROOT/boot/xen-syms${ext} } So the architectures are being specified, but the files don't exist. Anyone got any pointers as to what I need to do? For the full build log and to see my spec file, see my branch[0]. Many thanks, Andy 0 - https://build.opensuse.org/package/show/home:FunkyPenguin:branches:Virtuali… -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 1

Re: [opensuse-virtual] XEN on a 13.1 system
by Jim Fehlig 22 Jan '14

22 Jan '14

Charles Arnold wrote: >>>> On 1/20/2014 at 07:29 PM, in message <52DDDBA2.5000908(a)suse.com>, Jim Fehlig >>>> > <jfehlig(a)suse.com> wrote: > >> Hans Witvliet wrote: >> >>> Yes, i forgotten that xm/xend is depreceated. >>> Heard that a couple of times at several fosdems from Ian, >>> and when you mention "xm" at the xen-lists you are considered a relic >>> from a distant past.... >>> >>> >>> How ever: >>> When you do a fresh instalation of the xen-stuff in 13.1, and you try to >>> create a VM like one is used to do in previous versions, i still got a >>> warning that i had to check because "xend was not running" >>> >>> >> Charles, is there a check in {vm,virt}-install for xend running? I >> vaguely recall something along those lines, but suppose it was fixed >> long ago. >> > > Yes. vm-install does check for a running xend. This is how it knows > whether to use 'xm' to start VMs or if xend is not running it uses a > libvirt connection to start VMs. The only time vm-install uses 'xl' for > starting VMs is if xend is not running and it fails to connect to libvirt. > Failure to connect could mean libvirtd was not running or some other > error occurred when connecting to libvirtd. > BTW, I don't think we should support xl in vm-install. If vm-install cannot connect to libvirt, then it should just fail IMO. That seems to be the behavior on KVM # systemctl stop libvirtd.service # vm-install libvirt: XML-RPC error : Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory Otherwise users might be able to create VM's, which they are then unable to see or manage with virt-manager. Jim -- 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] XEN on a 13.1 system
by Hans Witvliet 22 Jan '14

22 Jan '14

Hi all, Are there any known issues with 13.1 as a DOM0 ? @work, i installed+updated a new system, added XEN-tools + XEN-kernel, enabled bridging, verified with "xm list" that all was up-and-running. But when trying to create a domU (with the yast2-module) no show. First issue was that an ubuntu-client needed hw-virtualisation (which was disabled in the bios), but after tweaking that, still no show. Next i tried sles11sp3 (thus using paravirt.) but same problem. Disabled graphic-emulation, still fails. (sorry for the briefness, no access to those systems here athome) Is there anything i should tweak on 13.1? On 12.1 and 12.2 it worked out-of-the-box... Hans -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

4 7

Re: [opensuse-virtual] XEN on a 13.1 system
by Jim Fehlig 21 Jan '14

21 Jan '14

Charles Arnold wrote: >>>> On 1/20/2014 at 07:29 PM, in message <52DDDBA2.5000908(a)suse.com>, Jim Fehlig >>>> > <jfehlig(a)suse.com> wrote: > >> Hans Witvliet wrote: >> >>> Yes, i forgotten that xm/xend is depreceated. >>> Heard that a couple of times at several fosdems from Ian, >>> and when you mention "xm" at the xen-lists you are considered a relic >>> from a distant past.... >>> >>> >>> How ever: >>> When you do a fresh instalation of the xen-stuff in 13.1, and you try to >>> create a VM like one is used to do in previous versions, i still got a >>> warning that i had to check because "xend was not running" >>> >>> >> Charles, is there a check in {vm,virt}-install for xend running? I >> vaguely recall something along those lines, but suppose it was fixed >> long ago. >> > > Yes. vm-install does check for a running xend. This is how it knows > whether to use 'xm' to start VMs or if xend is not running it uses a > libvirt connection to start VMs. The only time vm-install uses 'xl' for > starting VMs is if xend is not running and it fails to connect to libvirt. > Failure to connect could mean libvirtd was not running or some other > error occurred when connecting to libvirtd. > > For virt-install, it only uses libvirt for starting VMs. It will try to default > to a xen connection if '/var/lib/xend' and '/proc/xen' exist otherwise it > It shouldn't look for /var/lib/xend, since that directory wont exist on a system without xend. Jim > looks to see if qemu/kvm is present and connects to that. With > virt-manager, and the command line virt-install you can specify the > connection you want and that is what virt-install will use assuming the > appropriate libvirt driver was loaded. > > - Charles > > -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

3 2

[opensuse-virtual] Xen compat
by Wolfgang Rosenauer 17 Jan '14

17 Jan '14

Hi, I've noticed a few days ago that openSUSE 13.1 cannot be installed on openSUSE 11.4 Xen host. All the virtualization stuff with Xen is starting to annoy me if I need to update the host all the time. Therefore I want to look into providing my own kernel for 13.1 and try to get it run. There is a Xen compatibility setting in the kernel which apparently says in 13.1 that it should be backwards compatible down to xen 4.2. Can I simply change that value or are problems expected already before I'm going to try it? Thanks, Wolfgang -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

3 4

[opensuse-virtual] Static IP and internet access in a VM
by Sankar P 13 Jan '14

13 Jan '14

Hi, I am not sure if this is the right list but this seemed the most suitable. I am using openSUSE 13.1 and using virt-manager I created a SLES virtual machine. One of the applications that I am going to install in the VM requires static ip address and so my VM must have static ip address. In the VM Details, I have set the NIC card to be "Virtual network 'default': NAT" and inside the VM I have given a static i.p. in the yast. However, I am not able to access the internet from my VM. So, what should I do to get: 1) a static i.p. for my VM 2) with the ability to access the internet in the VM (using the host's internet connection) ? 3) Ability to ssh into the VM directly without coming into the host machine, will be good to have but not at all needed if it will complicate the setup (due to the static ip requirement) In VirtualBox, I have achieved the above by creating two network cards one with hostonly and another with Bridged networking. One will be DHCP (bridged) and will give me access to the internet and the hostonly will give me a static i.p. address for the VM. (IIRC) Is there a way to satisfy this requirement ? Google does not seem to return any helpful results for this. Any help will be appreciated. Thanks. -- Sankar P http://psankar.blogspot.com -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

4 6

[opensuse-virtual] BUG: unable to handle kernel NULL pointer dereference
by Jeroen Groenewegen van der Weyden 13 Jan '14

13 Jan '14

Hi All, Yesterday my xen machine stopped working, after a kernel panic. To me it seems to problem started at something called xen_spin_kick, I attached a screenshot of the console of the xen machine. Is this email-list the right one to address this bug? disto: openSuse 13.1 kernel 3.11.6-4-xen xen : 4.3.1_02-4.4 mfg, Jeroen

2 3

[opensuse-virtual] Question start order KVM client
by Günther J. Niederwimmer 27 Dec '13

27 Dec '13

Hello, Is it possible to define the start order for KVM Clients I found nothing in the www. Background, for my home server I like a separate Ldap, kerberos dns server, but when I start this server, the start order is always different. Ok I can clone all this on a second server, and I have no Problem with missing ldap dns usw. on start. But the nicer way is to have all this on one server ;). -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

3 2

[opensuse-virtual] After Update KVM lost his clients
by Günther J. Niederwimmer 14 Dec '13

14 Dec '13

Hello, after the update from 9-10. 12.13 I have lost all my Client in KVM. the configuration exist but virsh start xxxx is no longer working or a "virsh list" don't found the clients also in virtual-manager the client are gone ? Have any a idea why? -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

3 10

[opensuse-virtual] libvirt packaging have now requires for virtualbox ?
by Bruno Friedmann 09 Dec '13

09 Dec '13

With the new packaging of the virtual stack, libvirt now push dependencies on xen, AND virtualbox. Look like we are getting more and more stuff auto-bad-gically installed. I don't need xen, nor I don't want to have virtualbox (which ask virtualbox-qt, which then ask other things on a server) Is it possible (I didn't dig into packaging spec) to make libvirt smarter. For example if someone want only kvm virtualization he didn't get xen, lxc, virtualbox. In link with yast, there was a time you could choose on virtual system (kvm,xen). So the yast module has to bee re-aligned with new possible choices. Perhaps I've lost track on something. So my assumptions good be wrong, but I would like to hear someone about the benefit over the inconvenient. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot -- 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] QEMU 1.7 package update troubles
by Andreas Färber 08 Dec '13

08 Dec '13

Hello, Here's my status for the pending qemu package update: GitHub opensuse-1.7 branch has been updated to final v1.7.0. Manual rebasing had been necessary for DictZip (only build-tested). qemu-1.7.0.tar.bz2 is now checked in at: home:a_faerber:branches:Virtualization qemu ppc Factory build succeeded but ppc64 was in "unresolvable" state. armv7l didn't get scheduled fast enough. For x86 I'm still facing a problem with the ROM builds. I tried hacking the .spec file to skip SeaBIOS build but then it failed the same way for VGABIOS, so I reverted that again. Somehow a stray "w" ends up in "make w -C ...". Bruce, could you please investigate what is going wrong there? Maybe BdMdesigN can help enlighten us. If you do find a good solution please SR to Virtualization. I won't be at a computer 'til end of next week. For now I have left out %check make check V=1 to avoid an additional source of build failures or delays. opensuse-1.6 branch is left at v1.6.0, The v1.6.1 rebase went fully automatically, but MR for 13.1 is not yet out and with the 1.7 problems I did not want to break the patch queue of the current Virtualization package by pushing my changes. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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] libvirtd fails to start of NetworkManager is enabled
by Olaf Hering 27 Nov '13

27 Nov '13

Current libvirtd from Virtualization/libvirt fails to start because ncf_init() fails. nc__suse_config_init fails because it expects NETWORKMANAGER=no, so that "network.service" is returned to __netcontrol_enabled. netcontrol was appearently not changed since a long time. So I think for some reason libvirtd changed. Upstream git did appearently not change, netcfStateInitialize always returned some error if ncf_init() fails. What is supposed to happen with libvirt if NM is active on a 11.4 system? This used to work at least two weeks ago. Olaf -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 4

[opensuse-virtual] opensuse 13.1 DomU stalls @boot for long time; eventually completes/boots OK ?
by ar16 25 Nov '13

25 Nov '13

I've an Opensuse 13.1 DomU on a 13.1 Dom0. Both host & guest were upgraded from 12.3. The Opensuse 13.1 Xen DomU Guest is booting successfully, but taking a long time (~3 mins; up from ~20sec on 12.3). Where the delay is is clear; here's img output from "systemd-analyze plot" -> http://pbrd.co/17UxVRS which corresponds to: systemd-analyze blame 1min 222ms kmod-static-nodes.service 1min 152ms dev-mqueue.mount 1min 142ms systemd-udev-root-symlink.service 1min 141ms systemd-vconsole-setup.service 1min 140ms systemd-modules-load.service 3.715s network.service 2.242s quotad.service 2.223s autofs.service 2.201s network(a)eth0.service 1.068s nfs.service 625ms nfsserver.service 489ms systemd-udev-settle.service 319ms rsyslog.service 312ms rpcbind.service 285ms systemd-logind.service 234ms lvm2-activation-early.service 213ms systemd-tmpfiles-clean.service 174ms systemd-fsck(a)dev-xvda1.service 107ms lvm2-activation.service 104ms sshd-custom.service 80ms systemd-tmpfiles-setup-dev.service 71ms boot.mount 66ms systemd-sysctl.service 65ms systemd-remount-fs.service 58ms user(a)0.service 56ms systemd-random-seed.service 47ms systemd-udevd.service 44ms systemd-readahead-done.service 41ms systemd-user-sessions.service 38ms systemd-udev-trigger.service 38ms sys-kernel-debug.mount 35ms systemd-update-utmp.service 32ms systemd-tmpfiles-setup.service 32ms systemd-journal-flush.service 27ms systemd-update-utmp-runlevel.service 26ms var-run.mount 22ms dev-xvdb1.swap 12ms rc-local.service 12ms var-lock.mount 5ms sys-fs-fuse-connections.mount WHY, the delay is occurring, isn't clear. Here's `journalctl -xb` -> http://pastebin.com/YGjAMnaP (~ 1700 lines). @ #systemd, this is called out as a possible problem: Nov 25 10:45:31 os131guest systemd[1]: Job dev-xvc-1.device/start finished, result=timeout Nov 25 10:45:31 os131guest systemd[1]: Timed out waiting for device dev-xvc-1.device. Nov 25 10:45:31 os131guest systemd[1]: Job serial-getty(a)xvc-1.service/start finished, result=dependency The .cfg @ Dom0 that launches this Guest contains my usual: cat os131test.cfg name = 'template' builder = 'linux' bootloader = 'pygrub' bootargs = '' disk = [ 'phy:/dev/VG0/vm_os131boot,xvda,w','phy:/dev/VG0/vm_os131swap,xvdb,w','phy:/dev/VG0/vm_os131root,xvdc,w',] root = '/dev/xvdc1' extra = 'textmode=1 xencons=xvc0 noirqdebug elevator=noop' localtime = 0 on_shutdown = 'destroy' on_reboot = 'restart' on_crash = 'destroy' ... There are additional delays/stalls you can see in the log. Atm, I'm only seeing these boot-up delays on Xen Guests. Dom0 has no similar delays, neither do any non-Xen machines. So, something unique to the Guest -- whether it's Xen related, or other, not clear yet. Does anything in logs stand out? -- 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] 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

Re: [opensuse-virtual] Issues with virt-manager 0.9.5
by Michael Hill 01 Aug '13

01 Aug '13

Thanks, Tony. On Tue, Jul 16, 2013 at 6:34 PM, Tony Su <tonysu(a)su-networking.com> wrote: > - What version openSUSE are you running, and what Desktop? 13.1/Factory with GNOME Factory desktop (mostly 3.9.4). > - Is there a reason why you choose to run virt-manager 0.9.5? It's just the version I get with Factory, I guess. > - Exactly what do you mean by "import?" - Are you trying to create a > new Guest using an existing virtual disk, or something else? I'm importing the GNOME OSTree qcow2 image from here: http://build.gnome.org/ostree/buildmaster/images/z/current/ ...as described here: https://wiki.gnome.org/GnomeOSTree > - If you're trying to create a new VM, are you doing it by clicking > the "Create a new virtual machine" button top left and directly under > the "File" menu? Yes. > - Are you trying to change the disk format or just use a disk "as is?" As is, using "Import existing disk image" and "Customize configuration before install." Clicking on "Disk 1" in the customization dialogue gives the error. > Also, you should know that if you're trying to create a new VM, there > are <two> different programs, one can be launched from vm manager and > has a "pretty chrome" appearance. The other can be launched a couple > ways, one is from the Desktop, eg 'virt-manager --no-fork -c qemu:///session' to access QEMU Usermode. I imported the daily image a number of times until about a month ago (when I messed up my laptop). It can then be launched from virt-manager or GNOME Boxes. > App Launch button > System > Virtualization > Create Virtual Machines > for Xen and KVM I'll take a look at this, thanks. Mike -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

1 1