| xnox | cpaelzer, can i fake an ECKD drive with like file loop mounts? | 16:08 |
|---|---|---|
| xnox | cpaelzer, to lift raw track data... even though the underlying is just a loop mount. | 16:08 |
| xnox | in a QEMU kvm, not a z/vm | 16:08 |
| cpaelzer | xnox: ah you have a raw track image and want to load that | 16:13 |
| cpaelzer | xnox: how about dd it onto a spare dasd and providing that to the guest then? | 16:13 |
| cpaelzer | so on host dd to disk | 16:13 |
| cpaelzer | and then add the dasd to the guest | 16:13 |
| cpaelzer | that is kind of a loop mount, but with a spare dasd instead of /dev/loop | 16:13 |
| xnox | cpaelzer, i have no dasd at all. | 16:13 |
| xnox | cpaelzer, i'm in kvm, need to create a raw track data dump. somehow =) | 16:14 |
| xnox | cpaelzer, because for a z/vm cloud; i need to ship raw track data dump, not a tarball. | 16:16 |
| cpaelzer | oh "inside" kvm | 16:18 |
| cpaelzer | not on the host | 16:18 |
| cpaelzer | I actually don't know | 16:18 |
| cpaelzer | borntraeger: ^^ | 16:18 |
| cpaelzer | hca: ^^ | 16:18 |
| borntraeger | xnox, cpaelzer, not sure what you are trying to achieve. | 16:20 |
| borntraeger | what kind of system do you have and what do you want to do | 16:20 |
| cpaelzer | borntraeger: being inside a KVM guest and having a raw image of track data | 16:20 |
| cpaelzer | borntraeger: being abel to mount it | 16:20 |
| cpaelzer | that is the case xnox has if I got it right | 16:20 |
| * cpaelzer feels there is an answer of the "you should know" kind coming | 16:21 | |
| borntraeger | what raw track image is this? How was it created? | 16:21 |
| cpaelzer | xnox: what was the source ? | 16:21 |
| xnox | cpaelzer, borntraeger, for normal ubuntu cloud images, we create a empty file, kparxt connect it, create partition table, debootstrap things on it, run zipl, unmount. and that ends up being a cloud image in qcow2 format that is bootable in s390x Ubuntu Openstack. | 16:22 |
| xnox | cpaelzer, borntraeger - now, for the L1CC (original) / z/VM cloud connector / nova-zvm it needs raw track data. Thus in the past i would ssh into a z/VM | 16:23 |
| borntraeger | So its an image file for z/VM guests? | 16:24 |
| borntraeger | xnox, still do not get what kind of raw track file you have and how it was created | 16:26 |
| xnox | and then i would qemu-nbd mount this qcow2 image, dd it onto a dasd drive, re-run zipl, switch the drive into raw track access mode, package that as a file and ship it to glance | 16:26 |
| xnox | from where nova-zvm-driver takes that raw track data file, blasts it onto ECKD dasd drive to provision new z/vms | 16:26 |
| xnox | however, currently launchpad builds everything in containers, and we create qcow2 image statically. And ideally, I should be able to create a raw track data of an eckd drive, without having a physical dasd drive to mangle. | 16:27 |
| borntraeger | so you use a Linux under z/VM with the dasd driver in raw access mode to access the raw tracks after you have filled it with "normal means" | 16:27 |
| xnox | borntraeger, can nova-zvm-driver use a non-raw-track-data image? but like a regular qcow2/raw iamge? | 16:27 |
| borntraeger | xnox, I have no clue whatsoever about the z/Vm openstack driver | 16:28 |
| cpaelzer | xnox: borntraeger knows everything but likely wants to stay away from nova-zvm things :-) | 16:28 |
| xnox | borntraeger, currently yes; but ideally i do not want to =/ because my stock build environment has no dasd drives that i can abuse. | 16:28 |
| xnox | borntraeger, i'm after to qemu-img convert -> raw track data; because surely it should be possible for the linux kernel, and/or userspace construct track data, which when dd'ed onto a dasd drive in raw track mode just "magically works" | 16:29 |
| xnox | borntraeger, is there a defined data format of what raw track data is? | 16:30 |
| borntraeger | xnox, I am sure that there is some way to construct the track data out of block data | 16:30 |
| borntraeger | xnox, but I do not know | 16:30 |
| borntraeger | xnox, maybe somewhere in the zdsfs fuse tool you find information about the track format | 16:30 |
| borntraeger | xnox, s390tools/libzds/ | 16:31 |
| cpaelzer | borntraeger: do you think it would make sense to write to linux-s390 mailing list with that | 16:32 |
| cpaelzer | borntraeger: for the other devs around you to check their toolboxes if one has something that achieves that? | 16:33 |
| borntraeger | cpaelzer, yes maybe. | 16:33 |
| borntraeger | xnox, cpaelzer, wouldnt it be better if z/VM openstack would support a raw image? | 16:35 |
| cpaelzer | oh yes of course | 16:35 |
| borntraeger | the openstack thing uses xcat, which uses a Linux | 16:36 |
| xnox | borntraeger, as long as i can force zipl to create the right boot code which would be bootable off dasd.... | 16:36 |
| borntraeger | so I would assume that this is possible | 16:36 |
| borntraeger | xnox, you can force all kind of things with zipl | 16:36 |
| xnox | borntraeger, my understand was that blasting raw image onto dasd, wouldn't end up with the right bootcode. I should test it. | 16:36 |
| borntraeger | zipl.conf has targettype (e.g. CDL) | 16:37 |
| borntraeger | and targetgeometry | 16:37 |
| xnox | borntraeger, who can i talk to about image formats that the newly rewritten cloud connector supports. | 16:37 |
| borntraeger | and targetblocksize | 16:37 |
| borntraeger | xnox, no idea. its not us in Boeblingen | 16:37 |
| * xnox somehow thought that zipl for CDL ends up on stuff outside of raw image and somewhere before it in the raw track data, but i guess not. | 16:37 | |
| borntraeger | xnox, its on the first track which is smaller than the usual 4k | 16:38 |
| borntraeger | but when you write it the dasd driver ignores the additional bytes and fakes 4k | 16:38 |
| xnox | borntraeger, right but the first track is "accesible" by dd when basting things to /dev/dasda which is in non-raw mode. ack. | 16:40 |
| borntraeger | yes | 16:40 |
| xnox | cool. | 16:40 |
| borntraeger | xnox, "newly rewritten cloud connector" refers to whatever is on z/VM I guess? | 16:41 |
| borntraeger | xnox, for the kvm openstack mpavone should be able to tell you everything | 16:41 |
| xnox | borntraeger, i believe it refers to the "old xcat thing stuff to do openstack instances in z/vm" but rewritten / renamed / upgraded for newer openstack. | 16:42 |
| xnox | borntraeger, kvm openstack is all good. we ship cloud images that are usable directly - just add a config drive, and voila. | 16:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!