Hi, Petrus B. van Bork wrote: > > Had some 'tap-dance' > at the virt-manager site (which I will deal with later) Just wondering what issues you had. If the documentation to build from source isn't clear I'd like to improve it. > CloneManager.py, on my machine, as per the first link Cole, so kindly, > provided. I deleted the one line shown in red with a minus, and added > the following line, in green, with a plus (...just for the record). > This resulted in virt-clone running - but very touchy. After the change > virt-clone would still not run interactively - it would ask for a disk > and go back to the prompt and it would not run with a full string of > command line switches I'm a bit confused. I see below that just running 'virt-clone' fails (this is a bug that needs to be fixed) but a full string of cmds fails as well? I can't seem to reproduce this. > (...as illustrated in my last email and Cole's > reply). It would, however, run: > > #virt-clone -f foo.dsk > > ...at that point it would ask for several things, including the original > clone's UUID or name (...this for those trying it for the first time, > seems to need the Virtual Machine Manager running and connected to the > Xen hypervisor but, of course, with the DomU to be cloned "Shutoff"). > > When the cloning began it started with: > > libvir: Xen Daemon error : GET operation failed: > libvir: Xen Daemon error : GET operation failed: > > ...then I got - to my relief... > > Cloning from /home/xenguest/hanoverguest.dsk to KohaHanoverConf_Gold.dsk > > ...this worked...sort of...no more error messages BUT the result I ended > up with was: > > * an .sxp file that did not have a disk path to the .dsk, > * and it was missing a number of other things as well such as the > reference to localhost:5900 > * tried running "xm create" But...xm create would not run command > xm create -c /... path to UUID/config.sxp resulted in: > > Error: Errors were found at line 5 while processing > /var/lib/xend/domains/...UUID.../config.sxp: (VCPUs_live 1) - alas, this > was the 100% identical line from the config.sxp that it was lifted from > (...the running DomU). > > * virsh didn't like the .sxp either and I was not sure how to create > an xml for it to read, just don't know enough and not enough > documentation available. > After a successful virt-clone, the domain will already be defined. This means both virsh and xm know it exist. You shouldn't need to run xm create at all: just try 'virsh start cloned_vm_name' or 'xm start cloned_vm_name' and the guest should run. virsh doesn't sxp files, it uses xml. Try 'virsh dumpxml cloned_vm_name'. > At the end of the day - another day spent fruitlessly trying, trying, > trying... I am a little further than yesterday but I am no further than > I was this morning. Still completely unable to get the new cloned DomU > to run. Using #xm start <domainName> changes the status to 'running' in > Virtual Machine Manager but with 0 CPU usage and RAM usage. Does anyone > have any idea what is wrong? I am still in the dark and would still be > most grateful for any more illumination on this! > > Best, > > P. > > ------------------------------------------- > > Other Issues with virt-clone after fix, this morning: > > #virt-clone > > ...result: ERROR: A new disk image file for the cloned guest is > required, followed by a command prompt... [...no interactive > functionality available, as yet...] > As mentioned above this is definitely a bug. > #virt-clone -f testdisk.dsk > > ..result "What is the name or uuid of the original virtual machine? > [...which is the correct response but you have not fed the script a path > and will result in a config.sxp with no path for the disk!] > This is also a bug, we should put the full path in the cloned guest config. > #virt-clone -f /var/lib/xen/images/testdisk.dsk > > ...result: ERROR: Disk size must be an in or a float. > What would you like to use as the disk path? > [...problematic...can't seem to use '-f' switch, as per man syntax, > unless I have misread the man....) > I can't reproduce this. -f and --file should give the exact same result: they literally call the same functions. > #virt-clone --file /var/lib/xen/images/testdisk.dsk > > ...result: "What is the name or uuid of the original virtual machine? > > > So...my question to Cole: "Does the version from the virtual manager > site, as per your second provided link, fix the above as well? Or, not > yet?" Obviously, if the material at the repository is better/later, I > will use it, once I figure out "hg" - which is 'unknown command' on my > system, presently. > > The 'hg' command belongs to the mercurial package (intuitive, I know.) To use the upstream checkout, try this: yum install mercurial hg clone http://hg.et.redhat.com/virt/applications/virtinst--devel cd virtinst--devel ./virt-clone insert-args-here Let us know how that goes and if you are still encountering above issues I couldn't reproduce. Thanks, Cole -- Fedora-xen mailing list Fedora-xen@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-xen
