search for: my_vm

...nd clearly. I concluded it is impossible, but Virtual Iron support VM''s(domU) pxe boot. I am confused. If it is possible, in my opinion, it needs a boot-loader support PXE ( for example, pygrub support pxe boot - of course I know it is not support PXE currently ) Actually I want this. [my_vm] name = "my_vm" memory = 256 disk = [ ''file:/xxx/xxx/xx.img, sda1,w'' ] <== I don''t care correct or not vif=[''mac=00:16:3e:11:22:33''] root="/dev/sda1 ro" bootloader="/usr/bin/pygrub-with-pxe" boot_way = "PXE...

...nd clearly. I concluded it is impossible, but Virtual Iron support VM''s(domU) pxe boot. I am confused. If it is possible, in my opinion, it needs a boot-loader support PXE ( for example, pygrub support pxe boot - of course I know it is not support PXE currently ) Actually I want this. [my_vm] name = "my_vm" memory = 256 disk = [ ''file:/xxx/xxx/xx.img, sda1,w'' ] <== I don''t care correct or not vif=[''mac=00:16:3e:11:22:33''] root="/dev/sda1 ro" bootloader="/usr/bin/pygrub-with-pxe" boot_way = "PXE...

...true ExecStart=/bin/true ExecStop=/root/vm_migrate.sh [Install] WantedBy=multi-user.target ########## Command to migrate ############ /usr/bin/virsh migrate --verbose --p2p --tunneled --live --compressed --comp-methods "mt" --comp-mt-level 5 --comp-mt-threads 5 --comp-mt-dthreads 5 MY_VM qemu+ssh://root@$node2/system Thanks,

...king an external snapshot for the second time. A fix is released: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg06163.html I thought, why not download the source, apply the patch, build + make and then copy qemu-system-x86_64 to the /usr/bin/ folder..... But if I do 'virsh start my_vm', I get these errors: fout: internal error: early end of file from monitor, possible problem: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] qemu: could not load PC BIOS...

...lti-user.target >>> >>> >>> ########## Command to migrate ############ >>> /usr/bin/virsh migrate --verbose --p2p --tunneled --live --compressed >>> --comp-methods "mt" --comp-mt-level 5 --comp-mt-threads 5 >>> --comp-mt-dthreads 5 MY_VM qemu+ssh://root@$node2/system >> >> Does this command alone succeed? >> BTW: unless really needed --live will only make the migration take longer. >> >> I don't know enough about systemd but maybe it's not waiting for virsh >> to finish? Can you try to ge...

...gt; > >>> > >>> ########## Command to migrate ############ > >>> /usr/bin/virsh migrate --verbose --p2p --tunneled --live --compressed > >>> --comp-methods "mt" --comp-mt-level 5 --comp-mt-threads 5 > >>> --comp-mt-dthreads 5 MY_VM qemu+ssh://root@$node2/system > >> > >> Does this command alone succeed? > >> BTW: unless really needed --live will only make the migration take > longer. > >> > >> I don't know enough about systemd but maybe it's not waiting for virsh > &g...

...ss, the only way to know what happens is to run virt-v2v in debug mode (-v -x) and parse the (very extensive) output. Virt-v2v-wrapper does it for us in IMS, but it is merely a workaround. I'd expect a conversion tool to provide a comprehensive progress, such as "I'm converting VM 'my_vm' and more specifically disk X/Y (XX%). Total conversion progress is XX%". Of course, I'd also expect a machine readable output (JSON, CSV, YAML…). Debug mode ensures we have all the data in case of failure, so I don't say remove it, but simply add specialized outputs. The third ch...

On Wed, Sep 26, 2018 at 11:39 AM Richard W.M. Jones <rjones@redhat.com> wrote: > On Wed, Sep 26, 2018 at 09:57:22AM +0200, Fabien Dupont wrote: > > Hi, > > > > There has been discussion about the OpenStack output and Richard asked > for > > a public thread on this list, so here it is. > > > > For v2v from VMware to RHV, there is a Python script that

...hich we should address. I thought we had an RFE filed for this, but I cannot find it. At the moment the workaround you mention is very ugly and clunky, but AFAIK it does work. > I'd expect a conversion tool to provide a comprehensive progress, > such as "I'm converting VM 'my_vm' and more specifically disk X/Y > (XX%). Total conversion progress is XX%". Of course, I'd also expect > a machine readable output (JSON, CSV, YAML…). Debug mode ensures we > have all the data in case of failure, so I don't say remove it, but > simply add specialized ou...

...unky, but AFAIK > it does work. > You're right. I works. We'll test if the --machine-readable enhances the machine experience, and make RFEs if needed. > > I'd expect a conversion tool to provide a comprehensive progress, > > such as "I'm converting VM 'my_vm' and more specifically disk X/Y > > (XX%). Total conversion progress is XX%". Of course, I'd also expect > > a machine readable output (JSON, CSV, YAML…). Debug mode ensures we > > have all the data in case of failure, so I don't say remove it, but > > simpl...