search for: oloop

...pe references 'filename "/tftpboot/pxelinux.0";' to hand out pxe file 2) download a quick pxe prepared 2.88MB floppy (http://www.fdos.org/ripcord/beta8h02/images/fd288mb.zip) 3) unzip the file (ramdskNT.img,newdos288.img) 4) mount my custom working ghostbootnet.img (mount -t vfat -oloop ghostbootnet.img /mnt/floppy) 5) mount the DOS/vfat version of the 2.88MB floppy to shim in all the files from my old floppy a)Is this last step correct? b)Why does it error? (mount -t vfat -oloop newdos288.img /mnt/floppy/) c)Are their any additional steps required after the files are copied ov...

...lems with IBM DB2 10.5 server on KVM guest: [db2inst1@wc8ws-auth ~]$ time db2 create db test DB20000I The CREATE DATABASE command completed successfully. real 7m46.155s user 0m0.022s sys 0m0.027s It takes 30 seconds to create a database on an image mounted with -oloop. I think it's because db2 uses O_DIRECT to ensure consistency. I also think that O_DIRECT is not propagated to host with default cache modes in VM settings. The real problem is: when guest writes data in small blocks, host CPU becomes a bottleneck. I hava a relatively old 24-core Xeon. Host `...

...d2 and the qemu-nbd process exits, as I wish. I presume at this point that the new file has integrity. I can take the qcow2 file that belongs to the domain and serve it up via NBD: qemu-nbd --partition=1 -p11112 /path/to/my/qcow2/file.qcow2 nbd-client localhost 11112 /dev/nbd2 mount /dev/nbd2 -oloop /mnt/foo and lo! in /mnt/foo I found my root filesytem. Seems perfectly reasonable. If, however, I try to use my generated-via-NBD file, I get this: # qemu-nbd --partition=1 -p11112 $PWD/dsk.test.qcow2 & [1] 7672 # qemu-nbd: Could not find partition 1: Invalid argument [1]+ Exit 1...

...I wish. I presume at this point that the > new file has integrity. > > I can take the qcow2 file that belongs to the domain and serve it up via > NBD: > > qemu-nbd --partition=1 -p11112 /path/to/my/qcow2/file.qcow2 > nbd-client localhost 11112 /dev/nbd2 > mount /dev/nbd2 -oloop /mnt/foo > > and lo! in /mnt/foo I found my root filesytem. Seems perfectly reasonable. > > If, however, I try to use my generated-via-NBD file, I get this: > > # qemu-nbd --partition=1 -p11112 $PWD/dsk.test.qcow2 & > [1] 7672 > # qemu-nbd: Could not find partition 1:...

I am experimenting with the blockcopy command, and after figuring out how to integrate qemu-nbd, nbd-client and dumpxml/undefine/blockcopy/define/et. al. I have one remaining question: What's the point? The "replication" disk file is not, from what I can ascertain, bootable. I expect this operation to create a pristine copy of my source qcow2 file (at a given point in time)

Hi everyone, I''ve pushed out my current kernel git tree to a new branch called integration-test. This is meant for integration testing only and should not be run by anyone who doesn''t love crashes. I''ve pulled together a lot of important work from a lot of different people. It includes: The new inode number allocator Delayed inode and directory item updates Scrub,

...ile=/var/run/xenconsoled.pid root 12188 0.0 0.1 102236 10324 ? S 10:34 0:00 /usr/bin/python2.5 /usr/lib/xen-4.0/bin/xend start root 12189 0.1 0.3 242208 28696 ? SLl 10:34 0:03 \_ /usr/bin/python2.5 /usr/lib/xen-4.0/bin/xend start 6) $ sudo mount disk.img /mnt -oloop,ro $ scangzip 0 < /mnt/boot/vmlinuz-2.6.32-5-amd64 | strings | grep "^Linux " 0: found potential gzip header at offset 0x3a69 Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (dannf at debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011 gzip: stdin: de...

depends on "autoconf: regenerate configure scripts with 4.4 version" This series removes some of the really old deadwood from the tools build and makes some other things which are on their way out configurable at build time with a default depending on how far down the slope I judge them to be. * nuke in tree copy of libaio * nuke obsolete tools: xsview, miniterm, lomount & sv *